RE: An Example Use of RM's MakeConnection

Tony,
  your layering question is actually something we tried to take into 
account during the design of MakeConnection and the RManonURI.  You said 
you think the entire EPR should be available but we were not convinced 
that would always be true.  We had envisioned some environments where 
there was a gateway (or ESB) type of component that would be handed a 
message and told "go deliver this" - meaning all components before that 
point didn't need to examine the contents of the wsa:Address value at all 
- its not their job to deliver it so they had no need.  It wasn't clear 
that we could guarantee that in all cases the gateway would be given 
anything more than the soap envelope. By the time it gets to the 
gateway/transport component it may have had all of its soap processing 
(signing, encrypting...) already completed and all that was needed was the 
physical movement of the bytes themselves to the other side. While its not 
necessarily our job to answer or solve this problem, we didn't think it 
would be wise for us to breaking an existing setup.  In the async case, 
this environment may work just fine, and we wanted to ensure that by 
simply turning around the transport mechanism (pull vs push) we limited 
the disruption to existing solutions by allowing the code impact to be 
limited to the transport layer and not above it - if that's what the 
implementation chose to do. 
  Again, we tried to follow WSA's lead on how it designed the anon and 
none URIs - it seemed like a very well structured approach.  And to be 
honest, I don't really see why some other 'special' URI should not reuse 
the existing processing model.  As I see it, if the wsa:Address conveyed 
the transport mechanism and the identity of the endpoint (just like 
http://www.cnn.com does), then no extension to the EPR itself is needed. 
This is basically what anon and none do - except for the unique identity 
part :-) .  But if each time a new transport mechanism were developed it 
required an extension to the EPR then I think the EPR model is broken - 
but I don't think it is.  For example, I don't see much of a difference 
between switching from http://www.cnn.com to http://...wsrm/anon?id=123, 
or to smtp://....  - each descibes a different transport mechanism - why 
would anything else be needed?
  Perhaps that begs the question, and it would be fun to turn it around 
for a bit :-),  why should the RManonURI not be treated like any other URI 
(or like anon and none)?  Aside from the WSDL marker issue, what are the 
technical reasons RM's URI should require an extension to the EPR while 
anon, none, http://.. vs smtp://... do not?  If all that is different is 
the mechanism by which we get the connection/socket then there really is 
no reason.

thanks
-Doug




"Rogers, Tony" <Tony.Rogers@ca.com> 
10/10/2006 10:09 PM

To
Doug Davis/Raleigh/IBM@IBMUS, <public-ws-addressing@w3.org>
cc

Subject
RE: An Example Use of RM's MakeConnection






I'm not sure that he was suggesting that the additional headers belong 
outside of the EPR. 
 
I agree, the EPR is a powerful abstraction, and one of its most powerful 
points is that we can extend it, that we can add extra elements to it. 
Unless the additions are marked mustUnderstand=true, we are permitted to 
ignore them. Of course, RM additions may require mustUnderstand=true, 
given their impact on the message flows.
 
If the (to) address in the EPR is "anonymous", and an additional element 
(inside the EPR) carries the information that allows correlation of this 
EPR with the message stream/conversation/message sequence, then it's still 
a single EPR. This does mean that the RM processing would have to happen 
at a point where the whole EPR was available, rather than deep in the 
bowels of the SOAP stack where the URL is all that's left, but I remain 
unconvinced that the latter is appropriate layering. When the code 
dismantles the EPR to send a message to it, that would seem to be an 
appropriate point to recognise that RM processing should be invoked (due 
to the presence of the RM element, perhaps), instead of later, when we 
recognise that the URL requires special processing.
 
Tony Rogers
tony.rogers@ca.com
 

From: public-ws-addressing-request@w3.org 
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Doug Davis
Sent: Wednesday, 11 October 2006 3:09
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
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295 

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:Header>
>    <wsa:To> 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</wsa:Address>
>    </wsa:ReplyTo>
>   </soap:Header>
>   <soap:Body>
>    <foo:GetQuote> IBM </foo:GetQuote>
>   </soap:Body>
> </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:Header>
>    <wsa:To>http://www.w3.org/.../anonymous</wsa:To>
>    <wsa:Action> http://...wsrm/CreateSequence </wsa:Action>
>    <wsa:MessageID> uuid://.../101 </wsa:MessageID>
>    <wsa:RelatesTo RelationshipType="http://...wsrm/InitReliable">
>      uuid://.../100
>    </wsa:RelatesTo>
>    <wsa:ReplyTo>
>     <wsa:Address> http://stockquote.com </wsa:Address>
>    </wsa:ReplyTo>
>   </soap:Header>
>   <soap:Body>
>    <wsrm:CreateSequence> ... </wsrm:CreateSequence>
>   </soap:Body>
> </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:Header>
>    <wsa:To> http://stockquote.com </wsa:To>
>    <wsa:Action> http://...wsrm/CreateSequenceResponse </wsa:Action>
>    <wsa:RelatesTo> uuid://.../101 </wsa:RelatesTo>
>   </soap:Header>
>   <soap:Body>
>    <wsrm:CreateSequenceResponse> ... </wsrm:CreateSequenceResponse>
>   </soap:Body>
> </soap:Envelope>
> 
> Step 4 - Having not received the GetQuoteResponse, the Client uses 
> MakeConnection to allow it to flow back
> <soap:Envelope ...>
>   <soap:Header>
>    <wsa:To> http://stockquote.com </wsa:To>
>    <wsa:Action> http://...wsrm/MakeConnection </wsa:Action>
>    <wsa:ReplyTo>
>     <wsa:Address>http://www.w3.org/.../anonymous</wsa:Address>
>    </wsa:ReplyTo>
>    <wsa:RelatesTo RelationshipType="http://...wsrm/InitialRequest">
>      uuid://.../100
>    </wsa:RelatesTo>
>   </soap:Header>
>   <soap:Body>
>    <wsrm:MakeConnection>
>    </wsrm:MakeConnection>
>   </soap:Body>
> </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:Header>
>    <wsa:To>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:Body>
>    <foo:GetQuoteResponse> 139.0 </foo:GetQuoteResponse>
>   </soap:Body>
> </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.
> 
>