[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Implementation question for RM spec!
I concur. -gvh- Marc Breissinger wrote: > > I am in agreement with Chris for removal of this restriction. > > marc > ========================================================================== > Marc Breissinger voice (W): 703-460-2504 > Director, Product Strategy - webMethods, Inc. voice (C): 703-989-7689 > Email: marcb@webmethods.com We're hiring!!! > Email2: breissim@earthlink.net URL: http://www.webmethods.com > ========================================================================== > > > > > > -----Original Message----- > > From: christopher ferris [mailto:chris.ferris@east.sun.com] > > Sent: Friday, September 29, 2000 11:24 PM > > To: ebxml-transport@lists.ebxml.org > > Subject: Re: Implementation question for RM spec! > > > > > > Jim/All, > > > > It isn't clear to me why it would be necessary to > > block until the previously sent message is ack'ed. > > That would be one manner of implementing, but not an > > approach I'd choose. > > > > Since each message is ack'ed individually, you can > > send as many messages as you like and process the > > acks or retry (in the case of a timeout) oob. > > > > The specification stipulates that one MAY use either > > the sequence number OR the messageId (refToMessageId) > > for the purposes of determining which message is being > > ack'ed. > > > > This is my understanding of what we have worked out for > > phase one. Possibly, it is misguided, but I for one would > > not advocate a (logically) blocking protocol. > > > > Cheers, > > > > Chris > > > > Jim Hughes wrote: > > > > > > Sanjay, > > > > > > Reliable Message grouping (sending one ACK for a group of messages) was > > > eliminated in phase 1 for a variety of reasons - error propagation not well > > > understood, how to handle partially sent groups, how to recover, etc. The > > > result is a very simple solution that does enforce a single pipeline as you > > > point out, with each reliable message being acknowledged before the next > > > one is sent (unreliable messages flow at any time). We will remove the > > > restriction after Phase 1, when there will be more normative specifications > > > for implementors. Simplicity rules for the moment... > > > > > > Jim Hughes > > > Fujitsu > > > > > > At 06:56 PM 9/29/2000 -0700, Patil, Sanjay wrote: > > > > > > >Jim, > > > > > > > >Could you please also comment on the third question in my original mail. > > > >It's about parallelism between any given sender-receiver pair. > > > >Is this restriction of working on one message at a time between > > > >any given sender-receiver pair a result of some TRP > > > >decision to get rid of the windowing. I vaguely remember > > > >your initial RM spec talking about windowing. > > > > > > > >Please advise. > > > > > > > >thanks, > > > >Sanjay Patil > > > >---------------------------------------------------------------------------- > > > >------------------------------ > > > >Work Phone: 408 350 9619 > > > >http://www.netfish.com > > > > > > > > > > > >-----Original Message----- > > > >From: Jim Hughes [mailto:jfh@fs.fujitsu.com] > > > >Sent: Friday, September 29, 2000 6:37 PM > > > >To: ebxml-transport@lists.ebxml.org > > > >Subject: Re: Implementation question for RM spec! > > > > > > > > > > > >Marty's exactly right on the complexity issues. > > > > > > > >The current TRP resolution for RM requires each sending MSH to generate > > > >sequence numbers for each sender-receiver pair (regardless of transport). > > > >Whether a receiving MSH actually uses the sequence number or the globally > > > >unique MessageID to detect duplications is implementation dependent. It's a > > > >lot easier to detect dups using sequence numbers... > > > > > > > >Jim > > > > > > > >At 06:10 PM 9/27/2000 -0400, Martin W Sachs/Watson/IBM wrote: > > > > > > > > >I believe that you correctly understand the intent of the RM protocol and > > > > >its implementation requirements. There indeed has to be a separate > > > > >"logical channel" for each pair of channels, if not for each conversation, > > > > >using reliable messaging, precisely to avoid the blocking you mention. > > > > >That's what it takes to get the parallelism you mention. > > > > > > > > > >I believe that the implementation would be simplified and perform better if > > > > >the sequence numbers were eliminated as someone (yourself?) has already > > > > >suggested. I assume that sequence numbers have been discussed at this > > > > >week's TRP face to face. > > > > > > > > > >Except for the sequence number question, I believe that exactly the same > > > > >implementation considerations would be present if reliable messaging were > > > > >done in the transport layer instead of the message service. > > > > > > > > > >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 > > > > >*************************************************************************** > > > >********** > > > > > > > > > > > > > > > > > > > >"Patil, Sanjay" <Spatil@netfish.com> on 09/27/2000 02:45:15 PM > > > > > > > > > >To: "Ebxml-Transport (E-mail)" <ebxml-transport@lists.ebxml.org> > > > > >cc: "Ebxml-Poc (E-mail)" <ebxml-poc@lists.ebxml.org>, "Askary, Sid" > > > > > <saskary@netfish.com> > > > > >Subject: Implementation question for RM spec! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >I was going through the Reliable Messaging spec for scoping the work > > > > >involved in implementing the spec for the upcoming Tokyo POC. > > > > >Questions about the same ...particularly in the context of the following > > > > >requirement posed by the RM spec ... > > > > > A sender MSH should not send the next message till it receives > > > > > an Acknowledgement Message from the Receiver. > > > > > > > > > > 1>This will necessitate instantiating a separate MSH instance for each > > > > >recipient > > > > > party, as it will not be fair for blocking outgoing messages to > > > > >Parties > > > > >having > > > > > a clear messaging channel while Messages to Parties with poor links > > > > >are > > > > > > > > > > successfully sent (tried to send). > > > > > > > > > > 2>This will also mean that separate outbound message queues are to be > > > > > maintained for each recipient. For each recipient Party, I will have > > > > >to > > > > >manage > > > > > the lifecycle of a dedicated SequenceCounter i.e.recycling the > > > > >SequenceCounter > > > > > upon tripping over the max as well as when they get stale after "long > > > > >time". > > > > > In hub scenarios, this will amount to a lot of runtime objects > > > > >creation > > > > >and > > > > > will also require an ongoing activity in the server to manage the > > > > >queues and > > > > > lifecycles of the SequenceCounter objects. > > > > > > > > > > 3>With lots of outbound messages for the same recipient Party, there > > > > > should be some provision for parallelism. Typically when servers can > > > > >handle multiples > > > > > of parallel message exchanges, the RM spec will necessitate using a > > > > >single > > > > > pipeline resulting into underutilization of capacity and slowing down > > > > >of the entire > > > > > process. Critical messages requiring immediate transfer might get > > > > >stuck > > > > >in the > > > > > queue for unreasonable amount of time. > > > > > > > > > >Or am I missing something very fundamental. It's been a while I have done > > > > >ebXML, > > > > >and with the Tokyo POC not very far, I got to catch up :-). > > > > > > > > > >thanks, > > > > >Sanjay Patil > > > > >--------------------------------------------------------------------------- > > > >- > > > > > > > > > >------------------------------ > > > > >Work Phone: 408 350 9619 > > > > >http://www.netfish.com
begin:vcard n:Van Huizen;Gordon tel;work:510-848-1988 x-mozilla-html:TRUE url:http://www.sonicmq.com org:Progress Software;XML and Internet Technology adr:;;14 Oak Park;Bedford;MA;01730; version:2.1 email;internet:gvh@progress.com title:Director, Product Management fn:Gordon Van Huizen end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC