incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Date Wed, 15 Feb 2006 08:27:45 GMT
On 14 Feb 2006, at 21:38, 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.

Sure but it really helps. The JBI container does much of the heavy  
lifting, letting the BPEL engine focus on its core feature -  
correlation & orchestration and not worrying about all the other  
stuff as well.

> 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.

Agreed. But similarly - should a BPEL engine deal with different  
integration components, different SOAP stacks, different WS-*  
policies, monitoring, management, using HTTP or JMS or Jabber or file  
systems, deployment, versioning, runtime management & monitoring of  
each flow? The J2EE analogy is quite good; BPEL is a discrete service  
but can reuse the container environment of JBI to avoid the BPEL  
engine having to write a container, a deployment model and a suite of  
'binding components' to different SOAP stacks, WS-* policies and  
transports - together with all the runtime management.

BPEL engines and orchestration services were one of the primary  
drivers of JSR 208 (JBI)

> What
> about editing BPEL process descriptions? And eventually, is the JBI
> implementation going to provide BAM interfaces?

Yes - BAM hooks at least.


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

View raw message