OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] issue 115: clarifying question


Comments inline . . .


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Tuesday, April 25, 2006 7:05 PM
To: Patil, Sanjay
Cc: Gilbert Pilz; Paul Fremantle; wsrx
Subject: RE: [ws-rx] issue 115: clarifying question


So, in this case the mU has different semantics as to whether it is used in the soap:Header vs a soap:Body? 
 
soap:mU and wsrm:mU have the same semantics but different processing models. The first is interpreted by the general SOAP processing engine, the later by the RM layer. I think this is the part that people are not picking up on. If you send a CreateSequence that contains an extension that has the "wsrm:mU" attribute to an RMD that does not support that extension it is the RMD that is responsible for detecting this fact and not the general-purpose SOAP engine. That's why our proposal includes a wsrm:MustUnderstandFault; we felt it would be misleading and incorrect to return a soap:MustUnderstand fault because, as far as the SOAP engine was concerned, there was nothing wrong with the message. 

The spec currently says that for "piggy-backed" RM elements, that a fault in processing should be ignored, but for
others? Do we ignore the extension mU fault or proceed to process the rest of the message, just without RM? 
 
These questions don't really make sense because you are assuming it is the SOAP processing engine that interprets wsrm:mU when it is not; wsrm:mU should only ever be processed by the RMS or the RMD.
 
Actually it is in the area of "piggy-backed" RM elements where the idea of using SOAP headers to refer to extensions inside of WS-RM defined components really runs into trouble. If you extend SequenceAcknowledgment in a "mustUnderstand" way then piggy-back that header (plus the SOAP mU-header that refers to that extension) onto an arbitrary message the SOAP engine of a non-supporting node will fault on that message before it can reach the RMS where the special case on "the processing of the original message MUST NOT be affected" can take effect. The result is that the intended recipient would not get the message even though that message may not have been "carried reliably" or otherwise been involved in any way with WS-RM. 
 
If you used "wsrm:mustUnderstand" to annotate the extension the SOAP engine wouldn't/shouldn't get involved and the RMS will (a) notice that it can't process this acknowledgment and (b) apply the special case and forward the message for further processing.

Do we actually have any specific use cases that we can use to vet this new wsrm:mU against besides the obvious one of CS/STR? 
 
By its nature you can't talk about specific use cases when it comes to supporting extensibility. I don't remember anyone providing a use case around why CloseSequence (to pick an example) needs to be extended but the extension points are there. If you agree that not all extensions are ignorable then you must have a way to indicate to the recipient that some extensions must be understood.
 
As I have previously noted, the spec already has an extensibility strategy; SHOULD ignore. Why are we proposing
to change that? 
 
Because "SHOULD ignore" is not sufficient to cover those cases where ignoring an extension could lead to serious negative consequences (such as the omission of any security processing by the RMD).

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295



"Patil, Sanjay" <sanjay.patil@sap.com>

04/25/2006 06:27 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
"Gilbert Pilz" <Gilbert.Pilz@bea.com>, "Paul Fremantle" <paul@wso2.com>, "wsrx" <ws-rx@lists.oasis-open.org>
Subject
RE: [ws-rx] issue 115: clarifying question





 
There may other valid SOAP headers that are entirely unrelated to RM (or just unrelated to the specific instance of the problematic RM Sequence) which I believe should rightfully see the day light.
 
In the case of CS/STR mU that can not be respected, I do expect that a fault be raised but I don't see why the other valid parts of the message be discarded.
 
-- Sanjay


From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent:
Tuesday, Apr 25, 2006 15:19 PM
To:
Patil, Sanjay
Cc:
Gilbert Pilz; Paul Fremantle; wsrx
Subject:
RE: [ws-rx] issue 115: clarifying question



What, then, would you have the processor do? Is it to take a case-by-case assessment?


In the case of the CS/STR, I certainly DO expect that the entire message fault in this manner.


Cheers,


Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295


"Patil, Sanjay" <sanjay.patil@sap.com> wrote on 04/25/2006 05:51:48 PM:

>  

> Doesn't SOAP mU processing model require that the entire message be
> abandoned and a fault raised if the mU semantic can not be respected
> by the receiver. I am not sure we have enough reasons to justify
> triggering such a behavior for RM mU scenarios!

>  

> -- Sanjay

>
> From: Paul Fremantle [mailto:paul@wso2.com]
> Sent: Tuesday, Apr 25, 2006 9:40 AM
> To: Gilbert Pilz
> Cc: Christopher B Ferris; wsrx
> Subject: Re: [ws-rx] issue 115: clarifying question


> Gil
>
> Why is creating a new SOAP header a problem?
>
> Paul
>
> Gilbert Pilz wrote:
> So you are saying that the definition of qname of the header is the
> reference to the extension? This means that, for every extension for
> which I want mU semantics, I need to define a unique header? Why is
> this preferable to defining a single new attribute?

>  

> What if I extend something like the SequenceAcknowledgement header?
> Suppose an RMD is returning a message into which it inserts two
> separate SequenceAcknowledgement's, one of which has a
> mustUnderstand extension and the other which does not. It seems
> that, using your mechanism, an RMS that did not understand the
> extension would not be able to process either of the acknowledgments
> despite the fact that one of them is not extended in any way. What
> if there were three SequenceAcknowledgement headers in the same
> message; one that carries a mustUnderstand extension, another that
> carries a mayIgnore extension, and a third that isn't extended at all?

>  

> - gp

>
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Monday, April 24, 2006 6:07 PM
> To: Gilbert Pilz
> Cc: wsrx
> Subject: Re: [ws-rx] issue 115: clarifying question


>
> Gil,
>
> Actually, I had something more like this in mind:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
> xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200604"
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> wssecurity-secext-1.0.xsd"
> xmlns:foo="http://example.org/foo"
> xmlns:wsa="http://www.w3.org/2005/08/addressing">
> <S:Header>
>  <foo:SecureRM S:mustUnderstand="1"/>
>  <wsa:MessageID>
>   http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
>  </wsa:MessageID>
>  <wsa:To>http://example.com/serviceB/123</wsa:To>
>    <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200604/CreateSequence
> </wsa:Action>
>  <wsa:ReplyTo>
>   <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
>  </wsa:ReplyTo>
> </S:Header>
> <S:Body>
>  <wsrm:CreateSequence>
>    <wsrm:AcksTo>
>      <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
>    </wsrm:AcksTo>
>    <wsse:SecurityTokenReference>
>      ...
>    </wsse:SecurityTokenReference>
>  </wsrm:CreateSequence>
> </S:Body>
> </S:Envelope>
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> "Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 04/24/2006 05:41:23 PM:
>
> > During the conference call of 4/20/2006 Chris asserted that you can
> > use a SOAP header with a mustUnderstand attribute to flag the fact
> > that some element in either another header or in the message body is
> > an extension that must be understood by the receiver. I'm not sure I
> > understood exactly what Chris thought this should look like. For
> > example, imagine the following CreateSequence message. The extension
> > elements have been marked in bold. What is supposed to go in the
> > <wsrm:Extension> header?
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope"
> > xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200604"
> > xmlns:wsa="http://www.w3.org/2005/08/addressing">
> >  <S:Header>
> >   <wsrm:Extension S:mustUnderstand="1">
> >     ????
> >   </wsrm:Extension>
> >   <wsa:MessageID>
> >    http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
> >   </wsa:MessageID>
> >   <wsa:To>http://example.com/serviceB/123</wsa:To>
> >     <wsa:Action>http://docs.oasis-open.org/ws-rx/wsrm/200604/CreateSequence
> > </wsa:Action>
> >   <wsa:ReplyTo>
> >    <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
> >   </wsa:ReplyTo>
> >  </S:Header>
> >  <S:Body>
> >   <wsrm:CreateSequence>
> >     <wsrm:AcksTo>
> >       <wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
> >     </wsrm:AcksTo>
> >     <wsrm:SecurityComposition>
> >       <wsrm:Identifier>
> >         http://docs.oasis-open.org/ws-
> > rx/wsrmsp/200604/profile/http_auth/samenode
> >       </wsrm:Identifier>
> >     </wsrm:SecurityComposition>
> >   </wsrm:CreateSequence>
> >  </S:Body>
> > </S:Envelope>
> >
> > I'm sure that most of us could all come up with a reasonable design
> > to do what you suggest, but for the purposes of further discussion
> > I'd like to know what design Chris had in mind?
> >
> > - gp
>
> --
>
> Paul Fremantle
> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
>
> http://feeds.feedburner.com/bloglines/pzf
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]