I'd like to retract this email. I have doubts on both sides of this
and may try to explain them in a clearer way in another message.
My apologies
david jencks
On Feb 13, 2006, at 6:26 PM, David Jencks wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
