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 touse of extended anonymous uri


 > 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.

I think we *are* in agreement here.
I do believe it is an errata. I was trying to make a point that WS-A IMO 
did not go a good job of the whole 'anon' issue. The specs tried to say 
as few things as possible and therefore leave a few things open.

There are two potential errata issues for the wsa soap binding here:

1) use of 202 when ReplyTo is wsa anon. Currently it says the SOAP 
1.1/HTTP binding does not change. It should say the binding, which 
includes SOAP1.1/HTTP as defined by SOAP 1.1 + ROR, does not change.

2) It doesn't say anything about what happens if the ReplyTo is 
non-anon? Does the binding change? Is it required that 202 be sent back? 
Can a SOAP envelope be still sent back with a 200 response? These are 
open and important questions that remain unanswered.

-Anish
--

Christopher B Ferris wrote:
> 
> 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]