What is BPEL and its purpose?
BPEL is an acronym for Business Process Execution Language. It was created as a way of translating BPMN into the SOA world, or bring a notation for business interaction between web services. However, BPEL is a specification fault, and here I present my reasons:
1) Make the common case fast – or – Keep It Simple, Sir
The BPEL specification aims to achieve between web services orchestration. However, the interaction between services often requires, translation of complex objects to other complex objects. If there are variations between input parameters or output, some parts of the process should be partially or completely redone, making it difficult to maintain this.
2) Offer Bonus
The BPEL specification provides standard elements which facilitate the addressing of complex issues, such as waiting for a certain time interval before proceeding with certain tasks. However, most common cases in BPMN, as the interaction with humans, there is no standard specification. This turns out to be the burden of specific tools such as Oracle BPEL – which makes the process strongly coupled to a vendor .
3) Learn what to use, and when
BPEL is a tool that should be used on systems that have had the development cycle ended. The tool is primarily for service orchestration – which does not mean it should be taken as the only means to do so. What I mean is that if a system is developed in a single programming language, is a high probability that integration done within the scope of this language is better and faster than using BPEL tools. Thus, BPEL is ideal for orchestration between separate services for creating new – but should not be used to create basic services.
Explained my reasons, I say I have been using BPEL for any SOA project. It is inevitable to say before starting a project that has claim to be SOA, ask yourself if it is SOA or just SOA-Ready . Most systems do not need SOA-Ready BPEL, SOA in contrast to systems where the most need.
It’s as simple as can be. Development approaches top-down, meet-in-the-middle or green field should be avoided to the maximum use of BPEL. Only bottom-up approaches to the use of the tool can be considered (not yet approved). Even for bottom-up, one must answer some questions:
- How many different languages are used in the project? If the answer to this question is “more than one”, there is good chance that BPEL fits well in context. Otherwise, consider adapting what already exists before considering the adoption of this tool.
- There must be the existence of a single transaction during the invocation of these services? If the answer is yes, I issue a warning: it is possible, with specific tools, controllers use distributed transactions to ensure that this requirement is fulfilled. However, it is always easier to accomplish this control within the scope of the applications themselves ( use the right tool in what she does best )
- Are there business analysts involved in the project? If so, maybe BPEL is well put: because the process can help the understanding between the BPMN and BPEL implementation. Otherwise, BPEL may not be justified.
In conclusion … BPEL, like so many other well-established tools, is a fantastic tool. However, it should be able to use. The correct use of certain tools in a project may make its use essential. But the use of wrong tools can make your design to be developed slowly, much more expensive and difficult to maintain. As with any tool misused.