OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC