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

 

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org] 
> Sent: Friday, December 05, 2003 12:23 PM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: Why "web services architecture" is a bit of a misnomer
> 
 
> When I went on (and on and on ... 8-) about the value of 
> architectural constraints, this is what I was getting at;  by 
> relaxing constraints one builds a bigger and bigger umbrella 
> under which more and more architectural styles can be 
> included.  But in doing so, the value of the umbrella style 
> approaches zero.

OK.  I'd say the umbrella that covers "Web services architecture" is overly
broad by itself (it's about as meaningful as the "XML architecture", but
there are some distinct "ribs in the umbrella" such as distributed objects,
REST, SOA in general, Web applications as they really are, etc. that are
meaningful and constrained.  If one wants to do meaningful architectural
work, focus on the ribs not the umbrella.  

Still, I think we've learned some useful things that weren't obvious two
years ago:

- Most obviously, and as Ugo points out, the very term "Web services" is
extremely slippery to define rigorously.  It probably became pervasive
because of its power as a marketing term, and definitely not because it
reflects an underlying technical reality.

- There is no contradiction between REST and Web services, it's just that
most people were equating the Web services *technologies* with the
distributed object *architecture" a couple of years ago.

- Likewise, although the distributed object perspective is no longer
fashionable, that doesn't mean it's wrong or useless, just useful in far
fewer environments than it appeared a few years ago. If one really has a
fast, clean, well-managed, but diverse infrastructure behind the firewall,
SOAP/WSDL RPC may be just the ticket.

- Specific constraint systems such as REST or distobj are not to be either
blessed in general nor scorned in general, but to be understood as
appropriate in specific scenarios: What are the goals of the application,
the infrastructural constraints on calling code/sending messages, and the
assumptions about how quickly and manageably change will happen?  Or as I
like to put it, it's about engineering, not religion.  For awhile there, I
wasn't so sure :-)

- Any particular "stack diagram" bakes in assumptions about goals and
constraints.  Thus each vendor's preferred diagram incorporates its view of
what problems its customers have and it has the technology to solve.  Not
surprisingly, industry-wide consensus on all this is elusive.  One can
bemoan the lack of industry cooperation (or the participation of the big
vendor companies in several of the W3C efforts),  but that reflects the
diversity of opinions on what the problem being addressed is as much as a
desire to control the solution.

- There is no technological fix to any of this.  No methodology, business
process diagramming tool, IDE, programming language, etc. is going to make
implementing a  "service oriented architecture" quick and easy.  Indeed,
there's a danger that the marketing/analyst/pundit weasels have seized on
SOA and are in the process of squeezing meaning out of it just like meaning
was squeezed out of "Web services."  If nothing else, we've documented a
little slice of history that others can look back on to keep history from
repeating itself.

Can anyone suggest other lessons that we've learned?

Received on Friday, 5 December 2003 12:57:15 UTC