incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <>
Subject Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Date Wed, 15 Feb 2006 03:14:35 GMT
Hi Matthieu,

I don't think Aaron would disagree with you.  Going back to his  
transaction manager analogy, a transaction manager is much more  
complicated than geronimo the container.  Just like a BPLE engine is  
much more complicated than a JBI container.  The beautiful thing  
geronimo and servicemix have in common is that they provide a  
standard way to wire components together to create more complex and  
sophisticated systems.

In short, servicemix is simply about having a standard way of  
integrating service based engines like BPEL, SCA, Web Services, and  
legacy stuff.


On Feb 14, 2006, at 4:38 PM, Matthieu Riou wrote:

>> 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.
> I've been trying to stay out of the discussion so far because I'm
> obviously partial (as a contributor on Agila BPEL), however I've seen
> this opinion voiced many time on these threads and can't ignore it
> anymore. Aaron it's not against you at all :)
> I've worked enough on BPEL implementing it to say, really strongly,
> that BPEL is very far from being a discrete component. You can see it
> as something "behind the scene" when you're working on a JBI
> container, however when you're interested in having an orchestration
> layer, you really don't. I don't think Oracle, IBM and many other
> editors would be so successful in selling their product if it was so
> discrete.
> You really don't need a JBI container if you're only dealing with web
> services interfaces. Actually my view on this was that an ESB is just
> a communication bus around an orchestration layer. Quite the reverse
> opinion, isn't it? And I can't see any JBI implementation dealing with
> the BPEL grammar. Is the JBI implementation going to deal with
> compensation, correlation and partner links? I don't think so. What
> about editing BPEL process descriptions? And eventually, is the JBI
> implementation going to provide BAM interfaces?
> So the scope of a full BPEL implementation is quite large. I hope that
> people working on the BPEL specs didn't hear too much about this
> thread, that would be quite depressing :)
> Matthieu Riou.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message