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