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

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

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.

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

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

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

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

- 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 "routing of Acks" multihop subsection at the
- 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
- 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
- more complete section 1.8
- figures added in MEP section, explicit model separating ICloud hops from
"peripheral hops".
- 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]