incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Ode / BPEL Donation of BPEL 2.0 Engine
Date Fri, 17 Feb 2006 08:52:03 GMT
On 16 Feb 2006, at 22:40, Sanjiva Weerawarana wrote:
> +1 for importing the codebase into 2 subdirectories to start with.
> However, if we want to merge the two into one, then let's make it a  
> goal
> that we don't release anything until we've figured out how to cut-n- 
> chop
> & mix-n-match to make that real.

I don't really understand what this means. Today both codebases have  
significant numbers of users. We've been using PXE on ServiceMix for  
about 6 months now - one of the things I'm looking forward to is  
getting the latest PXE code to work with ServiceMix as its a bit  
broken currently :). We're also keen to reuse the Sybase code in  
ServiceMix - right now.

Integrating the two code bases together is gonna be a slow, iterative  
process; we're talking complex code here. It could be that to start  
with things are completely separate, after 6 months they are 10%  
common, 2 years 50% common etc. The figuring out "how to cut-n-shop &  
mix-n-match" could well take 5 years as this is an ongoing iterative  
process. Sure we'll be heading closer and closer towards a unified  
engine but it could take a long time to get there (and pieces could  
very well never completely merge).

So are you saying that neither code bases will be able to even do a  
milestone release for other people to use them until the community  
has everything completely figured out years from now?

I don't quite follow this restriction - why not let the project  
release milestones when it feels it has something useful for its  
(already existing) user base?

> I too greatly prefer the idea of having one BPEL engine (properly
> layered ofcourse .. the part that does the core language vs. the part
> that does people-facing activities etc.) as there's little benefit in
> having multiple of those in ASF given it'll simply reduce the  
> available
> developer resources.

While its a worthy goal that I share, I'd advise against forcing this  
outcome from the start. Look at something so trivial as parsing XML  
into some data structure; we have 4 different projects I can think of  
at Apache (there could be more); XMLBeans, JaxME, Axis, Xerces -  
which all do it in very different ways. Orchestration is way more  
complex than XML parsing (have you seen how big the PXE codebase  
is? :) and its fine if we have different implementations of things  
within Ode as there are various ways to do it (e.g. persistence can  
be done many different ways - you can orchestrate via pi-calculus or  
state machine etc).

Its a worthy goal to reuse as much code as is possible - most  
developers I work with in open source do this anyway without being  
told to do so. I'm quite concerned however on putting too much  
pressure on the folks involved to unify code bases too soon - like  
say before they can actually deliver some useful code to their  
existing user base. The initial aim of the project should be to grow  
a community of developers and *users* around the collective codebase;  
code reuse is secondary IMHO.

Please remember, we're talking a large technology scope here; generic  
orchestration engine (state machine / pi calculus stuff), BPEL 1.1,  
BPEL 2.0, human workflow, tooling etc. Its fine for there being  
different implementations of similar things if thats what the  
community wants.

For those long time Apache folk here, I'm very worried about Ode  
turning into another Avalon if we try and force there to be *just  
one* engine (I'm not even sure if there can be just one engine, just  
like there can't be one XML parsing library). I'm sure everyone  
involved in an ideal world would like just one implementation of  
everything; but lets try to get there calmly and without undue  
pressure with the knowledge that its OK to diverge if it makes sense  
as there are many different ways to solve this problem together with  
a wide range of user requirements in this space.

e.g. if we ended up with 2 engines with different features doing  
things differently for valid reasons and sharing some code and - more  
importantly - the developers of each engine share ideas openly with  
each other, then that will still be a big success IMHO.

> I'm glad to see the two seed organizations be so
> willing to cut-n-chop to make that real; it bodes really well for the
> success of the project!

Agreed - but lets not put unnecessary handcuffs and restrictions on  
the folks involved; lets encourage code reuse but allow diversity to  
flourish too.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message