|
|
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 Service Bus Concepts and Architecture.
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:
You can achieve these goals and others with every Oracle Service Bus configuration.
Deploying Oracle Service Bus may require completing some or all of the following tasks:
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:
WebLogic Server administrators provide in-depth technical and operational knowledge about WebLogic Server deployments in an organization. They have experience and expertise in the following areas:
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:
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 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 WebLogic Server resources that are most relevant to the deployment of an Oracle Service Bus solution. You can configure these resources from the WebLogic Server Administration Console or through J2EE and WebLogic resource descriptors.
WebLogic Server provides many configuration options and tunable settings for deploying Oracle Service Bus solutions in any supported environment. The configurable 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 WebLogic Server on a cluster. For more information about clustering, see 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 from Sun Microsystems, Inc.
JMS servers can be clustered and connection factories can be deployed on multiple instances of 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.
For more information about controlling throughput, see “Server Self-Tuning for Production Environments” under New and Changed Features in WebLogic Server Environments in Designing and Configuring WebLogic Server Environments.
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:
The execution thread pool controls the number of threads that can execute concurrently on 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. |
For more information about controlling throughput, see “Server Self-Tuning for Production Environments” under New and Changed Features in WebLogic Server Environments in Designing and Configuring WebLogic Server Environments.
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 Programming WebLogic Resource Adapters.
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 “Viewing and Changing Business Services” under Business Services in Using the Oracle Service Bus Console. For information on how to update the value of existing endpoints, see “Finding and Replacing Environment Values” in System Administration in Using the Oracle Service Bus Console.
Proxy services are Oracle Service Bus definitions of intermediary Web services that Oracle Service Bus implements locally on 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:
For more information about proxy services, see Proxy Services in Using the Oracle Service Bus Console.
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 ?wsdl to the endpoint for the service. For example, when running the Oracle Service Bus Examples Server (Start ProgramsOracle ProductsExamplesOracle Service BusOracle Service BusStart 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 Oracle Service Bus Security Guide.
Oracle Service Bus uses proxy service providers to supply credential-level validation to proxy services. The following types of security are available:
For information about how to configure this resource appropriately for your environment, see Proxy Service Providers in Using the Oracle Service Bus Console.
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 Oracle Service Bus Security Guide.
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, 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 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 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 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:
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.config.jar file . 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 information about database tuning requirements associated with Oracle Service Bus applications, see Oracle Service Bus Release Notes.
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 Oracle Service Bus Release Notes.
|