[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]