Web services are touted one of the largest technology drivers over the next decade. Gartner predicts that the market for web services-based solutions will be US billion in 2005. Fu et al [3] specifies the goal of web services as “to have a collection of network resident software services accessible via standardised protocols, whose functionality can be automatically discovered and integrated into applications or composed to form more complex services". The W3C has put together a set of specifications (WSDL, SOAP, UDDI) which form the basic infrastructure required for web services. The more comprehensive web services stack contributed to by multiple standardisation efforts now consists of a complete suite of language specifications ranging from Policies (WS-Policy), Transaction (WS-Transaction) to Agreement (WS-Agreement) and composition (BPEL). In this article, we discuss about BPEL, a composition language for web services.
The specification of BPEL was initiated with the primary objective of standardising web service composition in the B2B domain. It draws heavily upon earlier work on WSFL (Web Service Flow Language) from IBM and XLANG from Microsoft, and is widely supported by many B2B integration solution providers. The specification is currently in version 1.1. BPEL can be used either within an organisation or across organisations (B2B applications) where multiple web services are part of a workflow. The primary requirement from such applications is the notion of loosely coupled systems which allows adapting the workflow with minimal monetary costs and strict time constraints. Service-oriented architecture (SOA) is the first step in this direction, of which BPEL forms an integral part.
Where does BPEL Fit in?
BPEL was designed to target two application scenarios – to be able to represent abstract and executable business processes. Abstract processes are used for inter-organisational sharing of business workflows. This is used to communicate complex processes to partners, giving only sufficient detail for B2B integration without divulging the private aspects of the process. Executable processes are a more complete definition of the workflow and can be executed by a BPEL execution engine (i.e. it is syntactically and semantically complete).
Who Use it, Why and What for?
BPEL can be used by solution architects to specify business processes for the purposes of sharing across organisations, and by developers to implement a workflow. Note that multi-party integration can be implemented using traditional programming languages as well. What distinguishes BPEL is its applicability to the service-oriented architecture and its conformance to the goals set by SOA.
Does it Supersede Older Technologies?
BPEL is expected to replace XLANG and WSFL as a web service composition standard adopted by B2B solution providers. As BPEL is highly accepted as the standard for web service composition, it will replace older and less mature composition languages.
Where do Popular Languages like Java Fit in?
Java and other languages will continue to be used. The services are exposed using web services languages and composed using BPEL. But, the services themselves will still be implemented in traditional languages. BPEL just replaces these languages in areas where looser coupling is employed to realise SOA. BPEL is also a language at a higher level of granularity (i.e. at the service level of abstraction).
Language Constructs
The BPEL vocabulary provides a set of constructs to describe web service compositions. Some BPEL constructs can be compared to features provided by traditional programming languages, though these constructs operate at a much higher level of abstraction. In order to give equal attention to other aspects of BPEL, we will only briefly introduce the available constructs.
The key constructs provided by BPEL can be classified based on the aspects of business integration (B2B) that they address.
Variables – Web services are stateless software entities. Unlike web services, business processes (i.e. composition of web services) are required to maintain some amount of state information which is enabled by the use of variables. Variables are of XML Schema type, and BPEL also identifies the possible access mechanisms for these variables using XPath notations.
Partner Links – Partner Links represent the global relationship (or conversational aspect) of the business process. They are used to indicate how the process interacts with other atomic services (and complex processes).
Event Handling – A business process is also associated with events, which can be handled concurrently with other activities of the process. Events are generally used to provide a means for status enquiries by interested parties.
Exception Handling – Exceptions occur during a process when normal execution of the process is interrupted due to a fault. Such conditions are handled using fault handlers which perform corrective measures. These constructs are analogous to the try and catch constructs available in programming languages.
Compensation Handling – Compensation handling is similar to database rollback. In BPEL, when distributed services are part of a particular business process, rollback of a process presents some challenges. BPEL provides an explicit compensation construct which can be used to invoke services responsible for rolling back operations.
Correlation sets – At any instant of time, a BPEL execution engine manages multiple instances of the same process definition. Correlation sets are a subset of fields of BPEL variables which can be used to identify the right BPEL instances.
Activities – BPEL provides constructs which are used to specify different kinds of activities in the business process. Invoke, receive, reply is used to call up other services, wait for invocation by other services and return responses. Like traditional programming languages, BPEL also provides control flow constructs like switch, flow, sequence, link. The flow construct is drawn from WSFL and sequence construct from XLANG.
A BPEL process specified using the above language constructs can be executed using a BPEL compliant execution engine.
BPEL Extensions and Engines
A misconception with BPEL is that it should provide all possible features required for any application domain. Though BPEL does provide constructs which can be used to express many business scenarios, it is not designed with the intention of being a utopia to all business situations.
We repeat a section of the BPEL specification with a particular purpose. The design principle behind BPEL is not rightly understood by many users. It serves as an important guide for BPEL designers and extensions provided by some existing BPEL engines. “Even where private implementation aspects use platform-dependent functionality, which is likely in many, if not most realistic cases, the continuity of the basic conceptual model between abstract and executable processes in BPEL4WS makes it possible to export and import the public aspects embodied in business protocols as process or role templates while maintaining the intent and structure of the protocols. This is arguably the most attractive prospect for the use of BPEL4WS from the viewpoint of unlocking the web services’ potential because it allows the development of tools and other technologies that greatly increase the level of automation and thereby lower the cost in establishing cross-enterprise automated business processes". Tool developers are expected to provide additional constructs to BPEL based on business needs, maintaining a careful balance between portability and requirement. BPELJ, BPEL+ are some of the extensions, while others are currently in development (like BPXL). We introduce some execution engines with an emphasis on the extensions each provides.
Oracle (previously Collaxa) Process Manager provides additional constructs for manipulation of BPEL variables. It targets extensions to the BPEL assign construct, which is insufficient in some application domains where variable sizes (e.g. XML Schema unbounded array) dynamically change at run-time.
IBM Process Choreographer is yet another BPEL engine which provides some extensions (BPEL+) to capture the notion of "staff" activities. BPEL does not make a distinction between services which involve only machine-based computation and manual input. Processes with manual input are usually long running and asynchronous with additional requirements to specify role players and access restrictions. BPEL+ also supports minimal inclusion of Java snippets into a BPEL process definition.
An additional BPEL extension is the BPELJ (BPEL-Java) specification (http://www-106.ibm.com/developerworks/webservices/library/ws-bpelj/) which combines the benefits of both BPEL and Java. BPELJ fits nicely into domains where some additional language features of Java are to be used, at the cost of portability which draws lower priority. At the time of writing this article, BPELJ engines are still under development.
Many open source implementations (e.g. Active BPEL – http://www.activebpel.org/) of BPEL engines are either available or currently under development. Such implementations provide solution providers a good starting point to create extensions suiting their requirements.
Mapping BPEL in Model Driven Architecture
BPEL-based processes are currently being designed by architects (and developers) through the use of BPEL-specific editors, which provide graphical interfaces to process designers. The Model Driven Architecture (MDA), put forward by the OMG, requires interoperability between higher level models and BPEL so as to exploit all the advantages of MDA. In other words, mappings should exist between various meta-models and BPEL.
The research community is presently addressing automatic mappings to BPEL. This draws from past work in compiler-based technologies to translate from one language to another. In particular, there has been work in the translation from UML-like languages which allow specification of processes in a much higher level of abstraction. The mapped BPEL process is then worked on by developers to create an executable process. Readers interested in exploring this area or using MDA with BPEL in their solutions can refer to Baina et al [1], Bezivin et al [2] and Koehler et al [4].
Validating BPEL Processes
One issue that is often overlooked by many BPEL users is the accuracy of the process specification. The global behaviour of multiple interacting business process in either an intra-organisation or a B2B setting has to be analysed and verified for accuracy before their use in the real world.
Verification of accuracy can be defined informally as the answer to question – “Does the global behaviour of the B2B system result in a state from which the required business goal cannot be reached?". Recently, there has been work on applying techniques from modal checking to answer this question. This involves transforming BPEL processes into finite automata and verification of accuracy of the behaviour of communicating finite automata using model checking (e.g. Spin – http://spinroot.com/spin/whatispin.html) software. Though this process appears trivial, it requires significant research from the view of mapping BPEL, and bounding state space search. In most cases, in complicated business processes, the message exchange patterns could lead to computationally infeasible searches by the model checking software.
An advantage of BPEL in the above scenario is that its modularity allows easy verification of accuracy critical to many business processes. Robust verification is largely ignored in traditional programming language-based systems since communication aspects are not explicit as in BPEL. Readers interested in further details on these formalisms and tool support can refer to Fu et al [3] and Baina et al [1].
Conclusion
In this article, we have presented BPEL, with a specific purpose of not just introducing the reader to language constructs, but also to give an overview of related technologies, misconceptions and extensions. Though BPEL addresses many issues for service-oriented architectures, the true potential of BPEL is yet to be exploited.
Pranam Kolari is a PhD student and research assistant in the Department of Computer Science and Electrical Engineering at UMBC. His research interests include Semantic Web and web services. Pranam has a B.E. in Computer Science from Bangalore University(UVCE) and an MS in Computer Science from the University of Maryland Baltimore County. He currently holds a Ph.D fellowship from IBM Toronto Labs.
Li Ding is a PhD student and graduate research assistant in the Department of Computer Science and Electrical Engineering at UMBC. His research interests include artificial intelligence, semantic web and trust. He has a BS and an MS in computer science from Peking University, China. He leads the Semantic Web Search engine (http://swoogle.umbc.edu) effort at UMBC.
Links & Literature
[1] K. Bana, B. Benatallah, F. Casati, and F. Toumani, Model-driven web service development, in Proceedings of 16th International Conference on Advanced Information Systems Engineering (CAISE04), 2004. Best Paper Award.
[2] J. Bezivin, S. Hammoundi, D. Lopes, and F. Jouault, Applying mda approach to b2b applications: A road map, in Proceedings ofWorkshop on Model Driven Development (WMDD 2004) at ECOOP 2004, 2004.
[3] X. Fu, T. Bultan, and J. Su, Analysis of interacting bpel web services, in WWW'04: Proceedings of the 13th international conference on World Wide Web, ACM Press,2004, pp. 621-630.
[4] J. Koehler, R. Hauser, S. Sendall, and M. Wahler, Declarative techniques for model-driven business process integration, IBM Systems Journal, 44(1) (2005). |
