- From: Jim Webber <Jim.Webber@newcastle.ac.uk>
- Date: Thu, 4 Nov 2004 21:55:09 -0000
- To: "Harm Smit" <hsmit@easyconnect.fr>, "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>, "Francisco Curbera" <curbera@us.ibm.com>, "Mark Little" <mark.little@arjuna.com>
- Cc: <public-ws-addressing@w3.org>
Harm: > Why are you complicating the issue? I actually think it's an architectural simplification. wsa:action is used as an aid for dispatchers in most situations where one could just as simply dispatch by qname of a message. > What is being demonstrated here is that in document mode, you > can't unambiguously infer the opcode from the soap:Body. > So, in fact, the SOAP message can be viewed as a command of which > wsa:action is the opcode and the soap:Body the operand. > What's wrong with this and why would you try to find some > convoluted solution to make the wsa:action optional? Is it really the case that business permit different processing of the same document? The only places I've seen the same document being processed differently is where that document has been used as a bucket for seralised method paramters a la RPC. The view of opcode plus operand does WS an injustice. WS are not about "invoking" or "operations" they are about the exchange of structured documents between business systems. When I received a bill from a utility company, it doesn't "invoke" the "GiveMeMoney" operation on me. I just get a document which I parse and understand, and may take some action on. Certainly the utility company does not stick an action on the envelope like "urn:pay:up:or:supply:will:be:cut" which is the function of was:action. Jim -- http://jim.webber.name
Received on Thursday, 4 November 2004 21:55:26 UTC