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 17:42:08 GMT
How about this for an idea of how we can get started (particularly if  
the thought of another Jakarta Commons-like project scared some  
people off :)...

Agila already has 2 codebases inside it today; the original BPM and  
Twister BPEL.

So how about we start the Ode podling with the same structure -  
containing the Sybase and PXE code in separate modules.

Then inside the Ode podling we figure out over time what BPEL stuff  
we can merge etc. Over time the Twister code could merge/move into  
Ode. BPM code from Ode could move into Agila. Or we can merge  
everything into Ode, or Agila can become the BPM project again and  
Ode can be the BPEL project - we'll see, we can figure that out  
later. But the structure from day one would be we'd have a new  
podling with a similar structure to the existing Agila project.

The only issue is users of Sybase or PXE will want milestone builds  
so they can test against the incubating code & to give us feedback  
that things are working etc.  (e.g. we already test against PXE in  
ServiceMix and we want to test against Sybase too and use ServiceMix  
as an integration test case for any work done on the merge).

So we don't really need a full "Jakarta Commons" type project  
structure; just a way to allow some level of independent releases of  
the Sybase & PXE codebases until the day when its all one single  
engine. (The Agila project might want to do this too).

I don't see anything in the current release policies that would  
explicitly prohibit a podling from having, say, 2 different kinds of  
release; say 'ode-pxe' and 'ode-bpe' or whatever we call them.

Does this structure seem reasonable to everyone?

On 17 Feb 2006, at 15:56, James Strachan wrote:
> On 17 Feb 2006, at 12:58, Sanjiva Weerawarana wrote:
>> My concern is that the proposed path
> I wasn't proposing a specific path, just highlighting issues we'll  
> have if we assume the "only one engine" approach.
>> is one where there's little
>> convergence in the near term
> FWIW convergence will happen however many projects we use
>> and where the single incubating project
>> releases multiple files on their own schedules. That's fine, but  
>> that's
>> not one project.
> It depends on how you define a project.
> There are many moving pieces; today they are all separate, over  
> time they will merge together in some way.  If we're including the  
> Agila code and maybe the BPEL4People code (if thats separate -  
> haven't looked at it yet), we might have 5 completely different  
> code bases all solving different problems in different ways.  
> Turning those into "one engine" might not be possible any time soon  
> - it might not even make sense to do so ever; at the same time each  
> of these 5+ codebases have users somewhere.
> I don't think in the grand scheme of things it makes a massive  
> difference how many individual modules we have and at what  
> granularity they are released (by release here I'm not necessarily  
> talking post-incubator official release, I just mean making some  
> kinda milestone that users can actually work with). Most reasonably  
> complex Java software is made up of many modules; often different  
> modules that implement the same feature but in different ways.
> So we could do this in one project if we allow it to be modular and  
> for the parts to be released (even as a milestone) as and when they  
> are ready & have user demand.
>> What's the point of being one project if there's no viable plan to  
>> make
>> the code marry?
> To unite the community and encourage them to work together and  
> share code.
> I don't think uniting the community under one project necessarily  
> means that we absolutely must force everything into one unified  
> engine just to release some code to users. e.g. what if we never  
> reach agreement? What if X% of the community want engine A and Y%  
> of the community want engine B - imagine the voting fun when folks  
> try to release B?
> So I'm wondering if it might make sense to start the incubation  
> process as an umbrella project; we let the code move into whatever  
> modules as we think we need (which will change over time) -  
> including allowing multiple implementations to coexist for however  
> long we think is necessary. Then we let the modules have their own  
> lifecycles and see how we get on. It might be we release everything  
> in one go; or release in N different parts. I don't know the answer  
> yet - I'm just raising a red flag that waiting for complete  
> consensus across 5 different codebases as to what the one-true- 
> engine is just doesn't seem practical.
> e.g. imagine a Jakarta Commons-like model for a second. Its got  
> lots of modules that do lots of different things all developed  
> under one project by one community; now in the orchestration/ 
> correlation/bpel/human workflow space we are hopefully talking a  
> much more focussed and less diverse area than Jakarta Commons -  
> there may only be 1-3 modules (who knows when we start adding  
> tooling and human workflow there may be many modules) - but the  
> general principle of different modules that live on their own, yet  
> developed by the community at large - could work well here.
> Over time I hope we merge modules together and promote code reuse;  
> it may be we need to diversify too (e.g. different persistence  
> modules, state machines v pi calculus etc). If the community  
> decides to split off a piece (like commons-httpclient) then that's  
> all well and good - but generally the community works together and  
> we share code & ideas incrementally without forcing "one engine".
> If we don't go for some kind of umbrella project then I'd suggest  
> starting things with separate podlings to begin with and then  
> seeing where the common areas for reuse lie during the incubation  
> process. But given the problem space I think an umbrella-style  
> project (restricted to all things orchestration/correlation/bpel/ 
> workflow) could well work.
> One of the aims of the incubator is to develop communities; why  
> don't we start with one community with the goal to make  
> orchestration/bpel/workflow software in a single project, import  
> all the modules, let each module have its own lifecycle and see  
> what happens. Then further down the road we can start deciding  
> whether or not we should split parts of into separate podlings or  
> not. I think its gonna take quite a bit of incubation before we  
> really know what all the parts are gonna be - so why don't we stay  
> as flexible as we can be in the early stages of incubation and see  
> what happens? We then can always change our minds further down the  
> line once we've had a chance to work together as a community on the  
> code.
>> I of course know the task is complex and indeed was
>> quite surprised when everyone was willing to say "merge 'em all"
> I think the desire is more to unite the community together - than  
> to "merge them all into one engine". I'm not sure if anyone  
> seriously thinks there will ever be one single engine for all use  
> cases of orchestration/correlation/BPEL/human workflow; whether or  
> not there is one single engine or several doesn't matter much  
> really - whats more important is we try to work together and share  
> as much code and ideas as possible.
>> but
>> there's no point at all in pretending we're merging if the task is
>> indeed too complex.
> I think we're all agreed that merging is complex; will take a lot  
> of time and we've no real idea as yet how much code will get merged  
> and what code we'll be left with at the end. Though as well I think  
> we're all agreed that uniting the community together is a good  
> thing too - I just think we need to keep things flexible and modular.
> BTW its worth mentioning that currently Agila consists of 2  
> completely different code bases existing side-by-side - they have  
> been separate code bases for 1 year or so. So I don't see a problem  
> with starting the incubation process as a single umbrella project -  
> unless folks think it will restrict the ability for us to make  
> milestone releases of the Sybase & PXE code during incubation?
> James
> -------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:


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

View raw message