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] PR issue 1 - WS-Addressing comment on ws-rm related to use ofextended anonymous uri



I'd like to add my own $0.02 to a point that Anish made:

> > and for SOAP 1.1/HTTP it says:
> >
> > "When "http://www.w3.org/2005/08/addressing/anonymous" is
> > specified for the response endpoint then there is no change
> > to the SOAP 1.1/ HTTP binding."
> >
> > What does all this mean wrt to sending a message to a an EPR
> > that has WS-A 'anon' as a value of wsa:Address? I don't know.
> > All it says is that the SOAP 1.1/HTTP binding does not
> > change. I.e. ROR is *not* allowed.
> > I.e. the 'response' has to be sent back on HTTP back channel.


I'm not sure that I would agree. I think that this may in fact be
an errata on the WS-A SOAP Binding spec. I think that what was meant
was that the SOAP Binding (defined by the SOAP1.1 RoR) does not change
since I believe that it was the intent of the WS-A Group to have
that binding defined specifically so that WS-Addressing could be
used. I would also point out that this (SOAP1.1 RoR)is, in principle,
what almost all SOAP stacks do in practice anyway.

Cheers,

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


"Gilbert Pilz" <Gilbert.Pilz@bea.com> wrote on 09/28/2006 07:48:45 PM:

> Overall I think this sums up the situation pretty well. I do have one
> disagreement that I've marked in line . . .
>
> - gp
>
> > -----Original Message-----
> > From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> > Sent: Thursday, September 28, 2006 12:59 PM
> > To: Paul Fremantle
> > Cc: Doug Davis; Gilbert Pilz; ws-rx@lists.oasis-open.org
> > Subject: Re: [ws-rx] PR issue 1 - WS-Addressing comment on
> > ws-rm related to use of extended anonymous uri
> >
> > Paul,
> >
> > I was merely trying to say that this issue (whether ws-a anon
> > uri is appropriate for MakeConnection) was raised during this
> > discussion without saying whether I agree with it or not.
> >
> > Here is my view on things:
> >
> > WS-A WG did a poor job on WS-Anon (granted they had some
> > constraints wrt timing/charter). There are still some dragons
> > in WS-A anon and the semantics are underdefined.
> >
> > Forgetting that the name 'anon' is a misnomer, this is what
> > the Core spec says:
> >
> > "Some endpoints cannot be located with a meaningful IRI; this
> > URI is used to allow such endpoints to send and receive
> > messages. The precise meaning of this URI is defined by the
> > binding of Addressing to a specific protocol and/or the
> > context in which the EPR is used."
> >
> > This doesn't mean a whole lot and one has to look at the binding.
> >
> > The SOAP Binding of WS-Addr says:
> >
> > "A value of "http://www.w3.org/2005/08/addressing/anonymous"
> > for the [destination] property implies no additional
> > semantics beyond those resulting from the rules defined below
> > and as described in Web Services Addressing 1.0 -
> > Core[WS-Addressing Core]. In particular, note that Web
> > Services Addressing 1.0 - Core[WS-Addressing Core], section
> > 3.4 requires such a value in messages sent to a response
> > endpoint whose [address] is
> > "http://www.w3.org/2005/08/addressing/anonymous"."
> >
> > [Note: 'Response endpoint' in that section refers to ReplyTo/FaultTo]
> >

> > and for SOAP 1.1/HTTP it says:
> >
> > "When "http://www.w3.org/2005/08/addressing/anonymous" is
> > specified for the response endpoint then there is no change
> > to the SOAP 1.1/ HTTP binding."
> >
> > What does all this mean wrt to sending a message to a an EPR
> > that has WS-A 'anon' as a value of wsa:Address? I don't know.
> > All it says is that the SOAP 1.1/HTTP binding does not
> > change. I.e. ROR is *not* allowed.
> > I.e. the 'response' has to be sent back on HTTP back channel.
> >
> > There are two problems with this:
> > 1) This specifically disallows sending a 202 using SOAP 1.1
> > ROR HTTP Binding addendum note. This is a problem for WS-RM,
> > if you want to send message and poll for a response later.
> > 2) It does not say anything beyond the SOAP/HTTP binding
> > "MEPs". What is the semantics when used in AcksTo? What does
> > it mean when used in an EPR that is not replyTo/Faulto? It is
> > not defined.
> >
> > If you ignore what the spec-ese says and look at the
> > intention (as I see
> > it):
> >
> > The WS-A WG mostly looked at this from the view of
> > ReplyTo/FaultTo and in the context of res-res
> > MEP/transmission primitives. The intention was to allow
> > clients to say: send me stuff on the back-channel of this
> > http-connection OR open a new connection. The problem is
> > *this* http-connection, which is not what is meant by WSRM anon URI.
> >
> > How do we get out of this?
> > I think we have two solutions:
> >
> > 1) keep the WSRM anon URI as is and ask WS-Addr to relax
> > their requirements on wsaw:Anonymous wsdl marker or the
> > policy-friendly marker/assertion that they are thinking about.
> >
> > 2) remove WSRM anon URI and reuse WS-Addr anon uri. And use refps.
> > Define a specific ref property including comparison rules.
> > That is what refps were meant for. The reason for not using
> > these were cause of trepidations around WS-Addr issue 1, web
> > arch issue and all that good stuff.
>
> The WS-Addressing Core spec *does* *not* define any such thing as a
> "reference property". It defines "reference parameters" and is specific
> about the fact that reference parameters are opaque to everyone except
> the party that created the EPR. As I understand it, the fact that
> reference properties aren't in the WS-Addressing Core spec is not a
> mistake by omission; the WG deliberately decided that they didn't want
> reference properties (for various resons only some of which had to do
> with Web architecture). I don't understand why it's unthinkable to
> "break" the Core spec by adding a "useBackChannel" attribute to
> wsa:Address yet it's somehow ok to "ignore" the Core spec by using
> non-existent EPR properties.
>
> Also please don't use the term "refp". It could stand for either
> reference parameters or reference properties, an ambiguity which is not
> very helpful in the current context.
>  
> > Personally I'm fine with either of the two options, but I
> > know Doug had some problems with (2) not related to WS-Addr
> > issue 1. I don't quite understand or agree with that, so
> > won't try to explain it.
> >
> > If we use option (2), the issue we'll have to tackle is the
> > fact that the SOAP/HTTP binding does change when you use the
> > refp in the replyTo/FaultTo to allow 202. OR say that when
> > used in replyTo/FaultTo the reply/fault must be sent in the
> > back-channel of *that* connection except when there is a
> > failure (in which case there is no change to the SOAP/HTTP
> > binding as WS-A stipulates).
> >
> > HTH.
> >
> > -Anish
> > --
> >
> > Paul Fremantle wrote:
> > > Anish
> > >
> > > I'm not clear exactly which interaction you are talking about. Any
> > > chance you can give a scenario and explain exactly which
> > anon URI in
> > > which interaction *may* be at fault.
> > >
> > > Paul
> > >
> > > Anish Karmarkar wrote:
> > >> Paul,
> > >>
> > >> The replyTo/FaultTo was just an example. What I was trying
> > to convey
> > >> was that, during the MakeConnection discussion there was
> > point made
> > >> that we *may* not be able to use the WS-A 'anon' URI because that
> > >> particular URI identifies the back-channel (in the case of
> > soap/http)
> > >> for a particular connection, whereas an ws-rm 'anon' URI
> > identifies
> > >> any back-channel of a connection created by the
> > MakeConnection message
> > >> containing the right/same UUID.
> > >>
> > >> -Anish
> > >> --
> > >>
> > >> Paul Fremantle wrote:
> > >>> Anish
> > >>>
> > >>> I don't agree with this point. RM is composing with the
> > existing flow
> > >>> to *add* reliability. There are many reasons that the
> > server cannot
> > >>> reply on the backchannel - network failures, timeouts,
> > etc. In those
> > >>> cases the original contract for delivery is over, since
> > WS-A and SOAP
> > >>> have no inherent retry or retransmission model. WS-A does not and
> > >>> should not say what goes on beyond that original
> > request/response. If
> > >>> or how the reply gets returned beyond that point is not WS-A's
> > >>> concern. That is when RM should kick in. At no point was it the
> > >>> intention or the result of WS-A to prevent the composability with
> > >>> reliability with the existing URI schemes.
> > >>>
> > >>> I suggest anyone who has any doubt about this carefully
> > rereads the
> > >>> distinction between "response" and "reply" in the WS-A spec.
> > >>>
> > >>> Paul
> > >>>
> > >>> Anish Karmarkar wrote:
> > >>>> Doug Davis wrote:
> > >>>>>
> > >>>>> IIRC there were some other reasons as well.  
> > >>>>
> > >>>> Another reason that was discussed was:
> > >>>> is it even valid to use the WS-A 'anon' URI for this?
> > >>>> WS-A 'anon' URI in a ReplyTo/FaultTo says, send the
> > reply/fault in
> > >>>> the HTTP-response (back-channel) of *this* connection (in the
> > >>>> SOAP/HTTP binding case), whereas the WS-RM 'anon' URI in a
> > >>>> ReplyT/FaultTo means send the reply/fault in the
> > HTTP-response of
> > >>>> this connection (in the SOAP/HTTP binding case) or *any*
> > >>>> HTTP-response of a connection created using the
> > wsrm:MakeConnection
> > >>>> message with the correct/same UUID.
> > >>>>
> > >>>> -Anish
> > >>>> --
> > >>>>
> > >>>> <snip/>
> > >>>>
> > >>
> >


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