[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]