How to Become a Web Services Provider
- Searching for Practical Examples
- Web Service Availability
- Finding Web Services Applications
- Different Web Service Providers
- Preparing for the Future
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this chapter
- Searching for Practical Examples
- Web Service Availability
- Finding Web Services Applications
- Different Web Service Providers
- Preparing for the Future
This chapter addresses an aspect of Web services that is still evolving rapidly. Admittedly, the technologies surrounding Web services are not standing still. Far from it! They are being actively developed and they evolve almost daily. Still, the technical road is well mapped out.
In other words, we have a reasonably clear picture of what to expect on that front. For example, there is no doubt that XML and SOAP are the two cornerstones of Web services. However, the vision is less clear for the business model supporting Web services, and this chapter is partly about the said business model.
You see, the problem is that the technology is so new that the industry that benefits from it is still in its infancy. We lack proven examples of working business models.
The business model behind Web services is not a secondary issue, though. In fact, it is my strong belief that developers (that's you) will play a very important role in shaping that market.
Although, as I've just explained, this chapter is more tentative than the technical ones, I hope you will find food for thought as you read it. Read it, criticize it, but, most importantly, do not ignore the issues it covers.
Searching for Practical Examples
Developers have a very important role to play in the adoption of new technologies. Not only do we support the technology, but we also have to educate our organizations in how to best benefit from new developments. The business models supporting Web services are still being written as you read, and you have an important role to play in writing those business models.
Lacking a reliable crystal ball to predict the future, I will turn to past experience to help me shed some light on the future of Web service providers. I know of two markets that are close to what Web services may turn into: EDI (supported by Value-Added Networks) and ISPs (Internet Service Providers). The discussion of ISPs focuses on hosting providers, sometimes also referred to as ASPs (Application Service Providers).
A Look Down Memory Lane: EDI
If you are reading this book, I can safely assume you are familiar with ISPs and Web hosting, but you might not be so familiar with the EDI market. In Chapter 2, "The Internet and Web Services: Changing Business," you were introduced to EDI and how it compares and contrasts to XML as a messaging system. Let me take a moment to further describe the EDI market to you and to explain why it's relevant to Web providers.
EDI stands for Electronic Data Interchange. It was originally introduced more than 20 years ago, and it aimed to provide an early form of e-commerce. The exact meaning of e-commerce is lost in hype.
When thinking of e-commerce, most people think of Amazon.com or other online shops. There are more popular and older forms of e-commerce, however. Online shops cater primarily for the business-to-consumer (B2C) side of e-commerce.
The other side is business-to-business (B2B) e-commerce, or the buying, selling, and other commercial transactions that take place between businesses. B2B commerce is less well known than the consumer-oriented side, mainly because it is less visible, more abstract: We shop in various stores (online and offline) every day, but few of us really care where the stores are buying their goods.
Stores (businesses) buying goods from their suppliers (other businesses) is B2B commerce. And the surprise is that it accounts for a very large volume of activity, because behind the supplier there is another supplier, and another, and another.
Let's take an example. You have bought Java Web Services Unleashed at a bookstore. The bookstore bought the same book from a distributor. The distributor bought it from Sams. Sams had the book manufactured by a printer. To manufacture the book, the printer bought paper and ink. You get the idea.
So, for a single, consumer-orientated transaction (you buying the book), there have been several business-to-business transactions. This multiplying effect means that B2B commerce—and consequently, B2B e-commerce—is destined to outnumber consumer activity by a wide margin.
Electronic Data Interchange Concepts
Probably the oldest form of e-commerce is EDI, which is solely concerned with B2B e-commerce. The idea behind EDI is very simple: To do business, companies have to exchange enormous amounts of paperwork. Let's replace the paperwork with electronic files.
For example, if my company decides to buy goods from yours, we'll issue a purchase order. We also expect the goods to come with an invoice. To pay the invoice, we might cut a check.
Do we write these documents with a pen and paper? Unlikely—most companies use some sort of accounting software (anything from QuickBooks to SAP) that tracks orders, invoices, and payments.
Take the following test: Go to the mail department and watch as the clerks shift through the morning mail. You will find that most documents are printed by a computer (and incidentally, you'll understand why Intuit makes so much money selling checkbooks), most of them by the sender's ERP (Enterprise Resource Planning). Follow the paper trail and you'll find the same documents are being routed to...your own ERP!
So the process is to print commercial documents, send them by postal mail and key them in at the receiving end. The paperwork and all the manual processing it requires is a small annoyance for small corporations like mine, but it's a major cost for larger organizations.
More than 20 years ago, some companies realized they could simplify things by building a more direct link between the two accounting software systems. Instead of spitting out a paper purchase order, my computer produces a file. I can e-mail you the file and you can feed it straight into your accounting package. No paper or postal mail is involved, and it's better than regular e-mail because the commercial documents are automatically imported.
Some of the benefits of EDI include:
Electronic documents take less time to exchange and process.
Typing and re-typing the same document is a major cause of errors (for example, it's easy to type 10,000 instead of 100,000). Electronic documents eliminate the retyping and associated errors.
Processing electronic documents requires less human resources.
How big is EDI? According to Forrester Research, B2B e-commerce (comprising EDI and Internet transactions) is valued at $671 billion in 1998. Why don't we hear more about it? One of the reasons may be that most transactions take place on private networks, not the Internet. In fact, Internet transactions represented only $92 billion.
Most transactions taking place on private networks are not based on XML. Instead they use the EDI specific-formats, such as UN/EDIFACT and ANSI X12.
EDI and Web Services Compared
Do you see the similarities between EDI and Web services? Beyond the obvious technical differences (private networks as opposed to the Internet, obscure file formats as opposed to XML), both intend to automate and improve the flow of information between corporations.
Lacking a better frame of reference, Web service providers can learn a lot from more than 20 years of EDI experience. You'll read about some of these issues in a moment, but I also want to highlight two features that distinguish EDI from Web services:
EDI is capital-intensive.
EDI focuses on cost savings.
Setting up an EDI infrastructure is pricey, which partly explains why it is not more popular. EDI really was designed for large corporations doing business frequently. It lacks the agility of e-commerce on the Internet. In contrast, Web-based solutions, such as Web services, are more affordable and can be deployed more quickly.
EDI focuses exclusively on cost savings; its aim is to reduce the amount of paperwork so that business can be done more efficiently. However, reducing costs is only one half of its impact. It also enables new ways of doing business. For example, because an electronic order is sent and processed in minutes instead of days for its paper counterpart, it is possible to keep less inventory and re-order more frequently. This in turn frees financial resources.
Keep these differences in mind as you review the EDI experience. Despite the differences, there are two important lessons to learn from EDI:
It is crucial to document the application and, more specifically, its APIs properly. Documentation is important in any software project, but it is even more important when the project involves the IT departments of two or more companies.
This is a very important topic but, fortunately, one that is well addressed by Web services standards. Turn to Chapter 11, "WSDL," for coverage of this all-important topic.
The more partners that can join the exchange—in other words, the larger the community surrounding a Web service—the more valuable it becomes. In practice, it means that Web services should be cheap to implement and cheap to deploy. Although that may not be the case yet, past Internet experiences show that we can expect a lowering of the entry costs.