Re: WS-Addr issues

"Mark Baker" <distobj@acm.org> writes:
> 
> But seriously, aren't you concerned that everybody seems to think
> that wsa:Action is something different?  We've got the GED, wsa:Action,
> the WSDL operation name mapping requirement, and WSDL's operation
> style, all vying to have some say in describing service and/or message
> semantics.  It's a mess, and interop is not being served by there
> being such a mess.

I agree such a mess does not help interop. 

Are you familiar with WSDL 2.0's operation name feature? That 
basically says that the name of operation must be represented
on the wire somehow. That was put in because the input GEDs of 
a collection of In-Out patterned operations in the same interface
even are not required to be unique. The {name} property of Interface
Operation components are required to be unique.
 
> If wsa:Action is the annointed mechanism that's going to clean up that
> mess, I'm all for that, but IMO, that's going to require calling a
> spade a spade, and not dodging the hard questions.

I see wsa:Action being the annointed mechanism for realizing the
operation name feature when WS-Addressing is in use. If you're
not using WS-Addr then you're welcome to use the 1st child element 
QName the phase of the moon or whatever you want for dispatching.
The important thing is that the client doesn't care: they just 
need to put whatever the server asked to put and then it'll work.

> Does wsa:Action indicate the operation or not?  

It does. Without it we either have to introduce the requirement
that top level GEDs must be unique (which no one requested BTW
during the LC period of WSDL 2.0 ;-)) or create some other way
to distinguish between the same incoming XML messages requiring
different actions.

Others have already covered why making the GEDs unique is 
unnecessarily limiting.

Another reason I don't like to have to crack open the actual 
payload to figure out what to do with the message is that it
gets complicated in the presence of reliability and security
for example. For example, in the case of RM its useful to not
have to touch the payload until the RM protocol has run. However,
there can be operation specific RM policies declared (different
timeout for different operations for example) and that requires
you to open the payload before being able to determine the
policies for RM.

Thus, there's a chicken-and-egg problem in general with policy:
if there are operation specific policies at play then you have
to be able to figure out the operation to determine the policies,
but until you know the policies you don't know whether to decrypt,
verify signatures etc. if the operation itself is in the payload. 

> If yes, how does it relate to the underlying protocol method,

I'm not a RESTafarian as you know ;-) - what protocol method? Maybe
the SOAP message was delivered to me via courier pigeon or worse
yet the postal-vote-losing-USPS. What "method"?

> the GED,

No relation; see WSDL 2.0.

> the WSDL style,

If its an RPC styled operation then the action is indeed implicit
in the GED of the message because the GEDs will be unique (assuming
WSDL 2.0 style no overloading). In that case both the top level GED
and the action provides the same info, except of course that the
GED is inside the payload and the other is outside.

> WSDL operation name, and WSDL operation name mapping?

wsa:Action is a relization of the operation name feature as I 
indicated above. The operation name in WSDL 2.0 is logical and
is there really to enable referring back to that operation
within a WSDL document (for bindings for example). FWIW I tried,
without success, to make the operation name optional (as most
bindings will not need per-operation bindings esp. in WSDL 2.0/SOAP).

> Or, if wsa:Action is sometimes an operation and sometimes not, what
> else can it be, and what tells a recipient of a message what it is for
> a given message or service?  Operation style?  Something else?

Its always the way to figure out what to do with the message: i.e.,
the operation of the WSDL.

Sanjiva.

Received on Saturday, 6 November 2004 01:24:31 UTC