Columns

Lifting the fog on Web services

Web services is a hot topic. There are a plethora of conferences on the subject, and a small mountain of Web services tomes looms over the book-buying public. And, to a large degree, all of this hype is deserved. Nonetheless, there are statements about this new technology that I see repeated in the press, expressed at conferences and even written on billboards that just aren't true. In this column, I'll address the misconceptions I see as most ripe for correction.

Web services represent a technology breakthrough. The truth is that the core idea of Web services -- invoking methods in remote systems -- has been around for decades. As most commonly used today, SOAP is just another way to do RPC. Riding on HTTP is a useful idea, but not much of an innovation. The difference between SOAP and its many antecedents, including Microsoft DCOM, Java RMI and CORBA IIOP, is that every vendor has bought into it. Widespread agreement is by far the most significant innovation brought by this new protocol. Web services represent a breakthrough not in technology, but in vendor politics.

Web services are the evolution of components. The notion of a component isn't especially well defined, so it's problematic to talk about how it might evolve. Still, given that Web services provide not much that is technologically new, how can they be the evolution of anything? I often hear that Web services will enable apps to be built from components available on the Internet and internal networks. Yet this kind of app could have been built years ago (on intranets, anyway) using older technologies such as DCOM and IIOP. People didn't do it much because this approach doesn't often make sense. How many services are so valuable and hard to replicate that access to them is worth the cost of a network hop? Not many, because few apps do this today. SOAP's widespread support will make this approach easier, especially for Internet-based apps, and so I'm optimistic that we will see more widespread access to some kinds of services. Still, calling this the evolution of components is accurate only in the most abstract sense.

Web services are about to usher in a world of dynamic, rapidly changing business interconnections across the Internet. Get real. Who's going to allow their software to choose a business partner? And what is the pressing business problem this would solve? While it's not impossible that the dynamic environment envisioned by some proponents will some day emerge, it's not even on the horizon today. In fact, the killer app for Web services has appeared: EAI. EAI has always been a messy problem due, in large part, to the lack of agreement on how to communicate between different platforms and apps. SOAP's primary contribution to the world is enabling this type of agreement. Accordingly, Web services are a natural solution for this challenging but critically important area.

Sun Microsystems is a leader in Web services. Earlier this year, Sun put up a billboard on Highway 101, the main artery of Silicon Valley. The sign promoted Sun's support for Web services, announcing "Innovators are always controversial." Yet far from being an innovator, Sun was a major impediment to the adoption of SOAP. Perhaps blinded by its Microsoft hatred, Sun's Java group dragged its feet in adding Web services support to J2EE. Instead, the firm pushed ebXML as an alternative, hoping to create a viable competitor to SOAP. Fortunately, the ebXML committees adopted SOAP as their transport protocol. Yet the damage was substantial. The J2EE specs won't include support for Web services until later this year -- a delay that forced Java app server vendors such as IBM to add their own proprietary Web services interfaces in advance of the official specs. Sun has bought into Web services - it had no choice -- but despite its claims, the firm was more impediment than innovator.

New technologies are always accompanied by misunderstandings, wishful thinking and overblown claims. Web services are no different. Inevitably, however, the fog lifts and what is most useful becomes apparent. Clearing some myths from our minds can only help.

About the Author

David Chappell is principal at Chappell & Associates, an education and consulting firm focused on enterprise software technologies. He can be reached via E-mail at [email protected].