RE: [ebxml-msg] About intermediaries

["Moberg Dale" <dmoberg@axway.com>]

Will the asynchronous intermediary effectively "terminate" the HTTP
request and reply interaction? So it would issue its own SOAP faults,
any other protocol error messages, HTTP status codes, and SOAP header
responses as needed? Or would intermediaries be restricted to OneWay
meps only? (with any SOAP faults simply generated downstream from the
intermediary, and not transmitted back (unless the downstream nodes
started a new connection back either through the intermediary or
bypassing the intermediary to the origin directly)) I think once we
enter into soap paths with node count higher than 2, the existing mep
vocabulary becomes incomplete and basically inadequate for the job.

I don't see how intermediaries can participate in other meps (beyond one
way non-robust) without going into the synchronous mode? However, even
then the issue whether the next hops on the soap path must be
synchronous with respect to the intermediary is another matter, right?

There is a much more complex set of combinations that need to be
addressed.


-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info] 
Sent: Monday, October 22, 2007 11:18 AM
To: Durand,Jacques R.
Cc: ebxml-msg@lists.oasis-open.org
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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php