Re: FW: T2, Proposed solution for ... Re: SyncReply andReliableMessagingMethod in QualityOfServiceInfo

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Thu, 20 Sep 2001 16:45:07 -0500
   From: David Fischer <david@drummondgroup.com>

   From: Chris.Ferris@Sun.COM [mailto:Chris.Ferris@Sun.COM]
   Sent: Thursday, September 20, 2001 11:50 AM

   How does this work if the sending MSH knows nothing of intermediaries?
   Are you suggesting that the Via element is now REQUIRED on all messages?

   <df>Yes, this is a problem, not only for retryCount but for all parameters in
   Via.  I have asked this same question before, is Via always required?  If we are
   doing RM at all, then Via is required in order to pass the ackRequested and
   reliableMessagingMethod parameters.  I guess Via is REQUIRED for all RM
   messages -- regardless of retryCount.
   </df>

Right, the question is whether it's an RM transmission or not.

Every hop in a communication is either using ebXML RM or not: ebXML RM
is being used if (a) this is supposed to be a reliable communication
and (b) reliableMessageMethod says that the reliability is done with
ebXML RM rather than by the transport layer.

Even if there is no IM, there is still one hop, and the hop is either
using ebXML RM or not.

   How does an intermediary distinguish itself as such?

   <df>The IM must know that it is an IM in order to forward rather than process
   the payload.  If the IM is not the From Party or the To Party then it must be an
   IM.  This is not quite true for a mailroom situation (need to work on this --
   something like MTA routing tables?  or MX records?).
   </df>

And whenever a hop happens, the MSH's at each end of the hop have to
"know" somehow what the reliableMessageMethod parameter is, so that
they know whether to talk ebXML RM or not.

   retryInterval applies to the RM retry. You are now stating that the DR is the RM
   artifact, not the Acknowledgment. What happens when no DR is requested/required?
   Does the sending MSH wait for the response message?

   <df>Chris, you are right, almost.  There is a CPA to the first IM and a CPA with
   the end.  

If we're going to be using CPA's this way, I think the CPA is going to
need some work.

The overall idea of the CPA is that you examine what business process
you're doing, what role you're in, and what service and action you're
performing; you submit this to the CPA, and it gives you back a
DeliveryChannel and a Packaging.  DeliveryChannel, in turn, give you
a Transport and a DocExchange, plus some parameter values.

The information in Transport is only relevant to hop-to-hop
communications; it's meaningless to ask for, say, the TCP address of
the To Party when there are IM's, since the From Party doesn't talk
directly to the To Party.

The information in Packaging is all about the payload, and so it's
only relevant to end-to-end communications; IM's don't pay attention
to the contents.

How about the parameters in DeliveryChannel, and DocExchange?  It
looks to me like they are about the communication as a whole, i.e. all
the hops, but this perhaps should be clarified.

Should the IM's really be looking at the Service and Action fields of
the message, and looking through the Override elements of a CPA, in
order to decide what parameters to use?