- From: Jim Webber <Jim.Webber@newcastle.ac.uk>
- Date: Wed, 16 Jun 2004 11:41:35 +0100
- 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 UTC