RE: LC 76 - What makes a msg WS-A?

Gudge,

I suppose that alternately, you *could* leave mU optonal on the 
wsa:Action. I guess this does
come full circle to your original post then. wsa:Action defines a WS-A 
message. However, I think
that in the SOAP binding it must be made clear that a SOAP node MUST NOT 
"understand"
any element in the wsa: namespace EXCEPT the wsa:Action element for 
purposes of 
triggering any WS-A behavior.

Thus, if a message were received that did not have a wsa:Action SOAP 
header block, then
no fault will be received with the exception of a soap:MustUnderstand 
fault should there be
a SOAP header block belonging to the wsa: namespace present in the message 
that also
has a mU='true'. This involves far less processing overhead as it is a 
simple boolean to determine
whether there is to be any WS-Addressing processing and that is already 
something that the
SOAP node MUST perform.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Martin Gudgin" <mgudgin@microsoft.com> wrote on 07/15/2005 09:22:54 AM:

> Chris
> 
> I having trouble seeing the practical difference between what I proposed
> and what you describe below...
> 
> Gudge
> 
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> > Sent: 15 July 2005 13:31
> > To: Martin Gudgin
> > Cc: David Hull; David Orchard; Katy Warr; 
> > public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> > Subject: RE: LC 76 - What makes a msg WS-A?
> > 
> > Gudge,
> > 
> > I think that this is pretty close to the mark. How about 
> > mandating that 
> > the wsa:Action carry a mU='true'
> > AND disallowing mU='true' on all other elements of the wsa: 
> > namespace. 
> 
> 
> > I 
> > think that that effectively
> > gets you something that can be assured to be consistent with the SOAP 
> > processing model since "understanding"
> > is predicated on the expanded name of the SOAP header block. An 
> > implementation that receives a
> > message containing a SOAP header block in the wsa: namespace 
> > that is not 
> > wsa:Action that also
> > has a mU='true' MUST return a soap:MustUndrstand fault. 
> > Further, you have 
> > the WS-A spec (in the SOAP binding) define
> > "understanding" of the wsa:Action to include the processing 
> > of all other 
> > SOAP header blocks that 
> > have the wsa: namespace.
> > 
> > Cheers,
> > 
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > blog: http://webpages.charter.net/chrisfer/blog.html
> > phone: +1 508 377 9295
> > 
> > 
> > 
> > "Martin Gudgin" <mgudgin@microsoft.com> 
> > Sent by: public-ws-addressing-request@w3.org
> > 07/15/2005 01:43 AM
> > 
> > To
> > "David Hull" <dmh@tibco.com>
> > cc
> > "David Orchard" <dorchard@bea.com>, "Katy Warr" 
> > <katy_warr@uk.ibm.com>, 
> > <public-ws-addressing@w3.org>
> > Subject
> > RE: LC 76 - What makes a msg WS-A?
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > From: David Hull [mailto:dmh@tibco.com] 
> > Sent: 15 July 2005 06:31
> > To: Martin Gudgin
> > Cc: David Orchard; Katy Warr; public-ws-addressing@w3.org
> > Subject: Re: LC 76 - What makes a msg WS-A?
> > 
> > Martin Gudgin wrote: 
> >  [snip]
> > [MJG] How about this? Is wsa:Action is missing then you MUST 
> > proceed as if 
> > you DO NOT understand WS-Addressing. And if wsa:Action is 
> > present and any 
> > other constraints in the spec are violated, then you MUST generate a 
> > fault. 
> > The upshot of the first 'MUST' is that during the mU check, 
> > if any wsa: 
> > header is found with mU='true' then a check to make sure 
> > wsa:Action is 
> > present has to occur to determine whether you 'understand' that wsa: 
> > header. Essentially, understanding wsa:Action becomes part of 
> > understanding all the other wsa: headers.
> > 
> > This approach has the advantage of producing consistent 
> > behaviour between 
> > WS-A and non-WS-A nodes for messages that DO NOT contain wsa:Action. 
> > 
> > This helps, I think.  I continue to be uneasy with using the 
> > fact that 
> > Action happens to be the one mandatory property that's also a 
> > mandatory 
> > header, but at this point, any port in a storm. 
> > [MJG] What would make you less uneasy?
> > 
> > If I read this right, the behavior if wsa:ReplyTo is present, 
> > mU false, 
> > and no wsa:Action is present, is that the ReplyTo is silently 
> > ignored -- 
> > since Action is missing, I have to not understand ReplyTo. 
> > This doesn't 
> > seem like a good kind of silent failure, but the client at 
> > least has the 
> > option of turning on mU for the ReplyTo if it wants to be safe. 
> > [MJG] Right, if the client cares, it should put mU='true' on 
> > the ReplyTo. 
> > 
> > Where would we say this?  In the SOAP binding? 
> > [MJG] That would seem like the most sensible place. 
> > 
> > 
> > 
> >

Received on Friday, 15 July 2005 13:54:16 UTC