Book Image

WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7

Book Image

WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7

Overview of this book

Business Process Execution Language (BPEL, aka WS-BPEL) has become the de facto standard for orchestrating services in SOA composite applications. BPEL reduces the gap between business requirements and applications and allows better alignment between business processes and underlying IT architecture. BPEL is for SOA what SQL is for databases. Therefore learning BPEL is essential for the successful adoption of SOA or the development of composite applications. Although BPEL looks easy at first sight, it hides a lot of potential and has many interesting advanced features that you should get familiar with in order to maximize the value of SOA.This book provides a comprehensive and detailed coverage of BPEL. It covers basic and advanced features of BPEL 2.0 and provides several real-world examples. In addition to the BPEL specification, this book provides comprehensive coverage of BPEL support on IBM's WebSphere SOA platform including security, transactions, human workflow, process monitoring, automatic generation of BPEL from process models, dynamic processes, and more.The book starts with an introduction to BPEL, its role with regard to SOA, and the process-oriented approach to SOA. The authors give short descriptions of the most important SOA platforms and BPEL servers—the run-time environments for the execution of business processes specified in BPEL—and compare BPEL to other business process languages. The book then moves on to explain core concepts such as invoking services, synchronous and asynchronous processes, partner links, the role of WSDL, variables, flows, and more.Moving ahead you will become familiar with fault handling, transaction management and compensation handling, scopes, events and event handlers, and concurrent activities and links. The authors also discuss the business process lifecycle, the correlation of messages, dynamic partner links, abstract business processes, and mapping from BPMN to BPEL.The book discusses details of using BPEL with IBM WebSphere SOA platform. You will be able to develop BPEL and SCA composite applications, and demonstrate different approaches with the help of examples in this book. You will get exhaustive information on monitoring BPEL processes, and developing dashboards.The authors explain transformation of business process models in BPMN (using Business Modeler) to BPEL and how to achieve round-tripping. The book covers a complete BPM lifecycle from modeling through implementation, execution, monitoring, and optimization, and presents advanced real-world examples. In addition to standard BPEL it also covers IBM specific extensions on the WebSphere SOA platform.
Table of Contents (16 chapters)
WS-BPEL 2.0 for SOA Composite Applications with IBM WebSphere 7
Credits
Foreword
About the Authors
About the Reviewers
Preface

Why business processes matter


Enterprise applications and information systems have become fundamental assets to companies. Companies rely on them to be able to perform business operations. Enterprise information systems can improve the efficiency of businesses through the automation of business processes. The objective of almost every company is that the applications it uses, should provide comprehensive support for business processes. This means that applications should align with business processes closely.

Note

A business process is a collection of coordinated service invocations and related activities that produce a business result, either within a single organization or across several organizations.

Although this requirement does not sound very difficult to fulfill, real-world situations show us a different picture. Business processes are usually dynamic in nature. Companies have to improve and modify, act in an agile manner, optimize and adapt business processes to their customers, and thus improve the responsiveness of the whole company. Every change and improvement in a business process has to be reflected in the applications that provide support for them.

It is most likely that companies have to live with very complex information system architectures consisting of a heterogeneous mix of different applications that have been developed over time using different technologies and architectures. These existing applications (often called legacy applications) are a vital asset in each company and core business usually depends on them. Replacing them with newly developed applications would be very costly and time consuming and usually would not justify the investment.

On the other hand, existing applications have several limitations. Probably the most important fact is that the majority of older applications have been developed from the functional perspective and have addressed the requirements of a single domain. Therefore, such applications typically do not provide support for the whole business process. Rather they support one or a few activities in a process. Such applications provide support for certain functions or tasks only. For an information system to provide complete support for business processes, it has to be able to use the functionalities of several existing applications in a coordinated and integrated way.

The consequence is that users need to switch between different applications to fulfill tasks and also perform some tasks manually. The flow of the tasks is in the heads of users, not in the information system and this has several disadvantages, such as limited insight into the way business activities are performed, difficulties in tracing current status and progress, difficulties in monitoring key performance indicators, and so on.

Existing applications have often been developed using older technologies, languages, and architectures, which are by definition less flexible to change. Tightly coupled applications, constructed of interrelated modules, which cannot be differentiated, upgraded, or refactored with a reasonable amount of effort, place important limitations on the flexibility of such applications. This is why such applications are sometimes called stovepipe applications.

Let us summarize — on one side we have the business system, which consists of business processes. Business processes define the order of activities and tasks that produce a specific business result. Business processes have to be flexible in order to adapt to customer requirements, to market demand, and to optimize operations.

On the other side, we have the information system with multiple existing applications. Existing applications have important business logic implemented, which a company relies upon to perform business operations. Existing applications are also difficult to modify and adapt, because they have not been developed in a flexible way that would allow modifying application parts quickly and efficiently. This is shown in the following figure: