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.
http://incubator.apache.org/servicemix/Publish+Subscribe+Routing
James
-------
http://radio.weblogs.com/0112098/
