Pim on routing intermediaries, WS-ReliableMessaging

["Moberg Dale" <dmoberg@axway.com>]

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