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 Thursday, 5 June 2003 05:51:59 UTC