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


You caught me writing things a little too quickly here. 
You are right: the ebMS header should not - must not - be altered by
So this seems to imply that multi-hop routing always requires each
message to use the same MPC all along, the MPC becoming de-facto an
end-to-end channel.

In this case multi-hop forwarding would fall into one of these 2

- either the MPC is used as routing function, by associating each
routing path unambiguously with a single MPC end-to-end. 
- or the MPC is not sufficient to determine the routing, which makes use
of additional routing functions. But even in that case, each message
must still use the same MPC end-to-end.

In both cases, the "forward" intermediary operation will need to comply
with this MPC invariant (the P-modes configuring the intermediaries must
reflect this).

All this is to be distinguished from routing uniquely based on other
headers, say WS-addressing, in which case the intermediary does NOT need
be an ebMS intermediary in the sense it does not need to understand the
ebMS header - and is out of scope of this MPC invariant.


-----Original Message-----
From: Ric Emery [mailto:remery@us.axway.com] 
Sent: Tuesday, October 23, 2007 4:43 PM
To: Durand, Jacques R.; Moberg Dale
Cc: ebxml-msg@lists.oasis-open.org; David RR Webber (XML)
Subject: Re: [ebxml-msg] About intermediaries

Jacques you said something in your response that confuses me a bit.

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

The MPC of an ebMS Message is included in the
eb:Messaging/eb:UserMessage/@mpc attribute. If the MPC value needs to be
changed at the intermediary wouldn't that necessitate the ebMS Message
header being modified? I didn't think we were contemplating modification
of the values within the ebMS Message header.

On 10/22/07 4:23 PM, "Durand, Jacques R." <JDurand@us.fujitsu.com>

>  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 
> "push-and-sync-and-push"...</JD>
> 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, right?
> There is a much more complex set of combinations that need to be 
> addressed.
> <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
> 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
> </JD>
> -----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
> 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>
> http://lists.oasis-open.org/archives/ebxml-msg-comment/200709/msg00000
> .h
>> 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

> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> ---------------------------------------------------------------------
> 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

> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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