OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-poc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Implementation question for RM spec!

that is a phase 1 restriction only. it will be lifted in phase 2 or 3... i
don't remember which phase? dick or chris do you... best regards, rik

-----Original Message-----
From: Patil, Sanjay [mailto:Spatil@netfish.com]
Sent: Wednesday, September 27, 2000 1:45 PM
To: Ebxml-Transport (E-mail)
Cc: Ebxml-Poc (E-mail); 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 Parties
     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
     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 creation
     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 stuck
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