[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: FWD Re: Failed posting on RM issues
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC