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 13:13:08 -0800
To: "bhaugen" <linkage@interaccess.com>, <public-ws-chor@w3.org>

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of bhaugen
> Sent: Wednesday, February 26, 2003 5:21 AM
> To: public-ws-chor@w3.org
> Subject: RE: Dubray paper comments + questions
> Assaf Arkin wrote:
> > BPEL4WS, BPML, WSCI, etc are based on processes defined for each
> > communicating agent, dating back to the model proposed in CSP and
> later
> > refined in pi-calculus and other works in that space. BPSS and EBPML
> prefer
> > to express processes as a centralized sequence of exchanges and then
> each
> > agent has to derive its process by extracting all activities related
> to some
> > role.
> > I think there's conversion from one to the other, but I don't have
> evidence
> > that you can move from the CSP model to the centralized one and back
> without
> > losing some information.
> I don't think it is accurate to describe BPSS as "centralized".
> It was derived from the UNCEFACT Business Collaboration
> Protocol metamodel, which is a state-alignment protocol.
> That is, the protocol is intended to align the states of
> "common knowledge" or mutually-agreed-upon
> state machines, which may be implemented using
> the Half-Object-Plus-Protocol pattern. (Nothing
> centralized.)

Perhaps 'centralized' is not the correct term since it has some unwanted
connotation so the meaning could be easily misinterpreted. Sorry about that.

It is common to define protocols in terms of communicating agents, and this
goes back to the days of CSP and later refined in various forms of process
calculus, most interesting being pi-calculus and action calculus. The TCP
yields well to that formalism (in fact requires it), so does the Web
(links=passing channels by names) and the manner in which an application
protocol can be described using WSDL in combination with WSCI or a similar

It is also possible to pull that information together into a central
definition, hence the choice to use the term 'centralized', or as you call
it state-alignment protocol. I am not aware of any formal models that
describe communicating processes in that way, is there some better lingua
franca we could use?

From my perspective if you have worked to define all the participants prior
to engaging in any interaction, both models are identical and I do not have
preference for one or the other. On the other hand, if you prefer the
flexibily inherit in the Web model, being able to pass communication links
in messages and being able to cover discovery of services in the
choreography, then the formal process model is preferrable.

I am, of course, a big advocate of the formal process model and in
particular one that allows this form of interaction when not all
participants are know in advance. I do that on a daily basis when I use the
Web or correspond through this mailing list (notice how your e-mail address
was added to the CC by act of replying).

> The protocol does make a distinction between
> external collaborations (whose states must be aligned)
> and internal activities (whose states are none of
> anybody else's business).
> So if you took a model which included both external
> and internal activities (in this sense), and moved
> to BPSS, the BPSS representation would only
> include the external activities.
> That does not mean the internal activies would
> be lost.  It's just a separation of concerns.

This is true for both models. You would describe external activities in WSCI
and then extend the interaction with internal activities with BPML. The
formal process models provide proofs that can be used to asses that the
implementation indeed fulfills the contracts defined in the choreography,
hence the interest in leveraging that work.


> -Bob Haugen
Received on Wednesday, 26 February 2003 16:14:41 UTC

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