Re: FWD Re: Failed posting on RM issues

[Gordon van Huizen <gvanhuiz@progress.com>]

Considering that these acks are above transport-level acks, I would
think that one ack per message would be OK. How messages groups get
marshaled over the wire will be a separate issue.

-gvh-

David Burdett wrote:
> 
> > 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.
> 
> I tend to agree. There is a much simpler implementation where each message
> that needs to be sent reliably gets an individual ack. My rule of thumb on
> optimization, where it introduces greater complexity, is to see a use case
> where the need for the optimization is shown to be an imperative rather than
> a "nice-to-have". We went through a "KISS" exercise on the original 0-5
> version of the main spec. Do we want to do the same thing with the RM spec?
> 
> David
> 
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@east.sun.com]
> Sent: Thursday, August 24, 2000 7:54 AM
> To: ebxml transport
> 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
begin:vcard 
n:Van Huizen;Gordon
tel;work:510-848-1988
x-mozilla-html:TRUE
url:http://www.sonicmq.com
org:Progress Software;XML and Internet Technology
adr:;;14 Oak Park;Bedford;MA;01730;
version:2.1
email;internet:gvh@progress.com
title:Director, Product Management
fn:Gordon Van Huizen
end:vcard