[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: FWD Re: Failed posting on RM issues
Farrukh Najmi wrote: > > Chris, > > For some reason my post failed. It seems that the list srever may be > having problems. If you have any secret weapons please try and post this > for me in advance of todays POC call. BTW I have been meaning to say > welcome back from vacation. Hope it was the best. > > -- > > Regards, > Farrukh > > ---------------------------------------------------------------------------------------------------- > > Subject: Delivery Notification: Delivery has failed > Date: Thu, 24 Aug 2000 07:55:34 -0400 (EDT) > From: PMDF at eList eXpress <postmaster@eListX.com> > To: Farrukh.Najmi@east.sun.com > > This report relates to a message you sent with the following header fields: > > Message-id: <39A50D97.55587DBA@east.sun.com> > Date: Thu, 24 Aug 2000 07:57:11 -0400 > From: Farrukh Najmi <Farrukh.Najmi@east.sun.com> > To: "ebxml-transport@lists.ebxml.org" <ebxml-transport@lists.ebxml.org> > Subject: A few comments on RM spec > > Your message cannot be delivered to the following recipients: > > Recipient address: ebxml-transport@lists.ebxml.org > Reason: Not found in directory > > ---------------------------------------------------------------------------------------------------- > Original-envelope-id: 0FZS00002P4MBM@eListX.com > Reporting-MTA: dns;eListX.com (DIRECTORY-DAEMON) > > Action: failed > Status: 5.1.1 (Not found in directory) > Original-recipient: rfc822;ebxml-transport@lists.ebxml.org > Final-recipient: rfc822;ebxml-transport@lists.ebxml.org > > ---------------------------------------------------------------------------------------------------- > > Subject: A few comments on RM spec > Date: Thu, 24 Aug 2000 07:57:11 -0400 > From: Farrukh Najmi <Farrukh.Najmi@east.sun.com> > Organization: Java Software East > To: "ebxml-transport@lists.ebxml.org" <ebxml-transport@lists.ebxml.org> > > First let me congratulate Shimamura San on a very elegant description of > issues in the RM spec. > > In my first reading I was not clear what the RM-Group was all about. I > had it mixed up with conversationId. It took soem time to realize that > this group of messages is not grouping messages related to a > conversation but possibly messages from several conversations between > the same two parties over the same transport. This could be better > explained in the spec. > > The main purpose of RM-group seems to be efficiency by aggregating acks > for all messages in an RM-group to a single group ack. The motivation > and purpose of RM-groups should be mentioned in spec. > > The remainder of this note outlines some issues I perceive and in some > cases suggestions for improvement. > > Do We Need RM-Group Complexity? > -------------------------------------------- > RM-Groups certainly add some additional complexity in the implementation > of RM in a ebXML messaging service. The only rationale I can identify is > performance efficiencies. Immediate concern is whether this is a > premature optimization that is pushing against the KISS principal and > is best to defer to a second version of ebXML. > > Determination of RM-Group boundaries > ----------------------------------------- > While I started by questioning the need for RM-Groups, I did spend some > time thinking about it. This led me to realize that the biggest issue I > have with RM-Group is not implementation complexity but the fact that > the spec currently seems to imply that it is up to the application layer > to determine the begin and end boundaries of an RM-Group. > > If my interpretation is correct then this is not desirable. Applications > have enough to worry about already and the goal of ebXML should be to > relieve the application of as much application neutral responsibilities > as possible. I cannot see how (or why) application would determine when > to begin or end an RM-group. Application errors can now impact RM > delivery of messages. > > I would be satisfied with the RM-Group concept despite added complexity, > if we could find a way for the RM layer to determine RM-Group > boundaries. One possibility I could think of is as follows. The TPA > defines a polling interval for the RM layer to check for messages for > each TPA. The interval could be immediate (event driven) or some other > periodic frequency specified in TPA. The RM implementation could use > this TPA info to do a combination of event driven + polling. When it > checks for messages waiting to be delivered for a TPA it could then make > them all be part of RM-Group. The actual RM-Group semantics and > algorithms would remain unchanged. The main improvement is that it is up > to the RM layer to determine the RM-Group boundary and set the > appropriate header fields defined by the RM spec. Does this sound like > it could work? > > Transport Specific Nature of RM-Group > ----------------------------------------- > It is possible that message exchanges between 2 parties may occur over > different transports. Even the same message may involve different > transports > during different hops. I am not sure why an RM-group is tied to a > sender-receiver-transport rather than sender-receiver. I suspect it is > because > the transport level error are being delegated to transport layer rather > than > the RM layer. At the very least a recommend a clearer description in the > spec on > why the transport is a consideration. > > Loss of an Error Message > -------------------------- > The spec mentions the issue regarding loss of an error message but does > not offer a solution. Would the following solution work? When an error > message is lost, the sender of the error message detecting a timeout if > no messages are resent for that group and resends the Error message (N) > times. If all attempts fail it raises an error to the application layer. > > Thanks again to for a good spec. > > -- > > Regards, > Farrukh Najmi > > ---------------------------------------------------------------------------------------------------- > > Farrukh S. Najmi <najmi@east.sun.com> > Sun Microsystems > Java Software > > Farrukh S. Najmi > Sun Microsystems <najmi@east.sun.com> > Java Software HTML Mail > 1 Network Drive, MS BUR02-302 Fax: 781-442-1610 > Burlington Work: 781-442-0703 > MA > 01803-0902 > USA > Additional Information: > Last Name Najmi > First Name Farrukh > Version 2.1 > > ---------------------------------------------------------------------------------------------------- > > Farrukh S. Najmi <najmi@east.sun.com> > Sun Microsystems > Java Software > > Farrukh S. Najmi > Sun Microsystems <najmi@east.sun.com> > Java Software HTML Mail > 1 Network Drive, MS BUR02-302 Fax: 781-442-1610 > Burlington Work: 781-442-0703 > MA > 01803-0902 > USA > Additional Information: > Last Name Najmi > First Name Farrukh > Version 2.1 -- _/_/_/_/ _/ _/ _/ _/ Christopher Ferris - Enterprise Architect _/ _/ _/ _/_/ _/ Phone: 781-442-3063 or x23063 _/_/_/_/ _/ _/ _/ _/ _/ Email: chris.ferris@East.Sun.COM _/ _/ _/ _/ _/_/ Sun Microsystems, Mailstop: UBUR03-313 _/_/_/_/ _/_/_/ _/ _/ 1 Network Drive Burlington, MA 01803-0903
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC