|Oracle® Fusion Middleware Deployment Guide for Oracle Service Bus
11g Release 1 (184.108.40.206.0)
Part Number E15022-02
This document describes how to deploy Oracle Service Bus configurations in a production environment. The following sections introduce key concepts and tasks for deploying Oracle Service Bus in your organization:
This document focuses on the deployment phase of the Oracle Service Bus software lifecycle. For a general overview of Oracle Service Bus, see Oracle Fusion Middleware Concepts and Architecture for Oracle Service Bus.
Oracle Service Bus combines intelligent message brokering with service monitoring and administration to provide a unified software product for implementing and deploying your Service-Oriented Architecture (SOA). When deploying Oracle Service Bus configurations, consider the following goals:
High Availability. A deployment must be sufficiently available and accessible, with provisions for failover in the event of hardware or network failures.
Performance. A deployment must deliver sufficient performance at peak and off-peak loads.
Scalability. A deployment must be capable of handling anticipated increases in loads simply by using additional hardware resources, rather than requiring code changes.
Security. A deployment must sufficiently protect data from unauthorized access or tampering.
You can achieve these goals and others with every Oracle Service Bus configuration.
The term topology refers to a particular configuration of servers, clusters, applications, products in a domain, and where applications and products are deployed. The term Oracle Service Bus deployment topology refers to which servers/clusters the Oracle Service Bus product is deployed on.
Oracle Service Bus supports different deployment topologies, including coexistence with non-Oracle Service Bus servers/clusters in a domain. Following are the supported deployment topologies for Oracle Service Bus:
Admin-only topology – In this topology, Oracle Service Bus is deployed on only the admin server.
Admin + managed server topology – In this topology, Oracle Service Bus is deployed on the admin server and one non-clustered (stand-alone) managed server. Management features are deployed on the admin server, and run-time features are deployed on the managed server.
Cluster topology – In this topology, Oracle Service Bus is deployed on the admin server and one cluster. Management features are deployed on the admin server, and run-time features are deployed on the cluster. Only one Oracle Service Bus cluster is allowed in a domain.
The first two topologies, Admin-only and Admin + managed server, are sometimes referred to as “non-clustered" Oracle Service Bus topologies.
Non-Oracle Service Bus servers/clusters can also coexist in an Oracle Service Bus deployment topology. You can create a domain using one of the Oracle Service Bus deployment topologies and create as many stand-alone non-Oracle Service Bus managed servers or clusters as you wish. These non-Oracle Service Bus servers/clusters can contain other Oracle products or user applications.
Oracle Service Bus can also be co-located with other Oracle products, with restrictions. Co-location means two products are deployed on the same servers/clusters. Currently Oracle Service Bus can be co-located with Oracle SOA Suite, though only in the Admin + managed server topology.
You create a particular Oracle Service Bus topology by applying an Oracle Service Bus domain extension template using the Oracle Fusion Middleware Configuration Wizard user interface or scripts. The use of domain extension templates automates most of the deployment tasks and greatly simplifies domain creation.
Oracle Service Bus provides two domain extension templates:
Oracle Service Bus – This template lets you create all Oracle Service Bus deployment topologies.
Oracle Service Bus for developers – This template is provided as a more convenient way of creating an Admin-only Oracle Service Bus topology; for example, in a development environment.
For information on creating Oracle Service Bus domains with the Oracle Fusion Middleware Configuration Wizard, including co-location with Oracle SOA Suite, see "Installing and Configuring Oracle Service Bus 11g" in the Oracle Fusion Middleware Installation Guide for Oracle Service Bus.
Deploying Oracle Service Bus may require completing some or all of the following tasks:
Define the goals for your Oracle Service Bus deployment, as described in Section 1.1, "Deployment Goals."
Create your deployment topology, as described in Chapter 1, "Oracle Service Bus Deployment Topology."
Deploy your Oracle Service Bus configuration, as described throughout this guide.
Set up security for your Oracle Service Bus deployment as described in "Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.
To deploy an integrated solution successfully, a deployment team must include people who perform the following roles:
One person can assume multiple roles, and all roles are not equally relevant in all deployment scenarios. A successful deployment, however, requires input by people in each role.
Deployment specialists coordinate the deployment effort. They are knowledgeable about the features of the Oracle Service Bus product. They provide expertise in designing the deployment topology for an ESB solution, based on their knowledge of how to configure various Oracle Service Bus features on one or more servers. Deployment specialists have experience in the following areas:
Resource requirements analysis
Deployment topology design
Oracle WebLogic Server administrators provide in-depth technical and operational knowledge about Oracle WebLogic Server deployments in an organization. They have experience and expertise in the following areas:
Hardware and platform knowledge
Managing all aspects of a Oracle WebLogic Server deployment, including installation, configuration, monitoring, security, performance tuning, troubleshooting, and other administrative tasks.
Database administrators provide in-depth technical and operational knowledge about database systems deployed in an organization. They have experience and expertise in the following areas:
Hardware and platform knowledge
Managing all aspects of a relational database (RDBMS), including installation, configuration, monitoring, security, performance tuning, troubleshooting, and other administrative tasks
This section provides an overview of resources that can be modified at deployment time. The term resource is used in this document to refer to technical assets in general, except in discussions of security where it is used to refer only to Oracle WebLogic Server entities that can be protected from unauthorized access using security roles and security policies.
The key resources that may be modified at deployment time are:
This section provides general information about Oracle WebLogic Server resources that are most relevant to the deployment of an Oracle Service Bus solution. You can configure these resources from the Oracle WebLogic Server Administration Console or through J2EE and WebLogic resource descriptors.
Oracle WebLogic Server provides many configuration options and tunable settings for deploying Oracle Service Bus solutions in any supported environment. The configurable Oracle WebLogic Server features that are most relevant to Oracle Service Bus deployments are:
A cluster is a group of servers that can be managed as a single unit. Clustering provides a deployment platform that is more scalable than a single server. To increase workload capacity, you can run Oracle WebLogic Server on a cluster. For more information about clustering, see Chapter 3, "Understanding Oracle Service Bus Clusters."
The WebLogic Java Message Service (JMS) enables Java applications sharing a messaging system to exchange (create, send, and receive) messages. WebLogic JMS is based on Java Message Service Specification version 1.0.2 at
JMS servers can be clustered and connection factories can be deployed on multiple instances of Oracle WebLogic Server. For more information about WebLogic JMS, see the following topics:
The number of EJBs in an Oracle Service Bus deployment affects system throughput. You can tune the number of EJBs in the system through either the EJB pool or the EJB cache, depending on the type of EJB. The following table describes types of EJBs and their associated tunable parameter.
Table 1-1 Parameters for Tuning EJBs
|EJB Type||Tunable Parameter Name||Tunable Parameter Description|
The maximum number of listeners that pull work from a queue.
Stateless Session Beans
The maximum number of beans available for work requests.
Stateful Session Beans and Entity Beans
For more information about controlling throughput, see "Using the WebLogic Persistent Store" in Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server.
Java Database Connectivity (JDBC) enables Java applications to access data stored in DBMS. To reduce the overhead associated with establishing database connections, WebLogic JDBC provides ready-to-use connection pools.
JDBC connection pools are used to optimize DBMS connections. If you are using the Oracle Service Bus JMS Reporting Provider, you can tune Oracle Service Bus performance by configuring the size of JDBC connection pools. A setting that is too low may result in delays while Oracle Service Bus waits for connections to become available. A setting that is too high may result in slower DBMS performance.
For more information about WebLogic JDBC connection pools, see:
"How Connection Pools Enhance Performance" under "Performance Tuning Your JDBC Application" in Oracle Fusion Middleware Programming JDBC for Oracle WebLogic Server.
"Connection Pool Features" under "Configuring JDBC Data Sources" in Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server.
The execution thread pool controls the number of threads that can execute concurrently on Oracle WebLogic Server. A setting that is too low may result in sequential processing and possible deadlocks. A setting that is too high may result in excessive memory consumption, and may cause thrashing.
The number of execute threads also determines the number of threads that read incoming socket messages (socket-reader threads). This number is, by default, one-third of the number of execute threads. A number that is too low can result in contention for threads to read sockets and can sometimes lead to a deadlock.
Set the execution thread pool high enough to run all candidate threads, but not so high that performance is hampered due to excessive context switching in the system. Monitor your running system to empirically determine the best value for the execution thread pool.
Note:Most production applications require an execution thread count greater than the default value. A thread count of 50 is a commonly used value. Be sure to adjust your JDBC connection pool to match your thread count value.
The WebLogic J2EE Connector Architecture (JCA) integrates the J2EE Platform with one or more heterogeneous Enterprise Information Systems (EIS). The WebLogic JCA is based on the J2EE Connector Specification, Version 1.0, from Sun Microsystems, Inc.
For information about the WebLogic J2EE-CA, see "J2EE Connector Architecture" in Oracle Fusion Middleware Programming Resource Adapters for Oracle WebLogic Server.
Oracle Service Bus configuration resources contain environment-specific settings that you will want to change or tune when deploying the configuration to a new domain. The following sections describe the resources that you may need to reconfigure after deploying a configuration.
Business services are Oracle Service Bus definitions of the enterprise information services with which you want to exchange messages. Business services in a production environment could specify multiple endpoints (URLs) for load balancing purposes and high availability. For information on how to add endpoints to a business service, see "Editing Business Service Configurations" the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus. For information on how to update the value of existing endpoints, see "Finding and Replacing Environment Values" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Proxy services are Oracle Service Bus definitions of intermediary Web services that Oracle Service Bus implements locally on Oracle WebLogic Server. While the majority of the metadata that defines a proxy service can be deployed without change in a new environment, there is some information you may need to update:
Proxy service message flows route messages to named destinations (business services, other proxy services, and so on). Message routing definitions may need to be updated in a new environment.
Definitions of proxy services for File, FTP, and Email message types must specify a single managed server for deployment of polling runtime components in a cluster. The list of managed servers appears in the Oracle Service Bus Console only for clustered Oracle Service Bus domains.
Proxy service definitions can include directory names that may need to be updated for a new environment. For information on how to configure this resource appropriately for your environment, see "Finding and Replacing Environment Values" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Proxy service definitions include references to other Oracle Service Bus resources. It is important to verify the validity of these references in a new environment.
JMS queues and connection factories in the proxy service URL may need to be updated.
Each proxy service relies on an instance of Oracle WebLogic Server Work Manager for its dispatch policy. You can tune the Work Manager instance to meet the requirements of your production environment. For more information, see "Using Work Manager to Optimize Scheduled Work" in Oracle Fusion Middleware Configuring Server Environments for Oracle WebLogic Server.
For more information about proxy services, see "Proxy Services: Creating and Managing" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Oracle Service Bus uses WSDL (Web Service Definition Language) to describe proxy services and business services. WSDL is used to describe what a Web service can do, where it resides, and how to invoke it.
You can base the definition of proxy services and business services on existing WSDL files, and complete configuring the service using the Oracle Service Bus Console. WSDL files used as the basis for defining services are stored as Oracle Service Bus resources. These resources are unlikely to require updating when deployed to a new environment, because Oracle Service Bus does not use the URLs in these WSDL files at run time.
Note:Oracle Service Bus creates a new WSDL file for each HTTP proxy service. You can view the contents of this WSDL file by appending
?wsdlto the endpoint for the service. For example, when running the Oracle Service Bus Examples Server (Start > All Programs > Oracle Service Bus > Examples > Start Examples Server), you can view the WSDL for the loangateway2 proxy service at http://localhost:7021/crejws_basic_ejb/loangateway2?wsdl.
A schema is a document that defines valid content for an XML document. Schemas are used to add XML information to messages exchanged in Oracle Service Bus. These resources are unlikely to require updating when deployed to a new environment.
Oracle Service Bus uses service accounts to provide authentication when connecting to a service or server. For information about using this resource appropriately in your production environment, see "Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.
Oracle Service Bus uses service key providers to supply credential-level validation to proxy services. The following types of security are available:
SSL client authentication
Web services security X509 token
For information about how to configure this resource appropriately for your environment, see "Service Key Providers" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Oracle Service Bus uses Web Service Policies (WS-Policies) to associate Web service security policy with proxy services and business services. For information about how to configure this resource appropriately for your production environment, see "Security" in the Oracle Fusion Middleware Developer's Guide for Oracle Service Bus.
These resources are unlikely to require updating when deployed to a new environment.
Transformation maps describe the mapping between two data types. Oracle Service Bus supports data mapping using either XQuery or the eXtensible Stylesheet Language Transformation (XSLT) standard. These resources are unlikely to require updating when deployed to a new environment.
Message Format Language (MFL) is an Oracle proprietary language used to define rules to transform formatted binary data into XML data. MFL documents are unlikely to require updating when deployed to a new environment.
JARs (Java ARchive) are zipped files that contain a set of Java classes. They are used to store compiled Java classes and associated metadata that can constitute a program. JARs act as callable program libraries for Java code elements (so that a single compilation link provides access to multiple elements, rather than requiring bindings for each element individually). JARs are unlikely to require updating when deployed to a new environment.
An Alert Destination resource captures a list of recipients that can receive alert notifications from the Oracle Service Bus. In typical system monitoring contexts, alerts generated by Oracle Service Bus bear significance to a finite set of users. In Oracle Service Bus, each Alert Destination resource may be configured to include a set of recipients according to a given context. Alert Destinations are used by Alert actions configured in the message flow, and also by SLA alert rules. An Alert destination could include one or more of the following types of destinations: Console, Reporting Data stream, SNMP trap, Alert log, E-mail, JMS queue, or JMS topic. In the case of E-mail and JMS destinations, a destination resource could include a list of E-mail addresses or JMS URIs, respectively. Alert Destinations are unlikely to require updating when deployed to a new environment.
A UDDI Registry resource is a global resource that stores information about UDDI Registries used by Oracle Service Bus. After the UDDI Registry resource is configured, you can then publish Oracle Service Bus proxy services to the associated registry, or import business services from the registry to be used by an Oracle Service Bus proxy service. You must be in an active session to configure the UDDI registry resource. UDDI Registry resources must be updated or reconfigured when deployed to a new environment. For more information on updating UDDI Registry resources during deployment, see Section 220.127.116.11, "Best Practices to Follow When Migrating Global Resources."
JNDI Provider resources are definitions of JNDI providers that describe the URL (or list of URLs in the case of clustered deployments) of the JNDI providers used by Oracle Service Bus. They are global resources and can be re-used across projects with an Oracle Service Bus domain. If the JNDI provider is secured, then the JNDI Provider resource description also carries a user name and password to gain access. JNDI Provider resources must be updated or reconfigured when deployed to a new environment. For more information on updating JNDI Provider resources during deployment, see Section 18.104.22.168, "Best Practices to Follow When Migrating Global Resources."
SMTP Server resources are definitions of SMTP Servers that describe the URL and port for the SMTP Servers used by the Oracle Service Bus. They are global resources and can be re-used across projects with an Oracle Service Bus domain. If the SMTP Server is secured, then the SMTP Server resource description also carries a user name and password to gain access. SMTP Server resources are used while configuring Alert Destination resources and E-mail transport-based Business Services. SMTP Server resources must be updated or reconfigured when deployed to a new environment. For more information on updating SMTP Server resources during deployment, see Section 22.214.171.124, "Best Practices to Follow When Migrating Global Resources."
Global resources include the UDDI Registry, JNDI Provider, and SMTP Server resources. These resources typically have different values in testing environments from those that will be used in staging or production environments. When you migrate a deployment from a test environment to a production environment, use one of the following methods:
Create new global resources on the production domain with the same names as in the test environment. Alternatively, import these resources directly from the test environment for the first time, and then customize them (rather than spend time creating them manually).
When exporting artifacts from the test environment, exclude the global resources. Then simply import the
config.jar file. If there are any resources in the
config.jar file that references Alert Destinations, JNDI providers, or SMTP providers, these references will simply snap into place when the import is complete.
Alternatively, export all the artifacts (including the global resources), but exclude the global resources when importing the
Oracle Service Bus relies on database resources for storing message-reporting data by the JMS Reporting Provider. Database performance is a factor in overall Oracle Service Bus performance.
For additional information on tuning your database, see your database vendor's documentation.
Hardware, operating system, and network resources play a crucial role in Oracle Service Bus performance. Deployments must comply with the hardware and software requirements described in the "Oracle Fusion Middleware Supported System Configurations" at