Re: Implementation question for RM spec!

[Martin W Sachs/Watson/IBM <mwsachs@us.ibm.com>]

If a logical channel is not blocked until the ACK is received, retries will
get messages out of order.  If every message has a business-level response
and ordering of messages is enforced by sequencing rules, then everything
will stay in order. Of course, that only means that blocking is taking
place at the business process level and it doesn't matter whether blocking
takes place at the MS level.
Blocking is needed at the MS level to keep messages in order when the
business process level doesn't force ordering.

The questions are:
   Do we want to restrict ourselves to scenarios where ordering is
   preserved at the business process level?
   If the business process level does not preserve ordering, do we care
   whether the MS level gets things out of order?

The conservative answer is not to let the MS level get messages out of
order on a given logical channel.  That may or may not be the best design.

Note also that MS blocking is only within a single logical channel.
Blocking in one channel does not cause other channels to stall (assuming a
good implementation).

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



christopher ferris <chris.ferris@east.sun.com> on 09/29/2000 11:24:06 PM

To:   ebxml-transport@lists.ebxml.org
cc:
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