incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: [VOTE] accept donation of a business process engine into the ServiceMix project
Date Fri, 03 Feb 2006 15:22:40 GMT
On 3 Feb 2006, at 15:05, Rodent of Unusual Size wrote:
> Davanum Srinivas wrote:
>> Why can't you treat an orchestration engine like a component like the
>> way you treat Axis or XFire? Why does the code have to live within
>> ServiceMix? Lot of us want a BPEL engine, we don't want a JBI
>> container. The code coming in does exactly that, it is a BPEL engine
>> and has no relation to JBI or Java for that matter. Why can't you  
>> have
>> a separate project for BPEL and add glue code as a JBI component
>> EXACTLY the way you work with other projects like XFire?
> 	:
>> We seem to agree on the ends but not on the means. You like a very
>> good integration with a BPEL engine for ServiceMix. I like a very  
>> good
>> BPEL engine for its own sake. Am sure we can find people on both  
>> sides
>> and some who may like both objectives.
> An interesting point.  There is no reason people in the ServiceMix
> couldn't also work on a BPEL project.  But if we goes through with
> this as proposed, and someone wants a BPEL engine, is it going to
> be necessary to take all of ServiceMix along with it?

Not at all.

To use an analogy from Geronimo. You can reuse the Transaction  
Manager inside Geronimo by itself without anything else from  
Geronimo. Everything developed within the Geronimo PMC is modular;  
you can use what you like. Modularity and reuse is a given on all the  
Geronimo projects I'm aware of (which is most of it).

Geronimo benefited greatly from one project to define the kernel, the  
container, the transaction manager and the other components together  
by one cohesive team - then running the TCKs on it all - than having  
lots of little projects. I think the JBI community (container,  
components, routers and orchestrators of componentes) can get the  
same benefit of community growth.

> What
> about versioning?  Is the idea that the BPEL bit within ServiceMix
> would be versioned/released separately?  Or only when the thing
> of which it is a part is released?

I prefer frequent releases of everything in a project as often as  
possible personally but I'm sure if there's a need we could release  
different modules at different times. Lets let the community decide.

> If the code is of use to more that ServiceMix, and/or there are
> people who'd like to work on it but aren't interested in working
> on any part of what ServiceMix is now, then it makes sense to
> me that it be a separate project.  As proposed, anyone with an
> interest only in the BPEL aspect would have to join the ServiceMix
> community despite a lack of interest in it.
> This is all hypothetical; I don't know if there *are* people
> who'd want to work on it but not ServiceMix, and I have
> to take on faith the remarks that there are other packages
> that would like a BPEL engine without ServiceMix attached.

Folks can work on the transaction manager in Geronimo and not worry  
about the rest of it (and thats quite a bit 'rest' :); Similarly I  
see no real harm with anyone joining ServiceMix (we're nice folks  
really :).

But if the community grows to a large enough size of only- 
orchestration-engine-without-caring-about-JBI people, the Geronimo  
PMC can always reconsider and consider splitting the projects up. But  
that'd be a great problem to have; a large healthy community focussed  
only on orchestration wishing to make its own way. Today we have only  
folks interested in ServiceMix wanting to work on the code there - so  
I'm hoping we can bootstrap the community there first - then who  
knows, lets let the community (under the guidance of the Geronimo  
PMC) decide.


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

View raw message