ebxml-transport message

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


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: RM Group Definitions

One rejoinder in line.



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

Marc Breissinger <marcb@webmethods.com> on 08/30/2000 06:00:29 PM

Please respond to marcb@webmethods.com

To:   Jim Hughes <jfh@fs.fujitsu.com>, ebxml-transport@lists.ebxml.org
Subject:  RE: RM Group Definitions

See  comments inline.
-----Original Message-----
From: Jim Hughes  [mailto:jfh@fs.fujitsu.com]
Sent: Wednesday, August 30, 2000 5:09  PM
To: ebxml-transport@lists.ebxml.org
Subject: Re: RM  Group Definitions

... History removed ...

At the risk of generating  more email (thanks, but I get enough TRP email
these days!), let me assert  some points that seem to be common in recent

a) eliminate the  use of RM-Groups. MSHs must process individual messages
in a reliable manner  and post an error if the delivery was not completed.

--> note: if we  agree to this, we can avoid all the email discussions on
complexities of how  groups are used, set, involved with BP-level
activities, etc.!


b) successful RM delivery  means the MSH on the receiver side got the
message. No upper-level BP is  involved.


c) if an MSH knows that  the transport is reliable, it may make use of this
knowledge and not use RM  semantics for the message. We will then need to
indicate in the Routing Header  (most likely place) that even though the
Message Header specifies  "AtMostOnce", there is no MSH-level ack expected
by the sender.


d) Routing Header  elements are added for each MSH-MSH link in the path. RM
needs to have some  fields in this header, but there may be requirements
for other fields  (security, audit, etc.).


e) the sending application flags *each* message as reliable or  not.


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

g) For simplicity, ACKs  which indicate successful receipt of a reliable
message are just MSH-level  acks. The presence/absence of BP or transport
level ACKs is orthogonal. (this  one had several differing viewpoints!)


There are probably more  architectural points we could resolve, but if we
can get past these now, I can  make progress on a revised RM draft.

===> Please post  comments/agreements/disagreements to the above points by
COB 1 September (or  let me know if you need more  time).




At  09:43 AM 8/29/2000 -0400, Christopher Ferris wrote:
I agree. It isn't clear to me where the notion  of BP-level
or application-level grouping came from as I haven't  had
an opportunity to read ALL of the messages sent during  my
vacation, but this seems to me to be something we should
steer  well clear of.


richard drummond wrote:
>  i don't see grouping messages as being a key point of a reliable
> spec. yes it is important for performance... but not for  reliable
> that is why i think we should forgo it on this  round and concentrate on
> rm part of things.... best regards,  rik

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC