My Code Snapshots

Orchestrating Services with BPEL

Recap of SCA

Business Process Execution Language, commonly known as BPEL or WS-BPEL, is an XML based standard markup language that is emerging as the answer to process orchestration requirements. BPEL has very rich and comprehensive orchestration semantics, is based on wide industry participation, and is broadly accepted. The BPEL process coordinates interactions between a process instance and its partners. Both the BPEL process and its partners are modeled as WSDL services. Therefore, the BPEL process definition:• Interacts with one or more WSDL services• Provides the description of the behavior and interactions of a process instance through WSDL.

That is, the definition of a BPEL business process follows the WSDL model of separation between the message content and deployment information (messages and port type versus binding and address information)In short, a BPEL component can be exposed as a service through the composite WSDL if its operation can be useful to external clients.

Orchestration Requirements

Describing Process OrchestrationThe concept “process orchestration” encompasses the idea of coordinating services in a business process from a single run-time environment. Orchestration:• Directs and manages an on-demand assembly of multiple services• Results in the creation of a composite application forming a business processIndustry has now converged on using the Business Process Execution Language for Web Services (BPEL4WS) as the core standard for Web services orchestration, simply known as Business Process Execution Language (BPEL). Oracle BPEL Process Manager provides a run-time environment for executing applications developed in BPEL. The BPEL process runs in a specific run-time container to coordinate one or more services to complete a business process (flow).

BPEL Process Manager

The design environment (Oracle JDeveloper) enables you to design and deploy BPEL processes. You design BPEL processes by dragging and dropping elements (known as activities) into the process and editing their property pages. You integrate BPEL processes with external services that you also design and edit (known as partner links). You also integrate technology adapters and services such as workflows, worklists, transformations, notifications, sensors, and business rules with the process. Deployment sends the Oracle BPEL Process Manager archive (a set of files in a JAR file with a directory structure similar to the project directory structure) to Oracle BPEL Server. The deployment operation automatically validates and compiles the project directory into the BPEL archive.

Oracle BPEL Process Designer - JDev


Introduction to Activities



The HelloWorld Process

The Hello Process

During this lesson and practice you will create a simple BPEL process. It takes a name as an input message and returns the message “Hello ” followed by the name, through a synchronous reply.

In Oracle BPEL Process Designer, on the left, the Applications and Connection Navigators provide navigation within your project. The Applications Navigator shows the files associated with your project and the Connection Navigator provides access to wizards for configuring your connections (for example, Oracle BPEL Process Manager Server and database connections).

 In the middle of the window is the Diagram View which is a visual representation of the flow logic. Opening any component exposes a list of any global XML variables defined for the flow. An Inspector pane allows you to drill down into the Diagram View. At the bottom of the window, the Source tab allows you to switch into text-editing mode for the source code of the BPEL process.

Note: Two-way editing is enabled; such that, changes you make in either editing mode are reflected in the other mode.

On the right, the Component Palette provides a list of process activities, code snippets, and preferred components to include within your BPEL process.

Anatomy of a Composite

The files that are created to support this synchronous process are:

bpel.xml: The deployment descriptor for the process. This file contains the metadata for the Hello process and it defines the locations of the WSDL files for services called by this flow, along with other project-specific parameters.

Hello.bpel: The BPEL source for the process. The New Project dialog creates an empty flow, with just the minimum activities and definitions for the selected flow type. For a synchronous BPEL process, the only activities created are a <receive> to initiate the flow from a synchronous client request and a <reply> for the return.

Hello.xsd: This file contains the definitions of the messages that are exchanged by this process.  This file is referred to in the WSDL fileHello.wsdl: The WSDL (client) interface for this process. Defines the input and output messages for this flow, the client interface and operations supported, and the BPEL partnerLinkType(s), so that the flow can be incorporated into other processes. The New Project dialog generates a document-literal style WSDL that takes a string input message and returns a string response message.

Viewing the WSDL Source

  TYPE DEFINITION - List of services participating in this BPEL process The default output of the BPEL designer uses strings as input and   output to the BPEL Process. But you can define or import any XML Schema type and use them as part of the message types.

  MESSAGE TYPE DEFINITION - Definition of the message types used as part of the port type definitions

  PORT TYPE DEFINITION - A port type groups a set of operations into a logical service unit

 PARTNERLINKS – BPEL extension to WSDL.  The extensions are required because the WSDL specification is inadequate for this requirement of BPEL

WSDL provides a standard way in XML format to describe Web services. WSDL describes what functionality a Web service offers, how it communicates, and where it is accessible. WSDL documents have a <definitions> element that may contain:

Type definitions in a <types> element to describe message structures.
Interface (port type) definitions in an <interface> element to describe sequences of messages that a service can send and receive.

Binding definitions in a <binding> element describing the message format and protocol used - the implementation details to access the service (or endpoint).

Service definitions in a <service> element to describe a set of <endpoint> elements, each describing service details such as a URI to access the service.
WSDL Extensions provides a way to extension WSDL by defining structured message sequences and type patterns, security rules, and others items needed by an application.

BPEL depends on WSDL and WSDL Extensions:
•In partner links to reference message type structures for variables, and to invoke operations provided by a Web service.
•To describe the BPEL Process as a Web service, exposing the interface (message types and operations) to applications that interact with the BPEL process.  This is because when deployed, BPEL Processes are automatically published as Web Services so that they can be easily initiated by other BPEL Processes and also by Visual Basic applications, Excel spreadsheets or J2EE applications.

This WSDL file is copied from the deployed process visible through the BPEL Console.  Notice the <service> and <binding> tags, which were not present in the WSDL created in JDeveloper Note the <endPoint> tag inside <service>.  This tells the location where we can access this service (‘service’ because the BPEL process is automatically deployed as a web service as part of deployment)

BPEL Process Source Structure

The <variables> element is a container of one or more <variable> elements that represent messages and XML documents used by activities in process. The <variable> element provides a messageType attribute whose value, usually an XML type from in an XML schema, identifies the structure of the message or XML document variable.

•The <sequence> element contains the orchestration logic, or process flow. The process flow is comprised of a sequence of activities that coordinate the flow of messages across the services integrated within the business process. For example:•The <receive> element initiates a new instance of the process when a process request message is received.•The <assign> element can assign messages to output variables from literals, other variables, expressions, and combinations of each.•The <reply> element returns a synchronous response message to the client or requestor of the service formed by the BPEL process.

What next?



Deploying where?


Building and Deploying the process

If the BPEL process has been already deployed, JDeveloper will prompt you to enter a new version if you don’t want to overwrite the existing process deployed on the server.  It will show you all the versions that are currently deployed.

Managing and Administering 


BPEL's Relation to other Web Service Standards


BPEL Process Manager


Core Engine Architecture

The Delivery Manager listens for new messages coming in and the Dispatcher dispatches messages to the core engine. When a new version of an existing process is requested during deployment, the Lifecycle Manager creates a new JAR file. As soon as the server see the new JAR file, the Loader loads it. The core engine is stateless and any information related to state, is kept in the database. The Persistence Service handles the persistence of a state, passing the state to the Write Thru Cache for storage in the database. Dehydration is equivalent to persistence and dehydration occurs for all asynchronous processes, by default. If a failure occurs, the Persistence Service handles the return of state by hydrating back. Synchronous processes are not passed through dehydration.