|
|
This document describes how to deploy Oracle WebLogic Integration solutions in a production environment. The following sections introduce key concepts and tasks for deploying Oracle WebLogic Integration (WLI) solutions in your organization:
| Note: | This document focuses on the deployment phase of the software lifecycle for WLI applications. For information about the deployment phase of the software lifecycle for WebLogic applications, see Deploying Applications to Oracle WebLogic Server. |
For examples of source and utilities to build, configure, and deploy WLI applications, see WebLogic Integration Sample Code.
| Note: | Code samples and utilities are posted on Oracle Technology Network (OTN) for your convenience. They are not supported by Oracle. |
WLI is a single, unified platform that provides the functionality businesses can use to develop new applications, integrate them with existing systems, streamline business processes, and connect with trading partners.
When deploying WLI solutions, consider the following goals:
Deploying WLI may require that you complete some or all of the following tasks:
For a detailed list of deployment tasks associated with WebLogic applications, see Deploying Applications To Oracle WebLogic Server.
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, but successful deployment requires input from people in each role.
Deployment specialists coordinate the deployment effort. They are knowledgeable about the features of WLI. They provide expertise in designing the deployment topology for an integration solution, based on their knowledge of how to configure various WLI features on one or more servers. Deployment specialists have experience in the following areas:
Oracle WebLogic Server administrators provide in-depth technical and operational knowledge about Oracle WebLogic Server deployments in an organization. They have knowledge of the hardware and platform, and experience 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 in the following areas:
This section provides an overview of resources that can be modified at deployment time:
| Note: | The term resource is used in this document to refer to technical assets in general, except in Using Oracle WebLogic Integration Security, where it is used to refer only to those underlying Oracle WebLogic Server entities that can be protected from unauthorized access using security roles and security policies. |
This section provides general information about Oracle WebLogic Server resources that are most relevant to the deployment of a WLI solution. You can configure these resources from the Oracle WebLogic Server Administration Console or through EJB deployment descriptors.
Oracle WebLogic Server provides many configuration options and tunable settings for deploying WLI solutions in any supported environment. The following sections describe the configurable Oracle WebLogic Server features that are most relevant to WLI deployments:
To increase workload capacity, you can run Oracle WebLogic Server on a cluster: 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.
For more information about clustering, see Understanding Oracle WebLogic Integration Clusters.
The Oracle WebLogic Java Message Service (JMS) enables Java applications sharing a messaging system to exchange (create, send, and receive) messages. WebLogic JMS is based on the 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 Oracle WebLogic Server. In addition, JMS event destinations can be configured to handle workflow notifications and messages, as described in Process Application Resources.
For more information about WebLogic JMS, see the following:
In a WLI deployment, the number of EJBs 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 by configuring EJBs, see Tuning Oracle WebLogic Server EJBs in Oracle WebLogic Server Performance and Tuning.
Java Database Connectivity (JDBC) enables Java applications to access data stored in SQL databases. To reduce the overhead associated with establishing database connections, Oracle WebLogic JDBC provides connection pools that offer ready-to-use pools of connections to a DBMS.
JDBC connection pools are used to optimize DBMS connections. You can tune WLI performance by configuring the size of JDBC connection pools. A setting that is too low results in delays while WLI waits for connections to become available. A setting that is too high results in slower DBMS performance.
For more information about WebLogic JDBC, see Programming WebLogic JDBC.
The execution thread pool controls the number of threads that can execute concurrently on Oracle WebLogic Server. A setting that is too low results in sequential processing and possible deadlocks. A setting that is too high results in excessive memory consumption and may cause thrashing.
The number of execution threads also determines the number of threads that read incoming socket messages (socket-reader threads). This number is, by default, one-third the number of execution threads. A number that is too low can result in contention for threads for reading sockets and can sometimes lead to a deadlock.
Set the execution thread pool high enough so that all candidate threads run, but not so high that performance is hampered due to excessive context switching in the system. Monitor your running system to determine empirically 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 configuring execution thread pools, see Oracle WebLogic Server Performance and Tuning.
The Oracle 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 Programming Oracle WebLogic Server Resource Adapters.
A process application is represented as an EAR file. You compile the EAR file for deployment using the standard procedure for compiling any Oracle Workshop for WebLogic application, see Workshop for WebLogic User’s Guide.
The EAR file consists of multiple web applications and some shared class files. The generated schema files go to the shared class files. Each web application corresponds to a project in the IDE workspace (see Figure 1-1).
Each web application consists of the following items:
The input JMS queues use an optimized, internal format for messages. They are used implicitly by WLI components including process controls, Message Broker, buffered messages, and so on.
| Note: | These input queues are not intended to be used directly by applications. If you are looking for a JMS queue that can be used directly by an application, consider the Workshop SOAP/JMS protocol or the WLI JMS Event Generator. |
| Note: | For more information about the SOAP/JMS protocol, see Workshop for WebLogic User’s Guide. |
| Note: | For more information about the JMS Event Generator, see Event Generators in Using The WebLogic Integration Administration Console. |
This is used for dispatching exception elements in process definition.
Figure 1-2 shows the components in a process web application.
The asynchronous dispatcher has different interactions with stateless and stateful processes. For an illustration of the interaction between the asynchronous dispatcher and a stateless process (see Figure 1-3).
For an illustration of the interaction between the asynchronous dispatcher and a stateful process, see Figure 1-4.
The process control allows messages to be sent directly from one process to another, either through RMI or through JMS using an optimized data format. Normal Oracle WebLogic Server load balancing rules apply when using RMI or JMS. Typically, the message stays on the same server in a cluster due to server affinity of Oracle WebLogic Server load balancing.
An in-memory dispatcher table provides the detailed information needed by the process control to send the message at run time. This dispatcher table is automatically updated when an application is deployed or redeployed.
The behavior of a process call depends on whether it is being used for a synchronous or asynchronous dispatch.
Figure 1-5 shows the behavior of a process control used for a synchronous dispatch.
Figure 1-6 shows the behavior of a process control used for an asynchronous dispatch.
It is also possible for a synchronous client process to interact with an asynchronous process.
| Note: | You can optimize performance of this configuration by creating the following dedicated execution thread pools: |
| Note: | Choose a thread pool size that matches the requirements of your application and tracking level. |
| Note: | If you do not create these pools, threads are consumed from the default thread pool. |
For more information about this configuration, see Building Synchronous and Asynchronous Business Processes in Guide to Building Business Processes.
For implementation examples, see WebLogic Integration Sample Code.
Any time the Message Broker publishes a message through a Message Broker publish control or event generator, the following actions occur:
The Message Broker uses the same JMS asynchronous queue that the process control uses. Once a message is enqueued, it follows the same code path as if it were sent using the process control.
For more information about publishing using the Message Broker control, see Figure 1-7.
WLI has a number of native event generators:
The JMS event generator is packaged as a message-driven bean pool. It can be targeted freely to any number of managed servers in a cluster. It would typically be targeted at either a single managed server (when using a physical JMS destination) or to the cluster (when using distributed destinations).
These event generators poll for events to happen. To do this, each event generator is packaged as a message-driven bean pool and configured with a specific JMS queue. Messages are sent from the event generator to its associated queue with a delivery time of poll-interval in the future. The queue is shared between event generators of the same type (file, email, and so on), and a selector is used to share messages in the queue.
How you target a polling event generator depends on how the JMS server owning the associated queue has been targeted, as shown in Table 1-2.
Because the polling event generators would contend with each other during their polls, they are restricted to being active on a single managed server in a cluster. When an event generator is associated with a migratable queue, it is active only on the single server containing the migratable JMS server, even though the polling event generator is targeted at the cluster.
| Note: | WLI supports polling event generators targeted at a single server. This configuration is, however, not appropriate for applications that require high availability. |
The HTTP event generator is a servlet that takes HTTP requests, checks for the content type, and then publishes the messages to Message Broker channels.
The MQSeries event generator polls for messages on a WebSphere MQ queue and publishes the messages (MQMD headers as metadata along with the message payload) to Message Broker channels. Content filtering, as well as other handling criteria, are specified in the channel rules for the event generator.
Both HTTP and MQSeries event generators can be targeted at a single managed server or cluster.
The RDBMS event generator polls the database table to check for added, deleted, or updated rows and publishes the results to Message Broker channels. You can also use this event generator to run custom queries on the database table and publish the results to Message Broker channels.
For more information, see Event Generators in Using The WebLogic Integration Administration Console.
The suspended status of an event generator is not preserved when the server is restarted. If the event generator is in the suspended state when the server is restarted, the event generator remains suspended and no events are processed. You can restart the event generator by setting it to ‘running’ from the WebLogic Integration Administration Console.
For more information, see Event Generators in Using The WebLogic Integration Administration Console.
Trading Partner Integration (TPI) provides a framework for peer-to-peer business protocols, implementing RosettaNet (versions 1.1 and 2.0) and ebXML (versions 1.0 and 2.0).
| Note: | Trading Partner Integration was formerly known as B2B. Some resource names contain abbreviations that are a legacy from prior WLI releases. The Trading Partner Integration resources currently retain B2B as part of their names |
When you deploy WLI to a clustered domain, all Trading Partner Integration resources—with the exception of resources for the administration server—must be deployed homogeneously in the cluster. Targeting Trading Partner Integration resources to all clustered servers in a domain enables you to achieve high availability, scalability, and performance improvements for your application.
For more information about Trading Partner Integration resources and clustering, see Designing a Clustered Deployment.
For information about resources that can be configured to accommodate Trading Partner Integration loads, see Trading Partner Management in Using The WebLogic Integration Administration Console.
The Trading Partner Management Repository is an important part of Trading Partner Integration. Database operations on this repository and for all of Trading Partner Integration are performed through the JDBCTxDataSource named cgDataSource using the JDBCPool named cgPool.
Data from the Trading Partner Management Repository is cached during server startup to improve performance by reducing access to this resource. In a cluster environment, the Trading Partner Management Repository data is cached on the administration server and each managed server. These caches are synchronized through the mechanism shown in Figure 1-8.
The Oracle WebLogic Integration Administration Console enables you to perform updates, imports, and deletions to the Trading Partner Management Repository. For information about using the Oracle WebLogic Integration Administration Console to perform these operations, see Trading Partner Management in Using The WebLogic Integration Administration Console.
Trading Partner Integration is initialized during server startup by the WLI-B2B Startup EJB.
| WARNING: | The WLI-B2B Startup EJB has an initial-beans-in-pool setting of 1. Changing this value will cause Trading Partner Integration startup to fail. |
At run time, outgoing and incoming Trading Partner Integration messages traverse different paths. The following sections describe the paths and process flows for outgoing and incoming business messages.
Figure 1-9 shows the path of an outgoing business message.
Figure 1-9 illustrates the following process flow:
wli.internal.b2b.rosettanetencoder.queue and wli.internal.b2b.ebxmlencoder.queue, respectively.wli.internal.msgtracking.queue. The WLI Message Tracking message-driven bean listens to this queue. It will update the various message tracking tables based on the tracking level set in the Trading Partner Management module of the Oracle WebLogic Integration Administration Console.For information about using the Oracle WebLogic Integration Administration Console to set tracking levels, see Trading Partner Management in Using The WebLogic Integration Administration Console.
Figure 1-10 shows the path of an incoming business message.
The preceding figure illustrates the following process flow:
B2BdefaultWebApp/WEB-INF/web.xml. The filter inspects the URL and decides if the incoming request is a TPI URL / request. If it is not destined for Trading Partner Integration, the message continues on to other filters and the final destination servlet.b2b.war. wli.internal.msgtracking.queue. The WLI Message Tracking message-driven bean listens to this queue. It will update the various message tracking tables based on the tracking level set in the Trading Partner Management module of the Oracle WebLogic Integration Administration Console.For information about using the Oracle WebLogic Integration Administration Console to set tracking levels, see Trading Partner Management in Using The WebLogic Integration Administration Console.
WLI relies extensively on database resources for handling run-time operations and ensuring that application data is durable. Database performance is a key factor in overall WLI performance.
For information about database tuning requirements associated with WLI applications, see Preparing Your Database and the database-specific notes in Maintaining Availability.
For additional information on turning your database, see your database vendor’s documentation.
Hardware, operating system, and network resources play a crucial role in WLI performance. Deployments must comply with the hardware and software requirements described in the Oracle WebLogic Integration 10g Release 3 (10.3) Release Notes.
You can use deployment plans to configure WLI applications for deployment.
Deployment plans are optional XML documents that you can use to configure WLI applications for deployment to specific Oracle WebLogic Server environments. By using deployment plans, you can override property values that are defined in deployment descriptors, or define property values that are not explicitly defined in the deployment descriptors.
For more information, see the following sections in Configuring Applications for Production Deployment:
You can also use the PlanGenerator tool to export portions of the deployment configuration to a deployment plan. For more information, see weblogic.PlanGenerator Command Line Reference.
|