OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[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]