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