[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] About intermediaries
Ric: You caught me writing things a little too quickly here. You are right: the ebMS header should not - must not - be altered by intermediaries. 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 categories: - 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. Jacques -----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> wrote: > 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 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... > </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 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 > > > --------------------------------------------------------------------- > 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]