- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Wed, 11 Jun 2003 15:44:08 -0400
- To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'Jean-Jacques Dubray'" <jjd@eigner.com>, "'WS Chor Public'" <public-ws-chor@w3.org>
Yaron: >> >>BPSS has chosen one of a number of possible MEPs and each MEP has its own >>benefits and drawbacks that I don't believe this group needs to address. >>In >>fact I expect that each industry will pick the MEPs that best meet their >>functional and legal requirements. Therefore I would propose that our job >>is >>to enable the creation of such MEPs rather than specifying exactly what >>they >>are. [JJ] +1 >> >>As such I would propose rewriting Jean-Jacques' proposed requirement as: >> >>The WS-Chor message sequence description language MUST take into >>consideration the need to manage signals where a signal is defined as an >>application level processing error that is expressed as a message visible >>by >>other partners in the choreography. [JJ] I am not sure I would translate it this way. Signals are not just application level processing error messages. You may also have "message format errors" that could be trapped above the system of record. I would suggest: >>The WS-Chor message sequence description language MUST take into >>consideration the need to manage signals where a signal is defined as <a choreography state synchronization mechanism> that is expressed as a <standard> message visible >>by >>other partners in the choreography. >> >>> -----Original Message----- >>> From: public-ws-chor-request@w3.org >>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jean-Jacques Dubray >>> Sent: Thursday, June 05, 2003 2:51 AM >>> To: 'WS Chor Public' >>> Subject: More requirement >>> >>> >>> >>> I would like to add another requirement: >>> >>> The WSC-Languange MUST provide specific Message Exchange Pattern >>> templates that establish a reliable state of the WSC-instance when >>> needed. >>> >>> This requirement is essential since RM itself is not enough to guaranty >>> that the state of the choreography is identically represented in each >>> party. For instance a party sends a message with an incorrect format. If >>> we have RM only, then the state of the collaboration says that the >>> message got there, so the choreography should proceed as normal. >>> However, if this is a request, the responding party cannot send the >>> response since the message was structurally incorrect. >>> >>> Unless the WSC-definition specifies that at this point the responding >>> party can send a "INVALID MESSAGE" response, we get into a deadlock >>> (requesting party waiting for response, responding party unable to >>> respond). >>> >>> A similar deadlock can happen when the message is structurally valid, >>> but cannot be processed by the corresponding system of record (that is >>> in charge of producing the response). >>> >>> Providing MEP-templates would greatly simply the work of the designers >>> by establishing clear patterns, with standard error messages that can be >>> used over and over by anybody. >>> >>> This approach also offloads the business logic of the application/or >>> process engine to deal with "protocol" levels. Can you imagine the >>> simplification for the Orchestration/Process Definition-instance if >>> these concepts are implied rather than explicitly handled by the process >>> instance? >>> >>> See also this article: >>> http://www.looselycoupled.com/stories/2003/message-infr0528.html >>> >>> Of course most people would have recognized the BPSS business >>> transaction protocol, that itself has its root in prior work at RN and >>> UN/CEFACT. I think that generalizing this idea would be helpful. >>> >>> Cheers, >>> >>> Jean-Jacques Dubray____________________ >>> Chief Architect >>> Eigner Precision Lifecycle Management >>> 200 Fifth Avenue >>> Waltham, MA 02451 >>> 781-472-6317 >>> jjd@eigner.com >>> www.eigner.com >>> >>> >>> >>> >>>
Received on Wednesday, 11 June 2003 15:50:30 UTC