Re: Clarification for WS-RX

Dave,

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

This makes no sense to me at all. First off, what endpoint? The response 
endpoint? Any EPR? I certainly
hope not the latter. It actually makes the situation worse, not better 
than the status quo.

The spec [1] currently reads: 

When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified for the 
response
 endpoint and the request is the request part of a SOAP request-response 
MEP [SOAP 1.2 Part 2: Adjuncts], 
then any response MUST be the response part of the same SOAP 
request-response 
MEP [SOAP 1.2 Part 2: Adjuncts]. 

therefore, one would assume that what you possibly *meant* to write was:

 When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified 
 for the response 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].

However, I'm not at all clear that this is at all a meaningful 
improvement. By definition, any message
is the response. Are you trying to say that the endpoint has a scope of 
exactly that MEP and that it has
no meaning outside the context of that instance of the MEP? If so, then 
say that in plain english.

The term "response endpoint" is first introduced here (section 5.1), and 
is not 
defined anywhere. It is also only used in sections 5.1 and 5.2 of the SOAP 
binding spec. Possibly,
what was meant was to be more precise and refer to the [reply endpoint] 
property. I would offer up that IMO,
it should also apply to the [fault endpoint] property, as I see no reason 
that you can't have the
[reply endpoint] be non-anonymous and the [fault endpoint] be anonymous.

 When "http://www.w3.org/@@@@/@@/addressing/anonymous" is specified 
 for either, or both, of the [reply endpoint] and/or [fault endpoint], 
then 
 any use of that endpoint reference as a [destination] MUST be scoped to 
 the same instance of a given SOAP message exchange pattern such as the 
 SOAP request-response message exchange pattern [SOAP 1.2 Part 2: 
Adjuncts].

Basically, this says that the anonymous [reply endpoint] and [fault 
endpoint] EPR is useless outside 
the context of an instance of a given MEP. It is not clear to me that you 
would want to limit the definition 
to its relevance to the SOAP R-R MEP. Other MEPs may be defined for which 
the anon [reply endpoint]
property has relevance.

However, getting back to Umit's point, I think it is critical to 
distinguish the semantics of
the anonymous URI as being independent of the EPR element that carries it. 


In your previous note [1] in response to Katy's proposed resolution for 
CR23, you made the following
observation:

My larger concern is how one would build on this.  I may use anonymous
as the address of any EPR.  What this means depends on the MEP and
definition of the EPR in question (i.e., whether it's [destination],
[reply endpoint], AcksTo or whatever, IIUC).  The SOAP request-response
MEP defines a channel for response messages.

Is this meant to say that, in the context of a SOAP request-response
MEP, use of anonymous MUST refer to use of the response message, or that
it MAY refer to it?  If it's MUST, this disallows the proposed use for
cases where a TCP connection is kept open.  If it's MAY, then referring
to anonymous doesn't guarantee use of the back channel.  If it's
neither, just exactly what are we saying?

If we're trying to say that, in the context of request-response,
anonymous always and only refers to the response message of
request-response, then fine, but then let's say it in as many words.

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.

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