Thought of writing something on this topic while I’m waiting at the Dubai airport for my flight to Colombo.
WS-BPEL is used to implement business processes in which different systems are integrated together through their Web Service API’s. It is a complete XML based language which supports lot of functions in the language itself. The complexity of the business processes implemented using BPEL can vary from very simple short term processes to long running processes which can run for weeks or months.
Being an XML based language has some advantages as well as disadvantages. Following are the most important advantages.
- No need to compile
- Being a well known standard
- Usage of XPath, XQuary etc.
Due to these and the functions available in the BPEL language, it becomes a very powerful mechanism of implementing business processes. However, implementing such a powerful language on XML can have some disadvantages as well. One of those is debugging. There can be complex BPEL processes which are 5000 or 10000 lines long and having nested loops ect. In these situations, it’s not easy to debug your process if something goes wrong. There are tools which support BPEL debugging. But debugging XML won’t be easy as debugging a programming language like Java.
As the BPEL language is very rich, sometimes people tend to implement their complex business logic in the BPEL process itself. From my experience, that won’t be a good practice at all. When you want to change the logic later, it will be extremely hard to change the process according to your new requirements. Therefore, the safer option is to move the complexity into your services and let the BPEL integrate those services through Web Service calls. That’s why BPEL is mainly identified as a mechanism to orchestrate your system. Therefore, it’s important to identify what should go into your orchestration layer and what should go into your services layer.