Grid Orchestrator: BPEL Engine
Oracle BPEL Process Manager is a natural infrastructure fit for a utility computing-based SOA. Typically, BPEL engines are used to orchestrate and execute business processes. However, in our setup we deployed a BPEL process for SOA traffic management such as failover, switching, load balancing and parallel processing across the Oracle Application Server instances in the Amazon EC2 cloud. While there are lots of ways to handle traffic management, many of which are more appropriate than BPEL, this was an interesting architecture because it demonstrated the dynamic capabilities – here including dynamic orchestration of services, provisioning and even run-time traffic across the instances on the cloud.
Let’s examine a few of these traffic management functions across multiple copies of a web service. Figure 2 shows a simple BPEL process modeled using Oracle JDeveloper.
Failover: To see how Failover can be accomplished, consider Figure 2 with an Invoke_OracleAppServer_on_Amazon_EC2 task in the BPEL process calling a Partner Link Amazon_EC2 . This Partner Link has a property named location defined with two service endpoint URIs listed:
- http://domu-12-31-34-00-00- 0d .usma2.compute.amazonaws.com:8888/EC2
- http://domu-12-31-34-00-00- e0 .usma2.compute.amazonaws.com:8888/EC2
These endpoints only differ in the URIs and provide identical instances of the web services hosted on Instance #1 and Instance #2 on EC2. The number of instances can be scaled by a single EC2 command the corresponding additional endpoint URIs can be added to the location endpoint URI list. The BPEL engine provides extensive fault handling capabilities including managing runtime exceptions . If the first Amazon EC2 instance URI becomes unavailable because of a network, software or hardware failure, a run-time fault occurs that automatically enables the BPEL engine to retry the second instance URI.
Figure 2: BPEL Flow for Failover across OC4J instances deployed within Amazon EC2
Using such failover techniques adds resilience and reliability to Web services hosted with Amazon EC2. Oracle BPEL Process Manager extends the virtualization capabilities of Amazon EC2 by adding failover across multiple instances of web services deployed in the Amazon Cloud.
Switching: Figure 3 is a process display for switching between two instances of Oracle Application Server deployed in the Amazon Cloud. The switching condition is defined in the case statement and can be based on any input parameter extracted from the client request. For example, a certain class of purchase-order numbers for platinum customers can be targeted towards Amazon 1 whereas others can be sent to Amazon 2 endpoints. Such content-aware switching can align resource costs with preferred customers and provide granular IT asset alignment with revenue.
Switching can be combined with other SOA traffic-management functions such as Failover. For example, Amazon 1 in Figure 3 below can have multiple failover endpoints – as shown in Failover Figure 2. This would ensure that the corporation is paying a premium for providing reliability only for high-value customers by enabling significant redundancy, whereas the low revenue generating customer would be sent to nominally redundant partner links.
Figure 3: BPEL Flow for Switching across App Server Instances in EC2
Additional Traffic Management: A few additional SOA traffic management processes are described below:
Dynamic Scalability: Oracle BPEL Process Manager provides a powerful mechanism called dynamic binding . This enables a BPEL process to decide which endpoint to call at run-time. A BPEL process can start off by invoking the Amazon EC2 SOAP API and calling the DescribeInstance operation. This operation can return a list of all instances running and available to the BPEL process within the Amazon Cloud. Once all the endpoints are known, dynamic binding can be used for failover, switching, load balancing or any other traffic management algorithm. This is called a "Parameterized Launch," which lets you pass configuration data at launch time and you can also "read" Instance Metadata like IP address, DNS, and so on, from the EC2 API.
Concurrent Processing: Oracle BPEL Process Manger provides Parallel Flows to perform multiple tasks at the same time. Selected computationally intensive processes can be deployed within Amazon EC2 and Parallel flows within a BPEL engine can be used to control client interaction with such intensive processes. With flowN activity, any arbitrary number of parallel branches can be invoked dynamically based on the upstream data available. For example, a process can first determine the number of endpoints available through an invoke call to Amazon EC2 DescribeInstance . If an array of say 5 endpoints is returned by Amazon, this data can then be sent to the flowN activity to create 5 branches for simultaneous invocations of the 5 Amazon EC2 instances.
