Jacques,
Good catch and summary.
I suspect CDC and from my experience NIH - both have "burst" type needs. In NIH case its submission deadlines - in CDC - in response to real world events.
This is different from "normal" B2B weekly / monthly peaks.
Certainly NIH receives 90% of traffic in a month over 1 or 2 days!
Also - the push/pull model is very important - ultimately both use cases want an initial tiny notification message to queue up later an asynchronous transfer when bandwidth permits / priorities require.
Not sure if this helps at all?! My sense here is we want simple mechanisms that are self-adaptive to a wide range of anticipated use patterns without requiring any intervention.
Maybe a combination of some synchronous - and other asynchronous channels available for both uses?
Cheers, DW
"The way to be is to do" - Confucius (551-472 B.C.)
> -------- Original Message --------
> Subject: [ebxml-msg] About intermediaries
> From: "Durand, Jacques R." <>
> Date: Mon, October 22, 2007 1:29 pm
> To: <>
>
> Looking at requirements on the comment list some time ago
> <http://lists.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000.
> h>
> http://lists.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000.h
> <http://lists.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000.
> html> tml
>
> 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
