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