> 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. 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. What about editing BPEL process descriptions? And eventually, is the JBI implementation going to provide BAM interfaces? So the scope of a full BPEL implementation is quite large. I hope that people working on the BPEL specs didn't hear too much about this thread, that would be quite depressing :) Matthieu Riou.
