Re: CR33: Describing RM using WSDL?

Alastair,
 If the wording in the RM spec isn't clear then we can open an issue and 
fix that - but the intent of the wording in the spec is to allow the RM 
anon URI to act like the WSA anon URI as long as the original backchannel 
is open - once it is no longer available then MakeConnection is needed. 
Given that, I think a WSA WSDL marker that precludes the use of any other 
anon URI in a wsa:ReplyTo header is of some concern to the RM spec. 
Wsaw:anon=prohibited isn't the right answer because that would prevent the 
use of anon w/o RM - meaning a non-RM client wouldn't be able to use WSA's 
anon.  Anish and I are working on some new text for the wsdl marker - 
hopefully it'll help.
thanks
-Doug




Alastair Green <alastair.green@choreology.com> 
Sent by: public-ws-addressing-request@w3.org
08/14/2006 11:49 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
Christopher B Ferris/Waltham/IBM@IBMUS, Jonathan Marsh 
<jmarsh@microsoft.com>, "[WS-A]" <public-ws-addressing@w3.org>, 
public-ws-addressing-request@w3.org
Subject
Re: CR33: Describing RM using WSDL?






Doug,

There is a small but important difference between what I said in c):

"that the receiver can do either a), or b), depending on how they feel/the 
application contract?"
 
and what you said in your reply: 

"The RM anon URI is just like the WSA anon URI as long as the original 
connection's backchannle is available."

The WS-A anon "expectation", as I read WS-A Core/SOAP Binding, is 
generally that there will be a good reply or a fault. It is intended for 
use when the application has a request-reply message exchange, and the 
only exception to "message in/message out", is a fault. Strictly, I think, 
this expectation only turns into a true contract if using SOAP 1.2 RR MEP, 
but that is at least one important case where the spirit becomes the 
letter of the law. Therefore, the possibility of an empty, non-fault 
response is precluded, in general, by use of WS-A anon.

Whereas, the RM facility is about polling for response messages that may 
not be available. The RM anon contract is different. It says: there will 
be a good reply (a SOAP envelope with app stuff in it), a transport-level 
ack (no SOAP envelope) if applicable, or a fault. There is explicit 
reference in RM 3.7 to a non-message, non-faulting response (aka, an ack).

If true, this is, I think, significant for the WSDL issue.

If the RM anon URI (RM-AU) induces exactly the same behaviour as WS-A anon 
URI (WS-AU) when inserted in a response endpoint, then it would be no 
different from the WS-AU. 

[Parenthetically, this would entirely undermine the justification for the 
existence of the special RM-AU. The passing of the UUID part on app 
messages could easily be accomplished by application means, or by use of 
wsa:From, etc].

The RM spec says that the RM-AU is "semantically similar" to the WS-AU if 
the back-channel is available. This is a dangerous piece of wording -- it 
conceals more than it reveals. It seems that the intent is that RM URI 
will always allow the transport to ack immediately if no message is 
available. This might, for example, translate into a rule that SOAP 1.2 RR 
MEP cannot be used in combination with it.

Looking at this from the WSDL standpoint. I don't believe that the 
wsa:Anon marker can have anything to say about RM-AU, because it has 
different semantics from WS-AU. I don't see how they can be treated as 
substitutable, equivalent, values for a response endpoint. Put another 
way, RM-AU is not a superset or sub-class of WS-AU -- it has different 
base behaviour.

This would indicate on a first pass that wsa:Anon = prohibited, and a 
WS-RM-specific marker would be the right combination if the RM-AU was 
needed.

Alastair

Section 3.7 of the RM spec excerpted, my emphasis:

'This URI template in an EPR indicates a protocol-specific back-channel 
will be established through a
mechanism such as MakeConnection, defined below. When using this URI 
template, ?{uuid}? MUST be
replaced by a UUID value as defined by RFC4122[UUID]. This UUID value 
uniquely distinguishes the
endpoint. A sending endpoint SHOULD transmit messages at endpoints 
identified with the URI template
using a protocol-specific back-channel, including but not limited to those 
established with a
MakeConnection message. Note, this URI is semantically similar to the 
WS-Addressing anonymous
URI if a protocol-specific back-channel is available.

The MakeConnection is a one-way operation that establishes a 
contextualized back-channel for the
transmission of messages according to matching criteria (defined below). 
In the non-faulting case, if no
matching message is available then no SOAP envelopes will be returned on 
the back-channel.'

Doug Davis wrote: 

Alastair, 
  section 3.7 of the RM spec says, or tries to say :-), that the service 
may use any appropriate 
transport backchannel.  So, the response to your question is 'c'. The RM 
anon URI is just like 
the WSA anon URI as long as the original connection's backchannle is 
available.  Once that 
is lost, then the RM-ness kicks in an a MakeConnection is required.  It 
was very important, from 
a performance perspective, to not require a MakeConnection if it wasn't 
necessary. 
thanks, 
-Doug 


public-ws-addressing-request@w3.org wrote on 08/14/2006 04:34:28 PM:

> Doug,
> 
> I'd like to ask a question which may help frame today's discussion.
> 
> If a message (eg GetStockQuote), carried in a transport request, 
> has a [reply endpoint][address] set to RM's special anon+UUID does 
> this imply (in your view)
> 
> a) that the receiver will send a message in the transport response 
> to the tranport request, or 
> 
> b) that the sender of the transport request will, at some future 
> point, send a wsrm:MakeConnection, which will allow a message to be 
> sent in the transport response to the transport request that carried
> the message containing the MC element, or
> 
> c) that the receiver can do either a), or b), depending on how they 
> feel/the application contract?
> 
> 
> a) and b) would equate to the following sequences:
> 
> a) 
> 
> Transport request A/message 1/reply=anon+UUID
> Transport response A/message 2 [part of the same application-level 
> conversation as message 1]
> 
> or, b)
> 
> Transport request A/message 1/reply=anon+UUID
> Transport response A/[ack/no message]
> Transport request B/message 2/wsrm:MakeConnection/Address=anon+UUID
> Transport response B/message 3/ [part of the same application-level 
> conversation as message 1]
> 
> I don' t think the design intent here is written down anywhere, is it?
> 
> Thanks,
> 
> Alastair
> 
> 
> 
> Doug Davis wrote: 
> 
> Yes, thank goodness for the 'SHOULD' :-)  although, it would seem a 
> bit odd for WSA to preclude some other URI from being defined that 
> means something other than 'open a connection' - especially when 
> 'none' seems to do exactly that - thus violating that rule. And I 
> would point out the Note at the end of the paragraph you pointed me to:  

>   Note that other specifications MAY define special URIs that have other 

>   behaviors (similar to the anonymous URI). 
> which is exactly what RM does - so how does this last sentence 
> coexist with the wsaw:Anon marker?  The sentence seems to imply some
> extensibility, but the marker (as currently worded) removes it. And 
> this is our concern with the marker - not that RM wants to reuse it 
> - RM actually doesn't use it at all.  But we want to make sure that 
> this marker doesn't unnecessarily prevent us from using an 
> extensibility point in the core WSA spec. 
> 
> IMO, if the wsaw:Anon text were reworded in a similar way to how 
> that paragraph was worded (something akin to: WSA defines the anon 
> URI but other specs can define their own too, and this flag 
> indicates whether or not an anon-like URI must be used) then I think
> the WSDL spec would be consistent with the core spec and keep the 
> extensibility point intact.  Even simply changing the MUST to a 
> SHOULD would do it too - as Chris pointed out. 
> 
> thanks 
> -Doug 
> 
> 
> public-ws-addressing-request@w3.org wrote on 08/14/2006 10:29:46 AM:
> 
> > OK, so the problem is in [1] which conflates ?non-anonymous? with 
> > ?addressable?.  That implies that any URI other than the WS-A 
> > anonymous SHOULD NOT use the back-channel.  Fortunately (if the RM-
> > style-anonymous is a good idea, which I still am not sure of), the 
> > SHOULD is there, which may give us wiggle room. 
> > 
> > But since RM hasn?t reused our anonymous URI, I don?t see why you 
> > want to reuse our wsaw:Anonymous marker.  Why doesn?t RM-anonymous 
> > have its own marker, which may or may not be composable with all 
> > values of wsaw:Anonymous?  (Composition of a policy expression with 
> > a WSDL extension seems like it might be tricky too.) 
> > 
> > [1] 
http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/#nonanonaddress 
> > 
> > 
> > 
> > From: Doug Davis [mailto:dug@us.ibm.com] 
> > Sent: Sunday, August 13, 2006 5:49 PM
> > To: Jonathan Marsh
> > Cc: Alastair Green; Christopher B Ferris; [WS-A]
> > Subject: Re: CR33: Describing RM using WSDL? 
> > 
> > 
> > The interaction we're talking about _is_ an application-level 
> > interaction.  Using the classic 
> > StockQuote example, when the GetStockQuote request flows there are 
> > three possible 
> > values for wsa:ReplyTo that are of interest to this conversation: 
> > 1 - addressable URI (e.g. ibm.com) 
> > 2 - WSA's anonymous 
> > 3 - RM's anonymous 
> > 
> > Obviously 1 is the normal async response case.  Its the 2nd and 3rd 
> > cases that get a 
> > bit more interesting.  If the wsaw:Anonymous is set to 'required' in
> > the WSDL then it would 
> > preclude the use of RM's anonymous on the GetStockQuote request 
> message even 
> > though its use is consistent with WSA's anonymous, so this would 
> > mean only '2' is allowed. 
> > 
> > Not being involved in the history behind the wsaw:Anonymous flag I'm
> > guessing that 
> > its intended to let the client know whether or not the server will 
> > support sending back 
> > async responses or whether the client is limited to receiving them 
> > thru the transport 
> > back-channel.  RM's anonymous fits this pattern - which is why we 
> > have some concern 
> > with this flag if it only allows WSA's anonymous URI, and isn't 
> > extensible to support 
> > consistent (but different) URIs. 
> > 
> > RM's policy assertions do compose with WSA's but they only deal 
> withwhether or
> > not RM is required/optional - they do not say anything about the use
> > of anonymous. 
> > 
> > thanks, 
> > -Doug 
> > 
> > 
> > "Jonathan Marsh" <jmarsh@microsoft.com> wrote on 08/13/2006 07:36:05 
PM:
> > 
> > > I don't understand how wsaw:Anonymous (which is used for describing
> > > application-level interactions) and RM's use of a pseudo-anonymous 
URI
> > > would interact.  Are you trying to describe the RM protocol in WSDL?
> > > Don't you have an RM policy assertion for that?
> > > 
> > > It would be unfortunate if wsaw:Anonymous and the RM policy weren't
> > > composable.  This issue implies they aren't, that the 
application-level
> > > interactions aren't independent from protocol-level interactions, 
and
> > > that there may be constraints to the allowable values of 
wsaw:Anonymous
> > > when RM is engaged, which if true seems like a design flaw that 
can't be
> > > fixed simply by twiddling with the definition of wsaw:Anonymous.
> > > 
> > > > -----Original Message-----
> > > > From: public-ws-addressing-request@w3.org
> > > [mailto:public-ws-addressing-
> > > > request@w3.org] On Behalf Of Bob Freund
> > > > Sent: Wednesday, August 09, 2006 6:36 PM
> > > > To: Alastair Green; Doug Davis
> > > > Cc: Christopher B Ferris; [WS-A]
> > > > Subject: RE: CR33
> > > > 
> > > > 
> > > > Alastair,
> > > > The issue may be viewed at
> > > > http://www.w3.org/2002/ws/addr/cr-issues/#cr33
> > > > Thanks for joining.
> > > > -bob
> > > > 
> > > > > -----Original Message-----
> > > > > From: Alastair Green [mailto:alastair.green@choreology.com]
> > > > > Sent: Wednesday, August 09, 2006 4:20 PM
> > > > > To: Doug Davis
> > > > > Cc: Bob Freund; Christopher B Ferris; [WS-A]
> > > > > Subject: Re: CR33
> > > > >
> > > > > Hi Bob,
> > > > >
> > > > > If CR33 is something to do with the current RM-inspired 
discussion
> > > > then
> > > > > I would very much like to take part. Thank you for inviting me.
> > > > >
> > > > > I'm deep in the bowels of correspondence. Can you let me know 
what
> > > > CR33
> > > > > says, how do I find a link to it, etc? I am not familiar with 
your
> > > > > process, I'm afraid, and I haven't read the full gamut of mails 
from
> > > > > today.
> > > > >
> > > > > Yrs,
> > > > >
> > > > > Alastair
> > > > >
> > > > > Doug Davis wrote:
> > > > > >
> > > > > > Thanks Bob - I'll be there.
> > > > > > -Doug
> > > > > >
> > > > > >
> > > > > >
> > > > > > *"Bob Freund" <bob@freunds.com>*
> > > > > >
> > > > > > 08/09/2006 01:28 PM
> > > > > >
> > > > > >
> > > > > > To
> > > > > >    Christopher B Ferris/Waltham/IBM@IBMUS, "Alastair Green"
> > > > > > <alastair.green@choreology.com>, Doug Davis/Raleigh/IBM@IBMUS
> > > > > > cc
> > > > > >    "[WS-A]" <public-ws-addressing@w3.org>
> > > > > > Subject
> > > > > >    CR33
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Alastair, Chris, and Doug,
> > > > > >
> > > > > > The agenda for next Monday's meeting of ws-addressing will 
feature
> > > > > > CR33 which was originated by Doug Davis.
> > > > > >
> > > > > > I would like to invite you to participate in the call to 
express
> > > > your
> > > > > > points of view and participate in the resolution of this 
issue.
> > > > > >
> > > > > > The call is scheduled for 4:00p-6:00 US Eastern time.
> > > > > >
> > > > > > The conference call bridge is via Zakim +1-617-761-6200 access
> > > code
> > > > > > 2337(addr)
> > > > > > Irc is available at irc.w3.org, port 6665, and the channel for 
the
> > > > Web
> > > > > > Services Working Group is _#ws-addr_
> > > > <irc://irc.w3.org:6665/#ws-addr>.
> > > > > >
> > > > > > I hope that through your participation we can achieve a 
consensus
> > > > > > resolution to this issue quickly. Please let me know if you 
plan
> > > to
> > > > > > participate.
> > > > > >
> > > > > > Thanks
> > > > > > -bob
> > >