W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: WS-Addr issues

From: Jim Webber <Jim.Webber@newcastle.ac.uk>
Date: Thu, 4 Nov 2004 21:55:09 -0000
Message-ID: <37E80E80B681A24B8F768D607373CA800172C860@largo.campus.ncl.ac.uk>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT