The business model behind web services is still in its infancy. Therefore, developers will play an important role in shaping that market. This chapter examines the business of web services, including availability, applications, and different web service providers.

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.