Subject: RE: RM Group Definitions
One rejoinder in line. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* Marc Breissinger <marcb@webmethods.com> on 08/30/2000 06:00:29 PM Please respond to marcb@webmethods.com To: Jim Hughes <jfh@fs.fujitsu.com>, ebxml-transport@lists.ebxml.org cc: Subject: RE: RM Group Definitions See comments inline. -----Original Message----- From: Jim Hughes [mailto:jfh@fs.fujitsu.com] Sent: Wednesday, August 30, 2000 5:09 PM To: ebxml-transport@lists.ebxml.org Subject: Re: RM Group Definitions ... History removed ... At the risk of generating more email (thanks, but I get enough TRP email these days!), let me assert some points that seem to be common in recent emails: a) eliminate the use of RM-Groups. MSHs must process individual messages in a reliable manner and post an error if the delivery was not completed. --> note: if we agree to this, we can avoid all the email discussions on complexities of how groups are used, set, involved with BP-level activities, etc.! Agreed. b) successful RM delivery means the MSH on the receiver side got the message. No upper-level BP is involved. Agreed. c) if an MSH knows that the transport is reliable, it may make use of this knowledge and not use RM semantics for the message. We will then need to indicate in the Routing Header (most likely place) that even though the Message Header specifies "AtMostOnce", there is no MSH-level ack expected by the sender. Agreed. d) Routing Header elements are added for each MSH-MSH link in the path. RM needs to have some fields in this header, but there may be requirements for other fields (security, audit, etc.). Agreed. e) the sending application flags *each* message as reliable or not. Agreed. f) messages sent reliably on a sender-transport-receiver triple should be received/processed in the same sequence. Marty has expressed several times that this needed to be true for RM-Groups, and if we eliminate grouping, the principle should apply to singleton messages. This concept follows KISS and was in the original Fujitsu proposal. Not so sure I agree on this one. Given that multiple, independent BP-level conversations may be occurring over the same sender-transport-receiver triple, requiring ordering at the sender-transport-receiver triple level could prevent valid messages from being processed. I can understand the need when RM-Groups were involved and multiple transactions were being sent before receiving ACKs, but my concept of KISS in the singleton message scenario would be for the sender to manage the ordering (i.e., if ordering is required, the sender must wait for the ACK before the next message is sent). MWS: You are right that ordering need not be global. However the order of the messages in a given conversation must be preserved. This is a significant point if a conversation can include multiple messages which do not have business-level responses. (If the conversation is pure request-response, that will force the ordering.) I am not convinced that with the current reliable message draft, merely requiring a transport-level ACK is sufficient to guarantee ordering. That will depend on how we specify the relationship between the transport-level ACK and the RM ACK. I discussed this in an earlier posting. Note that, as I discussed in previous postings, retry of missing messages can get the messages out of order. g) For simplicity, ACKs which indicate successful receipt of a reliable message are just MSH-level acks. The presence/absence of BP or transport level ACKs is orthogonal. (this one had several differing viewpoints!) Agreed. There are probably more architectural points we could resolve, but if we can get past these now, I can make progress on a revised RM draft. ===> Please post comments/agreements/disagreements to the above points by COB 1 September (or let me know if you need more time). Thanks, Jim --------------------------- At 09:43 AM 8/29/2000 -0400, Christopher Ferris wrote: I agree. It isn't clear to me where the notion of BP-level or application-level grouping came from as I haven't had an opportunity to read ALL of the messages sent during my vacation, but this seems to me to be something we should steer well clear of. Chris richard drummond wrote: > > i don't see grouping messages as being a key point of a reliable messaging > spec. yes it is important for performance... but not for reliable messaging. > that is why i think we should forgo it on this round and concentrate on the > rm part of things.... best regards, rik
Powered by
eList eXpress LLC