[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] About intermediaries
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." <JDurand@us.fujitsu.com> > Date: Mon, October 22, 2007 1:29 pm > To: <ebxml-msg@lists.oasis-open.org> > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]