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: RE: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm relatedto use of extended anonymous uri


We are ignoring option 3. Remove RM anon URI and keep just the MakeConnection SeqID form.

-----Original Message-----
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com]
Sent: Thursday, September 28, 2006 4:49 PM
To: Anish Karmarkar; Paul Fremantle
Cc: Doug Davis; 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

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]