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!

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...


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.
>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
>      party, as it will not be fair for blocking outgoing messages to
>      a clear messaging channel while Messages to Parties with poor links
>      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
>      the lifecycle of a dedicated SequenceCounter i.e.recycling the
>      upon tripping over the max as well as when they get stale after "long
>      In hub scenarios, this will amount to a lot of runtime objects
>      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
>      pipeline resulting into underutilization of capacity and slowing down
>of the entire
>      process. Critical messages requiring immediate transfer might get
>in the
>      queue for unreasonable amount of time.
>Or am I missing something very fundamental. It's been a while I have done
>and with the Tokyo POC not very far, I got to catch up :-).
>Sanjay Patil
>Work Phone: 408 350 9619

[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