geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Waterman <lance.water...@gmail.com>
Subject Re: Let's rewind!!! (Re: [VOTE] accept donation of a business process engine into the ServiceMix project)
Date Wed, 15 Feb 2006 14:48:33 GMT
In the spirit of nailing down criteria, I would agree with;

> ... 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 <james.strachan@gmail.com > 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Mime
View raw message