[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]