RE: RM Group Definitions

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

One re-rejoinder in line (MWS::).

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



Jim Hughes <jfh@fs.fujitsu.com> on 08/30/2000 07:46:46 PM

To:   ebxml-transport@lists.ebxml.org
cc:
Subject:  RE: RM Group Definitions



At 06:30 PM 8/30/2000 -0400, mwsachs@us.ibm.com wrote:
>One rejoinder in line.

>f) messages sent reliably  on a sender-transport-receiver triple should be
>received/processed in the same  sequence. Marty has expressed several
times
>that this needed to be true for  RM-Groups, and if we eliminate grouping,
>the principle should apply to  singleton messages. This concept follows
>KISS and was in the original Fujitsu  proposal.
>
>Not so sure I agree on this one.  Given that multiple,  independent
>BP-level conversations may be occurring over the same
>sender-transport-receiver triple, requiring ordering at the
>sender-transport-receiver triple level could prevent valid messages from
>being  processed.  I can understand the need when RM-Groups were involved
>and  multiple transactions were being sent before receiving ACKs, but my
>concept of  KISS in the singleton message scenario would be for the sender
>to manage the  ordering (i.e., if ordering is required, the sender must
>wait for the ACK before  the next message is sent).
>
>MWS:  You are right that ordering need not be global.  However the order
of
>the messages in a given conversation must be preserved.  This is a
>significant point if a conversation can include multiple messages which do
>not have business-level responses.

Does the Message Service Handler (MSH) need to be aware of the ordering of
messages in a given conversation - or even be aware of any conversation
'state' between messages? I was working under an assumption that the
application kept this information, and 'ordering' meant that one reliable
message on a sender-transport-receiver triple had to complete (either by
ACK or timeout) before the next reliable message could be sent. (All this
discussion assumes we no longer have the concept of RM grouping, of
course).

MWS::  The message service handler (as defined in the Message Service
Specification)
does not have to be aware of the specifics of any conversation state.
However,
the specification does have to state whether or not it preserves order of
messages
as sent.  The ordering issue is especially important for applications that
send
messages that have no business-level responses (in which case, the
application
does not receive the responses that allow it to preserve order).  For
transports
that have transport-level acknowledgments, proper handling of
transport-level
acknowledgments can preserve order.  I have heard of cases, however, where
the
sending transport may send a message before receiving the ACK to the prior
message.  That allows things to get out of order also.  If we drop RM
grouping,
most of my ordering concern will disappear.  However there will still be
the
question of how the RM ACK and transport-level ACK will interact.

This solution certainly opens up the possibility that a rogue application,
setting an infinite timeout with a lost message, might cripple the link
without some safeguards.

MWS::  No easy solution here.  One possibility is to provide a messaging-
service deadline that overrides longer timeouts specified by the
application.
This makes sense at the transport level since it is probably easy to see
whether
an application- (or TPA-) supplied timeout is unreasonably long. At the
business
application level, all bets are off since reasonable timeouts could be days
if
subcontractors and human workflows are involved.  It also might be viewed
that
this safety issue is an implementation matter and not for the MS
specification.

>(If the conversation is pure
>request-response, that will force the ordering.)  I am not convinced that
>with the current reliable message draft, merely requiring a
transport-level
>ACK is sufficient to guarantee ordering.

Not sure of your comment. The current draft doesn't have anything to say
about transport-level ACKs - it only deals with MSH-level ACKs and is
"agnostic" to the actual transport used.

MWS::  Please forgive me if I am repeating this:  It is one thing to say
that
the reliable messaging specification can be used with any reasonable
transport
and quite a different thing to say that the design of the reliable
messaging
specification doesn't have to concern itself with transport
characteristics.
We know that some or most transports do have ACKs and we do have to concern
ourselves with how the reliable messaging ACK interacts with the transport
ACKs.
Keeping the transport level completely hidden from the MS level implies
that
a store-and-forward interface, with transactional semantics, exists between
MS
and transport.  Such an assumption has to be explicitly stated in normative
text.  I don't think that implementers will be happy with such a
constraint.

>  That will depend on how we
>specify the relationship between the transport-level ACK and the RM ACK.
I
>discussed this in an earlier posting.  Note that, as I discussed in
>previous postings, retry of missing messages can get the messages out of
>order.

Switching back to the current draft, which proposed RM-Groups, you are
correct that within an RM-Group the actual ordering of messages can be
indeterminate if there re-sends. We could work on that issue, but if there
is general agreement to abandon the concept of groups for now, we don't
have to have that discussion!  :-)

MWS::  I think that we have worked the set of RM issues enough to realize
that
a major piece of work is needed to get the RM-group concept working
reliably.
I agree with those who suggest putting the RM-group on the futures list.
But again, we still have to concern ourselves with the interaction between
the
RM-group ACK and the transport ACK,

Jim