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

RE: Dubray paper comments + questions

From: Assaf Arkin <arkin@intalio.com>
Date: Wed, 26 Feb 2003 15:06:48 -0800
To: "Jean-Jacques Dubray" <jjd@eigner.com>, "'bhaugen'" <linkage@interaccess.com>, <public-ws-chor@w3.org>
Message-ID: <IGEJLEPAJBPHKACOOKHNIEDMDEAA.arkin@intalio.com>



> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jean-Jacques Dubray
> Sent: Wednesday, February 26, 2003 2:12 PM
> To: 'Assaf Arkin'; 'Jean-Jacques Dubray'; 'bhaugen';
> public-ws-chor@w3.org
> Subject: RE: Dubray paper comments + questions
>
>
>
>
> >>I do assume that we're talking about long-running behavior all along
> which
> >>explains a lot of the complexity of the spec.
> [JJ] yes, ;-)
>
> If you consider a model (as in Model-View-Controller). You can typically
> do CRUD operations on the model (e.g. insert PO) that I do not consider
> long-running and then there are other operations such as "process PO"
> that can exhibit a long-running behavior (that I define as cannot meet
> the ACID requirements, right or wrong). Typically a Process PO operation
> involves talking to the billing component and invoking the insert PO it
> if passes the validation rules (could also need approval from a human),
> once all this is done, then and only then the ACK_PO can be generated.

Indeed.

I like to have a separation between the CRUD operation which in WSDL terms I
would call an operation, and those long-running operations which for lack of
a better term I would call an interface process or transaction (but not in
the ACID sense), which would include multiple operations.

So a "process PO" flow would involve one operation in which the PO is
submitted with any information necessary to lead to the second operation in
which some result is sent. Depending on scope it may be ACK_PO or the
eventual advance shipping notice. Again this is all recursive so we can talk
about that flow that ends with ACK_PO and that flow which ends with advance
shipping notice and contains the flow when ends with ACK_PO, etc.

That's all at the interface level and it constraints the implementation. The
implementation will also have to talk to the billing component,
authorization, etc before it can complete the interface process. That's the
kind of details you capture in the implementation, BPEL/BPML, Java,
whatever.

So, given a choreography that involves only n participants, the external
definition would of course be black box and describe only these activities
that are visibile to the participants through message exchange. You can then
build any number of implementations behind it, where an implementation does
a million other things.

> Of course this is also web service choreography but from a very
> "centric" perspective. I am the component and I describe my behavior
> from my point of view. Then you have the ether between components and
> partners which in my opinion obey different rules (could be proven
> wrong) in terms of web service choreography.

The term we like to use is orchestration with a clear separation. A service
implementation has to be computationally complete to make anything useful,
so if that involves talking to N other services, its definition would
include talking to N other services. It's definitely centric.

The service implementation participants in one or more choreographies
(depending on how you build it), and each choreography defines some number
of participants M (where N and M intersect by at least the service itself).
The choreography definition dictates which activities are included (see rule
above).

arkin


>
> JJ-
>
> >>
> >>In a long-running behavior you would have complex flows that are
> chained
> >>to
> >>each other. You can capture a simple flow with something like a
> sequence,
> >>but that doesn't extend well. You will probably want to break the
> complex
> >>flow into smaller flows and chain them together, which is where we
> >>introduce
> >>spawn and call*.
> >>
> >>In a long-running behavior you would also have flows that repeat
> multiple
> >>times within some state and that may be subject to how many messages
> are
> >>exchanged (or in reverse, capture the message exchange), which
> explains
> >>the
> >>need for nested processes.
> >>
> >>And of course you need to address the time issue, whether you want to
> >>express a minimal passage of time (e.g. delay) or put a time
> constraint on
> >>the completion of a flow (e.g. onTimeout).
> >>
> >>And probably some other requirements. Anything specific?
> >>
> >>arkin
> >>
> >>* The notion of recursive composition which is captured in this way
> and
> >>also
> >>with nested processes is very interesting, since it allows you to draw
> >>conclusions about a fine grained entities, then about a composition
> >>including multiple entities, and a composition including multiple
> >>compositions, and so forth. Seeing how formal process models do it,
> we've
> >>structured the language in a similar manner to allow the same form of
> >>recursive composition/analysis.
> >>
> >>
> >>>
> >>> JJ-
> >>>
> >>>
> >>>
> >>>
> >>>
>
Received on Wednesday, 26 February 2003 18:08:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:54 UTC