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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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


Subject: Synchronous Intermediaries




Synchronous intermediaries

We've focussed on asynchronous ebMS messaging across intermediaries
for good reasons, one being that in cases where the last MSH pulls
from the intermediary it is the only option and we still need a way to
reverse route Receipts, WS-* reverse messages and business responses. 

Do we still need to support synchronous intermediaries for messages
that are "pushed all the way"? Synchronous intermediaries are 
intermediaries that keep the requestor connection open to forward the
back-channel response. To limit the options, it seems preferable to
assume that either all intermediaries are waiting or none of them are
(see earlier discussion).

A disadvantage of synchronous intermediaries is that having all
intermediaries wait before their HTTP reply is made does not scale
well, is brittle and utilizes lots of resources. This is why it is not
supported in some production ebMS 2.0 intermediary deployments.

However, some ebMS-like messaging protocols that support
intermediaries have support for synchronous intermediaries. Sometimes
this is restricted to "idempotent" operations that do not require
reliability, such as looking up data in a remote databases.  Support
for synchronous intermediaries could provide an upgrade path for these
communities and extend the adoption of ebMS 3.0.

In point-to-point Web Services messaging synchronous SOAP
request/response interactions are also very widely used. It would be a
benefit for an intermediary to be able to support this model without
modifications to the behaviour of the server and/or the client.

The cost of supporting a synchronous Receiver seems to be quite
limited. The last intermediary can receive a synchronous response, and
forward it back to the initial sender asynchronously. The reverse path
could use a different path through the I-Cloud, as long as it ends at
the original sending MSH. 

What about the cost of supporting a Sender that assumes Two Way Sync?
I.e. the sending MSH sends a message to an intermediary and expect a
synchronous response. This first intermediary would send the request
to the intermediary and expect to be able to receive the response on
the HTTP back-channel. This first intermediary could send the request
asynchronously but remember which open incoming HTTP connection the
eb:MessageId is associated with. Assuming a response arrives in time
through the intermediary (correlated based on eb:RefToMessageId), the
intermediary could reply on the back-channel of the open incoming HTTP
connection. Despite its obvious limitations, there is very strong
interest in this kind of synchronous/asynchronous bridging for
clients.




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