A blog on consulting, developing, simplicity, and business in general.

Not every process is a BPEL process

There are 3 opinions of BPEL: I hate it, I love it, What is BPEL?

For those of you in the “What is BPEL?” category, here is a brief synopsis. If you’ve heard the buzz around web services, service oriented architecture, etc., then you have probably at least heard of BPEL. BPEL stands for Business Process Execution Language. It is a standard for expressing (you guessed it) business processes in XML. It’s on its second version (BPEL 2.0) but don’t let that fool you in to thinking that it’s a mature standard. Currently there are several implementations of the standard, but I’m going to focus on the one I’m most familiar with, Oracle’s SOA Suite which is part of their Fusion Middleware. The SOA Suite contains more than just their BPEL process manager and I have so much to say about this suite in general, I’m sure I’ll devote a post to each component somewhere down the line.

The people that love Oracle’s BPEL Process Manager tout its many cool features:
  1. Drag and Drop service orchestration
  2. Enhanced visibility and tracking into your processes
  3. Human Workflow
  4. Quick Development time
All of these things are there, and if used in appropriate situations, they work well. What they aren’t telling you is the many problems that come along with this in the real world, and why people hate it:
  1. It is XML based, making it slow and memory intensive
  2. It currently requires an Oracle Database
  3. It has a manual recovery ‘feature’ that will swallow your instances without notice.
  4. Unit testing is impossible
  5. Migrating through environments is difficult

If you have a truly service oriented architecture, then your long running business processes with inevitably use many different services and orchestrating these things through a home grown solution will take time and be difficult to manage. This is where BPEL shines. It can be kicked off by a JMS message, wait for a manager’s approval, escalate to the CEO after 2 weeks, then send a request to multiple external vendors for a price estimate, and return the lowest price that is returned within 10 minutes. All the while seamlessly tracking whatever variables you want to track, firing notifications, and giving you real time visibility every step of way.

If you have lazy programmers who love BPEL, it can also be used. This is where it fails miserably, allowing them to drag and drop together a short running process that calls a database, transforms data and sticks it in another database. The problem with this second scenario is that this IS NOT a candidate for BPEL. This is a disaster waiting to happen in your production environment, wastefully using resources, constantly getting stuck in the manual recovery queue, and with instances finishing much too quickly to get any benefit from BPEL’s strong points.

If you and your developers learn the appropriate places for BPEL, long running business processes that require service orchestration, and stay away from the quick and dirty uses, BPEL can help you.

-jeremiah