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 <[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] > >
