RE: T2, Proposed solution for ... Re: SyncReply and ReliableMessa gingMethod in QualityOfServiceInfo

["HUGHES,JIM (HP-Cupertino,ex1)" <jim_hughes@hp.com>]

Question: Does "reliable messaging" mean that the initial MSH (and maybe
intermediate node MSHs) needs to consider this as a quality request and, if
possible, pick the "most" reliable transport available? Or, is this just a
protocol for the receiving MSH to send a confirming ACK back to the sending
MSH?

I think it's the latter, and thus there is no directive for intermediate
node links to use the RM protocol to confirm among themselves that this
message got through. From their perspective, the overall MSH Ack looks like
a higher level function to them... and, in fact, it seems to me that having
the intermediate links try to use their own version of RM between their
endpoints really complicates the picture and maybe they should be prohibited
from trying to use RM since they aren't the start/end-points for the overall
message... IMO. 

jim



> -----Original Message-----
> From: Arvola Chan [mailto:arvola@tibco.com]
> Sent: Sunday, August 12, 2001 9:30 PM
> To: David Fischer; Burdett David
> Cc: ebXML Messaging (E-mail)
> Subject: Re: T2, Proposed solution for ... Re: SyncReply and
> ReliableMessaging Method in QualityOfServiceInfo
> 
> 
> David:
> 
> My comments are bracketed by <ac> and </ac>.
> 
> Cheers,
> -Arvola
> 
> ----- Original Message -----
> From: "David Fischer" <david@drummondgroup.com>
> To: "Arvola Chan" <arvola@tibco.com>; "Burdett David"
> <david.burdett@commerceone.com>
> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> Sent: Sunday, August 12, 2001 2:33 PM
> Subject: RE: T2, Proposed solution for ... Re: SyncReply and
> ReliableMessaging Method in QualityOfServiceInfo
> 
> 
> > Arvola,
> >
> > What if I am sending to you and you are using an IM for 
> some reason, e.g.
> no
> > persistent connection?  I might not even know and since I have no
> agreement with
> > that IM (my agreement is only with you), I cannot be responsible for
> putting the
> > CPAid in the Via -- there is no CPAid.  What I can do is 
> fill in the Via
> fields
> > as much as I am able in case there is an IM I am not aware 
> of.  This, IMO
> will
> > be a very common use case.
> >
> > This exact same situation would arise if you used multiple 
> MSHs where one
> was a
> > mailroom.
> >
> 
> <ac>
> I must admit that your use case is a very valid one and I 
> have not made
> provision for
> it.
> 
> Come to think of it, when I suggested that the sender MSH 
> should dictate if
> all intermediaries
> should use reliable message or not at all, it is not strictly 
> necessary for
> the sender MSH to
> know that intermediaries are involved, all it is choosing is between
> reliable message with
> intermediate Acks vs reliable messaging without intermediate Acks.
> 
> As you have indicated earlier, "Even though the ends don't 
> need to know
> about the IMs,
>  it is critical that the IMs realize their role." There, the 
> IMs should be
> able to respect the
> directive from the sender MSH to use intermediate Acks or not.
> </ac>
> 
> > You are correct, I need to be more clear.  I believe the 
> sender MSH would
> > construct the Via.  This Via would pass to the first IM MSH 
> who would
> construct
> > a new Via (possibly very similar to the original) and pass 
> this new Via to
> the
> > next hop's MSH.
> >
> > NEW PROBLEM WITH MULTI-HOP?
> > This brings up a good point.  I (the From Party MSH) know 
> how to send to
> you
> > (the To Party MSH) because I can look up your connection 
> info in the CPA
> > Database based upon a CPAid and a ChannelID.  This info 
> might not reside
> in the
> > To PartyID element.  If my message goes through an IM, how 
> does the IM
> know
> > where to send?  I don't send to you, I send to my IM.  If I 
> am using an
> IM, does
> > that mean any time I make an entry in my database I also 
> have to duplicate
> that
> > info to my IM (and they to each of their IMs etc.)?  This 
> would not be
> > acceptable.  Maybe this connection info MUST reside in the 
> To PartyID?
> This
> > would not be a problem for single-hop.  Maybe the Receiver 
> connection info
> needs
> > to be put in the Via?
> >
> 
> <ac>
> I agree with you this is a problem. The intermediary needs to 
> be configured
> with the
> Endpoint and various characteristics for the To Party (or the 
> Endpoint for
> yet another
> intermediary who can route messages to the To Party directly 
> or indirectly
> and its
> characteristics). My understanding is that CPPs and CPAs 
> currently deal only
> with
> the point to point case. Therefore, there is no automated way 
> to configure
> intermediaries
> using CPAs. This is something the CPP/A TC will have to 
> address in its 2.0
> spec.
> </ac>
> 
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >