PK
\Eoa, mimetypeapplication/epub+zipPK \E iTunesMetadata.plistV
Oracle Fusion Middleware SOA Suite provides a complete set of service infrastructure components for designing, deploying, and managing composite applications. Oracle Fusion Middleware SOA Suite enables services to be created, managed, and orchestrated into composite applications and business processes. Composites enable you to easily assemble multiple technology components into one SOA composite application. Oracle Fusion Middleware SOA Suite plugs into heterogeneous IT infrastructures and enables enterprises to incrementally adopt SOA.
This chapter provides a description of Oracle SOA Suite components from a high availability perspective. This chapter also includes sections that outline the single-instance concepts for SOA components that are important for designing a high availability deployment.
This chapter includes the following topics:
Section 5.1, "Introduction to Oracle Fusion Middleware SOA Suite"
Section 5.2, "Oracle SOA Service Infrastructure High Availability"
Section 5.3, "Oracle BPEL Process Manager and High Availability Concepts"
Section 5.4, "Oracle BPM Suite and High Availability Concepts"
Section 5.5, "Oracle Mediator and High Availability Concepts"
Section 5.6, "Oracle Human Workflow and High Availability Concepts"
Section 5.8, "Oracle Web Services Manager and High Availability Concepts"
Section 5.9, "Oracle User Messaging Service and High Availability Concepts"
Section 5.10, "Oracle JCA Adapters and High Availability Concepts"
Section 5.11, "Oracle Business Activity Monitoring and High Availability Concepts"
Section 5.12, "Oracle Service Bus and High Availability Concepts"
Section 5.15, "Configuring High Availability for Oracle BAM"
As illustrated in Figure 5-1, Oracle SOA Suite provides a comprehensive suite of products for developing, securing, and monitoring service-oriented architecture (SOA). Oracle SOA Suite 11g provides a unified runtime based on the SCA standard. The runtime consists of Service Engines (BPEL Process Manager, Human Workflow, Mediator, Rules) and Binding Components (JCA Adapters, B2B) that are managed and inter-connected by a common Service Infrastructure. Service infrastructure also provides common services such as lifecycle management and deployment.
A SOA composite application is the basic unit of deployment to the SOA runtime. Service components (BPEL process, business rule, human task, and Mediator routing rule) are the building blocks of a SOA composite. Components are targeted to service engines during deployment while services and references are enabled using the binding components. At runtime, messages are received by the binding component and are then routed to the appropriate service engine(s) by the Service Infrastructure.
The SOA runtime runs within the context of an application server such as the Oracle WebLogic Application Server. It leverages the underlying application server capabilities for load balancing and high availability.
This guide provides high availability information for the following SOA Suite components:
Oracle Service Infrastructure
Oracle BPEL Process Manager
Oracle BPM Suite
Oracle Mediator
Oracle Human Workflow
Oracle JCA Adapters
Oracle B2B
Oracle Web Services Manager
Oracle User Messaging Service
Oracle Business Activity Monitoring
The Oracle SOA Service Infrastructure is a Java EE application that provides the foundation services for running Oracle Fusion Middleware SOA Suite. This Java EE application is a runtime engine that is automatically deployed when Oracle Fusion Middleware SOA Suite is installed. You deploy composites (the basic artifacts in a Software Component Architecture) to the Oracle SOA Infrastructure and it provides the required services for the composites to run. Oracle SOA Infrastructure provides deployment, wiring, and thread management services for the composites. These services sustain the composite's lifecycle and runtime operations.
The information in this section guides you through the issues and considerations necessary for designing a SOA Service Infrastructure high availability cluster. Later sections of this chapter describe the same issues and considerations for the following SOA Service Infrastructure-related components.
Oracle BPEL Process Manager (Oracle BPEL PM)
Oracle BPM Suite
Oracle Mediator
Oracle JCA Adapters
Oracle Human Workflow
Oracle B2B
Oracle Web Services Management and Security (Oracle WMS)
Oracle User Messaging Service
Oracle Business Activity Monitoring
Backup and Recovery Considerations
For general information on backing up SOA Service Infrastructure files, see the "Introducing Backup and Recovery" and "Backing Up Your Environment" chapters of the Oracle Fusion Middleware Administrator's Guide.
The Oracle SOA Service Infrastructure is a Java EE-compliant application running on Oracle WebLogic Server. It provides the required services for running composites. A composite is basic unit of deployment for Service Component Architectures (SCA). The SCA Assembly Model is made up of a series of artifacts, which are defined by elements contained in XML files.
Composites are software packages made up of components, wires, services and references. For example, an Oracle BPEL process is a component, an inbound adapter is a service, an outbound adapter is a reference. Wires provide connections between service engines.
Individual components are targeted to specific service engines, such as Oracle BPEL PM, or Oracle Mediator. Oracle SOA Service Infrastructure connects to a SOA database to maintain composite state, and to the SOA Oracle Metadata Services (MDS) Repository to maintain composite metadata, such deployments, and version tracking. These two databases may be the same physical database, but the schemas used for each purpose are different. SOA infra provides a servlet for remote deployment of composites. The metadata and artifacts for remote deployments are also stored in the MDS repository. For more information on the MDS repository, see Section 4.1.2.1, "Configuring Multi Data Sources for MDS Repositories."
The Oracle SOA Service Infrastructure application is also responsible for targeting the individual components to their specific engine and for instantiating these composites when requests reach the SOA system. After targeting and instantiation, the Oracle SOA Service Infrastructure controls thread and resource assignment. This happens in the JVM, where the composite runs.
As illustrated in Figure 5-3, the Oracle SOA Service Infrastructure integrates SOA composite applications with UDDI registries. UDDI registries provide a standards-based foundation for locating published services, invoking services, and managing service metadata. The Oracle SOA Service Infrastructure is also the central hub used by the service engines to deliver messages through Oracle User Messaging Service infrastructure to communication channels, such as email and voice.
SOA Service Infrastructure provides the required services that sustain the different pieces in a Service Component Architecture, and allows the communication between them. For more details of the different components in an SCA system, refer to the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.
Oracle SOA Service Infrastructure Services are contained in the soa-infra-wls.ear
file. None of the services provided by the Oracle SOA Service Infrastructure system are singletons, therefore, the Oracle SOA Service Infrastructure can run in full active-active mode. The SOA Service Infrastructure Java EE application contains a Web module that provides browsing of the deployed composites and links to the test pages for these composites. This Web module uses /soa-infra
as the associated URL context. This Web module is stateless and does not have any specific session replication requirements.
Other modules in the Oracle SOA Service Infrastructure application provide task control for process instantiation and process tracking, and client services for accessing User Messaging System (UMS).
A task service controls instantiating and tracking processes asynchronously. In addition, there are multiple EJBs used by the Oracle SOA Service Infrastructure system. However, all of the EJBs are stateless, and there are no requirements for stateful session bean replication in an Oracle SOA cluster. The processing of transactions by these EJBs relies on Oracle WebLogic Server transaction control service. Configure the appropriate transaction stores as recommended in the basic Oracle WebLogic Server guidelines to guarantee recovery across failures in Oracle WebLogic Server container.
An Oracle SOA composite consists of the following:
Components such as a BPEL process, Human Workflow task, a Mediator routing rule or Business Rules.
Services and References for connecting Oracle SOA composite applications to external services, applications, and technologies.
These components are assembled together into an Oracle SOA composite application. This application is a single unit of deployment that simplifies the management and lifecycle of Oracle SOA applications.
When the Oracle SOA Service Infrastructure application starts, it initializes the different service engines and loads the present composites from the MDS repository. It targets the individual components to their specific engines. Once the composite is loaded, the system is available to receive requests. At runtime, the Oracle SOA Service Infrastructure manages all communication across service components. These calls between service engines are in-process calls. The following diagram reflects the sequence for the Oracle SOA Service Infrastructure startup and processing of work:
As described in the previous sections, the Oracle SOA Service Infrastructure system depends on the following components:
Instance manager service depends on the runtime SOA database schema (soa-infra).
Composite metadata is stored in the MDS database schema which acts as a repository.
In a clustered environment, the deployment coordinator service depends on the underlying Coherence cluster for signal propagation.
All three of these components must be available for the Oracle SOA Service Infrastructure to start and run properly.
The Oracle SOA Service Infrastructure application is started by default whenever any Oracle WebLogic Managed Server to which the Oracle SOA Service Infrastructure has been deployed is started. Normally, you should not need to stop the Oracle SOA Service Infrastructure or any of its components by themselves. Some operations may require Oracle WebLogic Managed Server where the SOA Service Infrastructure runs to be rebooted. Only some patching scenarios could require stopping the application.
You can use Oracle WebLogic Server Administration Console to verify status and to start and stop Oracle WebLogic Server. You can also use the WebLogic Server WLST command line to control the application. Oracle Enterprise Manager Fusion Middleware Control also allows multiple operations and configuration of the Oracle SOA Service Infrastructure application as well as monitoring its status. See the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for details on monitoring and controlling the Oracle SOA Service Infrastructure application.
Starting with Oracle Fusion Middleware 11g Release 1 (11.1.1.2), the configuration parameters for Oracle Service Infrastructure are stored in the SOA MDS database. The main controls of the Oracle SOA Service Infrastructure can be configured using Oracle Enterprise Manager Fusion Middleware Control.
The data source JNDI name for process dehydration.
Note: Once the JNDI names are read from this file, the databases used by the system are determined by the data sources that matched those JNDI names in WebLogic Server JDBS resources configuration. |
The server and callback URL
A CallBack URL is the address that asynchronous services specify to be notified of a response to the service they invoked.
Note: If a request to an external or internal asynchronous service originates from SOA, the callback URL is determined using the following in decreasing order of preference:
|
The audit level of information to be collected by the message tracking infrastructure.
Other configuration options at the container level, such as data sources, JTA configuration, and persistent stores, are maintained as part of the WebLogic Server Domain configuration, and are synchronized across a cluster of Oracle WebLogic Servers by the Oracle WebLogic Server core infrastructure.
The operations performed by the Oracle SOA Service Infrastructure and its components are logged by Oracle WebLogic Managed Server where the Oracle SOA Service Infrastructure is running. You can find these logs at the following location:
DOMAIN_HOME
/servers/WLS_ServerName/logs/WLS_ServerName.log
The log files for the different Oracle WebLogic Server managed servers are also available from Oracle WebLogic Server Administration Console. To verify the logs, access Oracle WebLogic Server Administration Console using the following URL: admin_server_host:port/console
. Click Diagnostics-Log Files.
It is also important to verify the output of the Oracle WebLogic Managed Server where the Oracle SOA Service Infrastructure is running. This information is stored at the following location:
DOMAIN_HOME
/servers/WLS_ServerName/logs/WLS_ServerName.out
Additionally, a diagnostic log is produced in the log directory for the managed server. This log's granularity and logging properties can be changed through the domain_dir
/config/fmwconfig/servers/WLS_ServerName/logging.xml
file. The properties in this file can also be modified from Oracle Enterprise Manager Fusion Middleware Control by selecting Farm, SOA, SOA Server. Right-click, and select Logs, and then Log Configuration.
Oracle Enterprise Manager Fusion Middleware Control allows performing selective searches in all the logs in the SOA domain. To do a selective search, access Oracle Fusion Middleware Control and click on Farm-Logs and enter the search criteria that pertain to soa-infra
or deployed composites. See the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for more details on the logs and information reported for a SOA System in Oracle Enterprise Manager Fusion Middleware Control.
Figure 5-6 illustrates a two-node Oracle SOA Service Infrastructure cluster running on two Oracle WebLogic Servers. The Oracle WebLogic Servers are frontended by two Oracle HTTP Server instances on web tier hosts, which receive requests from a load balancer in front of them.
Figure 5-6 illustrates the following main characteristics of this high availability configuration:
The SOA Service Infrastructure runs in Oracle WebLogic Server managed servers that are part of an Oracle WebLogic Server cluster. Oracle WebLogic Server cluster synchronizes the configuration for common artifacts of WebLogic Server cluster that Oracle SOA Service Infrastructure uses such as JTS configuration, data sources, and persistent store definitions.
The Oracle SOA Service Infrastructure uses the front end host and port information configured for the Oracle WebLogic Server cluster as the server and callback URL. You define these settings with Oracle WebLogic Server Administration Console. Select Clusters, SOA_Cluster_Name, HTTP/HTTPS frontend host and then Port. If there is no address for the Oracle WebLogic Server cluster where the Oracle SOA Service Infrastructure is running, the system uses the physical host name as the server and callback URL.
For SOA high availability installations frontended by Oracle HTTP Server, monitoring should be done on the Listen ports of Oracle HTTP Server. This is the case when a deployment uses all components deployed to the SOA Managed Server. A simple HTTP monitor that pings the HTTP/HTTPS port and expects a pre-determined response in turn should suffice. If only a specific SOA component is being used (such as B2B), then a monitor that does a deeper level check all the way to the Managed server can be considered to validate the health of the component in use. Check with your load balancer vendor on setting up the HTTP monitors with your load balancer.
For more information about the server and callback URLs see the Oracle Fusion Middleware Administrator's Guide. Changing the HTTP front end address for a cluster requires a restart of the managed servers that are part of the cluster.
The deployment coordinator is configured and used for deployment and updates of composites. The deployment coordinator sends notifications to deployment coordinator cluster members to retrieve new artifacts from the MDS repository, when they are updated by the group leader. A leader node performs singleton operations for the cluster such as updating the MDS after deployments, or changes are made to the composites.
The Oracle SOA Service Infrastructure system uses the Oracle WebLogic Server cluster name as its key to confirm a deployment coordinator group. If all nodes in a WebLogic Server cluster can communicate (over multicast or unicast) the deployment coordinator cluster is the same as the WebLogic Server cluster in which the SOA Service Infrastructure runs.
The Administration Server runs in Active-Passive mode. Whenever a failure occurs in SOAHOST1, you can restart the Administration Server in SOAHOST2; it uses a virtual IP or virtual hostname as listen address.
For information about configuring virtual IPs for the Administration Server and configuring the Administration Server for high availability, see Chapter 12, "Transforming the Administration Server for Cold Failover Cluster."
Oracle WebLogic Server Whole Server Migration
Although SOA Service Infrastructure can run in full active-active mode, the architecture uses the Oracle WebLogic Server Migration feature to protect some SOA components against failures. This implies that each of the WebLogic Managed Servers in which the SOA Service Infrastructure runs is listening on a Virtual IP that is migrated to another box upon failover. The Administration Server and Enterprise Manager run in AdminServer, not the managed server.
As shown in Figure 5-6, WLS_SOA1 listens on VIP1, and WLS_SOA2 listens on VIP2. Each managed server uses the other node as a failover resource, therefore, the system is configured in a cross manner. In other words, WLS_SOA1 fails over to SOAHOST2, and WLS_SOA2 fails over to SOAHOST1. The appropriate capacity planning must be done to anticipate the scenario where the two SOA managed servers are running on the same node. For more information on Server Migration features, see Chapter 3, "High Availability for WebLogic Server" in this guide.
To resume transactions after a server migration, configure the transaction and JMS stores in a shared storage. In case of failure in one of the server infrastructure instances, other instances can resume transactions and JMS operation by reading the persistent stores from that shared storage.
The Metadata store is configured in an Oracle RAC database to protect from database failures. Similarly, the SOA process state information is also stored in an Oracle RAC database. In this example, both Oracle RAC databases are the same.
About Oracle SOA Service Infrastructure Components
These high availability characteristics apply to most of Oracle SOA components contained in the composite applications deployed across the cluster. For specific two-node high availability characteristics of the individual components, see the specific component sections that follow in this chapter.
This section describes how an Oracle SOA high availability cluster deployment protects components from failure and the expected behavior if component failure occurs.
The WebLogic Server infrastructure protects the SOA Service Infrastructure system from all process failures.
If a WLS_SOAx server crashes, Node Manager attempts to restart it locally. If repeated restarts fail, the WebLogic Server infrastructure attempts to perform a server migration of the WLS_SOAx server to the other node in the cluster. While the failover takes place, the other SOA Service Infrastructure instance becomes the leader for deployments and composite updates and provides the basic services required by the service engines in the system.
Ongoing requests from the HTTP Server time out and new requests are directed to the other WLS_SOAx server. Once the server's restart completes on the other node, Oracle HTTP Server resumes routing any incoming requests to the server. The migrated server reads MDS repository for any updates that might have taken place during restart, and joins the deployment coordinator cluster to listen for new updates. The migrated server also resumes any pending transactions from the transaction logs in shared storage.
In the server migration scenario, the service engines, such as Oracle BPEL PM and Oracle Mediator, are failed over together with the SOA Service Infrastructure. They do not re-issue any requests to the other SOA Service Infrastructure instances by themselves. They resume operations together with the SOA Service Infrastructure once failover is complete.
The Oracle SOA Service Infrastructure application may be down due to failure in accessing resources, errors caused by the deployment coordinator infrastructure, or other issues unrelated to whether the managed server is running. Therefore, Oracle recommends administrators monitoring the soa-infra application for errors caused by the application in the managed server logs. For information about log file locations, see Section 5.2.1.6, "Oracle SOA Service Infrastructure Log File Locations".