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: Pim on routing intermediaries, WS-ReliableMessaging


The intermediary beeing itself an RM/security endpoint fits the
"gateway" topology use case T1 (in my previous summary)
But  CDC asked for a use case more like T3, where there could be a
"cloud"  of intermediaries (1 or more) between 2 parties that support
end-to-end RM.
Typically: party A --> regional hub 1 --> regional hub 2 --> party B.
With no possibility to bypass the hubs.

So here is some more ideas on the ebMS-routing option:

Regardless of the routing technique, something remains always true in
sequence-based RM
(whether WS-Reliability or WS-ReliableMessaging):
The sender must always know which messages are for the same destination
(i.e. belong to same sequence), even if it does not know this
destination.
That means all these messages have something in common, known from the
sender. This could suggest a possible ebMS-level handshaking to acquire
the Sequence ID, piggybacking an RM CreateSequence over a dummy ebMS
user message that we know will reach this destination.

To be more specific, the "T3" use case has two subcases:
(1)
party A --> regional hub 1 --> regional hub 2 --> party B.
With hub 2  = last intermediary, and party B = RMDestination.
(2)
party A --> regional hub 1 --> regional hub 2 --> party B --> subparty
B1, B2...Bn.
With party B = RMDestination, as well as an intermediary in DMZ. This
case combines T1 (the gateway pattern) with T3, and assumes a lot of
flexibility in adding subparties behind B.

In order to *not* ask anything to the final MSH (e.g. party B in (1), or
subparty B1 in (2)) beyond what the Core spec is requiring, the last
intermediary on the path would have to take care of routing back the
obtained Sequence ID using a similar piggybacking. For this it needs to
know it is the last intermediary on the path (could compare the wsa:From
it gets in response, with the URL it has sent the request to).

So it boils down to two major cases:
- If the final destination is known, then all routing could be based on
just wsa (e.g. wsa:To, and wsa:From or wsa:ReplyTo for the way back) and
obviously nothing more is needed.
- If the final destination is NOT known, some ebMS routing can still be
used, with an ebMS-driven handshake for RM sequence management
(creation, closure). Here too wsa would play some role, even if lesser. 

Jacques

-----Original Message-----
From: Moberg Dale [mailto:dmoberg@axway.com] 
Sent: Monday, November 19, 2007 12:32 PM
To: Pim van der Eijk; Durand, Jacques R.; ebxml-msg@lists.oasis-open.org
Subject: Pim on routing intermediaries, WS-ReliableMessaging

[Pim explained the conflict between WS-ReliableMessaging and the
advantages in using routing intermediaries.]

The main options for dealing with the conflict are 

0. Use WS-Addressing anonymous for reply-to and acks-to, and have all
intermediaries wait before their HTTP reply is made.
[The above does not scale well, is brittle, and utilizes lots of
resources.]

1. Use piggybacking (and presumably 1 message long sequences?).
[Still lacks routing advantages. RMSes have to target RMDs, and so have
high lifecycle configurability burdens. Routing intermediary topology
cannot be changed while leaving RMS configuration unchanged. Probably
destroys advantages of ebMS routing intermediary, as Pim explained.]

2. Locate RMD at routing intermediary, and check security at
intermediary also.
[ Loss of end to end reliability.]


Pim has convincingly explained how WS-ReliableMessaging is not very
intermediary friendly and, along with Jacques, reflects a step backwards
in trying to accommodate intermediaries with end-to-end acknowledgments.
However, the goal of WS-* technology level convergence seems to require
that we support WS-ReliableMessaging because it is the WS-I sanctioned
solution.

Is option 2 above an option that could be embellished to be
satisfactory? What would it take? Add on an ebBP/RN style
ReceiptAcknowledgment or ReceiptAcknowledgmentException (if we wanted to
be optimistic with respect to WS-ReliableMessaging terminated at
intermediary working most of the time?)

Just some reactions. Good analysis Pim!




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]