RE: [ebxml-msg] Groups - Multi-hop Section Draft 0.3 (ebMS3-Multihop.doc

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

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.

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.

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

ebxml-msg message