[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: RM Group Definitions
At 02:01 PM 8/30/2000 -0400, mwsachs@us.ibm.com wrote: >Normally, when a party needs to know whether a message was received before >sending another, they use a request-response protocol at the business >application level. Those are the requests and responses laid out in the >business protocol section of the tpaML proposal. > >Using the RM protocol for this kind of flow control is definitely mixing >the functions of the MS and application levels. You are absolutely right Marty. One notion that helps keep me on an even keel (some would argue I capsized a long time ago) is to think only in terms of asynchronous messaging at the BP level. Period. Now at the MS level the transport may be synchronous or asynchronous (that's a private implementation/configuration detail) but the programming model at the BP level is always the same. IMO, maintaining a consistent programming model will be key to adoption of ebXML TR&P. If we tie the programming model to the messaging choreography we may well be setting ourselves up to fail. It's entirely practical to have a request-response application protocol that enables an application to work through it's business logic in a consistent and well defined way. So, as for the notion of "grouping", I have yet to see a convincing use-case (without significant hand-waving) that justifies the complexity. I would very much appreciate it if someone could post such a use-case, making a clear distinction between the MS view and the BP view. Thanks in advance. Regards, Nick
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC