Book Image

WS-BPEL 2.0 for SOA Composite Applications with Oracle SOA Suite 11g

Book Image

WS-BPEL 2.0 for SOA Composite Applications with Oracle SOA Suite 11g

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 for 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 simple at first sight, it hides its large potential and has many interesting and advanced features. If you can get familiar with these features - you can maximize the value of SOA. This book provides a comprehensive and detailed coverage of BPEL, one of the centerpieces of SOA. It covers basic and advanced features of BPEL 2.0 and provides several real-world examples. In addition to BPEL specification the book provides comprehensive coverage of BPEL support in Oracle SOA Suite 11g, including security, transactions, human workflow, process monitoring, automatic generation of BPEL from process models, dynamic processes, and more. This 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 will then move on to explain core concepts such as invoking services, synchronous and asynchronous processes, partner links, 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, concurrent activities and links. The authors also discuss the business process lifecycle, correlation of messages, dynamic partner links, abstract business processes and mapping from BPMN to BPEL. The book presents in detail, how to use BPEL with Oracle SOA Suite 11g PS2. It explains the development of BPEL and SCA assemblies, and demonstrates different approaches with some practical examples. It addresses security, transaction handling, and human workflow. Then, the book addresses entity variables, notification services, fault management framework, and business events in BPEL. It provides exhaustive coverage of monitoring BPEL processes and developing dashboards with Oracle BAM. It explains how to use BPEL processes with Oracle Service Bus and Oracle Service Registry. Using examples, the book also demonstrates how to transform business process models in BPMN (using Business Modeler) to BPEL, how to achieve round-tripping using BPA Suite and BPM Suite, and how to use Oracle Enterprise Repository to govern BPEL processes. The book also covers the complete BPM lifecycle from modeling through implementation, execution, monitoring, and optimization and presents advanced, real-world examples.
Table of Contents (17 chapters)
WS-BPEL 2.0 for SOA Composite Applications with Oracle SOA Suite 11g
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.

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

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: