Re: Action item 2003-11-03 OperationName feature

On Thu, Jan 22, 2004 at 10:33:25AM -0800, Umit Yalcinalp wrote:
> >That assumes that SOAPAction's value is an operation name, but that
> >isn't necessarily the case.  It is for declaring "intent", which may
> >also be a *type* in some cases.
> >
> Ah, I guess my intent was not clear.
> 
> The only constraint on the SOAPAction value is only when you are using 
> the OperationName feature AND choose to engage both the OperationName 
> feature and the SOAP Action feature together.
> 
> This feature's intent is not to require  SOAP Action values and what 
> they should be.  This feature's  goal is to enable by the use of a 
> property to convey the receiver the name of the operation  and it 
> describes a variety of ways to implement this using different bindings. 
> This is why I described  a SOAP module to do this in a completely 
> transport independent way. SOAP specification does not state what the 
> value should be, our intent was to illustrate the only way you get the 
> value to be constrained this way is when you use the OperationName 
> feature, because the intent is to convey the name of the operation, 
> nothing else.
> 
> Other possible values for the SOAP Action is not part of this feature, 
> another feature may define what they could be in some other context.

Hmm, I'm pretty sure that's consistent with my reading of your proposal.
So to help better explain my point, here's an example...

Imagine that my operation has "GET" semantics, but the "intent" is
"StockQuote" (a type).  In the aggregate then, the request is
semantically identical(*) to an operation of "GetStockQuote" (aside;
this is how you'd build specific interfaces out of the uniform interface
in a self-descriptive/visible way).

This use of SOAPAction is most valuable when using SOAP in the
so-called "chameleon" style (coined in the early days of XMLP), where
it inherits the applicaton semantics of any application protocol it's
bound to.  I understand this isn't the common use of SOAP, but IMO it's
the only long-term viable one in conjunction with application (not
transport) protocols.

What I think we need is some additional styles (per the style AII),
including;

"inherited"; implies the chameleon use, that the operation name can be
found in the envelope of the underlying application protocol.

"explicit doc/lit"; state that the operation name is somewhere in the
message.  Should tie in to your proposal somehow, and perhaps should
also allow a reference to other established operation-name equivalents
such as wsa:action.  It's name is intended to suggest that the operation
is explicit in the message, rather than implicit (non-self-descriptive)
in the associated WSDL.

There's still more to work out, obviously, and I think I have a pretty
good grasp (after going through this just now) of what needs to be done.
But before I get too far I wanted to get your (and others') feedback.

(*) almost; SOAP processors aren't required to understand the
value of SOAPAction, which IMO is a bug

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Wednesday, 28 January 2004 00:02:15 UTC