Re: Clarification for WS-RX

Dave,

Please see my inlined comments.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

David Hull <dmh@tibco.com> wrote on 02/22/2006 06:40:32 PM:

> First, the proposal I put up was just meant to point out that, taken
> at face value, the stuff about "nothing more, nothing less" doesn't 
> automatically lead to useful results.  Would that it did, but it 
doesn't.
> 
> BTW, "response endpoint" is currently only defined in the WSDL doc 
> (as Umit helpfully points out).  It means "[reply endpoint] or 
> [fault endpoint] as the case may be".  Without it, we would have to 
> say things like "[reply endpoint] in case of a reply or [fault 
> endpoint] in case of a fault" in a few places.  As such, it's useful
> both there and here, and would probably be best defined somewhere in
> section 3 of the core.  I'm hoping we can do this as part of this or
> some other issue and not have to define a separate issue.

+1, just an observation on my part. I was actually trying to track down 
the
definitive meaning of the words used and found none.

> 
> Now to the interesting part:
> 

> [snip]
> 
> The key phrase here IMO is "context". You are defining the semantics
> of the anonymous [address] property 
> for the [reply endpoint] in the context of a SOAP MEP. In the case 
> of the WS-RX AcksTo EPR, we define its 
> context to an MEP + Sequence Identifier. That is to say that if a 
> SOAP message is received that carries the 
> same Sequence Identifier as was created in response to the 
> CreateSequence that carried the anon AcksTo, 
> that the ack may be sent using the channel provided by the 
> MEP/binding on which the received 
> SOAP message arrived. 
> If I understand this correctly, the MEP binding provides part of the
> definition and the definition of whatever EPR-valued property we're 
> talking about further refines this.  For example, we could say "in 

Yep, basically

> the context of SOAP 1.2 request-response, anonymous MUST [or MAY] 
> refer to the response message." and then when talking about 

Well, to be clear, I think it would be in the context of BOTH
the SOAP R-R AND the SOAP/HTTP binding. The HTTP binding provides
an implicit back-channel for the transfer of the response message.
A [reply endpoint] with anonymous [address] refers to the endpoint 
that can be reached via that back-channel which MUST be the
[destination] of the SOAP R-R response message (OutputMessage
from the perspective of the responding node)

> response endpoints (see above) say that  the response message has to
> be the response part of the same message exchange,  but when talking
> about AcksTo, say that  the response message may be part of any 
> message exchange  for which the request is a message belonging to 
> the sequence in question.

AcksTo is actually a little different. First, we have the notion
of being able to "piggy-back" a SequenceAcknowledgement SOAP
header block on any message targetted at the AcksTo EPR. This could
mean an application-level response message.

So, in the case of a WSDL in-out with a request message with 
[reply endpoint] anonymous [address], the SeqAck would be injected
into the response message. 

Additionally, we want to permit the RMD to leverage the underlying 
binding to be able to convey signals as SOAP envelopes, even when at 
the application level, there might be none.

> 
> This allows anonymous to mean something else with some other MEP (or
> in the absence of a MEP :-).  We can also talk about anonymous 
> [destination], in which case the context is the message itself.  I'm
> not sure how it squares with using anonymous [destination] on 
> requests on an already-open channel.

I would not get too wrapped up in "request". Protocols like BEEP
and I suppose Jabber and XMPP don't have the same convention that
HTTP does, in that the "client" establishes the connection and
makes the "request". BEEP, for instance, permits the connection to 
be established by either end and the messages may flow in either
direction, wherein a "request" could originate with the "server"
and be responded to by the "client".

> 
> If this is all accurate, then I think that this description is 
> helpful in understanding the problem.  However, I think the text I 
> gave previously captures all we need to capture:
> When "http://www.w3.org/@@@@/@@/addressing/anonymous" is used in the
> context of  a SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts],
> then it MUST [or MAY] refer to the use of the response message of 

I don't understand this. What does it mean "MUST [or MAY] refer to the
use of the response message"? The URI refers to the *endpoint*, not the
response message. It is "the endpoint that is reached via the
channel provided by a protocol-specific binding in the context
of some MEP". I don't see how it can have any other meaning. It doesn't
refer to a message, at least not as I see it. Maybe that is where 
we are not seeing eye to eye.

If the [address] is non-anonymous, what does it refer to? It refers
to an endpoint that can be accessed by resolving that URI to an 
IP address and port and opening a socket connection and passing 
the part component of that URI to the other side.

I think I also now understand what you are trying to express here.
That the WSDL output|fault message (if any) corresponding to the
WSDL input message carrying a [reply endpoint] with [address]
anonymous MUST be made available as the OutputMessage of the same 
instance of the SOAP R-R MEP for which the WSDL input message was 
received. Is that a more precise description 
of the above? If so, why not say that explicitly?

I frankly don't see how the above conflicts with the definition of
the anon URI I provided. The problem I have with the definition
you provided is that it refers to messages, and I find that 
problematic. IMO, the anon (as well as a non-anon) URI refers to 
the address of an endpoint. In the anon case, it refers to the
endpoint that is at the other end of a channel that has been
provided by the binding.

> the exchange.  When in particular it is used in a response endpoint 
> in a request message, any response MUST be the response part of the 
> same SOAP request-response message exchange [SOAP 1.2 Part 2: Adjuncts].
> Note how the first sentence talks about anonymous generically 
> (albeit in the context of a particular MEP) and the second narrows 
> down the behavior of response endpoints in particular.  I believe 
> this is in line with the two-level approach that Umit is advocating.
> That was certainly my intent in bringing the new text into the 
> already agreed text from the Editors' draft.
> 
> If we take this approach, we still have to decide whether we mean 
> MUST or MAY in the above, but I hope at least the question is 
> phrased clearly enough we can decide.
> 
> I would offer up the following definition of the semantics of the 
> anon URI for your amusement: 
> 
> The "http://www.w3.org/@@@@/@@/addressing/anonymous" URI MAY be 
specified as
> the [address] of an EPR to designate that the target endpoint is reached 
via 
> a contextualized channel of the underlying SOAP protocol binding. 
> The specification 
> of the relevant context is provided by the definition of the EPR 
> element itself 
> as it relates to the underlying SOAP protocol binding and/or SOAP 
Message 
> Exchange Pattern definitions. 
> 
> I think that this permits the definition of the semantics of the 
> anon URI for the [reply endpoint] and [fault endpoint] 
> by specifying that the context of that EPR is defined by virtue of 
> the SOAP MEP, as I have suggested 
> above. 
> 
> [1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0175.html
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295 
> 
> public-ws-addressing-request@w3.org wrote on 02/22/2006 02:45:46 PM:
> 
> > Here, then, are two simple resolutions 
> > 1. Close with no action.  Simple.  Done. 
> > 2. Section 5 to read as below.  The rules now apply to any endpoint.
> > Simple.  Done. 
> > 5.1.1 SOAP 1.1/HTTP 
> > When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified 
> > for an endpoint in a request message then there is no change to the 
> > SOAP 1.1/ HTTP binding. 
> > 5.1.2 SOAP 1.2 
> > When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified 
> > for an endpoint in the request part of a SOAP request-response 
> > message exchange [SOAP 1.2 Part 2: Adjuncts], then any message sent 
> > to that endpoint MUST be the response part of the same SOAP request-
> > response message exchange [SOAP 1.2 Part 2: Adjuncts]. 
> > 
> > Yalcinalp, Umit wrote: 
> > It seems to me we are just making a big deal out of an issue which is
> > easily fixed here in WS-A. 
> > 
> > We separate the problem into two separate issues: 
> > 
> > --define the anonymous URI's semantics 
> > --define the WS-A MAP semantics for reply endpoint/fault endpoint with
> > anonymous value. This wg can provide specific semantics for these two
> > MAPs we define which builds on anonymous URI and their relationship to
> > MEPs.
> > 
> > Nothing more, nothing less. 
> > 
> > Katy's proposal for CR23 [1] is definitely in the right direction and 
we
> > should fix this problem in this manner, by careful decomposition of 
the
> > problem. 
> > 
> > Intermixing the solution of these two issues and thinking in a very
> > restricted sense for the semantics of anonymous is not a good 
approach.
> > As a matter of fact, fusing the two solutions breaks composition for
> > other groups. The semantics of Anonymous should not be restricted to
> > specific MEPs, but can be further used to define the semantics in
> > certain MEPs and WS-A MAPs. Fusing the two prevents the composition, 
IMO
> > and I am weary of the tendency here. 
> > 
> > WS-RX can define the semantics of acksTo (which it owns) based on the
> > anonymous URI only. It can crisply define how acksTo can be used in 
its
> > own context and in conjunction with its own protocol exchanges/when it
> > is allowed, etc. 
> > 
> > It seems to me that resolving CR23 in this manner, we do not hinder 
any
> > composition, not the other way around. 
> > 
> > --umit
> > 
> > 
> > [1]
> > 
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0167.ht
> > ml
> > 
> > 
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org 
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> > David Orchard
> > Sent: Wednesday, Feb 22, 2006 8:27 AM
> > To: paul.downey@bt.com; dmh@tibco.com; public-ws-addressing@w3.org
> > Subject: RE: Clarification for WS-RX
> > 
> > 
> > OTOH, the last thing I want is some profile to crop up that 
> > "fixes" for
> > WS-RX how "broken" WS-A is.  At the end of the day, the stuff is
> > supposed to be composable, etc.
> > 
> > Cheers,
> > Dave 
> > 
> > 
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org 
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> > paul.downey@bt.com
> > Sent: Wednesday, February 22, 2006 6:09 AM
> > To: dmh@tibco.com; public-ws-addressing@w3.org
> > Subject: RE: Clarification for WS-RX
> > 
> > 
> > 
> > 
> > 
> > I'm a bit loath to send this to the whole WS-RX list, and I think 
> > there are enough WS-RXperts here to answer, so ...
> > 
> > but this is Web service addressing and I'm bothered that we 
> > do seem to keep descending into glorious detail on how WS-RX 
> > may or may not work, rather than answering tractable LC and 
> > CR comments from that WG wrt our specifications.
> > 
> > Paul
> > 
> > 
> > 
> > ______________________________________________________________
> > _________
> > Notice:  This email message, together with any attachments, 
> > may contain
> > information  of  BEA Systems,  Inc.,  its subsidiaries  and 
> > affiliated
> > entities,  that may be confidential,  proprietary, 
> > copyrighted  and/or
> > legally privileged, and is intended solely for the use of the 
> > individual
> > or entity named in this message. If you are not the intended 
> > recipient,
> > and have received this message in error, please immediately 
> > return this
> > by email and then delete it.
> > 
> > 
> > 
> > 
> >