Sander:
inline
My comments so far:
- Would it be a good idea to define the term addressing information?
Suggestion: Address information is the set of meta data information of messages
used by the I-Cloud to route message to their destination endpoint.
This definition allows different I-Clouds to use different address
information, for example one I-Cloud may only use PartyId where another one also
uses Service and Action values for routing.
<JD> we want that indeed.
I think that we shouldn't allow
such an open definition and fix the address information to the meta-data that is
available in ebMS user messages.
- Line 89-90: "although in some limited cases an Intermediary may add
WS-Addressing headers". Do we foresee intermediaries adding headers or
is this considered out of scope? (I would think last)
<JD> the only reason for an intermediary to add such wsa headers,
is to relieve an endpoint from doing it - if we provide such option.
Agree that we don't have to,
especially if we decide that all "RM signal responses" will use AcksTo EPR,
which is always known from the endpoint. The other corner case, is if an
Intermediary can generate eb:Errors that need be routed back. But this is a case
where the Intermediary itself is generating the message. So overall,
agree.
- Line 93: "an Intermediary must be able to
use streaming to forward a message" Do we need to require
streaming support? I think SHOULD or MAY is more appropriate.
<JD> possibly. Coming from our engineering as a
scalability necessity... Let us just say thet the design must not preclude this
- we don't need to state it in the specification.
- Line 101-103: "An Endpoint MSH
must not need to be aware of the I-Cloud. In particular, no change in its
configuration or PMode is needed when sending a User message to the same
destination either in point-to-point mode or in multi-hop mode" In most
situations I think it is impossible to go from P-2-P to multi-hop without
changing the configuration of the endpoint MSH's because the URL will change.
Beside that we will need some special handling from the endpoints on non user
messages so this requirement can't be satisfied.
<JD> I think that statement should be read as
restricted to User Message sending. But indeed it is premature to say the PMode
needs no change (besides the URL of next
destination).
- Line 141: "This functionality is
referred to as a “table” mapping ebMS metadata to next hop" When using
the term addressing information this could be changed to a mapping of address
information to a next hop.
<JD>
right.
Section 1.7.1:
- Step 5:
It is unclear to me whether the
functionality for the pulling endpoint as it is described here is in accordance
with the core spec. This because the core spec says that a pulling
endpoint MUST include a wsrm:Offer in the PullRequest and the
responder should use the offered sequence. The core spec doesn't mention the
case when the responder doesn't accept the offered sequence, so I might assume
the Initiator must be able to handle CreateSequence signals that are sent to it
in response to the CreateSequence for the PullRequest signal. If this
assumption is correct it might not be needed to add the dummy eb-header as the
Initiator already has to accept a CreateSequence signal.
<JD> in a multihop context, it appears we may have to pull more than just eb User messages
(i.e. RM signals, and eb signals). It also appears that an Intermediary may not
be able to act as an RM node itself (so in that case the requirement needs be
relaxed: PullRequests should not need be sent reliably, while pulled User
Messages may use RM. This is OK as the Intermediary never does resending itself.
Only the endpoint MSHs do). We have to look more into
this.
- Step 7:
Again it I'm not sure if this complies
with the core spec and the need for the dummy eb:header.
<JD> right, although dummy eb:headers are added here
by Intermediaries , not by endpoint MSHs.
Sander
On 28 mei 2008, at 08:05,
jdurand@us.fujitsu.com wrote:
- a few updates in the definition section
(editorial)
- added a commented Flow diagram (section 1.7.1) on RM
sequence
establishment. To review.
NOTE: suggest to first focus on and
finalize such diagrams before drafting
detail of spec content.
-- Mr
Jacques Durand
The document revision named Multi-hop Section Draft
0.3
(ebMS3-Multihop.doc) has been submitted by Mr Jacques Durand to the
OASIS
ebXML Messaging Services TC document repository. This document
is revision
#1 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.
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?document_id=28415
Download
Document:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/28415/ebMS3-Multihop.doc
Revision:
This
document is revision #1 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