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
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: "Gilbert Pilz" <Gilbert.Pilz@bea.com>
- Date: Tue, 25 Apr 2006 14:53:45 -0400
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/25/2006 02:42:34 PM:
> 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.
chacun à son goût
>
> 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.
This isn't a "complication" since the spec
already cautions that the
headers need to be signed with the body.
>
> 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.
It doesn't NEED to tell you WHICH one has it, it is
asserting that the
SOAP node "understand" that particular use
of the extension.
>
> 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
OMG! Alert the media!
> 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).
I would rather have this than require that all SOAP
processors change
the way in which they parse and process messages.
Furthermore, since you are
expecting every other spec to do the same thing, then
that means that each one
will have such an effect on the SOAP parsing/processing.
Somehow, I think that
is a REALLY BAD IDEA.
>
> - 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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]