Why "web services architecture" is a bit of a misnomer

Last spring, I foolishly submitted a proposal for the XML 2003 titled
"Toward a Reference Architecture for Web Services" that would summarize all
the wonderful progress we've made and put it in the context of other stuff
such as SOA, REST, the quasi-proprietary architectures promulgated by
Microsoft/IBM/BEA, etc.  Since the, ahem, deadline for sending them the
final presentation is today, I thought I ought to update my stock PowerPoint
file on the subject (actually it's now a Keynote file since I joined the Mac
cult <grin>) with some closing thoughts on where we've actually ended up and
how/why we got here.  Here's what I've come up with, for your critique.
It's not exactly a happy conclusion, but it's not all that depressing
either; in any event I consider it hard-won knowledge:

What we call "Web services" are a set of technologies -- XML, SOAP, WSDL,
and the various specs that extend SOAP and WSDL -- that can be used to
implement at least two quite different reference architectures.  This
difference is nicely summarized in the two most widely used expansions of
the (former) acronym SOAP:

Simple Object Access Protocol - The key architectural concept is an
"object", or a bundle of closely related data and methods that presumably
model some real-world object or concept. XML technologies and SOAP provide a
platform-neutral way to exchange serialized objects between applications and
systems and WSDL provides a language-neutral way to describe the interfaces
(primarily defined as methods to be invoked remotely).  See the CORBA
Reference Model, RM-ODP, etc. as reference architectures: They attempt to
help achieve portability of applications across heterogeneous platforms and
to hide the consequences of distribution from programmers as well as users.
In environments that are friendly to distributed objects, i.e. where
networks are fast, reliable, secure, and applications closely managed, Web
services technologies can be very useful in integrating objects and OOP
applications across platforms, network infrastructures, etc. in ways that
COM and CORBA could not.

Service Oriented Architecture Protocol - The key architectural concept is a
"service" -- a software agent that is capable of performing a set of tasks
when requested by messages conforming to well-defined service interface
description.  Web services technologies provide a good (but not the only!)
way to define service interfaces (WSDL) and service invocation messages
(SOAP).  There is no agreed-upon SOA reference model, but the goals are in
contrast to the goals of distributed object reference models: portability of
implementation code is a non-goal, but the ability to replace service
implementations without disrupting applications that request the services is
a goal, and in general the fact that a service is remote and accessed via
standard protocols rather than local and accessed by method calls is a
fundamental reality to be exposed rather than hidden. The general sense of
the WSA WG is that the Web and even REST would fit easily into such a
reference model, being defined as services to deliver representations of
resources using the Web interface definitions including URI and HTTP. The
great advantage of the SOA approach is that services can be defined,
implemented, and deployed in a more loosely coupled manner than distributed
objects can, making the approach more useful in situations where network
latency, reliability, security, and management are unpredictable.

Thus, since web services support both the quite orthogonal distributed
object and SOA reference architectures, there is not and cannot be a single
"web services architecture".  Web services are better seen as a collection
of inter-related platform-neutral messaging technologies that can be used in
a variety of architectural settings.  The W3C might (if it gets both broad
and deep member support) choose to take the lead on defining a SOA reference
architecture that would distinguish it externally from the distributed
object approaches and differentiate it internally among (for example)
RESTful and non-RESTful styles, but this would be considerably more focused
than a "web services architecture" could be.

  I'm not saying that the WSA effort was misguided (and my analysis would
apply to vendor-specific "stacks" such as whatever Microsoft calls GXA these
days as much as it does to our efforts).  I am saying that we've learned
that there is not a single reference architecture for web services that is
possible even in principle -- the web services technologies are more of a
"cloud" that can take on many shapes than a "stack" with one canonical
shape.  That's not the outcome we anticipated two years ago, but I think it
is a valuable conclusion [remember that this is my conclusion, not the WG's]
that was not obvious two years ago.

Does anyone violently object to this conclusion? (Not that I'm claiming to
speak for anyone but myself at the conference, but I do respect your
opinions and don't want to embarrass the group by association with anything
too egregiously stupid).

Received on Friday, 5 December 2003 11:18:40 UTC