Custom Search SOABYTE here

Friday, January 29, 2010

Introduction to BPEL

To give an answer to the question “when should you use BPEL?” it's important to first understand what BPEL is and what can be done with it. On this page we'll explain what BPEL is, how BPEL can be used in a real situation and which other standards are trying to achieve similar goals.

What is BPEL?

Before explaining what BPEL is, it's important to note that BPEL is based entirely on Web Services. Web Services provide a way to communicate over a network in an open and flexible way based on XML. We won't give an explanation on Web Services because there's are already a lot of information on that subject available on the Internet.

What BPEL does, is offer an open standard to make a flexible coupling between several systems. Because BPEL works with Web Services it is possible to connect systems that can be any where on this world or in outer space.
An important thing to note is that at the moment OASIS is busy developing WS-BPEL 2.0. In this new version there are going to be several changes to make the standard easier to implement and also some features are going to be improved. On this page we'll only talk about the BPEL4WS 1.1 specification.

Practical usage

To show how BPEL can be used, we'll give you a short example. This example will also be used later in the BPEL language explanation. In this example we are going to give a situation where a soda machine company wants to automate the software installation and upgrading based on actions happening in their ERP system. In this example we'll call the soda machine manufacturer SodaSys.
SodaSys has an Electronic Resource Planning (ERP) system in which all administration is done. When new machines need to be made, this is entered in the system and also when there is something wrong with one of the machines, this is entered in the ERP system. At the moment when a new machine is manufactured, a employee needs to install the software on the machine by inserting certain firmware on a memory card in the machine. The firmware is different for the serveral types of their machines. For example, a machine that is going to be used in America will have to use dollars, while a machine for France will have to be able to use Euro coins. In this example we will just assume that the hardware of these machines is already installed correctly and that the handling of this is done in the firmware.
Now SodaSys is going to upgrade their fabrication line by adding a network connection to their machines. When a machine is fabricated, then the ERP system is updated that the machine is connected to their local network and that it's ready to receive the proper firmware based on all the variables of the system. To install the firmware on the machine SodaSys has bought a provisioning server that can install the firmware on the soda machines.
Now the problem arises that in order to automate installing firmware, the ERP system needs to talk to the provisioning server. To connect these two parties we'll put a BPEL orchestration server in between them. Now there is one important requirement to either the ERP and the provisioning server. They both need to support Web Services. The ERP system has to be modified so that when a device is set ready for installing firmware, there should also be a call to the BPEL server. In this call there should be supplied which machine is ready to receive firmware, but also what localize settings to use. There are probably also a lot of other settings that have to be looked at, but in order to keep this example relatively simple, we'll just discard that information.
For all the actions in the ERP that have to invoke a certain action on the provisioning server, there should be a call from the ERP to the BPEL orchestration server. Even if this call doesn't do anything at the moment it would be smart to already put it in so that in the future when on that call the provisioning server has to do something, there has to be no adjustment to the ERP system.
The provisioning server has to have all the actions that can be invoked on it available as Web Service so the BPEL orchestration server can call the provisioning server to do something. The situation described above is shown in the figure below.
Example how BPEL connects ERP and provisioning server
Now you could be wondering why use this BPEL server and not connect the ERP system directly to the provisioning server? The answer is actually quite simple. When a small change has to happen with the provisioning server that makes it require a few other settings, then these settings also have to be adapted in the ERP system. This would probably mean that the ERP systems needs to be recompiled and reinstalled, this is not a wanted situation.
In the figure below the very simple version of the process of adding a new device is shown. After the ERP has invoked the BPEL Orchestration Server, the process first looks what language is supplied by the ERP. When this language is usa certain firmware is installed on the device by invoking the provisioning server to install certain firmware on the by the ERP supplied device name. When the option is france, other firmware is installed. After the firmware is installed the process returns the status of the firmware installation.
Detailed view of the process
Of course this is overly simplified, but it does show that the process can switch certain values given to the process. In the normal process there is probably also going to be set what the prices are of the several products that are in the machine. What also could be setup is what kind of beverages are in the machine and if these are cans or bottles.
An other important feature of BPEL is that the process could also check if the machine is properly installed. It could do this by invoking the provisioning server every 30 min what the status of the installation is. When the installation is finished without fault, this could then be returned to the ERP system. If the installation hasn't completed after 12 hours it could send a signal to the ERP system that a mechanic has to take a look at the system.
Of course it's not only at installation time that this BPEL process can be used. Take for example the situation where the prices in the machine need to be upgraded. Maybe now this is to be done by a employee that has to go to the machine and change the prices. But with the device also connected to the Internet the prices could be updated by first changing the prices in the ERP. The ERP then sends these new prices to the BPEL process that invokes the provisioning server. The provisioning server can now contact the machine and change the prices.
As you can probably see, there are a lot of practical uses possible with this technology. Also consider that in the BPEL process there could be error handling and rollbacks. When for example already some software is installed, but in that same process an error occurs at the end. The rollback would remove the other software too.

Competing standards

The biggest competitor of BPEL is BPML. BPML offers everything BPEL can do and a little bit more. The biggest problem of BPML is that the 1.0 version was released a month after the 1.0 version of BPEL. And BPEL was supported by big corporations like Microsoft, IBM and SAP. The BPML standard just couldn't cope with the big support behind the BPEL standard, so even the creators of BPML, acknowledged that BPEL would maybe be the better supported version.
Next to BPML and BPEL there are other standards for describing business processes, but most off them are not meant to be used for executable processes.
In the figure below there is a small time line that shows what other standard are also introduced that were doing similar things. More information about these standard can be easily found on the Internet, so we won't go into those any further.
Timeline of different specifications


Post a Comment

Blogger Profile