On 3 Feb 2006, at 15:05, Rodent of Unusual Size wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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.
James
-------
http://radio.weblogs.com/0112098/
