RE: More requirement

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.

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.

> -----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 14:41:40 UTC