Re: FW: T2 SyncReply and ReliableMessagingMethod inQualityOfServiceInfo

[Dan Weinreb <dlw@exceloncorp.com>]

I recently read the 73 previous emails in this thread.  As a newcomer
to the discussion, I apologize in advance if I backtrack over ground
that was already covered before I started listening, but I hope my
perspective as a newcomer might be helpful.

I found some of the points made in the discussion difficult to
evaluate, because I don't feel that I understand the scope of what
intermediaries are about.

Is there a set of "use cases" illustrating the ways in which it is
anticipated that intermediaries would be used?  In each case, it would
be helpful to understand the extent to which use of the intermediary
would have to be pre-arranged and/or understood by the From and To
parties, both at the MSH level and at the business level.

I'd also like to better understanding the question of "routing": if an
intermediary receives a message destined for some party, how does it
determine which communications protocol to use and what
communications-level address to use?

There were two interesting use cases mentioned earlier in the thread.

One was in Chris F.'s mail (of Wed, 08 Aug 2001 20:02:22), where one
endpoint party, which doesn't have a permanent presence on the
Internet, "uses an intermediary as a way station between itself and
another intermittently connected partner".  Here, the payload is
unaffected, and the intermediary is being used entirely at the MSH
level.

Another was in David B.'s mail (of Wed, 08 Aug 2001 18:35:13), in
which the intermediary translates payloads between RosettaNet and EDI
formats, and uses ebXML without RM over MQSeries on one hop, and ebXML
RM on the other.

Are these considered representative?  Is there a requirements
statement somewhere that explains what sorts of use cases the Message
Service is supposed to support?

In both cases, I would think that the use of the intermediary would
have to be pre-agreed by both sides, rather than being "invisible" to
either, and rather than being determined entirely dynamically (at
runtime after all pre-agreements).

In both cases, I'm not sure how the intermediary knows where to send a
message to, once it has received the message.  The From MSH sends out
the original message specifying the ultimate destination in the
MessageHeader/To/PartyID, and sending the message to a communications
address (e.g. an HTTP URL, an email address, or an MQSeries queue
name) that specifies the intermediary.  How does the intermediary know
what communications protocol and what communications address to use in
order to get to the final destination?  Even if the From and To
parties agreed in advance on this, and put it in their common CPA
(even though I don't see how the existing CPA format could represent
this), would the intermediary be expected to have a copy of that CPA?

David B.'s mail says:

   The intermediary has separate agreements with each party
   What this means is that there two types of agreements in place:
   1. Between the From or To Party and the Intermediary which covers how
   messages are sent but NOT the business process.
   2. Between the From and To Party directly that cover the business process
   they will follow but not how messages are sent.

This sounds right to me.  And it explains how the intermediary knows
where to send a message to.  It implies that there really need to be
two kinds of pre-agreement, rather than just one (the CPA).  That
seems to be a rather important implication, which was not followed up
on in subsequent mail.  Shouldn't this receive more attention?

Digression about layering (please take with a grain of salt):

There has also been discussion of having two kinds of acknowledgments,
two kinds of message ID's (either in the form of David B.'s proposed
ResendOfMessageId or David F.'s retry-number), etc.

My immediate reaction to all this, which I realize is rather radical,
is that perhaps what's needed is to separate the whole protocol into
two layers: a lower layer at which intermediaries are fully visible,
and a higher layer at which the intermediaries are invisible.
Protocol layering has been used extensively in real networks with
a lot of success.

For example, each layer would have its own concept of acknowledgement.
An acknowledgement at the higher layer (similar to the current
Delivery Receipt) would look, to the lower layer, like just another
message to be delivered, since the lower layer would not interpret the
higher layer.  We would not have to ask questions about how
Acknowledge's and Delivery Receipt's interact with each other, such as
in Arvola C.'s mail (of Sun, 12 Aug 2001 11:15:43).

Each layer would have its own way to do duplicate elimination and
retransmitting where necessary (just as the next layer down, TCP, has
its own duplicate elimination and retransmitting!).

And each layer would have its own form of pre-agreement, the CPA being
the one for the higher layer, and a new one being introduced for the
lower layer.

I realize that it's late in the game to suggest something like this,
and I apologize if I'm sounding presumptuous, but it's possible that
thinking in terms of this kind of layering might suggest useful
approaches.