ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: PXE implementation basis
Date Wed, 12 Apr 2006 18:41:15 GMT
The underlying model of Jacob is very simple and efficient, but the thing
that interests me the most is how simple it is to implement different
semantics on top of it. It's a snap to add new behaviors, e.g. when
BPEL 2.0introduced parallel foreach, changes to event handler and
handler semantics, termination handlers. It will be easier to extend or
support future versions of the spec.

pi-calculus is just a conceptual model, and mostly you're only interested in
the mobile calculus part, not the complex theorems and proofs. You can also
look at it from the eyes of a state-transition diagram or a Petri-Net, those
are all equivalent.

I recommend pi-calculus because I find state-transition/Petri-Net to be
decievingly simple. To really understand service orchestration (not a
problem specific to BPEL) you need to wrap your head around state-transition
diagrams with substates (compensation, isolation, flows, etc), or mobile
PetriNets. And those two are harder than mobile processes.

So as a designer, ignoring the math part, I actually find mobile process
easier to reason how the engine operates, understand where CPU is used,
network operations, database access, etc. It's one of those learning
investments that took a while, like object-oriented and relational algebra,
but ended up being worth the time and energy.


On 4/10/06, Bill Flood <bill.f.flood@gmail.com> wrote:
> On 4/6/06, Assaf Arkin <arkin@intalio.com> wrote:
> > There's one thing that takes a while to get used to. A pi-calculus
> process
> > may reduce to nothing, but a BPEL process never reduces.
> What then is the advantage that the complexity of pi-calculus brings
> once a BPEL model is deployed to the runtime (after reduction
> semantics in the model have already been expressed)?  Is it
> performance, scalability, or ?
> Bill

CTO, Intalio
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message