[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] scenario: RM-transparent Intermediaries
There are potential issues with the routing of wsrm:SequenceAcknowledgments when we assume asynchronous store-and-forward intermediaries. I.e. in a path Source -> AsyncInt -> Target, there are two connections: Source -> AsyncInt AsyncInt -> Target If the AcksTo for the sequence is the WS-Addressing anonymous IRI, the response wsrm:SequenceAcknowledgement must be sent on the back-channel of the HTTP connection. When Source includes a wsrm:AckRequested header with an ebMS message, AsyncInt cannot satisfy the request to provide the corresponding acknowledgment information. This is because it has yet to forward this request to Target. So, synchronous end-to-end sequence acknowledgments are incompatible with asynchronous intermediaries. Option 1: We could assume asynchronous acknowledgments, which WSRM supports. But then it is based on the WS-A AcksTo address. If WS-A headers are signed (and cannot be rewritten by AsyncInt), then that address will be the address of Source, not AsyncInt's address. So this acknowledgment would flow directly to Source, bypassing AsyncInt. Advantage: Simple and seems not to require any special functionality on intermediary or endpoints. Regular WSRM functionality. Drawback: The point of having an intermediary is often that such a direct connection is not possible (due to firewall issues, or due to a policy that all messages should flow via the intermdiary for monitoring purposes, or due to the Source and Target not being available at the same times e.g. both are small business endpoints just available at most a few hours a day). Option 2: Sticking to the synchronous acknowledgment model, we could assume a hybrid model where ebMS user messages are sent asynchronously, but (some) signal message(s) are to be processed synchronously. The asynchronous user messages would carry the regular wsrm:Sequence elements that identify sequence and number in that sequence. Exceptionally, we assume that there is a designated ebMS signal that is to be processed synchronously. Perhaps it is the same signal that we already need to carry the sequence life cycle messages. This signal is used to piggy-back standalone wsrm:AckRequested headers, and return the wsrm:SequenceAcknowledgement synchronously on the HTTP back channels. With multiple intermediaries, this assumes all connections are synchronous. Advantage: - We get the ebXML header-based routing we want, no issues with signed WS-A headers. Drawbacks: - When we have multiple intermediaries, the requirement to have these synchronous connections assumes both Source and Target and all intermediaries are available at the same time, and the point of having an intermediary may be that this is not the case. It is also potentially less robust. - We get an even more complicated model: intermediaries need to be either synchronous or asynchronous depending on message content. It would be simpler if we could just assume them to e.g. always be purely asynchronous. Possible solution 3: Assuming synchronous wsrm:SequenceAcknowledgments (anonymous AcksTo IRI). Source sends an ebMS user message with a wsrm:AckRequested to AsyncInt. AsyncInt just HTTP 200 closes the connection and does not provide the acknowledgment. Then AsyncInt forwards the wsrm:AckRequested header to Target, and gets a wsrm:SequenceAcknowledgment on the back-channel. AsyncInt just stores the information and waits for the next message from Source, and includes this information on the back-channel for this connection. Advantages: - Supports a fully asynchronous model for all message types - Supports ebXML intermediary routing and no issues with WS-A headers and signatures Drawbacks: - We assume Source's wsrm processor does not complain about the lacking wsrm:AckRequested when it first sends it to AsyncInt. Not sure if that is a valid assumption. - Less overall control over when Source actually gets the acknowledgments. - How does AsyncInt correlate a waiting wsrm:SequencAcknowledgments to a particular Source? What are the security issues? - What if the wsrm:AckRequested is on the last message in a sequence? In WSRM this is covered by the wsrm:CloseSequence which could be bundled with an ebMS signal. The wsrm:CloseSequence should be required in this use case (it is optional in the WSRM spec). But an asynchronous wsrm:CloseSequenceResponse has its own routing issues, see separate message. Possible solution 4 (extension to solution 3) For two way message exchanges, wsrm:SequenceAcknowledgments could be bundled with business response messages. Or with other (possibly unrelated) messages that Target happens to send to Source If those response messages require acknowledgments, those could be piggybacked on subsequent messages from Source to Target. Advantages: - Same as solution 3. Drawbacks: - Same as solution 3, plus: - Does not work for the one way MEP. - Even tighter coupling between ebMS or business functionality and WSRM processor. Pim ________________________________ From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com] Sent: 13 December 2007 22:02 To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] scenario: RM-transparent Intermediaries Scenario: ------------- RM-transparent Intermediaries Assumptions: ------------------- - the sender does not have to know the ultimate destination (MSH URL) of its messages, but it has to know whether two messages are intended for the same destination or not, because it has to assign every message sent reliably to an active RM sequence (and an RM sequence must go to a single RM destination). - An ultimate MSH is also supposed to represent a single RM destination. But the same ultimate MSH could deliver to different parties (message consumers), i.e. different PartyID, different Service/Action, etc. - the sender knows what fileds in a message are used to determine the ultimate destination (these fields are used for the routing function) Features: ------------- - Only the two ultimate endpoints are RM enabled. The Intermediaries are fully transparent: they do not touch the RM headers, nor related signatures etc. - The difficulty of this scenario is in the establishment of the RM sequence that will be used by user messages intended for the same destination. RM "sequence lifecycle messages" such as CreateSequence, TerminateSequence, and their responses, must be routed in the same way as ebMS messages. A way to achieve this is to piggyback RM signals on ebMS messages (either dummy user-messages, or signal-messages). This ebMS header would have same "determining header fields" as the future user messages intended for this RM sequence. - A piggybacking option is to use a "dummy" ebMS user message on all RM sequence management messages. Advantage: no new ebMS signal needs be designed for this piggybacking : a "dummy" user message has the service field set to: http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/service <BLOCKED::http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/serv ice> which is enough to process it correctly in core V3, i.e. to NOT deliver it to the MSH consumer layer. (that way, no additional feature is required from the destination MSH, other than core V3 compliance). We might want to specify a new Action field value, but no need to interpret it on receiver side. The drawback is that the Service field should not be one of the determining fields for routing... - Another piggybacking option is to define a new ebMS signal, that would still have all the potential business headers used for routing. - the response RM management messages need be routed back. Suggest to put the burden of the piggybacking for these responses on the last MSH intermediary, not on the ultimate MSH who should not be aware of the RM-thru-intermediaries aspects. So the communication between last intermediary and ultimate Receiver is unconstrained (e.g. get Acks on HTTP responses, etc), exactly as if the last Intermediary was the original sender in a one-hop. Evaluation: --------------- - Advantages: Very clear RM QoS: end-to-end RM is getting same level of reliability QoS than any one-hop RM exchange, and using the same RM infrastructure. Conventional RM modules are used (except for the fact the piggybacking of RM seq lifecycle messages must be controllable), and if the module supports duplicate detection for on-hop, will also work for multi-hop. But most of all, the intermediaries are really fully transparent: no overhead with RM headers substitution, no restriction on use of security (remember that RM headers are usually candidates for signing and other integrity protection). End-to-end security covers RM headers. - drawbacks: Need to design a piggybacking system introducing special ebMS messages, for routing the RM sequence management messages. The reliable "message sets" need be known in advance by sender, at least until the last intermediary: the initial sender has to know what are the messages intended for the same destination (might be indicated by P-Mode anyway). - do the initial sender / ultimate receiver need to support more than Core V3? Not receiver. But Sender implementation need be able to control piggybacking of RM signals. Although not really additional feature beyond Core V3 (unless a new signal introduced), it is a constraint on implementations.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]