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


- in Fujitsu's original July presentation, we explained that each reliable message had an associated expiration time set for the message. A counter was used so the loss of a message could be quickly detected by the receiver. A message-service level ACK was synchronously returned for each message and the expiration time used to detect lost messages by the sender.

- in the July meeting, there was strong vocal opposition to ACKs for *each* message, so we moved to a grouping concept in response. How to identify the size of a group (BP? MSH? TPA?) was not defined and remains an open question in the draft RM spec. There is a value shown for this in the current draft - "RM-Group Count".

- since the header has a presumed unique MessageID, there was push to use it as the "counter" for easy detection of duplicates or lost messages. We've kept the counter concept in the latest draft, known as the "Sequence Number".

- originally, we specified that the message's Expiration Time was a QoS value specified by the application, and this was passed with the message so the receiver's MSH could use it. The current draft needs to have an expiration time set on the Sender side (for timeout) but it is not passed to the receiver and thus is not in the message. We still have not decided how this value is determined, and the discussion is not too far removed from the "who sets the RM-Group size" discussion.

If the concept of grouping messages (to reduce the number of message-service level ACKs) is burdensome, Fujitsu could revert to our original proposal (see http://lists.ebxml.org/archives/ebxml-transport/200007/msg00094.html for details) and work from there.

However, we'd prefer not to make changes to the draft spec until some of the requirements and architecture are clearer. (I had thought several days ago that we should be updating our TRP requirements document, but today I'm not sure that the group even agrees on that point!)

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

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.

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

[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