About intermediaries

Looking at requirements on the comment list some time ago http://lists.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000.html

I think a feature needs to be discussed early on: "synchronous" vs. "asynchronous" intermediaries. Because these two modes of intermediation entail quite different sets of intermediary capabilities.

Synchronous int means that the connections are left open so that whatever response (QoS headers, payloads) the intermediary gets on the back-channel, is forwarded back to the original sender. This achieves full "transparency" of the intermediary, from the original sender viewpoint.

Although the notion of synchronous intermediary is attractive, it seems to have some robustness issues (high volume intermediaries with risk of insufficient connections, 2-way sync MEPs with potential delays, etc) in practice. Also, it may be that such intermediaries are better implemented at lower level than ebMS, e.g. HTTP or SOAP, as the need for ebMS-specific processing seems slim in such hubs.

On the other hand, the connected hubs topologies that I have seen in requirement documents (CDC and Pim's) seem to be better served by "asynchronous" intermediaries, as the transfer mode (QoS, MEP bindings) between 2 hubs seems to obey different requirements as between hub and endpoint. In this perspective, the hub is there precisely to support some communication QoS that the endpoints don't want to be burdened with. Or, this may be true of a subclass of hubs: gateways that act as bridges between local networks and external endpoints.

Is there any strong requirement for synchronous itnermediaries?

Jacques

ebxml-msg message