Oracle SOA Suite reference architecture

The following reference architecture shows how you can deploy Oracle SOA Suite 12c on AWS.

High-level architecture of Oracle SOA Suite 12c on AWS

This reference architecture includes a separate WebLogic domain for each component of Oracle SOA Suite (Oracle SOA, OSB, Oracle BPM, Oracle BAM, and Oracle ADF). Each WebLogic domain has one Administrative Server and multiple Managed Servers grouped into a WebLogic Server Cluster. The SOA metadata repository (MDS) is deployed on Amazon Relational Database Service (Amazon RDS). Amazon EFS is used for shared storage.

Traffic distribution

Amazon Route 53 domain name system (DNS) directs users to the application deployed on Oracle SOA Suite. Elastic Load Balancing (ELB) distributes incoming requests across the Oracle HTTP Servers and the WebLogic Managed Servers (for T3 traffic). The Oracle HTTP Server (OHS) along with the WebLogic Server Plugin serves as the reverse proxy routing the traffic to the respective WebLogic Managed Server instance. The WebLogic Managed Server instances host the various components of Oracle SOA Suite.

The Application Load Balancer load balances HTTP(S) traffic and the Network Load Balancer load balances T3 traffic.

Java Message Service (JMS) integration and T3 load balancing

Remote Method Invocation (RMI) communications in the WebLogic Server use the T3 protocol to transport data between WebLogic Servers and other Java programs, including clients and other WebLogic Server instances. When deploying on AWS, you can use a Network Load Balancer for load balancing T3 requests. WebLogic Server clients that use RMI can interoperate with a load balancer by tunneling T3 over HTTP/HTTPS or using T3 directly with the load balancer. Refer to WebLogic RMI Integration with Load Balancers on the Oracle Help Center for more information.

Storage

If you use file-based persistence, you must have storage for the Oracle WebLogic Server product binaries, common files and scripts, domain configuration files, logs, and persistence stores for Java Message Service (JMS) and Java Transaction API (JTA).

You can either use shared storage or Amazon Elastic Block Store (Amazon EBS) volumes to store these files.

Shared storage

Using Oracle Fusion Middleware, you can configure multiple WebLogic Server domains from a single Oracle home. This configuration allows you to install the Oracle home in a single location on a shared volume and reuse the Oracle home for multiple host installations.

Amazon EFS provides a simple, scalable, fully-managed elastic network file system (NFS). Amazon EFS can store the artifacts for Oracle Fusion Middleware, including Oracle home, Domain Home, Application Home, JTA Transaction Logs, and JMS Stores for persisting the JMS messages.

The reference architecture uses Amazon EFS for shared storage. The Oracle WebLogic product binaries, common files and scripts, domain configuration files, and logs are stored in Amazon EFS, which includes the commons, domains, middleware, and logs file systems.

Amazon EFS has two throughput modes for your file system: Bursting Throughput and Provisioned Throughput. With Bursting Throughput mode, throughput on Amazon EFS scales as your file system grows. With Provisioned Throughput mode, you can instantly provision the throughput of your file system in MiB/s, independent of the amount of data stored. For better performance, we recommend you select Provisioned Throughput mode while using Amazon EFS. With Provisioned Throughput mode, you can provision up to 1024 MiB/s of throughput for your file system. You can change the file system throughput in Provisioned Throughput mode at any time after you create the file system.

We recommend mounting the Amazon EFS on Amazon EC2 with a DNS name and the recommended NFS mount options. For more information, refer to Mounting on Amazon EC2 with a DNS name and Recommended NFS mount options.

High availability

The Managed Servers for each domain are grouped into a WebLogic Server Cluster that spans two Availability Zones (AZs). Use Availability Zones to operate production applications and databases that are more highly available, fault tolerant, and scalable than is possible from a single data center. In the unlikely event of failure of one AZ, user requests are routed to your application instances in the second zone. This ensures that your application continues to remain available at all times.

You can add and remove Oracle HTTP Server (OHS) instances from your load balancer as your needs change, either manually or with Amazon EC2 Auto Scaling, without disrupting the overall flow of information. ELB ensures that only healthy instances receive traffic by detecting unhealthy instances and rerouting traffic across the remaining healthy instances. If an instance fails, ELB automatically reroutes the traffic to the remaining running instances. If a failed instance is restored, ELB restores the traffic to that instance.

Oracle Metadata Services (MDS) Repository database contains the metadata for Oracle Fusion Middleware components, such as the Oracle Application Developer Framework. The MDS is hosted on Amazon RDS for Oracle. Amazon RDS for Oracle makes it easy to use replication to enhance availability and reliability for production workloads. Using the Multi-AZ deployment option, you can run MDS with high-availability and a built-in automated failover from your primary database to a synchronously-replicated secondary database in case of a failure. Since the endpoint for your database instance remains the same after a failover, applications can resume database operations as soon as the failover is complete without the need for manual administrative intervention. You can run Amazon RDS for Oracle under two different licensing models: License Included or Bring-Your-Own-License (BYOL). In the License Included service model, you do not need to purchase Oracle licenses separately; the Oracle Database software has been licensed by AWS.

Amazon EFS is designed to be highly available and durable. Your data in Amazon EFS is redundantly stored across multiple AZs, which means that your data is available in the unlikely event of an AZ failure.

State management

For the stateful components of Oracle SOA Suite such as Oracle BAM web services, you can configure Oracle WebLogic Server to replicate the HTTP session state in memory to another Managed Server in the Oracle WebLogic Server Cluster. Oracle WebLogic Server uses a cookie to track the location of the Managed Servers hosting the primary and the replica copies of the session state. If the Managed Server hosting the primary copy of the session state fails, Oracle WebLogic Server can retrieve the HTTP session state from the replica. For more information about HTTP session state replication, refer to Oracle WebLogic Server 12c: Managing HTTP Sessions in a Cluster.

High availability and state management of Oracle SOA Suite 12c components

The following table lists the various Oracle SOA Suite 12c components and the strategies used for failure protection, high availability, and state management.

Table 1: High availability and state management of Oracle SOA Suite 12c components

Domain	Oracle SOA Suite component	High availability	State management
Oracle SOA	SOA Service Infrastructure	Active-Active	Stateless
	SOA Admin	Singleton (Active- Passive)	Stateless
	SOA BPEL	Active-Active	Stateless
	BPM Suite	Active-Active
	B2B UI	Active-Active	Stateful (HTTP Session)
	Mediator	Active-Active	Stateless
	Human workflow	Active-Active	Stateless
	Oracle WSM	Active-Active	Stateless
	Oracle UMS	Active-Active
	Oracle JCA Adapters	Active-Active	Stateless
Oracle BAM	Web Apps	Active-Active	BAM web applications are stateful and need session replication for high availability.
	BAM Server	Singleton Active-Passive	Stateless
OSB		Active-Active

Failure scenarios

The following section describes how failure scenarios are addressed for the various components in the architecture.

Oracle HTTP server failure

You can also configure an Auto Scaling group with EC2 instances running Oracle HTTP Server in multiple AZs. Amazon EC2 Auto Scaling spins up new instances in case of failure of the Oracle HTTP Server.

If the underlying host for the OHS experiences a failure, you can also configure automatic recovery for Amazon EC2 instances to recover the failed server instances. When using automatic recovery for Amazon EC2 instances, several system status checks monitor the instance and the other components required for your instance. Among other things, the system status checks monitor for loss of network connectivity, loss of system power, software issues on the physical host, and hardware issues on the physical host. If a system status check of the underlying hardware fails, the instance is rebooted (on new hardware if necessary), but it retains its instance ID, IP address, Elastic IP addresses, EBS volume attachments, and other configuration details.

WebLogic Server node failure

Because SOA components run in an Oracle WebLogic Server Cluster, the components remain highly available as long as the components are running in Active-Active mode and deployed across multiple WebLogic Managed Servers.

WebLogic managed server failure

In the event of a Managed Server failure, Oracle WebLogic Node Manager restarts the WebLogic Managed Server.

Administration server failure

The Administration Server is used to configure, manage, and monitor the resources in the domain, including the Managed Server instances. Because the failure of the Administration Server does not affect the functioning of the Managed Servers in the domain, the Managed Servers continue to run, and your application is still available.

However, if the Administration Server fails, the WebLogic Server Administration Console is unavailable and you cannot make changes to the domain configuration.

If the underlying host for the Administration Server experiences a failure, you can use the automatic recovery for Amazon EC2 instances to recover the failed server instances.

Another option is to put the Administration Server instances in an Amazon EC2 Auto Scaling group that spans multiple AZs, and set the minimum and maximum size of the group to one. Automatic scaling ensures that an instance of the Administration Server is running in the selected AZs. This configuration ensures high availability of the Administration Server if an AZ failure occurs.

MDS database failure

The database instance failure can be handled by using Amazon RDS for Oracle with active-standby setup using Multi-AZ deployment. Refer to Multi-AZ deployments for high availability for more details on Multi-AZ deployments.

Considerations for deploying Oracle SOA Suite 12c on AWS

The following are some points to consider when deploying Oracle SOA Suite 12c on AWS.

• Configure Oracle WebLogic Server in unicast mode and make sure to allow the port number in the AWS Security Group configuration.

• Make sure to set the appropriate value of the Java property networkaddress.cache.ttl so that appropriate caching policy is set in the JVM for successful DNS lookups. See Setting the JVM TTL for DNS Name Lookups in Multi-AZ deployments for high availability for more information.

• Allow appropriate inbound and outbound traffic in the application security groups including the ports configured for T3, HTTP(S), Internal WebLogic Server Cluster intercommunication, and Internal Coherence cluster communication.

• If SOA nodes are not synchronizing after deploying the BPEL process, tune the Linux kernel parameters net.core.rmem_max and net.core.wmem_max. Refer to the Oracle Support document Nodes Not Syncing In 12C (Doc ID 2315273.1) for more information.