RE: An Example Use of RM's MakeConnection

+1. Encapsulating the "sub-conversation identifier" (as Alastair termed
it) in the EPR has enormous benefits.
 
- gp


________________________________

	From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Doug Davis
	Sent: Tuesday, October 10, 2006 10:09 AM
	To: public-ws-addressing@w3.org
	Subject: Re: An Example Use of RM's MakeConnection
	
	

	Alastair, 
	  There's a component of WSA that people are not really taking
to account when thinking about solutions to this problem, and that's the
EPR itself.  One of the many good things that WSA has given us is that
standard/consistent/reusable structure of how to refer to an endpoint.
Whether we want to share this information with another soap node, so we
put it into a soap envelope some place, or whether we are passing this
information around inside of our soap stacks, WSA has provided a very
nice wrapper for this information.  In the past we may have just passed
around a URI/String, but the EPR is far more flexible and useful than
that.  I believe that once people have adopted WSA the switch from
URI/String to EPR is one that is very wide-spread and nontrivial.  Once
it is done most of the code that may interact with an EPR really doesn't
need to do anything with the data inside of the EPR itself.  In most
cases the only time you would ever really need to look inside of it is
at the time the soap stack actually tries to send a message to that EPR.
And even then, I would hope its just the wsa:Address value that is
examined - the other bits (ref-p's) are just blindly echoed as headers. 
	
	  So, if people are passing around EPRs I get really worried at
the suggestion that something else needs to be passed around as well in
order to correctly talk to that EPR.  The thought that people will need
to revamp all of their code that deals with EPRs to also pass along
additional information is something that should not be taken lightly.  I
would also suggest that whether we are pushing messages that EPR (async)
or whether we are pulling messages for that EPR (makeconnection), the
logic above the transport layer should be blissfully unaware of it.
While as with all good rules there are exceptions, in the general case I
see no reason why the application should concern itself with whether the
wsa:Address field of the [destination] EPR is  http://www.cnn.com,
http://.../wsa/anonymous, http://..../wsa/none, or http://.../wsrx/anon.
The specific value of the URI is really not of any concern to it.  This
abstraction that the EPR construct provides is a very powerful and
useful one - and we should strive to maintain it. 
	
	 To your suggestion that there can be additional headers - given
all of the above, I do not believe any of that information should be
external to the EPR. Correlation related to semantics above the
transport layer (e.g. what Tx are we using) are things that make sense
as additional headers but information directly related to the endpoint
reference should be part of the EPR.  And I have similar concerns with
the wsa:RelatesTo proposal.  These proposals would, IMO, break existing
code that assumes an EPR is all that is needed when passing around
references. From personal experience (from a coder's perspective) the
impact of having to pass around anything more than what we already do
(meaning an EPR) would be huge (not to mention, IMO, the wrong choice
:-). 
	
	thanks 
	-Doug 
	
	
	
	
Alastair Green <alastair.green@choreology.com> 

10/09/2006 08:40 PM 

To
Christopher B Ferris/Waltham/IBM@IBMUS 
cc
Marc Hadley <Marc.Hadley@Sun.COM>, Doug Davis/Raleigh/IBM@IBMUS,
public-ws-addressing@w3.org, public-ws-addressing-request@w3.org 
Subject
Re: An Example Use of RM's MakeConnection

	




	I think we need to take a step back.
	
	The example I gave (shorn of XML) is in my view exhaustive. If
you can support this use case, then you're done -- for all applications
(including RM) that need to create a bilaterally-initiated conversation
out of a monologue.
	
	Here it is again:
	
	Given a connection identified as X, between endpoint A (that is
non-addressable) and endpoint B (that is addressable), I posited the
following canonical use case in a recent posting to WS-RX:
	
	A req: message 1, connection X, reply to anon if available. 
	B resp: message 2 
	A req: message 3, connection X, reply to anon if available 
	B resp: no envelope, 202, i.e. message not available 
	A req: MakeConnection, X 
	B resp: message 4, MessagePending 
	A req: MakeConnection, X 
	B resp: message 5 
	
	Net effect, for connection/conversation identified as X:
	
	A to B: message 1
	B to A: message 2
	A to B: message 3
	B to A: message 4
	B to A: message 5
	
	>From this you can draw out four semantic elements for which
someone must define types and syntax:
	
	1. An identifier for the conversation (X is an instance of this
type)
	2. An indication that a response on the back channel is
legitimate (but optional), if the recipient has a message that belongs
to the conversation X
	3. A no-op message, that invites an (optional) message on the
back channel that belongs to the conversation X
	4. An indication that it is worth sending no-op message 3 again,
because the number of responses to a message bearing indication 2, or a
message of type 3, is > 1.
	
	These are elements of a protocol that is a) nothing inherently
to do with WS-RM (one can imagine other uses) and b) nothing inherently
to do with WS-Addressing as it currently stands (you can do it all
without WS-A as it is today, hence the impulse to waive WS-A 3.4.)
	
	Examples of things like X are: conversation identifiers, and
sub-conversation identifiers, which map to a conversation identifier
(UUID and sequence id, in RM's case).
	
	Concretely, for a protocol called TalkToMe, ns prefix T:
	
	1) A header element <T:Identifier/> whose content is any
application-meaningful element (e.g. a UUID, or a sequence identifier),
and whose presence imports: "know this identifier, and respond to it on
the back channel of this or any subsequent message containing the same
identifier"
	
	2) A body element <T:Pull/>, which must have present and
associated a header <T:Identifier>, whose back-channel response may be
any message relating to the value of <T:Identifier>.
	
	3) A header element <T:MessagePending/>, which should only be
present in a message on the back-channel which relates to a prior
message carrying the header element <T:Identifier/>, which imports: "I
have another message relating to this conversation to send you".
	
	If WS-Addressing defined this protocol, then we could all use
it, and all users would stop pestering WS-Addressing.
	
	In other words, the "novel, unorthodox, interesting" MEP would
find a natural home, and become "customary, acknowledged, orthodox,
usual -- and generic".
	
	Each application would then be responsible for defining its
valid types for the child element (content) of <T:Identifier/>.
	
	This approach fully exploits the self-correlating nature of the
back-channel. I can't see why we need to explicitly state a relationship
that is unambiguous by its very fact. The identifier needed does not
relate to an individual message, but to a conversation.
	
	Alastair
	
	
	
	Christopher B Ferris wrote: 
	
	Marc, 
	
	Fine for handling request/response I suppose. However, not
everything is request/response. How does this work when 
	there is no "response" but rather a need to get messages from
the "server" to the "client"? 
	
	Cheers, 
	
	Christopher Ferris
	STSM, Software Group Standards Strategy
	email: chrisfer@us.ibm.com <mailto:chrisfer@us.ibm.com> 
	blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
<http://www.ibm.com/developerworks/blogs/page/chrisferris> 
	phone: +1 508 377 9295 
	
	public-ws-addressing-request@w3.org
<mailto:public-ws-addressing-request@w3.org>  wrote on 10/09/2006
12:26:07 PM:
	
	> Looking at the message flow, I think WS-RM could make more use
of  
	> wsa:RelatesTo instead of inventing a new anon URI. Here's the
same  
	> message flow using the WS-A anon URI and making more use of  
	> wsa:RelatesTo and @RelationshipType.
	> 
	> I think this formulation removes the requirement for
additional WSRM- 
	> specific anon URIs, let me know if I missed anything.
	> 
	> Marc.
	> 
	> Scenario: Client sends GetQuote to server unreliably.  Server
wants  
	> to send GetQuoteResponse using RM so it must sent a
CreateSequence  
	> before I can send the GetQuoteResponse back.
	> 
	> Step 1 - Client sends GetQuote to Server
	> <soap:Envelope ...> <soap:Envelope...> 
	>   <soap:Header> <soap:Header> 
	>    <wsa:To> http://stockquote.com <http://stockquote.com/>
</wsa:To>
	>    <wsa:Action> foo:GetQuote </wsa:Action>
	>    <wsa:MessageID> uuid://.../100 </wsa:MessageID>
	>    <wsa:ReplyTo>
	>     <wsa:Address>http://www.w3.org/.../anonymous
<http://www.w3.org/.../anonymous> </wsa:Address>
	>    </wsa:ReplyTo>
	>   </soap:Header <soap:Header> >
	>   <soap:Body> <soap:Body> 
	>    <foo:GetQuote> IBM </foo:GetQuote>
	>   </soap:Body <soap:Body> >
	> </soap:Envelope <soap:Envelope> >
	> 
	> Step 2 - Server sends an RM CreateSequence to the Client using
the  
	> only means it has available - the transport backchannel.
	> <soap:Envelope ...> <soap:Envelope...> 
	>   <soap:Header> <soap:Header> 
	>    <wsa:To>http://www.w3.org/.../anonymous
<http://www.w3.org/.../anonymous> </wsa:To>
	>    <wsa:Action> http://...wsrm/CreateSequence
<http://...wsrm/CreateSequence>  </wsa:Action>
	>    <wsa:MessageID> uuid://.../101 </wsa:MessageID>
	>    <wsa:RelatesTo
RelationshipType="http://...wsrm/InitReliable"
<http://...wsrm/InitReliable> >
	>      uuid://.../100
	>    </wsa:RelatesTo>
	>    <wsa:ReplyTo>
	>     <wsa:Address> http://stockquote.com
<http://stockquote.com/>  </wsa:Address>
	>    </wsa:ReplyTo>
	>   </soap:Header <soap:Header> >
	>   <soap:Body> <soap:Body> 
	>    <wsrm:CreateSequence> ... </wsrm:CreateSequence>
	>   </soap:Body <soap:Body> >
	> </soap:Envelope <soap:Envelope> >
	> 
	> Notice the use of RelatesTo with a WSRM-specific
@RelationshipType to  
	> indicate that this message is a WSRM-specific response to the
initial  
	> request.
	> 
	> Step 3 - Client sends a CreateSequenceResponse to wsa:ReplyTo
	> <soap:Envelope ...> <soap:Envelope...> 
	>   <soap:Header> <soap:Header> 
	>    <wsa:To> http://stockquote.com <http://stockquote.com/>
</wsa:To>
	>    <wsa:Action> http://...wsrm/CreateSequenceResponse
<http://...wsrm/CreateSequenceResponse>  </wsa:Action>
	>    <wsa:RelatesTo> uuid://.../101 </wsa:RelatesTo>
	>   </soap:Header <soap:Header> >
	>   <soap:Body> <soap:Body> 
	>    <wsrm:CreateSequenceResponse> ...
</wsrm:CreateSequenceResponse>
	>   </soap:Body <soap:Body> >
	> </soap:Envelope <soap:Envelope> >
	> 
	> Step 4 - Having not received the GetQuoteResponse, the Client
uses  
	> MakeConnection to allow it to flow back
	> <soap:Envelope ...> <soap:Envelope...> 
	>   <soap:Header> <soap:Header> 
	>    <wsa:To> http://stockquote.com <http://stockquote.com/>
</wsa:To>
	>    <wsa:Action> http://...wsrm/MakeConnection
<http://...wsrm/MakeConnection>  </wsa:Action>
	>    <wsa:ReplyTo>
	>     <wsa:Address>http://www.w3.org/.../anonymous
<http://www.w3.org/.../anonymous> </wsa:Address>
	>    </wsa:ReplyTo>
	>    <wsa:RelatesTo
RelationshipType="http://...wsrm/InitialRequest"
<http://...wsrm/InitialRequest> >
	>      uuid://.../100
	>    </wsa:RelatesTo>
	>   </soap:Header <soap:Header> >
	>   <soap:Body> <soap:Body> 
	>    <wsrm:MakeConnection>
	>    </wsrm:MakeConnection>
	>   </soap:Body <soap:Body> >
	> </soap:Envelope <soap:Envelope> >
	> 
	> Notice the use of the wsa:RelatesTo with a WSRM-specific  
	> @RelationshipType to indicate that this message is requesting
a  
	> response to the initial request message.
	> 
	> Step 5 - Server uses the backchannel to let the
GetQuoteResponse flow  
	> back to the Client
	> <soap:Envelope ...> <soap:Envelope...> 
	>   <soap:Header> <soap:Header> 
	>    <wsa:To>http://www.w3.org/.../anonymous
<http://www.w3.org/.../anonymous> </wsa:To>
	>    <wsa:Action> foo://GetQuoteResponse </wsa:Action>
	>    <wsa:RelatesTo> uuid://.../100 </wsa:RelatesTo>
	>    <wsrm:Sequence> ... </wsrm:Sequence>
	>   </soap:Header <soap:Header> >
	>   <soap:Body> <soap:Body> 
	>    <foo:GetQuoteResponse> 139.0 </foo:GetQuoteResponse>
	>   </soap:Body <soap:Body> >
	> </soap:Envelope <soap:Envelope> >
	> 
	> Notice the wsa:RelatesTo points to the GetQuote request
message and  
	> it is sent using RM (the Sequence header), and that the SOAP
Envelope  
	> looks exactly like it would if it had been sent on the
original  
	> transport backchannel - meaning, the wsa:To is derived from
the  
	> wsa:ReplyTo from the GetQuote request message not the
MakeConnection.
	> 
	> ---
	> Marc Hadley <marc.hadley at sun.com>
	> Business Alliances, CTO Office, Sun Microsystems.
	> 
	>