RE: RM and Intermediaries

How about message encapsulation?

If service A sends a message to service B through intermediaries X and Y
(A->X->Y->B), then service A is only interested in getting an ack from
service B (end-to-end).

However, the RM at A may be interested in getting an ack from X, and the RM
at X may be interested in getting an ack from Y. In that way if A
successfully delivers to X, then A gets one ack from X, does not attempt to
resend and waits for ack from B.

If X successfully delivers to Y then X gets an ack from Y but never waits
for anything else. (For X, the ack coming back from B is a different message
that needs to be acknowledged in its own right).

If Y successfully delivers to B then Y gets an ack for that delivery, which
means it can stop resending to B. The ack the B sends to A is a different
message (as far as Y is concerned), and may go directly to A or travel back
through Y->X with acks going back from A->X->Y->B to confirm delivery of
ack.

Whether A->X->Y->B do that is dependent on the protocol they use. Whether
A->B do acks is dependent on the use of a WS RM.

A may talk to X using HTTP and not require any protocol-level ack. X may
talk to Y using UDP and may require protocol-level ack. X may talk to Y
using some MOM and have absolutely no clue whether the MOM does or does not
use ack. Some implementations have different ways of doing acks without
sending ack messages at all (e.g. a reliable multicast may send nacks and
piggyback acks into data packets).

However, at its discretion X may decide to wrap the message sent by A into a
larger message and then use WS RM to send that message to Y getting a WS RM
ack from Y for the message sent by X, indicating successful delivery from X
to Y (in effect encapsulating one message inside another). Y then extracts
the underlying message, wraps it again and delivers to B.

I think that is consistent with what David has been saying, it just proposes
multiple strategies for protocol-level acks that do not change the semantics
of the WS ack. It also highlights that using the reverse path is optional.

You could have a path A->X->Y->B and reverse path for the ack B->Z->A.
However, if X gives you some feature you want to retain for all messages
(e.g. validating the certificate) you would want to include X in the reverse
path. In that case you will need some header to indicate which nodes should
be part of the reverse path (e.g. WS-Routing).

arkin


> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Ugo Corda
> Sent: Saturday, January 25, 2003 4:50 PM
> To: Ricky Ho; www-ws-arch@w3.org
> Subject: RE: RM and Intermediaries
>
>
>
> Last month I raised a similar issue, and I got an extensive
> response from David Burdett at [1], which you might want to look at.
>
> Ugo
>
> [1] http://lists.w3.org/Archives/Public/www-ws-arch/2002Dec/0095.html
>
> > -----Original Message-----
> > From: Ricky Ho [mailto:riho@cisco.com]
> > Sent: Saturday, January 25, 2003 7:50 AM
> > To: www-ws-arch@w3.org
> > Subject: RM and Intermediaries
> >
> >
> >
> > Lets say S is the sender endpoint, R is the receiver
> > endpoint, and i1, i2
> > are intermediaries that pre-process the message.
> >
> > S --> i1 --> i2 --> R
> >
> > Do i1 and i2 have to understand RM ? or RM is just an end-to-end
> > handshaking between S and R ?  If so, can S pick a different
> > path in its
> > message resend ?
> >
> > Rgds, Ricky
> >
> >

Received on Saturday, 25 January 2003 20:07:07 UTC