W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2003

RE: More requirement

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>
Message-ID: <001e01c33051$e57489d0$1b6e050a@JJD>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:21 GMT