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

Mike:
  Some of the lessons I have learned:

1. There's more to this stuff than meets the eye! This may reflect a 
personal bias (what doesn't), but I have been surprised at the deep 
philosophical implications of this architecture. By philosophical I 
mean issues like the relationship between 
resources-representations-URIs as a metaphor for the symbol-grounding 
problem, and message equivalence as  a metaphor for the objectification 
problem.

2. I am strongly of the opinion that we haven't seen the last of the 
implications coming from the structured message form (headers+bodies) 
and the corresponding processing model

3. May of the hard issues, architecturally, don't seem to be 
constrained by the technology questions themselves. For example, 
service, and service agent, represent concepts that don't seem all that 
focussed on XML, SOAP and WSDL (to pick some targets). However, there 
are problems that first of all `show up' at these technology levels 
(e.g., intermediaries and correlation) that are really issues at a 
higher level of abstraction.

4. There is a significant difference between an interoperability 
architecture and a model implementation architecture. I guess the jury 
is out on which is more useful; I feel quite strongly that we picked 
the right approach though.

5. The architecture is quite strongly influenced by the W3C community 
itself, with its interests and skill sets.

Not a lesson, per se, but I think that we have done some good work. It 
will be a shame if it is allowed to lapse. However, nothing is ever 
truly lost ...

Frank


On Dec 5, 2003, at 9:51 AM, Champion, Mike wrote:

>
>
>
>> -----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 13:30:19 UTC