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.
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 firstname.lastname@example.org.