BPEL (aka BHell) - is this programming ?

I was fortunate in my 3 years on the SOA project that I had delayed exposure to BPEL.  I managed to get involved in some large components that were done all in Java.  I could hear other developers grumbling about it but realised I needed some exposure to BPEL to know first hand the pros and cons of using it, so I put up my hand to do some BPEL.  Unfortunately, I got what I asked for.

BPEL is a SOA orchestration language that is a dialect of XML.  It is conceived to be coded up by dragging and dropping in a GUI based editor.  Some would conceive it as easy and the future of programming.  My experience of BPEL is sullied by the productivity sapping excuse for an IDE that is called JDeveloper (which is the only GUI based tool that can do BPEL in an Oracle Fusion environment).  As I have commented in an earlier blog post I became so frustrated with this tool that I resorted to coding BPEL in a text editor (Notepad++).   This was also not pleasant as XML is so verbose that the amount of code you can view on one page is limited to what would amount to a few lines in something like Java so you end up doing a lot of scrolling which is frustrating.  You also have to be very careful with namespaces and XML syntax to avoid obscure error messages.

BPEL's deficiencies as a programming language become immediately obvious once you try to do anything non trivial.  You can not define a function - the BPEL SOA service is the lowest level of granularity.  If you want to share functionality between two BPEL services then it needs to be done by defining another BPEL service with associated WSDL, XSD etc.  If you want to have some common code inside your BPEL that is called from multiple code paths in your BPEL then you have to be creative - eg set variables and then do all the common code at the end based on whether those variables have been set OR if you are brave use catch clauses since throwing exceptions will get you to a common point in the BPEL.

Booleans which should be simple are hard to do correctly in BPEL.  A simple if statement becomes a verbose switch/case/sequence monstrosity and a simple loop with a variable count is like going back to assembler.  Namespaces will test your sanity and constructing variables of types that have multiple consecutive optional elements becomes a nightmare of complexity (a default constructed type will have all optional elements populated so you first have to delete them but then the ones you want to add back in have to be explicitly added _after_ another named element.  When you have multiple consecutive optional elements you need to know which of the earlier optional elements are included so you can insert after the correct one).  Lists and maps of course are far too modern to even consider.

We ended up making use of the non-standard Java embedding to maintain sanity when anything other than copying elements from one XML type to another was required.

Similar to what I said with SoapUI the GUI interface is OK for new programs but when you have to modify a number of BPELs in the same way (eg because a WSDL has changed) you are left to slavishly repeat the same GUI steps for each BPEL.

One of my colleagues had a saying that "BPEL makes you dumber".  When it is exhausting just to get something simple done you just can't concieve of doing anything complex.  That can become habit forming.

Usually on a CV you would list as many skills as possible to make yourself look better and get hits on the automated CV searchers used by recruiting people but I would definitely hesitate before added BPEL to my CV because I would prefer to never see another line of BPEL again.