Oracle’s scalable application architecture in combination with the BPEL architecture combines the best elements to create a high available and high performance environment. This article describes a solution to deploy multiple BPEL processes into a high available application cluster.
Overview
In general the deployment of BPEL processes can be done as follows:
- Using the Oracle BPEL console.
- Using Oracle JDeveloper 10g.
- Using the obant tool.
- Copy files into the Domain’s deployment area on the BPEL server.
This article describes how to deploy BPEL processes to a clustered application server environment. In this scenario we will have three (3) instances of Oracle Application Server 10g. On each of the server an Oracle BPEL is installed. This is shown as example in the next diagram.
Each application server is added to a logical cluster. The cluster can be defined via Oracle Enterprise Manager 10g. This applies also for adding the application server instances to this cluster. It is assumed that the application servers are using the Oracle Database 10g for retrieving and storing their data. This database is made high available via Oracle Real Application Clusters.
Solution
Define a logical application cluster and add each application server to this cluster. This can be done via Oracle Enterprise Manager 10g.
- Create an application cluster, e.g. “BPEL_AS_CLUSTER”.
- Add each application server instance to this cluster.
After creating the OC4J instance, each application server will now have a local OC4J instance. The power of the OC4J instance, in other words a J2EE environment, is that it can deploy EAR and WAR files. Creating an EAR or WAR file and deploy this to the application server, results that this file will be unpacked in each OC4J instance.
Using this mechanism for BPEL processes, it confirms to the industry standard of J2EE deployment.
Create an EAR file that contains all the BPEL jar files that must be deployed. For example, create an EAR file with an application name “bpel_deploy” containing a web application named “files”. The names must be conforming to the EAR/WAR structure. In this example the EAR file contains a WAR file that contains the BPEL jar files.
bpel_deploy.ear
meta-inf/application.xml
files.war
files.war
web-inf/web.xml
bpel_ProcessTaks_1.0.jar
bpel_HelloWorld_1.0.jar
bpel_CreditRatingService_1.0.jar
Deploy the EAR file to the OC4J_BPEL_DEPLOY instance of the cluster. The trick is that the EAR file will be deployed to each OC4J instance on each application server! This results that all BPEL jar files are copied to all servers.
The deployment of the EAR file is done via Oracle Enterprise Manager 10g or via Oracle JDeveloper.
After this deployment the BPEL servers must me made aware that BPEL jar files have been deployed. Making the BPEL servers aware of these jar files is done once, only during the initial setup. This is done by replacing the temporary directory for BPEL processes on the server to point to the directory where the BPEL jar files are extracted from the EAR file.
This can be done as follows (UNIX example):
rm ${ORACLE_HOME}/integration/orabpel/domains/default/tmp
ln –s ${ORACLE_HOME}/j2ee/ OC4J_BPEL_DEPLOY /applications/bpel_deploy/files
${ORACLE_HOME}/integration/orabpel/domains/default/tmp
Each time a new EAR file is deployed, with all the BPEL jar files, the BPEL servers are aware that new BPEL processes are ready to apply in the BPEL server environment.
Conclusion
Using the EAR/WAR mechanism of J2EE for deployment of BPEL jar files, results in a more industry standard compliancy. The deployment is less complex to maintain in a high available environment. The risks of faults during deployment are reduced. Deploying the BPEL files is done in the same way as normal J2EE application. Deployment is done via HTTP or HTTPS protocol, making no need of special configuration in the network. Multiple BPEL processes are deployed at once.
