- From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
- Date: Wed, 22 Feb 2006 16:48:07 -0800
- To: "David Hull" <dmh@tibco.com>, "Christopher B Ferris" <chrisfer@us.ibm.com>
- Cc: "David Orchard" <dorchard@bea.com>, <paul.downey@bt.com>, <public-ws-addressing@w3.org>, <public-ws-addressing-request@w3.org>
- Message-ID: <2BA6015847F82645A9BB31C7F9D64165011989F0@uspale20.pal.sap.corp>
It is not clear to me whether I am able to follow your argument at this
point. Let me try.
Based on what you are saying
{However, I think the text I gave previously captures all we need to
capture:
When "http://www.w3.org/@@@@/@@/addressing/anonymous"
<http://www.w3.org/@@@@/@@/addressing/anonymous> is used in the context
of a SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap
.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2> ], then it
MUST [or MAY] refer to the use of the response message of 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
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap
.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2> ].
}
and
{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. }
If you are saying that this text captures all we need to solve CR23 and
also captures my intention, I would have to disagree. If you are saying
something else, then your point was not clear to me.
The rest of my message assumes that the you claim the text quoted above
captures all we need to solve CR23.
Closing the issue or accepting this text is not acceptable because it
ties the defn of the anonymous with in a particular MEP without defining
that it may also used in other contexts to refer to a backchannel. This
is NOT the two level approach I am advocating.
I advocate keeping the definition of anonymous independent of the
specific MEP. Without a generic text that Katy and Chris has proposed
first that applies to the definition of anonymous on its own, you can
not build other usages of anonymous within the context of EPRs other
than reply endpoint and fault endpoint.
Lets repeat them here for completeness to see what our alternatives are
so far.
Alternative 1: (Katy)
{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 by a channel of the underlying SOAP protocol binding.
The specification of the channel to which the
"http://www.w3.org/@@@@/@@/addressing/anonymous" URI refers depends on
the
Message Exchange Pattern (MEP) and on the
defined semantics of the EPR in question. Any underlying protocol
binding supporting the SOAP
request-response MEP provides such a channel for
response messages.
}
Alternative 2: (Chris)
{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.
}
Without one of these definitions that specify anonymous on its own, your
text is not enough. There may be other text that may be crisper. I can
live with them so far.
Based on the last concall, it seems to me however that you specifically
do not want to define anonymous to apply outside the context of an MEP
and independent of reply endpoint and fault endpoint. Please explicitly
state whether you agree with the goal of defining anonymous independent
of a specific MEP.
This is exactly what the WS-RX group asked for us to enable [1]. Hence,
your proposed text is not enough to close CR23 and it is not acceptable
to close this without action.
We made a decision to support their request, and the wg unintentionally
disabled the use case by accepting CR15. Those of us who agreed to the
resolution of CR15 never intended to disable CR4. I do hope that
disabling CR4 was not your intention.
--umit
[1]. http://www.w3.org/2002/ws/addr/cr-issues/#cr4
________________________________
From: David Hull [mailto:dmh@tibco.com]
Sent: Wednesday, Feb 22, 2006 3:41 PM
To: Christopher B Ferris
Cc: David Orchard; paul.downey@bt.com;
public-ws-addressing@w3.org; public-ws-addressing-request@w3.org;
Yalcinalp, Umit
Subject: Re: Clarification for WS-RX
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.
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 the
context of SOAP 1.2 request-response, anonymous MUST [or MAY] refer to
the response message." and then when talking about 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.
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.
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"
<http://www.w3.org/@@@@/@@/addressing/anonymous> is used in the context
of a SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap
.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2> ], then it
MUST [or MAY] refer to the use of the response message of 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
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2004/ws/addressing/ws-addr-soap
.html?content-type=text/html;%20charset=utf-8#SOAP12-PART2> ].
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"
<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.ht
ml
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"
<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"
<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.
>
>
>
>
>
Received on Thursday, 23 February 2006 00:44:33 UTC