RE: RM Group Definitions

[Marc Breissinger <marcb@webmethods.com>]

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

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

Agreed. 

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

Agreed.

 
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.

Agreed. 

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

 Agreed.

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

Agreed.

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

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

Agreed.

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

Thanks,

Jim

---------------------------


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.

Chris

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