Re: CR33: Describing RM using WSDL?

Doug,

Look forward to seeing the proposal.

It's the design intent/impact on WS-A I'm primarily interested in. I 
think the RM wording is not super-clear, but that's very much a 
secondary question.

On a lenient view, WS-A anonymous URI means: "you can send me a message 
in the transport response, if you like, but you could also just send me 
an ack and no real message". If this is the case then I don't think 
WS-RM needs a new URI at all, and therefore WS-A WSDL shouldn't have to 
be affected by what RM is up to.

Or, WS-A anonymous URI could be viewed as having a stricter meaning: "by 
saying anon I am not giving you permission to send a message in the 
transport response; I am /telling/ you that you are expected to return a 
message (and failure to do so would indicate a fault condition)". In the 
SOAP/HTTP context, I guess this would mean that absence of an envelope 
in the response would equate to a SOAP fault and/or a bad HTTP status.

If WS-A anon has the second meaning (is effectively a synonym for SOAP 
1.2 RR MEP), then WS-RM does need a new URI -- which by definition will 
not have the same meaning as the WS-A anon, as it will permit a simple ack.

I would appreciate the view of the WS-A WG on those two alternative 
interpretations of WS-A anon URI. (Of course, both could be false in 
some way that I have missed.)

Alastair

Doug Davis wrote:
>
> 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_ 
> <mailto: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_ 
> <mailto: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>_ 
> <mailto: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>
> > > > [_mailto:public-ws-addressing_-
> > > > > _request@w3.org_ <mailto: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>_ <mailto:bob@freunds.com>*
> > > > > > >
> > > > > > > 08/09/2006 01:28 PM
> > > > > > >
> > > > > > >
> > > > > > > To
> > > > > > >    Christopher B Ferris/Waltham/IBM@IBMUS, "Alastair Green"
> > > > > > > _<alastair.green@choreology.com>_ 
> <mailto:alastair.green@choreology.com>, Doug Davis/Raleigh/IBM@IBMUS
> > > > > > > cc
> > > > > > >    "[WS-A]" _<public-ws-addressing@w3.org>_ 
> <mailto: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
> > > >