W3C home > Mailing lists > Public > public-ws-addressing@w3.org > August 2006

Re: CR33: Describing RM using WSDL?

From: Doug Davis <dug@us.ibm.com>
Date: Mon, 14 Aug 2006 20:09:32 -0400
To: Alastair Green <alastair.green@choreology.com>
Cc: Christopher B Ferris <chrisfer@us.ibm.com>, Jonathan Marsh <jmarsh@microsoft.com>, "[WS-A]" <public-ws-addressing@w3.org>, public-ws-addressing-request@w3.org
Message-ID: <OF96FF3F18.FEC79B15-ON852571CB.0000A071-852571CB.0000DFBA@us.ibm.com>
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
> > > 
Received on Tuesday, 15 August 2006 00:10:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:14 GMT