CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
This is Chapter 4,”Oracle BPEL Process Manager,” from Business Process Execution Language for Web Services, published by Packt Publishing.
In this chapter we will take a detailed look at the Oracle BPEL Process Manager Version 2.0, a BPEL server that enables us to deploy and run business processes defined in BPEL. Oracle BPEL Process Manager is developed in Java and runs on a J2EE application server. In addition to deploying and running BPEL processes, it offers advanced functionality that makes it one of the most powerful BPEL servers at the time of writing this book. Oracle also offers a BPEL Designer that enables BPEL process development using an intuitive graphical editor instead of writing BPEL code by hand and also allows us to automatically deploy BPEL processes. The BPEL Designer eases the development (and maintenance) of BPEL processes considerably.
While discussing the capabilities of the Oracle BPEL Process Manager and the BPEL Designer, we will cover the following:
- Architecture of the BPEL Process Manager
- Major features
- Process deployment
- Managing and debugging processes with BPEL Console
- Graphical development with BPEL Designer
- Oracle-specific functions such as XSLT, XQuery, and XSQL engines
- Integration of BPEL processes with e-mail and JMS
- Integration with Java and J2EE
- XML business document façades
- Web Services Invocation Framework bindings
- Oracle BPEL Server Java APIs
- User tasks and their integration into processes
Overview and Architecture
The Oracle BPEL Process Manager (formerly known as Collaxa BPEL Server) is a run-time environment for BPEL processes. BPEL Process Manager 2.0 fully supports BPEL version 1.1 and provides additional tools for deployment, monitoring, and management of BPEL processes. At the time of writing this book, Oracle BPEL Process Manager is one of the most complete BPEL servers available.
BPEL Process Manager is developed in Java and runs on a J2EE-compliant application server, for example, the Oracle Application Server OC4J (Oracle Containers for Java). In addition to the OC4J version, Oracle also provides versions for the open source JBoss and for the BEA WebLogic Server. With manual installation, Oracle BPEL Process Manager can also be used with IBM and Sun application servers.
Let us now look at the architecture of the BPEL Process Manager, shown in the following figure:
The Oracle BPEL Process Manager has four major parts:
- BPEL Designer
- BPEL Server
- BPEL Console
- Database
BPEL Designer
BPEL Designer enables us to develop BPEL processes visually in a graphical environment without having to write BPEL code by hand. Instead, we can drag and drop activities to the process. We can add partner links and locate services through the UDDI browser. We can also use function and copy wizards. BPEL Designer can deploy the developed processes directly to the BPEL Server. This eases the development and maintenance of BPEL processes considerably. BPEL Designer is a plug-in for the Eclipse 3.0 platform, but we expect that it will become a part of the Oracle JDeveloper soon. Because it uses standard BPEL, processes developed by the BPEL Designer can be used with other BPEL servers (and vice-versa) as long as we do not use functionality specific to the Oracle product. We will discuss BPEL Designer later in this chapter.
BPEL Server
BPEL Server runs in a J2EE-compliant application server. It has the following main parts:
- Core BPEL engine
- WSDL bindings
- Integration services
Core BPEL Engine
The core BPEL engine is the run-time environment where the BPEL processes are deployed and executed. In addition to full BPEL v1.1 support, the engine provides support for key web services orchestration stack technologies, particularly WS-Addressing and the BPEL compensating transaction model.
The BPEL engine also provides support for version control. This enables us to develop several versions of a business process and deploy them side by side. This feature is important in realworld scenarios because business processes evolve over time. Having an effective versioning support simplifies the management.
Another very important feature is dehydration. In previous chapters we explained that business processes can be long-running because the involved partners might not be able to react instantly to the requests. This happens particularly in asynchronous scenarios where a business process invokes a partner web service (using the <invoke> activity) and then waits for the esponse (using the <receive>or <pick> activities). While waiting for the response the Oracle engine can store the process (and its state) in the database, thus freeing up server resources. This is called dehydration. When the engine receives the response it first restores the process with its state from the database (hydration) and then continues with the execution of the process. In real-world scenarios where many business processes might be running side by side, the dehydration capability is important as it reduces the demands on hardware performance.
Oracle BPEL engine also provides support for clustering. Clustering increases server reliability because fail-over can be configured on the engine. Clustering also improves scalability with load balancing. These features are very important in real-world usage of the
WSDL Bindings
The WSDL binding framework is responsible for communication with the BPEL processes deployed on the server. This includes clients that would like to access a BPEL process and BPEL processes that would like to access other web services (partner links). Although the BPEL specification talks only about web services, the Oracle BPEL Server even enables connectivity using protocols other than SOAP. In real-world scenarios, a business process will often have to connect to an existing application or system. Using the WSDL binding framework, the reach of BPEL is extended to systems using protocols other than those supported by web services (primarily SOAP).
Of particular interest here is connectivity to J2EE artifacts, such as EJBs (Enterprise Java Beans), RMI (Remote Method Invocation), JMS (Java Message Service), JCA (Java Connector Architecture), and also to e-mail and HTTP GET and POST. The integration is achieved through the WSIF (Web Services Invocation Framework) from Apache (http://ws.apache.org/wsif/). All this enables relatively easy and effective integration of backend systems, particularly existing and legacy systems, which cannot be simply exposed as web services.
Integration Services
Business processes described in BPEL communicate with web services and exchange XML documents. The integration services enable us to perform transformations (on these XML documents) that go beyond the support of XPath.
Note: Oracle BPEL Server provides support for XSLT transformations, XQuery, and XSQL.
XSLT (Extensible Stylesheet Language for Transformations) provides support for complex transformations of XML vocabularies and can also be used to transform XML to other markup formats such as HTML, WML, or VoiceXML for presentation purposes. For more information on XSLT please refer to http://www.w3.org/TR/xslt. XQuery and XSQL are XML query languages with functionality that goes beyond simple XPath queries. For more information on XQuery please refer to http://www.w3.org/XML/Query. For more information on XSQL please refer to Oracle documentation.
BPEL Server also provides Java integration. We have two choices:
- We can embed Java code in BPEL processes.
- We can use the Web Services Invocation Framework (WSIF).
The BPEL server exposes its functionality through a set of APIs. An important part of the integration services is the user task service. The built-in BPEL service provides an easy way to include user interaction in BPEL processes. Business processes often require that a user reviews or confirms a decision before carrying out further steps. However, the BPEL specification does not provide an easy way for doing this. The Oracle BPEL Server therefore provides user tasks through which we can include user interaction in an easy way, as we will see later in the chapter.
BPEL Console and Database
Through BPEL Console we can deploy, manage, administer, and debug BPEL processes. The most important features of the BPEL Console include:
- Visual process flows
- Audit trails
- Debugging view of processes
- Process history
Oracle BPEL Console uses a web-based interface, which is basically a set of JSP (Java Server Pages) and servlets that call the BPEL Server API (in Java). This means we could easily develop our own console if we need specific handling of BPEL processes.
We have already mentioned that Oracle BPEL Server supports dehydration, which stores the process state in the database. BPEL Server supports Oracle DBMS, Microsoft SQL Server, and IBM DB2. It can actually be configured to use any JDBC database. The trial version, which can be downloaded from Oracle web site, comes bundled with Oracle Lite. Note that for real-world scenarios a production-quality database should be used.
Process Deployment Example
Let us now show how we deploy a BPEL process on the Oracle BPEL Server. We will assume that Oracle BPEL Process Manager has been successfully installed according to the installation instructions and that it uses the default port 9700. If another port has been selected during installation, the examples have to be modified accordingly.
We will use the Business Travel BPEL process example that we developed in Chapters 2 and 3. The travel example is a simplified business process that selects the best airline ticket offer. To refresh our memory, let us have a look at the process activity diagram:
In the previous chapters we developed the BPEL code for the example; this consists of a Travel.bpel file with the source code and the Travel.wsdl where the WSDL definitions are stored. We will not show the source of these files here as they have been already shown in previous chapters. They can also be downloaded from http://www.packtpub.com.
