RE: RM Group Definitions

[David Burdett <david.burdett@commerceone.com>]

>>>My personal favorite solution *is* to let the upper layer have an 
opportunity to tell the MSH that a sequence of messages should be sent in a 
reliable mode<<<

I would change the "should be sent" to "must be sent". Then the Service
Interface can then:
1. send messages reliably even if there is no need as there is a common
reliable transport that is being used
2. It could flag an error if there was a request to send something reliably
when it couldn't

David

-----Original Message-----
From: Jim Hughes [mailto:jfh@fs.fujitsu.com]
Sent: Tuesday, August 29, 2000 1:38 AM
To: ebxml-transport@lists.ebxml.org
Subject: Re: RM Group Definitions


OK, if the upper layer is not supposed to establish the end of a sequence 
of reliable messages, then we need to decide how the MSH will do this. Do 
you have a particular algorithm to propose?

(My personal favorite solution *is* to let the upper layer have an 
opportunity to tell the MSH that a sequence of messages should be sent in a 
reliable mode. To do this, we need to agree on the Message Service 
Interface that would permit this... But if the group decides that, 
architecturally, we cannot have this link, then we need a resolution for 
solving this in the MSH.)

Jim

At 04:42 PM 8/28/2000 -0400, mwsachs@us.ibm.com wrote:
>Jim,
>
>Correct - the upper layer BP should not establish the group size.  Each
>process in the BP layer has a view only to itself.  With the BP processes
>requesting group size, the RM service would have to somehow resolve
>conflicts.  Using the largest requested group is one approach - but that
>would be larger than most processes want and therefore impair their
>latencies.  Note also that once the RM service is into resolving conflicts
>on group size, no BP process knows what the actual group size is anyway.
>
>The trivial case which you mention is probably not the best answer.  If the
>RM service, on its own, can only set the group size to 1, we might as well
>simplify the definition and have only a group size of 1.  That would be the
>worst case for the number of ACKs and the best case for message latency.
>
>Regards,
>Marty