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

 inline  <JD>

I would 
-----Original Message-----
From: Moberg Dale [mailto:dmoberg@axway.com] 
Sent: Monday, October 22, 2007 11:35 AM
To: David RR Webber (XML); Durand, Jacques R.
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] About intermediaries

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? 

<JD> as long as the intermediary "understands" (and consumes + relays)
the ebMS header - if only for routing functions - then it seems to me we
must make room for ebMS Faults generated at this level... w/r to this,
the intermediary can't apparently be fully transparent, even in the
synchronous intm case. In the asynchronous case, the HTTP interaction is
closed by the intemediary itself, and any propagation of faults or other
QoS signals / acks from the ultimate receiver would be done
asynchronously (reducing the binding options, but still an option)</JD>

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.

<JD> So far we have been careful to keep ebMS MEPs distinct from their
"MEP [transport] channel binding". The former (e.g. "Two-way") still
makes the same sense business-wise end-to-end regardless of whether
there are intermediaries or not. E.g. I'd assume the overall CPA party
infos and collaboration roles would still be same for such MEP - but new
(or composed?) CPA "delivery channels"  would be needed I guess. What is
new is that the "transport channel binding" of that MEP gets more
complicated with an intermediary: it is no longer just "sync"  or
"push-and-push". It could be something like "push-then-pull(for request
legs)-and-push-then-push(for reply legs)" e.g. when the request
recipient needs to pull from the intermediary. Or

I don't see how intermediaries can participate in other meps (beyond one
way non-robust) without going into the synchronous mode? 

<JD>again, new "transport channel bindings" need be invented, but not
the ebMS MEP itself. We still have plain old 1-way (end-to-end) and
2-way (end-to-end), so far. </JD>

However, even then the issue whether the next hops on the soap path must
be synchronous with respect to the intermediary is another matter,

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

<JD> I'd agree we [our intermediaries] have to support more combinations
than those supported by the "synchronous intermediary" notion, as Pim
suggested. But I suspect the complexity only exists if we pretend to
describe them all. In the same way as the Pull mechanism combines with
the Push in many ways for various flavors of (async) channel bindings
for a  2-way MEP (push-and-pull, pull-and-push, etc), I see
intermediaries creating more channel binding options for the same old
MEPs. P-modes will be the place where leg by leg behaviors are
specified, and the MPCs will play a major role in connecting these legs.
E.g., all an intermdiary may need to do for enabling any of  these
combinations, is to put "any message received on MPC 123, right into the
sending MPC 234". All other P-mode parametrs associated with these MPCs
are set as if the intermediary was an endpoint. </JD>
<JD>Overall, I may miss some of the complexity, but it seems to me that
core V3 has already what it takes to deal with a good part of it...

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


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
> h>
> html> tml
> I think a feature needs to be discussed early on: "synchronous"  vs.
> "asynchronous" intermediaries. Because these two modes of
> 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
> to have some robustness issues (high volume intermediaries with risk
> insufficient connections, 2-way sync MEPs with potential delays, etc)
> practice. Also, it may be that such intermediaries are better 
> implemented at lower level than ebMS, e.g. HTTP or SOAP, as the need
> 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
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]