Re: FWD Re: Failed posting on RM issues

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

It was my interpretation that an RM-Group is between a specific sender/receiver/transport. Further I
assume the sender/receiver mapped to a specific TPA instance. This led to the assumption that pollling
frequency could be specified in TPA. Marty, you seem to be implying that an RM-Group could contain
messages related to multiple TPAs. Which is the correct assumption about RM-Group?

BTW This sort of thing is again pointing to the need of clarifying what an RM-Group is.

6) One or more messages between the Sender and Receiver on the same Sender-Receiver-Transport triplet
may be sent using Reliable Messaging semantics. This sequence messages is termed an “RM-Group”.

--

Regards,
Farrukh

mwsachs@us.ibm.com wrote:

> Sspecifying polling frequency in the TPA is not appropriate because a given
> TPA involves two particular partners while the RM function involves all
> TPAs using the particular transport path.  Each TPA might specify different
> polling frequencies.  Oour goal should continue to be to keep the RM
> details transparent to the application (and therefore transparent to the
> TPA).  One could think about a TPA which defines the relationship between
> two Messaging Service instances but this should be a last resort.
>
> The RM proposal indeed increases efficiency by decreasing the ACK frequency
> but as I discussed in my comments to the current version of RM, this
> efficiency is at the cost of substantially increased latency for each
> message since no received message can be passed up to the application until
> all messages in the RM group have been successfully received.
>
> 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
> *************************************************************************************
>
> Christopher Ferris <chris.ferris@east.sun.com> on 08/24/2000 10:54:14 AM
>
> To:   ebxml transport <ebxml-transport@lists.ebxml.org>
> cc:
> 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