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


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.

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]