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: 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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC