geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Date Tue, 14 Feb 2006 22:17:46 GMT

Aaron Mulder wrote:
> On 2/14/06, Geir Magnusson Jr <geir@pobox.com> 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


Mime
View raw message