Commentary 4•01/5•01

softwaremag.commentary
eFRASTRUCTURE

Roger Sessions is CEO of ObjectWatch and one of the world's leading experts in e-commerce architectures. He has written five books, dozens of articles, and spoken at innumerable conferences. He writes and publishes the ObjectWatch Newsletter (www.objectwatch.com), a widely read and highly regarded newsletter on e-commerce architectures. His most recent book is COM+ and the Battle for the Middle Tier (John Wiley & Sons, 1999). E-mail him at roger@objectwatch.com.

Last Christmas I was in the neighborhood Wal-Mart and noticed a woman—let's call her Kate—talking on a cell phone. Kate would stop at an item, talk on her phone, and either pick up the item and put it in her shopping cart, or lose interest in the item and move on to the next item. What could she be doing?

I finally determined that Kate's husband was at the neighboring Kmart. The two had identical shopping lists and were comparing prices over their cell phones. If the item was cheaper at Kmart, her husband would buy it. If the item was cheaper at Wal-Mart, Kate would buy it. Then they would move on to the next item.

A great system, I thought, but limited. What if, for example, the item was cheaper at Toys R Us? They would never know.

If Wal-Mart, Kmart, and Toys R Us all had online catalogs of their current prices, Kate could have done her pricing in the comfort of her Web browser. This would have been an improvement in her cell-phone system, but still slow. She would have had to determine which stores she wanted to check, found the Web sites of those stores, found each item on her shopping list, and planned her travel itinerary—a time-consuming process.

Optimal Shopping Experience

A simpler solution is to have some software product—let's call it SearchIt—do this automatically. Kate simply enters her zip code, how far she is willing to drive, and her shopping list. SearchIt queries each candidate store in her radius and creates for Kate the optimal shopping experience

It seems like it should be easy to create a program like SearchIt. After all, each store has an online catalog. That online catalog allows Kate to check prices. Obviously that online catalog must have some business logic buried behind it that conducts inventory searches. If Kate can access that business logic, why can't SearchIt?

Poor SearchIt is hobbled by today's e-commerce systems, which are typically based on a tightly coupled three-tier architecture (see Figure, below). The first tier is the presentation tier, which accepts incoming HTTP requests from the browser acting on Kate's behalf. The middle tier is the business logic tier, which is what actually conducts the inventory searches. At the back end is the data tier, which stores the inventory information.

The data tier is connected to the business logic tier. And the business tier is connected to the presentation tier. The only entrance to this system, at least from the outside world, is via the presentation tier. The only requests the presentation tier understands are HTTP ones. And the only way it knows how to respond to those requests is with HTML pages. Great for Kate. Not so great for SearchIt.

The general solution to SearchIt's problem is a technology known as Web services. I define a Web service as a self-contained unit of business logic (such as inventory searching) that can be accessed programmatically over the Internet by another software system (such as SearchIt).

Web Services Architecture

Conceptually, a Web services architecture is a straightforward extension of the standard, tightly coupled three-tier architecture (see Figure, below). The architecture "merely" adds a new layer of software that accepts programmatic search requests over the Internet. This layer then translates those requests into something that the native business systems (say an inventory system) can understand, and translates the results into something that can be sent back to the requester (say SearchIt) over that very same Internet.

In the Figure, this layer of Internet-friendly software is shown as a separate Web services tier, but it could also be considered an auxiliary function of the presentation tier (which already knows all about Internet-friendly protocols). Over time, I expect the requirements of the Web services tier to expand and increase in complexity (for example, with the addition of transaction coordination, security, and data translation functionality), until eventually its unique perspective on the world will warrant a tier of its own.

One reason Web services are appealing to businesses is that they are reasonably inexpensive to implement.

One reason Web services are appealing to businesses is that they are reasonably inexpensive to implement. At least the incremental cost of implementing a Web service is reasonably inexpensive. The business logic (inventory searches) can be quite expensive to develop, but this cost has already been absorbed into the overall cost of the Web site. Once that business logic is implemented, the incremental cost of making it available as a Web service is relatively low.

Web services standards are at a very early stage. There are many groups working in this area, and the politics are, as in most standardization activities, intense.

Web Services Standards

Web services need interoperability standards in order to become generally useful. Here are some of the major standards areas with which a product like SearchIt would be concerned:

• A standard way to determine what requests a given Web service will support.
• A standard way to find all the Web services that support certain capabilities.
• A standard Internet-friendly protocol to make those requests of Web services.

Web services standards are at a very early stage. There are many groups working in this area, and the politics are, as in most standardization activities, intense. The standards that seem most likely to influence this rapidly evolving area are:

Simple Object Access Protocol (SOAP)—an Internet-friendly Web services request/response protocol (see www.w3.org/tr/soap). IBM, Microsoft, and Ariba are championing SOAP, and it seems to be widely accepted by all of the major players. It uses XML as a packaging technology and focuses on HTTP as a delivery mechanism. For more information, see www.objectwatch.com/issue_25.htm.

Web Service Description Language (WSDL)—for describing the requests that a Web service will accept. IBM and Microsoft champion WSDL. For the WSDL 1.0 specification, see www-106.ibm.com/developerworks/library/w-wsdl.html. For more information on WSDL, see www.objectwatch.com/issue_31.htm.

Universal Description, Discovery, and Integration (UDDI)—for registration of Web services. The uddi.org consortium champions this. For more information on UDDI, see www.objectwatch.com/issue_31.htm.

Electronic Business XML (ebXML)—for process-to-process cooperation. It is similar in some ways to SOAP, but tries to address more complex issues that become important when business processes try to cooperate, such as transaction coordination and security. A consortium working with the United Nations and OASIS controls ebXML. It is primarily championed by Sun. For more information, see ebXML Technical Architecture Specification, Version 1.04(www.ebxml.org/specdrafts/approved_specs.htm).

It's too early to know which companies will be the movers and shakers in Web services.

The Players

It's too early to know which companies will be the movers and shakers in Web services. My best guess is that four companies will largely dominate the industry: HP, IBM, Microsoft, and Sun.

HP's Web services offering is e-Speak, which started life in 1995 as a research project. The architecture is based on SOAP, and it is intended to be a superset of UDDI. HP differentiates e-Speak by open-sourcing it, encouraging the greater development community to make enhancements. HP will then sell an industrial-grade version with full product support, much like Red Hat tried (and failed) to make money on Linux.

IBM's Web services offering is WebSphere, whose lineage goes back to 1992 when IBM released its System Object Model (SOM). IBM's defining vision is of Web services being built on a completely standard API, with few, if any, vendor-specific features. This API includes the Java programming language, Java class libraries, the Enterprise JavaBeans (EJB) middle-tier infrastructure, and the Linux operating system. IBM believes that all relevant standards should be turned over to independent standards bodies and is quite miffed with Sun for both its unwillingness to give up control of the Java platform and its use of a proprietary operating system. IBM is working closely with Microsoft in both the SOAP and UDDI activities.

Microsoft's Web services offering is .Net, which goes back to 1996 when Microsoft started the component-oriented middleware movement with Microsoft Transaction Server (MTS). Microsoft also has a product called BizTalk, the forerunner to ebXML. Microsoft believes that Web services standards should be concerned only with interoperability (as is SOAP) and not portability (as is EJB). Microsoft is differentiating its Web services platform as one that offers mainframe reliability at WinTel commodity prices. Microsoft is also the only vendor not on the Java bandwagon. It believes that languages and platforms should be independent, and that organizations should be able to implement Web services in any number of programming languages. Along with IBM and Ariba, Microsoft is one of the leaders in the SOAP and UDDI movement. So far, Microsoft has shown little interest in ebXML.

Sun recently announced its Sun ONE platform, a product with few details available as of press time. Sun is clearly trying to leverage its leadership position in the Java movement, promising a Web services architecture built on an EJB middle-tier infrastructure. This is similar to the other Java-centric Web services platforms (including IBM's). Sun differentiates its Web services platform with the idea of "smart services," an as-yet-undisclosed technology that would allow unrelated Web services to share background information, such as the credit-card number of the human being (Kate) behind the browser. From a standards perspective, Sun acknowledges the importance of both SOAP and UDDI, but has taken a leadership role defining ebXML.

There are other companies that might get involved in Web services. BEA, for example, is a strong player in the middle-tier space, and therefore should be a natural player in Web services. To date, however, BEA has been uncharacteristically silent about its Web services vision. Oracle could also make a splash if it moves quickly to claim some territory.

At this point, IBM and Microsoft are the leading contenders to dominate the Web services space. Both have compelling products, a large customer base, and a well-articulated vision. And, although there are plenty of issues on which IBM and Microsoft differ, they do agree on the all-important details of how Web services should interoperate. Between them they already own a majority of the middle-tier/Web services space, so any interoperability protocols on which they both agree will rapidly become the de facto standards for the whole industry.

Sun and HP are likely to have less impact. Sun is a relative newcomer with no current products and a minimally articulated vision. It is also in the unenviable (and probably unprecedented) position of being at odds with both IBM and Microsoft. HP will likely attract a small cult following based on its embrace of the open-source movement, but this in itself is not enough of a defining vision to make it a major player. Whatever BEA and Oracle eventually come up with, it is probably going to be too little too late.

Commerce over the Web is obviously here. The next frontier is Web-based collaboration. The evolving vision of commerce on the Web is of a network of cooperating Web services. All this just to make it possible for Kate to buy items at the lowest possible cost. And to let her and her husband throw away their cell phones, and spend some quality time at home together!

For more information on this topic in the future, register Here.