RE: [ebxml-msg] Groups - End-to-end-RM_Transparent-multihop (ebMS-end2end-RM-scenario4.doc) uploaded

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Pim:

There are different options for routing a "response", back to the
initial "request" message sender.
RM has this AcksTo field, which - in general - is set to the original
message sender MSH (or its RM module).
The option in this proposal, is not that the responses flows directly to
the wsa:To address, but that the I-cloud has the ability to do routing
based on wsa:To URI (in addition to doing routing based on ebMS header
data.) This wsa:To matches the wsa:ReplyTo header in the request
message, set by the 1st intermediary on the path.

Jacques

-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net] 
Sent: Wednesday, February 20, 2008 2:19 PM
To: Durand, Jacques R.; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - End-to-end-RM_Transparent-multihop
(ebMS-end2end-RM-scenario4.doc) uploaded


Hello Jacques, 

I will join the call to discuss the document, but here is one comment
already:

Section 2.4, scenario A, step 8, does this assume that the last
intermediary can connect to, and has the address of, (wsa:To) the first
intermediary?  I think that assumption is questionable (especially in
the case of a One Way MEP). If the traffic has to flow through the
intermediary in one direction, then why would it be possible for the
response to flow directly back, bypassing the intermediary?  It seems
more likely that the traffic back has to flow in the reverse sequence of
intermediaries. 

Pim


-----Original Message-----
From: jdurand@us.fujitsu.com [mailto:jdurand@us.fujitsu.com]
Sent: 18 February 2008 08:30
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Groups - End-to-end-RM_Transparent-multihop
(ebMS-end2end-RM-scenario4.doc) uploaded

For review: Improved "transparent" ebXML intermediary model allowing
unmodified multi-hop re-routing of ebXML messages. It allows for
end-to-end reliable sequences, that avoid any RM header manipulation at
intermediary level.  No additional capability is required from the
endpoint MSHs involved in a multi-hop path, other than conformance to
Core V3 specification. No knowledge of the ultimate endpoint identity is
assumed, from Sending side.
The focus is here on a solution using WS-ReliableMessaging (which poses
greater challenges to multi-hop than WS-Reliability, given the routing
assumptions).

 -- Mr Jacques Durand

The document revision named End-to-end-RM_Transparent-multihop
(ebMS-end2end-RM-scenario4.doc) has been submitted by Mr Jacques Durand
to the OASIS ebXML Messaging Services TC document repository.  This
document is revision #2 of ebMS-end2end-RM-scenario2.doc.

Document Description:
Improved "transparent" ebXML intermediary model allowing unmodified
multi-hop re-routing of ebXML messages. No additional capability is
required from the endpoint MSHs involved in a multi-hop path, other than
conformance to Core V3 specification. The focus is here on a solution
using WS-ReliableMessaging (which poses greater challenges to multi-hop
than WS-Reliability, given the routing assumptions).

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/document.php?docu
ment
_id=27235

Download Document:  
http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/2723
5/eb
MS-end2end-RM-scenario4.doc

Revision:
This document is revision #2 of ebMS-end2end-RM-scenario2.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