RE: [ws-rx] Multiple endpoints per RM sequence scenarios

I also volunteered into investigating how MSFT proposal handles some use cases…

So here is my take on Doug’s cases, and how MSFT handle these.

-Jacques

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, November 20, 2006 6:27 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Multiple endpoints per RM sequence scenarios

Marc et al,
I took a todo from the last conf call to pull out the use-cases from the "Lack of support for multiple endpoints per Sequence" issue I raied with Marc's proposal. From the note I send before [1], here is the key section:

------
There are lots of scenarios in which a series of messages need to sent where the order must be preserved. Clearly one way to achieve this is to serialize the sending of the messages so that message number N is not sent until message number N-1's response is received. However, this is not a very efficient model. RM is an obvious choice here. By using RM a sending endpoint can parallelize its sending of the messages and be assured that the other side will reorder them appropriately. Thus adding a firewall into the environment you now have a series of anonymous clients all sending messages that need to be in the same RM Sequence in order to achieve the desired results. Saying that the clients should not be anonymous in the first place is simply ignoring the problem that many of our customers have. BTW, we have a requirement for this in some notification systems, where we need to ensure that the events we're sending are not processed out of order.

Looking at another use-case - say there's an RMS is implemented as a gateway/proxy - where all messages leaving the environment heading for another destination are placed into the same RM Sequence - because there's (as I've heard Chris describe it) "one big pipe" between the two companies. In this scenario the gateway has no idea of the MEPs being used or the application semantics involved - all it basically does is add the RM Sequence header to the messages. It then becomes up to each individual client (since its the only one that knows the MEPs and application semantics) to request the responses that may be expected. Again, we need to be able to identify which response goes to which client/MakeConnection request.
------

But I think the entire note (if not the entire thread) should be read :-)

As with may use-cases there many ways these could be supported however I'd like to see how these scenarios can work using Marc's MC proposal and what assumptions would need to be made about the implementation choices. In particular:
- who is required to send the MakeConnection? Can the client do it or must it come from the gateway?

<JD> in Marc’s, that is always the gateway (meaning the Client RMD itself).

Note: in contrast with MSFT proposal, I find it rather odd that in current draft spec (i.e. with RM anon URI solution), your use case expects that a client need be responsible to (or allowed to) craft a message – MC - that has only meaning to an RM component. In essence, that exposes some RM syntax to the application layer. We are talking of a solution to a use case where we tell how the Application Destination must communicate with the RM layer, which I thought was out of scope.

- if it is the client then how does the right response get delivered to the right client since all the server has is the anon wsa:To address?
- if it is the gateway then how does the gateway know that a MC needs to be sent if it doesn't know the WSDL or application semantics?

<JD> Lets suppose all these anonymous clients need to do sync request-response MEPs through the RM Client gateway – no use of MC here. We don’t expect the anon Clients to add themselves the Sequence header – we count on the RMD-gateway to do so, depending on how reliable every req-response needs to be. So the gateway is supposed to have knowledge of policies in use on RM server side. That should also be the way to know if a reliable sequence is needed from the RM server, in case one-ways need be pulled from RM server .

- if it is the gatewat then how does the response get routed to the right client when the client may be doing sync MEPs because it can't support hosting a server?

<JD> Assuming you mean sync request-response MEPs: then I believe no MC is needed at all for these and MSFT proposal behaves in same way as any other. The RMD on RM Client side knows the policies that tell such MEPs are to be sent reliably. It knows the seq ID associated with their responses (has likely offered these sequences), and that no MC is needed for getting these responses.

- and lets not forget about cases where the gateway is an intermediary and the sockets are broken - w/o a server on the client, if it doesn't send the MC then how does it work?

<JD> Not sure I see a problem that is bigger for one proposal than for the other, here. Again, if we are to make a robust pulling mechanism available for the Application Destination, then if it is pulling only for reliable messages (as for here) why not design one from AD to RMD, (instead of AD to RMS), and do it in an adjunct spec? The connection RMS to RMD is supposed to be reliable even for pulled messages.

One reason I’d do it AD-RMD vs AD-RMS, is that a lot less reordering will be needed if RMD does the pulling, in case of InOrder. And also, what if the Client ADs want to be called back instead of being in charge of pulling all these messages?

- how does the server group the messages into the right sequence when all it has is the wsa:Anon URI for the wsa:To value? ie. how does it know which messages are going to the same gateway or client is all it has is wsa:Anon to look at? We need to place the right message into the right sequence and one mechanism to do this may be the destination endpoint (esp. in cases where the RM logic isn't co-located with the application).

<JD> I think that could be where MSFT proposal is weak. Not that I think it cannot handle this, but it needs be more explicit. Stating the problem more precisely, I believe that (1) these anon clients (in the multiple endpoints use case) need anyway be identified one way or the other, and this identification known from the RMS Server, meaning that RMS must be able to associate messages submitted with these IDs. (2) the RMD Client must provide the means to the RMS to associate these client IDs with the sequence ID, at creation time – e.g. in CSR. Once done, still no need to use MC beyond com RM-client / RM-server…

On another note: having the MC in the SOAP header (as in MSFT prop) serves well a deployment where the RM server is implemented as a SOAP node. If MC is in the SOAP body, then how does the RM server know it is the ultimate destination of a message sent by a client? Is the RM Server supposed to peek inside the SOAP body of every message in case there is an MC for it? (absence of Sequence header is not sufficient indicator)

Thanks,

Jacques

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200611/msg00047.html

thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com

ws-rx message