Re: FWD Re: Failed posting on RM issues

[mwsachs@us.ibm.com]

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