Re: FWD Re: Failed posting on RM issues

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

Gordon,


<diclaimer>Forgive me if I am totally misinterpreting the RM spec...</diclaimer>

The whole point of RM-Groups as I understand it is to optimize bandwidth by
sending a single group ack per message group. I believe that messages in a message
group are sent on a per message basis in the proposal. Can someone validate my
assumption?

I think the core issue I raised in the original post was whether there is
justification for adding the complexity of RM-Groups in RM spec. I think Dave's
suggestion of articulating use cases is good.

A second related issue I had raised was that if we are to agree that the
RM-Group's bandwidth optimization is worth the added complexity of RM-Group
support, then it should be the RM layers responsibility to determine the begin and
end boundaries of an RM group (and not the applications). I suggested one possible
way that the RM layer could transparently handle boundary determination of
RM-Group by using some information that we could add to the TPA (polling
frequency).

Hopefully we can reach a balance between the extremes of over complexity and
dumbing down of the spec.

--

Regards,
Farrukh Najmi

Gordon van Huizen wrote:

> 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:Najmi;Farrukh 
tel;fax:781-442-1610
tel;work:781-442-0703
x-mozilla-html:TRUE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh S. Najmi
end:vcard