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