W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

Re: Proposed issue; Visibility of Web services

From: Mike Champion <mike.champion@softwareag-usa.com>
Date: Wed, 16 Jul 2003 16:57:42 -0400
To: www-tag@w3.org
Message-ID: <oprse8igmgt3hq37@localhost>

Mark Baker writes:

[and I respond here only because a TAG member has jumped in, I'll not 
perpetuate this permathread here unless continued interest is shown!]

> ask any Web services proponent and
> they'll tell you that they're enabling something which is currently not
> enabled within the constraints of Web architecture; machine-to-machine
> communication.  I'm personally content to consider this as a competition
> between two architectural styles, but the WSA WG has explicitly rejected
> the notion that Web architecture offers a solution to problems such as
> automated airline ticket purchasing

I don't believe that's true, and would appreciate a pointer to any text in 
the draft WSA document that might give a reader that impression.

Most WSA members would, IMHO, freely acknowledge that the Webarch provides 
*a* framework in which to address the problems of machine-machine 
interaction over the Web, but most resist the notion that "raw 
URI+HTTP+XML" offers *the* solution to the problem. Solutions lie on a 
continuum from a pure REST architectural style to a pure RPC/distributed 
object architectural style. One objective of the WSA is to help architects 
and specwriters better understand the tradeoffs for specific scenarios.  
For example, XML Document exchange over HTTP (e.g. whatever "son of RSS" is 
called today -- http://intertwingly.net/wiki/pie/)  is probably a case for 
which a RESTful approach is close to optimal.  But RPC can make lots of 
sense in well-managed, homogenous intranet envrionments where the necessary 
tight coupling is not a practical problem.

Most of the WSA WG, however, does not find the "raw URI+HTTP+XML" approach 
optimal for situations in which (for example) multiple networks and 
protocols are bridged; the actual identiy/address of the service that will 
handle a request is not known to the requester; reliable message delivery, 
choreography, transaction processing, industrial-strength security, etc. 
requirements are critical, etc.  Again, it would be *possible* to develop 
such solutions on the raw Webarch, but there are numerous advantages and 
optimizations possible by standardizing on WSA-level (as opposed to 
Webarch-level) technologies. That's the design space we're exploring 

Received on Wednesday, 16 July 2003 16:58:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:59 UTC