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 compensation 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. Assaf On 4/10/06, Bill Flood <[EMAIL PROTECTED]> wrote: > > On 4/6/06, Assaf Arkin <[EMAIL PROTECTED]> 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 http://www.intalio.com
