Aaron Mulder wrote:
On 2/14/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
In the same way that we built Geronimo from "best of breed" J2EE-ish OSS
projects that are out there, I'm sure we could do a similar thing with BPEL.
Maybe do a "bake off" to help find the best codebase, and have the
community collaborate around that? (I'm not sure what that would
entail, actually...)
Geir, I don't understand this at all. In different threads you seem
to be simultaneously talking about bringing it to Agila, bringing it
to ServiceMix, having the Geronimo PMC vote on it, and now you're
recommending a "bake-off" where no one does anything with any code
until "the one true way" emerges?
I don't know if you've been following this closely, but originally it
was suggested that the Sybase engine go to ServiceMix (hence the
"bringing it to ServiceMix" part), which would require the vote of the
Geronimo PMC (which is in fact what James did).
Today, we were introduced to the ODE Proposal, which is a new podling
proposal that is to be sponsored by the Geronimo PMC (hence my question
about a vote about that since it would be yet another podling sponsored
and overseen by the Geronimo PMC, and we hadn't voted on it), and I
wondered if there was interest/synergy w/ the Agila podling, which is
already working on an implementation of a BPEL orchestration engine.
I hope that clears up the confusion for the first three elements of the
above.
As for the "bake off", I'm not recommending anything - I was asking if
it made sense to see what kind of broader community could be assembled
around this, without presuming the primacy of one codebase - choosing
the best of what shows up.
If you've been following the whole soap opera for the past week or so,
you might recall that there was considerable concern from various
members of the ASF community regarding this subject, with the suggestion
(from greg) that we should "Erase the lines and create a community that
can work on something with a cooperative atmosphere."
> I won't speculate on your motives,
> but this strikes me as an... unusual approach.
What strikes you as unusual? Bringing multiple groups together to work
on a given technology?
My motive is to try and get rid of some of the cloud of bad karma thats
hanging over this whole discussion because it's the last thing the
Geronimo project needs right now. It's also not good for the new people
that wish to join our community, the Sybasians. (Sybasers?) I also
think that BPEL is an interesting technology and I would like to see a
community flourish around a great implementation here at the ASF.
What's your motive?
Also, I don't at all agree with your comparison of a BPEL Engine to
Geronimo. I would compare it to the transaction manager within
Geronimo. It's a discrete component, and we're not going to take the
best of 20 different projects to make a transaction manager, and I
don't see why we'd do the same to make a BPEL Engine.
Ok. I'll be the first to admit that I'm no expert on BPEL
implementations, but I certainly wouldn't suggest that we'd try to take 20.
However, could you imagine taking a few and finding the best aspects of
each? Are they really that monolithic that you can't find component
parts that you could blend together to make something better?
What about clustering? What about management or tooling? Support for
different versions of BPEL? How about service hosting? Do they have a
container (like PXE) or can they be used to orchestrate external
containers (say a mix of services deployed though a heterogeneous
environment, say w/ Geronimo, Tuscany and Axis+Tomcat (I dunno...), with
the BPEL engine just deployed into Jetty?
If anything, the JBI container is like Geronimo, and the BPEL Engine
is like the Transaction Manager, and note (everyone) what happened
there. We didn't create a separate projects for the transaction
manager, we just build a good one in Geronimo and made it
intelligently portable.
>
Then, when someone had a fancy to use it in
Spring without the rest of Geronimo, they created Jencks, and now we
have a standalone projects for that purpose and the best of both
worlds, but it was born by putting the code in the container where it
would be used, making it solid and portable there, and building
outward.
Hey - I'm not going to pretend to be an expert on BPEL orchestration
systems, so I guess I'll take your word for it that it's like a
monolithic transaction manager. In the past, I've built production
workflow systems (not BPEL, more like a JMS-driven SOA) that weren't at
all monolithic - they got a bit complicated, actually, so that's what's
driving my understanding of what a full BPEL orchestration system should
be like.
geir
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
