W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

RE: Which operation?

From: Jim Webber <Jim.Webber@newcastle.ac.uk>
Date: Wed, 16 Jun 2004 11:41:35 +0100
Message-ID: <37E80E80B681A24B8F768D607373CA80DC59A7@largo.campus.ncl.ac.uk>
To: <www-ws-desc@w3.org>

Mark:

[snip]

> That's what a contract is supposed to define; there's a whole 
> bunch of metadata/signalling information out-of-band of the 
> document payload that has been methodically stripped away 
> under the banner of Web services, in the pursuit of a more 
> loosely coupled architecture.  But none of that changes the 
> part of the architecture that affects the coupling, the 
> contract (the "connector" in software architectural 
> parlance).  All it really does is make for a very poorly 
> self-descriptive messaging infrastructure with an abundance 
> of ambiguity, as we've recently been discovering.

Why do messages need to be ambiguous? I can see how you can engineer a
way of making a message ambiguous but in a real deployment messages
would (or at least should) all be different from one another. A
cancelOrder message will look different from a placeOrder message - no
ambiguity.

You may choose to assume that the receipt of two slightly differently
populated placeOrder messages would imply an update to an order - or
whatever semantics your service decides upon. But I still can't see
anything ambiguous in this.

Having just an orderMessage and the POST and DELETE verbs achieves much
the same thing but couples you to that Web stuff.

> There is a better way!

Yes you're right - the "processThis" model [1] rocks :-)

Jim
--
http://jim.webber.name 

[1]
http://www.markbaker.ca/2002/09/Blog/2004/05/02#2004-05-garland-processt
his
Received on Wednesday, 16 June 2004 06:42:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT