[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.20 (ebMS3-Multihop-V20-Nov19.doc) uploaded
Review continued for 1.6 to 1.8, now for this version 0.20. Section 1.6 Section 1.6.1. The content of this is largely included in 1.5 now. The "Forwarding" function is also introduced earlier. Do we need this section? Section 1.6.2 As noted in the comment, the "asynchronous streaming" option seems to be mainly an implementation/optimisation choice that does not impact interoperability. The synchronous streaming option is needed to support synchronous business responses, signals and WS-* protocol response messages. Some discussion of the advantages / drawbacks of streaming versus store-and-forward could be useful for implementers. A proposal is in http://lists.oasis-open.org/archives/ebxml-msg/200807/msg00001.html Should we define conformance targets so that implementations can be clear about which options they support and users know what what to look for? I.e. some products may not support streaming at all. Section 1.6.3 Despite the title suggesting details on the routing function, this is not a a complete description of the per-hop configuration that also routing functions must set. See also: http://lists.oasis-open.org/archives/ebxml-msg/200806/msg00025.html A question is whether intermediaries have fixed settings for some parameters for all messages regardless of the business document header content. Or do we expect such values to be determined by the routing function? Some of them (e.g. "maxsize") look like fixed settings for any messages. NB: the cpa3:Transport element contains many of the relevant parameters in a nice reusable structure. http://lists.oasis-open.org/archives/ebxml-msg/200811/msg00011.html Section 1.7.1 Line 611-619 As the example confirms, now that we use WS-A we need to specify how wsa:Action is used in ebMS 3.0. This is more general than multihop. Section 1.7.3 Line 699: The reference for eb:Error is not RefToMessageId but RefToMessageInError. Section 1.7.1.2 Line 624-634. This reads as if intermediaries other than the last edge intermediaries must interpret the anonymous EPR exactly like the new I-Cloud EPR. Is that correct? Are we talking about asynchronously routing a SOAP response message that uses the anonymous EPR? Shouldn't we interpret an anonymous EPR in wsa:ReplyTo as an instruction to the chain of intermediaries to connect synchronously (i.e. "wait"). (If an intermediary doesn't support it, it could always generate an ebMS routing error, or a new error: synchronous behaviour not supported) How about the first edge intermediary: It looks as if an endpoint that specifies an anonymous EPR in the ReplyTo may still get the response asynchronously. Is that behaviour WS-A compliant and does that work interoperably with WS-A implementations? (I.e. is there not a risk that WS-* stacks may reject such asynchronous responses ?). To avoid all of this, users could always further profile this profile and specify that the anonymous EPR is never to be used, and the I-Cloud is used instead. This breaks the transparency goal though .. Other Pmodes are already specifying synchronous or asynchronous behaviour for business responses (MEP Binding), errors (PMode[1].ErrorHandling.Report.AsResponse) and receipts (Pmode.Security.SendReceipt.ReplyPattern). Section 1.7.3 Line 715-727, Signal Messages: Case (b1), in ebMS v3.0 Core, the Pmode.Security.SendReceipt.ReplyPattern parameter with values "callback" or "response" determines whether or not the signal is sent asynchronously or asynchronously. In the synchronous case, there is no need for WS-A. Is this still an option supported in this profile or does it require WS-A for all Signal messages even in synchronous communication? In MEP bridging scenarios, which MPCs are such Signal Messages pulled from? The eb:routinginput could specify an @mpc attribute value in conjunction with the I-Cloud URI. This could be a case (b3) analogous to the case third condition described in line 742-745. Line 737 Editorial: somehow the numbering of these conditions starts at 2. Section 1.8.1 Some comments not yet incorporated in this section are: http://lists.oasis-open.org/archives/ebxml-msg/200809/msg00000.html http://lists.oasis-open.org/archives/ebxml-msg/200809/msg00004.html Hope any of this is useful. Pim -----Original Message----- From: jdurand@us.fujitsu.com [mailto:jdurand@us.fujitsu.com] Sent: 19 November 2008 21:16 To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Groups - Multi-hop Section Draft 0.20 (ebMS3-Multihop-V20-Nov19.doc) uploaded The document revision named Multi-hop Section Draft 0.20 (ebMS3-Multihop-V20-Nov19.doc) has been submitted by Mr Jacques Durand to the OASIS ebXML Messaging Services TC document repository. This document is revision #18 of ebMS3-Multihop.doc. Document Description: Draft of the multi-hop section. V0.3: - a few updates in the definition section (editorial) - added a commented Flow diagram (section 1.7.1) on RM sequence establishment. To review. V0.4: - section 1.5 (Intermediary Role) rewritten, though not complete yet. (diff with 0.3 visible) V0,5: - section 1.5 updated based on feedback and extended for response messages. V0.14: - Section 1.5 redefines multihop MEPs in terms of first hop + last hop. It does not include the routing inside the I-Cloud which is relevant to the routing function. - Section 1.5.4: Two options for multi-hop pulling ... and probably one too many.... Need to define multihop pulling. - Section 1.6.3 on routing function has been edited. - Section 1.8 on PModes has been deeply redesigned based on what was said prior V0.6: - Added text to section 1.5 on streaming and store-and-forward models for implementing intermediaries V0.7: - Changed the text describing the streaming model to include two sub cases, asynchronous and synchronous streaming. V0.8: - a few updates / corrections (diffs visible) - fleshed out the "routing of Acks" multihop subsection at the end. V0.9: - Updated definition of routing function and mep bridging - Changes to section on details of the routing function. The changes here are mostly textual. Changes shouldn't have impact on spec itself. V0.10: - Moved section 1.4.3 Endpoints requirements to 1.6 where requirements can be more explicitly formulated - Reformatted handling of routing input by intermediary - New section 1.6 on Endpoints requirements, includes introduction of RefParam PMode feature - Added section 1.7 to specify definition of WS-A reference parameter V0.11: - Added text to section 1.4.6 on specific MEP bindings for multi-hop V0.12: - added missing flow diagrams (not yet fully comented) - inserted text for Section 1.8. - added several comments ([jacques]) and complement text (diffs visible) V0.13: - more complete draft of the MEP section 1.5, with multihop channel bindings. - added a new section on PModes for multihop (1.8) - minor changes in 1.7 - expanded on the Error handling section (1.4.5) V0.15: - Section 1.5 redefines multihop MEPs in terms of first hop + last hop. It does not include the routing inside the I-Cloud which is relevant to the routing function. - Section 1.5.4: Two options for multi-hop pulling ... and probably one too many.... Need to define multihop pulling. - Section 1.6.3 on routing function has been edited. - Section 1.8 on PModes has been deeply redesigned based on what was said prior V0.16: - more complete section 1.8 - figures added in MEP section, explicit model separating ICloud hops from "peripheral hops". V0.17: - sharpening of terminology in earlier sections - Section 1.5 largely rewritten, with updated figures (for terminology) - still some clean-up to do in 1.5 and also 1.8 V0.18: - remodeling of section 1.5, especially 1.5.2 and 1.5.3, with missing cases and new figures. - some figures migrated from 1.5 to 1.6 -section 1.7 on endpoint requirements, reorganized, with an addition on how to interpret wsa:ReplyTo (1.7.3). - edits in 1.8, with main addition 1.8.3 on how to control other aspects of multihop edges binding (not complete yet) V0.19: - addressed most comemnts from Sander (Nov17, 2008) and some from Pim. V0.20: - Added a more complete WS-Addressing section (1.7.1) - minor edits. View Document Details: http://www.oasis-open.org/committees/document.php?document_id=30106 Download Document: http://www.oasis-open.org/committees/download.php/30106/ebMS3-Multihop-V20-N ov19.doc Revision: This document is revision #18 of ebMS3-Multihop.doc. The document details page referenced above will show the complete revision history. PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser. -OASIS Open Administration
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]