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: RM Group Definitions

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


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

MWS::  The message service handler (as defined in the Message Service
does not have to be aware of the specifics of any conversation state.
the specification does have to state whether or not it preserves order of
as sent.  The ordering issue is especially important for applications that
messages that have no business-level responses (in which case, the
does not receive the responses that allow it to preserve order).  For
that have transport-level acknowledgments, proper handling of
acknowledgments can preserve order.  I have heard of cases, however, where
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
most of my ordering concern will disappear.  However there will still be
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
This makes sense at the transport level since it is probably easy to see
an application- (or TPA-) supplied timeout is unreasonably long. At the
application level, all bets are off since reasonable timeouts could be days
subcontractors and human workflows are involved.  It also might be viewed
this safety issue is an implementation matter and not for the MS

>(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
>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
the reliable messaging specification can be used with any reasonable
and quite a different thing to say that the design of the reliable
specification doesn't have to concern itself with transport
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
Keeping the transport level completely hidden from the MS level implies
a store-and-forward interface, with transactional semantics, exists between
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

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

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
a major piece of work is needed to get the RM-group concept working
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
RM-group ACK and the transport ACK,


[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