RE: More requirement

I have to admit that the term 'choreography state synchronization mechanism'
makes me really nervous only because it is so broad that it could
potentially mean anything. But let's adopt your proposed new language anyway
and when we do the full requirements review we can do a pass to look for
phrases such as that one and make sure they are used in a consistent and
well defined manner throughout the requirements.

		Yaron

> -----Original Message-----
> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
> Sent: Wednesday, June 11, 2003 12:44 PM
> To: 'Yaron Y. Goland'; 'Jean-Jacques Dubray'; 'WS Chor Public'
> Subject: RE: More requirement
>
>
> 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 Tuesday, 17 June 2003 13:05:20 UTC