I'm afraid I disagree completely :(. BPEL is complicated concurrent programming language. The community cannot help in implementing core language features unless it understands how to write concurrent programming language environments. It is difficult to implement such things correctly without relying on relevant primitives. In my view the only question is what primitive. Obviously I have a preference for JACOB not only because I wrote it, but because it exists, it works, it is based on known "theory", and it is suitable to the problem. As far as alternatives go, the only generally known concurrency primitive among developers--the shared memory threading model--is not at all suitable. Other alternatives certainly exist but would share the same learning curve issues that JACOB has; moreover using something else would require implementation, whereas 95% of BPEL 2.0 is already implemented using JACOB.
-mbs On Wed, 2006-05-10 at 18:50 -0600, Bill Flood wrote: > The Ode charter was formed to implement BPEL, not solve a general > process calculus problem (of which the latter is dubious in the > context of the runtime as formerly asserted in well respected academic > circles). > > If somebody wants to implement a general process engine or go beyond > BPEL with all sorts of extensions, that probably belongs somewhere > else. I don't want the community to need to understand process > calculus to work on this project (or the theory of universal Turing > machines for that matter) - because it is not entirely necessary in > the narrow context of the implementation of Ode for BPEL. > > I prefer the BPE core for that reason alone - simplicity and focus to > the BPEL runtime problem. The engine does precisely what it sets out > to do in a straightforward manner, doesn't introduce extra overhead or > concepts, and we can explain it in terms anyone familiar with BPEL can > understand. Besides, it's documented. ;-)
