After being nervous for quite a while I have come to think that the
sybase bpel engine should go in as part of servicemix and if further
uses outside servicemix develop we can see about splitting it off.
more comments inline.
On Feb 13, 2006, at 5:25 PM, Noel J. Bergman wrote:
Dain Sundstrom wrote:
I think ServiceMix is the perfect home for a BPEL engine. Every
JBI implementation that I am aware of has and integrated
orchestration
engine exposed via the BPEL specification.
If every JBI implementation has an integrated orchestration engine,
then we
should factor out the orchestration engine. Furthermore, as per
the JBI
Specification, "Java Business Integration JSR (JBI) extends J2EE
and J2SE
with business integration SPIs. These SPIs enable the creation of a
Java
business integration environment for specifications such as WSCI,
BPEL4WS
and the W3C Choreography Working Group." JBI is applicable outside
the
context of J2EE. So if ServiceMix is intended to be embedded
exclusively in
Geronimo (the subject of a whole other discussion), JBI should be
available
separately.
To me this appears to assume that the interface between the
orchestration engine and the JBI container is well defined and all
parties agree on it. I haven't heard any claims that this is the
case, although I'm still completely unfamiliar with the subject.
Also, we already have two engines in the Incubator, with two more
pending,
so we may have three implementations of BPEL. I would expect to
see at
least one of them close down, and would like to see the orchestration
communities merge, if possible.
This appears to me to be a strong indication that BPEL engines cannot
live an independent life and that we should try one as part of
another project such as servicemix. If the BPEL part of the
servicemix community turns out to be big vibrant and wanting its own
project, all the better. If not, servicemix gets a component it needs.
I've heard nothing to provide a reason for not bringing in the
contribution
as a standalone podling, which ServiceMix and others can consume.
This
would be in accord with Ken and Mads.
Through all this I don't think I've seen anyone actually say they
want to work on the code other than servicemix people. (If I've
missed anyone I apologize). It's been on the table a rather long
time for that not to mean that there isn't much interest outside
servicemix for actually working on it. The incubation process is not
a trivial amount of work and having 2 podlings rather than one pretty
nearly doubles a good deal of it IMO. Since the original request was
to be a part of servicemix, and AFAICT no one outside that group has
said they want to work on the project over the last x weeks of
stewing, what exactly can we gain by forcing a decision on this group
of people who want to work together?
On a related note, I believe that we need to evaluate projects for
graduation based in part on how well the community collaborates
with other
ASF projects, and become part of the ASF community. I don't consider
ghettos to be healthy for the ASF, no matter how internally
successful.
After looking at this for a while I don't have any idea what you
mean. Could you provide some concrete examples of projects that
should not have graduated based on this criterion and pre-incubator
projects that would not graduate had they gone through incubation?
While this appears at first to be a very nice idea I can't see any
way it could mean anything but stifling innovation. I hope you can
clarify what you mean.
thanks
david jencks
--- Noel
