This article is more than 1 year old
BPEL, business process management, SOA and you
Will 'coding in the large' replace what we do now?
Over the last few columns we have looked at how Service Oriented Architecture (SOA) based systems can be built using the Service Component Architecture (SCA) and Service Data Objects (SDO).
A system built using these frameworks can be formed by explicitly integrating services built using these elements. However, what we have not looked at yet, and what may not be clear, is how the management or control of these services should be achieved. It would certainly be possible to create an additional piece of software that accessed and controlled the Services to achieve some overall business aim. However, this might be quiet inflexible; requiring extensive maintenance.
An alternative approach is to use a Business Process Management (BPM) system. Such a system lets you represent the overall process explicitly and manage the services within this SOA-based system, which should be easier to maintain, modify and update.
In this column, we’ll look at this aspect of a SOA based system and in particular on Business Process systems that employ BPEL (Business Process Execution Language). BPEL is interesting in that it is the explicit representation of the process and thus the vehicle for flexibility. We'll also briefly consider compensation, which is used to handle failures within such business processes.
What is Business Process Management?
The first question I want to consider is “What is Business process management?” BPM relates to the identification, extraction and management of business processes or functions, which combine to solve an operational business need. Of course, we create most software systems to solve a business need! So what is so special here? The intention is that BPM, as realised today, goes further than this in that it also facilities the ability to quickly and easily change the execution, business flow or processes used.
This differs from pre-SOA-based Business Process Re-engineering. Business Process Re-engineering (or BPR) focussed on the manual re-engineering of processes (as a typically one-time event). These processes were then implemented, typically, via an ERP system. An ERP (Enterprise Resource Planning) system aims to integrate the data and processes of an organization into a single unified system. Within this single unified system, the business and process logic is hard-coded. However, the hard coding of the business logic resulted in a loss of flexibility and reduced competitiveness.
This of course is a key difference between an ERP based system and a BPM system based on SOA. In the BPM-SOA model, a set of disparate, loosely coupled, but integrated systems communicate to provide the business solution. The coordination or “orchestration” of the Services is handled by the BPM system.
Within BPM, a business process is a set of actions or operations performed by one or more actors (such as applications, people or organizations) to achieve a business purpose or objective. BPM is the management of these business processes; this includes the execution, monitoring, management and error handling associated with the overall business function. I have illustrated this in figure 1.
Figure 1 illustrates part of a business process representing the processing of an order for a customer. The business process illustrates the initial processing of an order. In parallel, the warehouse is checked to see if the stock ordered is available and the customer is notified that the order is being processed. Once the stock has been checked then the process checks to see that payment has been received before continuing.
BPEL is an XML based language that allows you to describe the business flow presented in Figure 1 explicitly. Thus, it defines the control and coordination of the services within a SOA. In the BPM-SOA world, BPEL is emerging as a standard way of defining such business processes.
As way of a bit of background, BPEL (Business Process Execution Language) can trace its origins back to WSFL and XLANG. WSFL (Web Services Flow Language) is an XML language proposed by IBM to describe the composition of Web Services). XLANG is an extension of WSDL (Web Services Description Language, which is used to describe Web Services) that describes the behaviour of a service as a part of a business process. BPEL was an effort initiated by IBM and Microsoft originally as a new language BPEL4WS. In April 2003, a consortium lead by IBM and Microsoft but now including BEA, SAP and Siebel Systems submitted BPEL4WS 1.1 to OASIS for standardization. This emerged in late 2004 as WS-BPEL 2.0. This change in name was intended to align BPEL with other Web Service related standards which all start WS-. In what follows, we will refer to WS-BPEL 2.0 as BPEL.
An interesting point to note here is that the use of BPEL is referred to as “programming in the large” and it is considered to be an “orchestration” language. The intention is to denote that a BPEL engine acts as the central controller of the business process – by analogy with a conductor, who is the central controller of an orchestra.
Within this model, services (from a SOA system) are the building blocks, and BPEL the glue, used to construct business processes. This provides a great deal of flexibility, which allows elements within a business process and the components a that make up that process to be reused and combined to address changing business needs and priorities.
Interestingly, there is nothing that stops this approach becoming recursive. That is, what is a service used within a BPM system at one level, may actually be defined in terms of a BPEL definition and a set of lower level services at the next. In fact, most BPEL engines, as well as the SCA standard described in earlier columns, support this.
Facilities provided by BPEL
I only want to indicate what BPEL offers in way of facilities rather than provide a detailed description of them (see the links in this article for more information). However, in addition to providing facilities to enable sending and receiving messages, the BPEL language also supports:
- A property-based message correlation mechanism.
- XML and WSDL typed variables.
- Flow of control constructs including if-then-else-if-else, while, sequence (to enable executing commands in order) and flow (to enable executing commands in parallel).
- Variable initialisation.
- XPath access to variable data (XPath variable syntax $variable[.part]/location).
- BPEL supports both synchronous and asynchronous service invocation.
Note, however, that BPEL is defined in terms of XML (an approach to producing a programming language that I am not 100% behind). As such, it has all the basic components of a programming language such as Logic, Data Types and I/O facilities. However, being based on XML this means that the components are provided in the following way:
- Programming logic defined in terms of XML elements.
- Data types defined using XML Schema Definitions.
- Input/Output (I/O) between SOA services defined via WSDL (Web Services Description Language).
There have been a number of extensions to BPEL and I will only pick out two here. These are BPEL4People and BPELJ. BPEL4People is intended to allow the integration of people and the tasks they perform into a BPEL defined business process. BPEJ is turn, is an attempt to extend BPEL to include programming in the small using the Java programming language. Each of these will be described in more detail in a future column.
Fault Handling and Compensation
Whether we consider BPEL to be an example of a programming in the large language or merely a way of integrating related business services, it is clear that there will be situations where at some stage in the process an issue may arise. This may be because of some process not completing due to an internal error, or because some business condition has not been met or the business process indicates that a failure scenario has been reached.
In traditional Java environments such scenarios may be handled via an exception being thrown and a transaction being rolled back. However, as BPEL may be integrating disparate applications which may include people based processes (via BPEL4People) and non-transactional operations - what should be done now? There’s certainly no distributed transaction to be rolled back, as many of the services involved may be asynchronous and may not support transactional concepts.
BPEL's solution is compensation. Compensation is not exception handling; nor is it transaction-based roll back of the effect of some operations. Rather, it is a way of recovering a business systems integrity following the identification of some situation. That is, compensation defines how a system is to attempt to recover itself when part (or all) of a BPEL process fails.
This means that compensation must be implemented as required for each of the services that have succeeded thus far at any point. This seems to involve particularly risky assumptions, given that a BPEL definition may be integrating processes which are very large or complex systems in their own right. Systems which, may or may not support correction themselves, following a later failure within the overall process.
For example, how do you undo sending an installation engineer out to install a new piece of hardware? These are not trivial issues and, currently, I suspect will require further investigation before a satisfactory solution is found.
Compensation and the pros and cons around compensation are a subject which I hope to explore in more detail in a future column.
Process Engine Vendors
There are a number of Open Source BPEL engines (such as JBoss jBPM and Intalio) as well as commercial BPEL engine vendors such as BEA with its AquaLogic product, IBM WebSphere Process Server (which runs on top of the WebSphere Application Server) and Oracle BPEL Process Manager .
Business Process Management offers a very powerful approach to providing flexibility and maintainability around SOA systems. However, question marks remain over the appropriateness of extensions such as BPEL4People and, particularly, BPELJ. In addition, the approach to compensation and fault handling may well need to evolve further, as we gain experience with the use of BPM.