OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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?
- 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?
- 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?
- 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?
- 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).

[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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]