> ... 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.
With regard to "runtime management" I am thinking transactions, resource allocation, etc ... but not BPEL process instance management.
Lance
On 2/15/06, James Strachan <[EMAIL PROTECTED]
> wrote:
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/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
