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