[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: RM Group Definitions
i don't think grouping is appropriate at this time. we need to keep it simple for the first round of ebxml... that is that though the end of may next year..... rik -----Original Message----- From: Jim Hughes [mailto:jfh@fs.fujitsu.com] Sent: Monday, August 28, 2000 11:32 AM To: ebxml-transport@lists.ebxml.org Subject: RM Group Definitions Our initial rendering of the RM spec just assumed that MS layer was sending messages needing "reliable delivery", with no context of a "conversation" or "multiple TPAs" assumed -- this was left to other MS functions or a higher layer. The grouping of what would otherwise be independent messages into an "RM Group" was just to provide performance/implementation improvements. If the MSH needs to group messages for other reasons, then we should have a discussion about this and see if the RM Group concept is embedded in that architecture, or should be separate in a lower layer in the MSH... Regarding Marty's comment on efficiency, we assume that the higher-level layer using RM would establish the size of an RM Group. Marty feels that the upper layer BP should not do this (correct, Marty?), so we need to decide architecturally if the MSH should determine this grouping and how it is done. The trivial case, of course, is to just set the size of each RM Group to be one message, which forces MSH-level ACKs for each message. Jim At 10:27 AM 8/28/2000 -0400, Farrukh Najmi wrote: >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 > > > **************************************************************************** ********* > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC