Sunday, May 15, 2011

Business Process Execution Language (BPEL): Definition & How it creates composite WebServices

Follow trongbang86 on Twitter
About me

Section 1: Introduction
BPEL is a language that can construct workflows. These workflows are a pre-defined combination of WebServices which follows the order of business processes. In other words, BPEL provides enterprises an industry standard that can orchestrate Web Services. The term “orchestrate” here refers to the ability to assemble discrete services into a complete process flow, thereby reducing the cost and complexity of process integration. Before the invention of BPEL, businesses had to use proprietary and platform specific solutions to wire legacy systems to construct a process flow. This approach has become obsolete due to the inability to expand as well as its complexity. BPEL has been now recognised as a promising solution to the problem of interoperability between partners using different technologies. This paper will present you what BPEL is, where it fits into the Web Service model and why we need to have it.

The structure of this paper is divided into three sections. Section 2 gives you the background, general context and why this topic is important. Section 3 is about the main content that will guide you through all the concepts and constructs of BPEL as well as the reason we need to have BPEL. And the last section will summarise the key elements of my report.

Particularly, in section 3, I will cover these areas:

·       Section 3.1: What is BPEL and examples?

·       Section 3.2: Where it fits into the WebServices model/stack

·       Section 3.3: Basic constructs

·       Section 3.4: Why we want to have BPEL

Section 1: Background
Before the invention of BPEL, to integrate different services from two silo systems, people had to use proprietary and platform specific solutions such as Dynamic Link Library (DLL from Microsoft) or leveraging database as an integration point. These solutions are very intuitive and have no support from the vendors regarding integration purposes. For example, if a database approach is selected, a thorough understanding of the databases from the two partners or systems is required. However, it’s not always the case that the two databases have common characteristics to facilitate this initiative because they were not designed for this purpose. Moreover, as the systems keep evolving, their databases are also expanded and contain more complex semantics. It turns out to be that the cost to integrate these systems keeps escalating, or it is even impossible to accomplish this task.
With the advance of Web Services concepts, systems are being developed in a more collaborative manner. Using SOAP or REST architecture, messages are exchanged between systems. On top of that, WSDL and UDDI are employed to define the contract of what services are being provided, how and where to invoke them. Based on that contract, we can use BPEL to facilitate the cooperation of services in a way that can reflect the business flow. Hence, the complexity and cost of integration can be reduced and the expandability of the systems is enhanced.
WebServices is a hot topic in every Programming Language (PL). There are tons of instructions and tutorials on how to develop WebServices. Learning these tutorials is really up to the taste of a developer whether it is Java or .Net. However, BPEL is a common structure with its own syntax that can be re-used in almost all PLs or even combines WebServices created in different platforms. 

BPEL is a convergence of Web Service Flow Language (WSFL) from IBM and XLANG from Microsoft. It is a way to orchestrate Web Services and hence is related to standards such as UDDI, SOAP and WSDL. The following figure is to illustrate where BPEL fits into the stack of Web Services.

Figure 1 - Where BPEL fits into the Web Service model
(Extracted from Diego, Lecture 3 – Soap, Semester 1, 2011)

As mentioned above, WSDL is to give the description of Web Services or a contract for the services provided by a service provider. On top of that, we have BPEL. It is to facilitate the peer-to-peer interactions between services according to the contract or WSDL. We will have an in-depth discussion about this in Section 3.2 - Where it fits into the WebServices model/stack.

Section 3: Content

Section 3.1: What is BPEL and examples?

BPEL is short for Web Services Business Process Execution Language (WS-BPEL). It was a convergence of WSFL from IBM and XLANG from Microsoft. After that convergence, BPEL4WS 1.1 was submitted to OASIS so that it can gain a wider industrial recognition and open standardisation (Kumar, 2011). The Organisation for the Advancement of Structured Information Standards (or OASIS) is a global association that leads the development and adoption of Web Service and e-business standards (SearchSOA website). The current version of BPEL is 2.0.
BPEL is XML-based so it leverages XML Schema, XSLT, and XML Query. Using the syntax of markup languages, it composes a set of discrete Web Services into a complete business process (BP) flow. There are two types of business processes that BPEL supports:
1)    An Executable Process is a business process that can be mapped to the actual behavior of a business interaction. It encompasses the precise semantics that can be used to validate and automate BPs. For example, Business Process Modeling Tools like BPM Workbench and UML are usually used to model this type of BP.
2)    An Abstract Process uses process descriptions to specify the message exchange behavior between two parties without revealing their internal behavior. Business Process Modeling Annotation is one example for this type of BP.
BPEL defines an interoperable integration between or within any types of BPs. Therefore, it can enhance the expansion of automated processes. An example of BPEL is depicted in the following figure:

Figure 2 - Order Fulfillment Process - (Extracted from YawlBook, 2011)

In figure 2, the graph on the left hand side is a business process which is realised in BPEL on the right hand side. It is an order fulfillment process which requires an order approval to be accepted first. That’s why we have a condition at line 4. After the approval, it is continued with a carrier appointment process (line 8). The carrier appointment process is split into two sub processes which are Freight in Transit and Payment processes (line 10 &11). The whole process closes with the freight delivered.

Section 3.1.1: BPEL in action
How does a life of a BPEL specialist look like? What is needed to do this job? The answers to these questions can be found in this section.
According to the Kumar (2011), there are three core components. Firstly, a BPEL specialist needs a BPEL Designer which acts as an Integrated Development Environment (IDE). Using that, s/he can define the business process flow. As described above, this will be an arrangement of Web Services so they need to specify how the services can be linked and in which order they need to follow. At the moment, this kind of BPEL is capable of graphical processing. In other words, the specialist can build the logic graphically.
Once the specialist finishes the business process flow, a process logic template comprising the process flow logic would be generated by the BPEL Designer. At runtime, the user can access the service which is hosted and executed by a BPEL Engine. The following figure demonstrates the whole process:

Figure 3 - BPEL in Action
(Adapted from Christoph, 2011)

Section 3.1: Where it fits into the WebServices model/stack
The following figure is the figure 1 introduced in Section 2. It is repeated here to facilitate readers.

 (Extracted from Diego, Lecture 3 – Soap, Semester 1, 2011)
From the figure, we can say that BPEL stays above WSDL. We are not taking into account other layers such as WS-Security, WS-Reliability or even UDDI. The reasons are they are not the main focus in this paper and they act as intermediary nodes which can add more values into the Web Service model.
BPEL is to facilitate the peer-to-peer interactions between services according to the contract described by WSDL. It composes and provides automated arrangement of services to achieve a desired outcome which is actually a business flow. In other words, it orchestrates Web Services and hence it is marked with the label Orchestration in figure 1. The following figure gives you an example in which BPEL orchestrates Web Services:
Figure 4 - Orchestration with Web Service
(Adopted from Nackman, 2005)
As depicted in the above figure, each small square icon represents a service. We can have a wide range of services coming from different areas. Without BPEL, they are just a diverse set of features/functions which might or might not create any business values. Using BPEL, we can coordinate and arrange them in such a way that reflects the business operations and can be automated.

Section 3.1: Basic constructs
BPEL is an XML-based approach to Web Services. To define business processes, it uses a rich set of XML elements. In the next section, I’m going to explain some key elements in a BPEL document:
·      Partner Link Types, Partner Links
·      Properties
·      Data Handling
·      Correlation
·      Activities
There are many more XML elements that can be used in a BPEL document. However, I am going to explain only the five elements listed above due to the time constraint on this paper.
Section 3.3.1: Partner Link Types, Partner Links
BPEL processes do not contain only internal Web Services of a company. They can actually interact with external Web Services provided by other companies which might be built on a completely different platform. They can also receive invocations from clients. One of the clients will be the user who kicked off the process. These two types of interactions computer-client and computer-computer can be implemented by the partner elements in BPEL. The following code is the examples as to how the partner elements can be declared:

Figure 5 - PartnerLinkType and PartnerLink
(Adapted from WS-BPEL v2.0)
According to WS-BPEL v2.0, the difference between the two is that partnerLinkType characterises the relationship between two services defining the roles played by them, whereas partnerLink defines the actual link between the two services. Moreover, it is stated that the former element <partner> was removed from the current specification. The element <partner> is the element that was used to wrap around <partnerLinkType> and <partnerLink> in the BPEL v1.1. The reason is that it was used for quite some times but people couldn’t find any specific use that can make the difference between with and without using <partner>.

Section 3.3.2:Properties
The property element has two usages. Firstly, it can be used in a <correlationSet> which will be discussed later. In this case, it is used as a token that can facilitate stateful interactions. Secondly, the property element can be used on the <variable> element (more details in section 3.3.3 Data handling). In this case, it can isolate the variable initialisation logic and the manipulation of the variable. The following figure is the demonstration of how to declare and use the <property> element.
Figure 6 - The Property element
Section 3.3.3:Data Handling
This concept of data handling is similar to any programming languages. It is to have a placeholder that can save state information and the manipulation of that placeholder to carry out the desired outcome. In BPEL, it is called <variable>. The following figure is the syntax and one example of how the <variable> element can be declared and put to use.
Figure 7 - The variable element
Similar to any programming languages, variables have a scope associated with. In other words, they can only be seen within the specified scope. In BPEL, the <scope> element is used to do this.
Section 3.3.4: Correlation
The ideas in this part are a study from Pymma Consulting Company. Before diving to the details, we are going to explore the differences among these concepts: BPEL engine, BPEL definitions and BPEL instances.

Figure 8 - BPEL Engince, BPEL Definitions and BPEL Instances

This is a generic architecture that depicts a simple interaction between a person and a BPEL process. As the user initiates the first interaction to the BPEL engine, the engine will consult the BPEL definition which is the XML-based document written by a BPEL designer. After that, the engine will create an instance of the BPEL process according to its definition.

So far we have seen the differences among the three concepts. We are going to explore the challenges to the BPEL design process that leads to the use of the concept “Correlation”. Assume now we have two users who initiate two different instances for their own use:

Figure 9 - Correlation Challenge Demonstration 1
In the second step, User 1 is invoking the service Add Integer and wants to add 10 to the total that was created in the process instance 1. Now the confusion comes as illustrated in figure 10:  

Figure 10 - Correlation Challenge Demonstration 2
Some protocols such as RMI, Corba can facilitate stateful communications. Unluckily, this is not a case for BPEL because loosely coupling is its main goal. In order to enable this feature, BPEL leverages the use of data located in the message to wire process instances with the correct partners which are, in this case, normal users.
As a naïve example of how this works, we can simply add a user name during the init method then when the user make further requests, we can use the user name to identify the process instance. Figure 11 visualises how the system works in this way:

Figure 11 - Correlation Challenge Demonstration 3
The above figure is the idea to make it works. Figure 12 maps the relationship between WSDL and BPEL elements which actually carry out the work:

Figure 12 - BPEL Correlation in relation to WSDL
Because of the time constraint, I couldn’t delve deeper into the details of how correlation works. To wrap up this section, the following figure is the syntax for declaring correlationSet according to WS-BPEL v2.0:
Figure 13 - BPEL Correlation Syntax
Section 3.3.5:Activities
According to WS-BPEL v2.0, there are totally ten basic activities and seven structured activities. The following table lists all the basic and structured activities:
 Basic activities are activities which are to bring out specific actions in the process such as invoking services, whereas structured activities are to control the flow within the process. Because the main goal of this paper is to introduce what is BPEL, how it sits within the overall framework of Web Services; we are not going deeper into the details of each activity. Rather we will study only some core activities such as invoke, and if structure.
Each basic activity has two optional attributes, and two optional elements according the BPEL v2.0. The two basic attributes are “name” and “suppressJoinFailure”. As its name suggests, the attribute “name” is to declare the name of an activity. The attribute “suppressJoinFailure” is for indicating whether a join fault should be suppress if it occurs. The two basic elements are <sources> and <targets>. They are used to specify the source and the target of an activity.
Section Invoke
A typical use of <invoke> element is to invoke an operation on a service provided by partners. Operations can be request-response or one-way operations. Inside the invoke element, we can declare other activities such as fault handling.
The following figure illustrates how the <invoke> element fits into a BPEL process:

Figure 14 – The Invoke element
 And figure 15 is one example of how to use this element:
Figure 15 - Invoke statement sample
(Adapted from Matjaz, 2005)
Section structure
The <if> element is to choose a specific action depending on the current state of the process, when we have multiple cases that could happen and each of them has different behavior. The following figure is a process for creating purchase orders.
Figure 16 - Creating Purchase Order
 As can be seen, if the purchase order is not approved, the process comes to the end state immediately. Otherwise, other steps will be performed to accomplish the order.
The next figure is to illustrate how we can declare the <if> element:

Figure 17 - If statement sample
(Adapted from WS-BPEL v2.0)
As can be seen, the process checks if the inventory level greater than 100 or not. If not, the fulfillment work will be performed.

Section 4: Why we want to have BPEL
Exchanging messages, arranging the flow of activities, and invoking operations on a remote computer might be done in any PL(s) without putting a tremendous amount of effort. However, this is only true for very simple processes. As a company is expanding, its processes also become more complicated. Therefore, using any PL(s) such as Java, .Net can still be a barrier to such expansions because adding more code and changing the existing code to modify the flow of services can require specialised knowledge and result in a great effort in testing.
Since BPEL is a standardised language for orchestrating services, this job can become much easier due to the global recognition of the BPEL syntax. It does not require any knowledge in a particular PL. The BPEL designer can visually model the process and generate the corresponding document which is an XML-based document using the BPEL syntax.
Next, BPEL is portable across platforms. It works with services implemented on different PL(s) as long as they follow the structure of Web Service model. This is one of the biggest advantages when using BPEL since business-to-business interactions are normally between partners using different platforms.
Besides that, invoking services on a remote computer which is more specialised, thereby enhancing the performance and usability of the whole business process, is a great innovation. However, with the rapid growth in the number of services, we can end up wiring them with proprietary solutions provided by IBM or Microsoft if BPEL doesn’t exist. Then the merits of Web Services in portability and open standard would be jeopardised.
Moreover, BPEL can be extended. For example, BPELJ is an extension of BPEL that can enable the mixing of BPEL and Java code. This can be very handy because using Java code; we can perform tasks such as calculating value, executing other Java code without creating another service.    
Section 5: Conclusion
In conclusion, BPEL is capable of orchestrating Web Services. In other words, it composes and provides automated arrangement of services to achieve a desired business flow. BPEL is an XML-based approach to Web Services. To define business processes, it uses a rich set of XML elements. Basically, the XML elements provide BPEL users the ability to declare business partners, to control the flow of the whole process and to interact with other Web Services.
Personally, I don’t think the concept of Web Service can rapidly flourish without the contribution of BPEL. Using BPEL, the complexity and cost of integration can be reduced and the expandability of the systems is enhanced. BPEL is a common playground for orchestrating Web Services. It is portable, standardised, extendable as well as easy to implement compared to wiring services using any PL. Without BPEL, it is a challenge for businesses to interact with each other provided the fact that they are using different platforms.

Section 6: References

Christoph, S., Web Service Orchestration with BPEL,, visited 16 March 2011.
Kumar, R., An Introduction to BPEL,, visited 13 March 2011.
Matjaz, J., BPEL and Java,, April 2005.

Nirmal, M., BPEL4WS (Business Process Execution Language for Web Services),, visited 16 March 2011.

Nackman, L., Coming Together: Java, Eclipse, and SOW, Fawcette Technical Publications ( 2005

OASIS organisation, Business Process Execution Language for Web Services,, published on 11 April 2007.

YawlBook, The Business Process Execution Language,, visited 13 March 2011.


Follow trongbang86 on Twitter

No comments:

Post a Comment

There was an error in this gadget