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] Groups - Multi-hop Section Draft 0.20 (ebMS3-Multihop-V20-Nov19.doc) uploaded

We still have to address these comments below.
See some inline <JD>

- Jacques

-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, November 19, 2008 1:52 PM
To: Durand, Jacques R.; ebxml-msg@lists.oasis-open.org
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:

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.

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.

<JD> Right. Proposal: for a UserMessage. wsa:Action = eb:Action, for a Receipt message,  wsa:Action = eb:Action + 'Receipt' (appending after wsa:Action of request)

Section 1.7.3
Line 699:
The reference for eb:Error is not RefToMessageId but RefToMessageInError.

<JD> Right.

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?

<JD> Right: in principle, an anon ReplyTo is not intended to be interpreted by Intermediaries of the I-Cloud. So the routing function prevails. If the EPR with anon Address was obtained from PMode (not ReplyTo), same thing.

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

<JD> I asked the former chair of WS-addressing. Of course the behavior of Intermediaries remained a gray area for WSA. But in principle, SOAP Intermediaries are NOT required to interpret ReplyTo. See in rev22: I suggest that for Interop reasons, the first Intermediary DOES interpret ReplyTo anon - actually based on PMode, but that all others inside the I-Cloud don't have to.

(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?

<JD> Right - for better consistency, rev22 says that the first hop and last hop comply with ReplyTo anon.

(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

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?

<JD> Its not the only place where there is some redundancy between PMode (i.e. configuration data e.g. MEP binding) and WSA (i.e. wire data). I guess we could adopt a general approach that WSA is NOT required to be used in such cases where PMode + routing function are sufficient. And when used, must be consistent with PMode.

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:

Hope any of this is useful.


-----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.
- a few updates in the definition section (editorial)
- added a commented Flow diagram (section 1.7.1) on RM sequence establishment. To review.
- section 1.5 (Intermediary Role) rewritten, though not complete yet.
(diff with 0.3 visible)
- section 1.5 updated based on feedback and extended for response messages.
- 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

- Added text to section 1.5 on streaming and store-and-forward models for implementing intermediaries
- Changed the text describing the streaming model to include two sub cases, asynchronous and synchronous streaming.
- a few updates / corrections (diffs visible)
- fleshed out the &quot;routing of Acks&quot; multihop subsection at the end.
- 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.
- 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
- Added text to section 1.4.6 on specific MEP bindings for multi-hop
- added missing flow diagrams (not yet fully comented)
- inserted text for Section 1.8.
- added several comments ([jacques]) and complement text (diffs visible)
- 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)
- 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
- more complete section 1.8
- figures added in MEP section, explicit model separating ICloud hops from &quot;peripheral hops&quot;.
- 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
- 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)
- addressed most comemnts from Sander (Nov17, 2008) and some from Pim.
- Added a more complete WS-Addressing section (1.7.1)
- minor edits.

View Document Details:

Download Document: 

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]