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

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

The information model seems wrong to me. I have a WS-RM defined element (message body or header). I'm extending it for some reason. My extension is "semantically significant" to the point where I need to be sure that thing receiving this extended element understands my extension. To me it seems correct and natural that the flag or annotation I would use to indicate that the extension is "mustUnderstand" should be on the extension element itself.

 

Using a separate SOAP header places the flag/annotation in a completely separate part of the SOAP envelope. It seems strange to do this solely because "SOAP:mustUnderstand" can only be applied to headers. As I pointed out earlier, it also complicates the security processing because I need to remember to include any "extension flag headers" in the signature that encompasses the thing being extended.

 

There is also a granularity problem. "wsrm:ExtendSeqAcksToIncludeAnEPR" just says that somewhere in this message is a SequenceAcknowledgement that has been extended to include an EPR and that the receiver needs to understand what this extension means. It doesn't say which SequenceAcknowledgment (there can be more than one in a message) has been extended.

 

Also, people keep saying "a" new SOAP header as if we were talking about the creation of a single new header when what we are really talking about is the creation of a new header for every extension to every message or header. If I add an STR to CreateSequence it's one header. If I add an STR to CreateSequenceResponse it's another header. If I add an EPR to AckRequested . . . you get the point. I can't help but think that creating a single new attribute is much simpler than creating a multitude of new headers (of course, this TC isn't the group that will have to create all these new headers and maybe therein lies the appeal). 

 

- gp

---

From: Paul Fremantle [mailto:paul@wso2.com]
Sent: Tuesday, April 25, 2006 12:40 PM
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