Submitted by Nick Gall, VP Gartner
Web Services based on SOAP and WSDL are "Web" in name only. In fact, they are a hostile overlay of the Web based on traditional enterprise middleware architectural styles that has fallen far short of expectations over the past decade.
The W3C should leave the work on standardizing the WS-* middleware
architecture to the middleware vendors and shift its focus to standardizing
aspects of Web architecture that make it easier to apply to "application to
application" scenarios.
The typical use case for enterprise middleware is to create applications with little emphasis on either a shared information model or process model across multiple applications (ie stovepipes). Middleware is then used to retrofit some degree of integration between applications (aka application to application or A2A integration), usually by wrappering existing applications with APIs that are often defined on an application by application basis (ie point to point integration).
Web architecture replaces the "application" concepts of "client" and
"server" with the concepts of "agent" and "resource". Agents interact with
resources to create, access, modify, and delete resources. Until recently,
the major emphasis was on standardizing the interaction between user agents,
especially browsers, and resources. Now the emphasis should be on "resource
agents": the relationship between resources where one resource acts as an
agent to another resource, but is itself a resource that other agents access.
This is the closest parallel to A2A integration in Web architecture. It is
what is really going on architecturally when we speak of "mashups". The goal
of the W3C should be to clarify, and if necessary extend the architecture of
the Web to treat "resource agents" (a completely automated agent that has no
user directly in the interaction loop) and "user resources" (a resource that
has a person sitting behind it) as first class concepts.
Traditional middleware styles include RPC (Remote Procedure Call, eg DCE), MOM (Message-Oriented Middleware, eg MQSeries), and DOM (Distributed Object Model, eg CORBA and DCOM). All are in production at many major enterprises. But all have fallen far short of initial expectations. Most have resulted in complex, tightly coupled, and difficult to extend integration networks.
Web Services based on SOAP and WSDL (hereinafter WS-*) are the technology standards underlying the Service-Oriented Architecture (SOA) wave rolling through enterprise IT for the past five or so years. WS-* specifically, and SOA generally promised to succeed where traditional middleware failed, ie to provide loosely coupled, extensible, and less complex integration networks. Unfortunately, SOA appears to following in the footsteps of all the other middleware waves (especially the last wave, known as EAI--Enterprise Application Integration).
To some degree, the expectations about Web Services have been driven by the name itself. It is assumed by those who are not deeply immersed in middleware and web architecture and the fundamental differences between them (ie most people in IT and business), that Web services are based on the architecture of the World Wide Web. Since the Web has been an incredible success and has actually delivered loosely coupled, extensible, and less complex application networks (at least between user agents [browsers] and automated agents [applications], it was assumed that Web services would deliver the same success to enterprise A2A integration.
Unfortunately, Web Services, at least the WS-* style, are "Web" in name only. While WS-* enables tunneling over HTTP (used merely as an XML message transport), in almost every important aspect, WS-* violates (or at best ignores) the architectural principles of the Web as described in the W3C's Architecture of the World Wide Web, Volume One and in Tim Berners-Lee's personal design notes.
While there are many examples of how WS-* violates or ignores the architecture of the Web, one should suffice for the purposes of this position paper. WS-* either ignores or violates the most important architectural concept of the Web: the Web is composed of resources identified by URIs. For example, WS-* replaces the concept of resources identified by URIs with the concept of services identified by WS-Addresses. But the problem goes deeper. Nowhere in the vast multitude of WS-* specifications or the articles or papers describing them is there any imperative or even any emphasis that a Web Service should return an XML document that is populated references to other Web resources, ie URIs. But it is a fundamental principle of the Web that good Web resources don't "dead end" the Web; instead, they return representations filled with URIs that link to other Web resources.
While nothing prevents a WS-*-style Web Service from returning XML
containing URIs, this usage is never encouraged or even emphasized. While
many Web-based enterprises like Google and Salesforce do return URI-filled
XML from their WS-*-style Web Services, it is my experience that traditional
IT organizations adopting WS-* rarely if ever do. Just look at some of the
XML industry standards like ACCORD or OAGIS: few if any elements contain
URIs. It is quite clear both in theory and in practice that WS-*-style Web
Services represent a "dead end" for the Web.
The large set of WS-* specifications is almost entirely focused on recreating traditional middleware capabilities using XML as the syntax for the formal message structure and the formal interface description. For example, WS-Reliability ans WS-ReliableMessaging simply apply the lessons learned by MOM vendors to reimplement their time tested algorithms for message acknowledgement, resend, etc. The same is true of WS-AtomicTransaction and WS-BusinessActivity and their relationship to traditional transactional middleware algorithms, eg two-phase commit. While there is nothing wrong with such work--in fact there is great value in having the major middleware vendors finally agree on middleware standards after so many years of proprietary middleware protocols--the problem is that such work has nothing to do with web architecture or the W3C. The only overlap between WS-* and the Web is a technological one: WS-* uses Web technologies such as XML and HTTP.
Actually, the W3C XML Protocol Working Group uses a much more accurate
name for WS-*-style Web Services: XML Protocol Services. If WS-* "Web
Services" had originally been "XML Middleware Services" (XMS-*), I doubt the
W3C would have ever gotten directly involved with standardizing such an
architecture. It would have left such work to the middleware vendors, and at
best coordinated with them in their use of HTTP, XML, etc. Instead the W3C
would have focused on protocols and formats such as RSS, Atom, Microformats,
and now GData that are the best examples of how to enable one software agent
to interact with another (aka A2A integration).
It is my position that the W3C should extricate itself from further direct
work on SOAP, WDSL, or any other WS-* specifications and redirect its
resources into evangelizing and standardizing identifiers, formats, and
protocols that exemplify Web architectural principles. This includes
educating enterprise application architects how to design "applications" that
are "native" web applications.