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

Mike,

Your analysis corresponds to my basic belief that Web services are primarily a marketing concept (and as such do not necessarily bring with them a coherent architecture).

Regarding the two optional interpretations you mention, I would say that SOA is the more orthodox one (and many people would strongly object to the Object interpretation). On the other hand, there are cases that definitely take the Object approach (a notable example being the mapping of Grid concepts to Web services).

Ugo

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Friday, December 05, 2003 8:12 AM
> To: www-ws-arch@w3.org
> Subject: 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 12:36:19 UTC