- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 15 Apr 2003 13:18:29 -0700
- To: Steve Ross-Talbot <steve@enigmatec.net>
- CC: Jean-Jacques Dubray <jjd@eigner.com>, "'Howard N Smith'" <howard.smith@ontology.org>, public-ws-chor@w3.org
>
>
>>
>> Following your comment that "everything" is a process, shouldn't we
>> expect that any 100% pi-c based solution will follow the same fate of
>> other "uni-cratic" systems like Java, C, SQL, COBOL, ... i.e. severe
>> limitations/complexities outside the realm of applications for which
>> they were designed (e.g. EJBs versus Classes).
>
I know SQL and COBOL are severly limited and not quite useful in the
business world. Still I would be willing to claim success if we get one
choreography definition for every COBOL program or SQL statement used in
an enterprise application. When we get to that point, let's revisit the
issue and ask where we've gone wrong ;-)
With respect to pi-c no matter how I stear at it I don't see an
explicit
choreography specification. All I see is the specification of the
behavior of agents which are capable of communicating which each other.
If you take the example: _xy.0 | x(u)._uv.0 | _xz.0, it expresses the
behavior of each agent and the composition "point" but by no means the
"choreography" is "visible" there. Furthermore, pi-calculus seem to be
limited to request/response message exchange patterns (I'd be
curious to
know how one would model complex MEPs).
Isn't that what B2B and conversation theory is all about?
Pi-calculus is a lower level language. It depicts one-way exchanges from
which you build MEPs. At least I am not advocating a pi-calculus
language, I am advocating a higher-level language that can captialize on
WSDL MEPs. Not a problem since all these MEPs can be reduced to their
pi-calculus formalism.
arkin
Received on Tuesday, 15 April 2003 16:20:56 UTC