|
|
|
|
|
|
Introduction
This document describes how to deploy BEA WebLogic Integration solutions in a production environment. The following sections introduce key concepts and tasks for deploying WebLogic Integration in your organization:
Deployment Goals
When deploying WebLogic Integration solutions, consider the following goals:
You can achieve these goals and others with every WebLogic Integration deployment.
Deployment Architecture
The following illustration provides an overview of the WebLogic Integration deployment architecture.
Figure 1-1 WebLogic Integration Deployment Architecture
The following section describes these resources in detail.
Key Deployment Resources
This section provides an overview of resources that can be modified at deployment time. It contains the following sections:
WebLogic Server Resources
This section provides general information about BEA WebLogic Server resources that are most relevant to deploying a WebLogic Integration solution. You can configure these resources from the WebLogic Server Administration Console or through EJB deployment descriptors.
WebLogic Server provides many configuration options and tunable settings for deploying WebLogic Integration solutions in any supported environment. The following sections describe the configurable WebLogic Server features that are most relevant to WebLogic Integration deployments:
For more information, see the BEA WebLogic Server documentation at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/index.html
Clustering
To increase workload capacity, you can run 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 Configuring WebLogic Integration Clusters.
Java Message Service
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 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 WebLogic Server. In addition, JMS event queues can be configured to handle workflow notifications and messages, as described in Business Process Management Resources.
For more information about WebLogic JMS, see the following topics:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/jms/intro.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/jms.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/monitoring.html
EJB Pooling and Caching
In a WebLogic Integration 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 WebLogic Server documentation recommends setting the number of execute threads rather than setting max-beans-in-free-pool. In a WebLogic Integration environment, however, it is more efficient to control the workload by specifying the max-beans-in-free-pool setting of the event listener message-driven beans than by setting the number of execute threads.
For more information about configuring pool and cache sizes, see Configuring Other EJB Pool and Cache Sizes.
JDBC Connection Pools
Java Database Connectivity (JDBC) enables Java applications to access data stored in SQL databases. To reduce the overhead associated with establishing database connections, 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. A setting that is too low results in delays while WebLogic Integration waits for connections to become available. A setting that is too high results in slower DBMS performance.
For more information about WebLogic JDBC connection pools, see the following sections:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/jdbc/intro.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/jdbc.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/monitoring.html
Execution Thread Pool
The execution thread pool controls the number of threads that can execute concurrently on 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.
In a WebLogic Integration environment, controlling the number of message-driven beans is generally the best way to throttle work. The execution thread pool should be set sufficiently high for all candidate threads to run. In general, a pool size that is too large is preferable to one that is too small.
For more information about configuring the execution thread pool, see Configuring the Execution Thread Pool.
J2EE Connector Architecture
The WebLogic J2EE Connector Architecture (J2EE-CA) 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, Proposed Final Draft 2, from Sun Microsystems, Inc.
For more information about the WebLogic J2EE-CA, see "Managing the WebLogic J2EE Connector Architecture" in the BEA WebLogic Server Administration Guide at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/jconnector.html
Business Process Management Resources
In WebLogic Integration, the Business Process Management (BPM) functionality handles the definition and execution of business processes. For an introduction to BPM functionality, see Business Process Management in Introducing BEA WebLogic Integration.
The following sections describe BPM features that are used for the deployment of WebLogic Integration solutions:
BPM resources can be configured to run on a cluster—a group of servers that can be managed as a single unit. For more information about clustering and BPM, see Configuring WebLogic Integration Clusters.
Overview of BPM Resources
The following diagram shows BPM resources for a single node in a cluster.
Figure 1-2 BPM EJB Resources
For a description of these resources, see the next section, Types of BPM Resources. Types of BPM Resources BPM uses WebLogic JMS (described in Java Message Service) for communicating worklist, time, and event notifications, as well as error and audit messages. BPM client applications send these messages, as XML events, to JMS event queues. BPM uses event listener message-driven beans to process XML events that arrive in event queues and deliver them to the running instance of the BPM engine. You create custom message queues using the WebLogic Server Administration Console, run the MDBGenerator utility to generate an event listener bean to listen on the queue, and update the BPM configuration to recognize the new event listener bean. For more information, see Configuring JMS Servers and Queues for Application Integration. The following sections describe the types of resources you can use when configuring BPM for a clustered environment and when tuning BPM performance:
Workflow Processor Beans
Workflow processor beans are stateful session beans that execute workflows, which proceed from a start/event node to an event/stop node (quiescent state to quiescent state). Workflow processor beans accept work from event listener beans, Worklist clients, and, when using sub-workflows, from other workflow processor beans.
Workflow processor beans are instantiated at run time based on the system load, so the exact number of workflow processor beans at run time is dynamic. The size of the workflow processor bean pool determines the number of workflow processor beans that can be active concurrently. If the number of beans exceeds the pool size, then excess beans are passivated until a container in the pool becomes available. In general, a pool size that is too large is preferable to one that is too small.
Workflow processor beans are clusterable (they have cluster-aware stubs), so they may accept work from other nodes in the cluster.
Event Listener Message-Driven Beans
Event listener message-driven beans pull work from the event queue and send work to the workflow processor beans. Event listener beans wait until the workflow processor bean either executes to completion or hits a quiescent state before getting new work from the queue.
Event listener beans have a configured pool size for unordered messages and they use a series of single bean pools (named beans with a free pool size of 1) for ordered messages, as described in "Generating Message-Driven Beans for Multiple Event Queues" in Establishing JMS Connections in Programming BPM Client Applications.
In combination, these pools determine the amount of parallel workflow execution that can occur when initiated from events.
Template Beans
Template beans are entity beans that contain the workflow template to be executed. In general, the size of the template entity bean pool should equal the maximum number of workflow templates (templates, not instances) to be executed concurrently. In general, a pool that is too large is preferable to one that is too small. Template entity beans are clusterable (they have cluster-aware stubs), so they can be used by workflow processor beans on other nodes in a cluster.
Template Definition Beans
Template definition beans are entity beans that contain the workflow template definition to execute. In general, the size of the template definition entity bean pool should equal the maximum number of workflow templates (not workflow instances) to execute concurrently. In general, a pool that is too large is preferable to one that is too small. Template definition entity beans are clusterable (they have cluster-aware stubs), so they can be used by workflow processor beans on other nodes in a cluster.
Instance Beans
Instance beans are entity beans that contain the workflow instance being executed. In general, the size of the instance entity bean pool should equal the size of the workflow processor bean pool. There is no advantage to having an instance entity bean pool that is larger than the workflow processor bean pool. In general, a pool that is too large is preferable to one that is too small. Instance entity beans are clusterable (they have cluster-aware stubs), so they can be used by workflow processor beans on other nodes in a cluster.
Event Queue
The event queue is a JMS queue that is tied to a specific JMS server. WebLogic Integration ships with a default event queue in the domain configurations. You can also create new event queues, as described in Configuring JMS Queues for BPM.
Note: To scale BPM functionality in a cluster, you must create new event queues.
Worklist Console
The Worklist client includes the swing-based WebLogic Integration Worklist console, as well as any user code that creates workflows from the BPM API. It is shown in Figure 1-2 for context only—it is not a configurable run-time resource.
BPM Work Sequence
The following diagram shows the interaction among BPM EJBs when processing events.
Figure 1-3 Interaction Between BPM EJBs When Processing Events
When a BPM event listener bean receives a work request from the event queue (whether the default queue or a user-defined queue), it creates a workflow processor bean to work on the request. The workflow processor bean executes the workflow until the workflow hits a stop or event node. Note that, when a workflow calls another workflow, a new workflow processor bean is created and the calling workflow does not exit the workflow processor bean. The template bean and template definition bean are read at the beginning of workflow execution. The instance bean is read at the beginning of workflow execution, and written when workflow execution quiesces at a transaction boundary (such as an event or done node). For event-driven workflows, the creation of additional workflow processor beans does not enable the deployment to do more work. The number of event listener beans limits the number of workflow instances that can be processed in parallel. B2B Integration Resources B2B integration resources are allocated dynamically, as needed; the deployment cannot be configured ahead of time. For information about resources that can be configured to accommodate B2B loads, see Configuration Requirements in Administering B2B Integration. While you cannot configure WebLogic Server resources to configure B2B integration, you should be aware that some B2B integration resources, such as delivery channels for hub-and-spoke configurations, affect performance. For more information, see "XOCP Hub and Spoke Delivery Channels" in Configuration Requirements in Administering B2B Integration. B2B integration functionality can be deployed on a WebLogic Integration cluster, but resources must be targeted to a single node in the cluster. For more information about clustering and B2B integration, see Configuring WebLogic Integration Clusters. Application Integration Resources The following sections describe the types of application integration resources that WebLogic Integration supports:
Application integration can be configured for a group of servers that are managed as a single unit. For more information about clustering and application integration, see Configuring WebLogic Integration Clusters.
Synchronous Service Invocations
Use synchronous invocations when the underlying EIS can respond quickly to requests, or when the client application can afford to wait.
The following figure illustrates the flow of a synchronous service invocation.
Figure 1-4 Synchronous Service Invocations
In a synchronous service invocation, a client (shown here as a workflow processor) calls the application view EJB (a stateless session bean). The application view calls the service adapter using a synchronous CCI request. The service adapter is a J2EE-CA service adapter that actually processes the request. Note: When a workflow acts as a client to an EIS, the workflow processor is stalled while it waits for the request to complete, tying up a workflow processor bean and perhaps an event listener bean as well. To optimize throughput, consider using asynchronous invocations instead unless the underlying EIS system can respond quickly to the request. Asynchronous Service Invocations The following figure illustrates the flow of an asynchronous service invocation. Figure 1-5 Asynchronous Service Invocations
In an asynchronous invocation, a client (shown here as a workflow processor) calls the application view EJB (a stateless session bean). The application view EJB then queues the request for later processing and returns control to the client. The asynchronous request is queued in the async request queue (wlai.myserver.ASYNC_REQUEST in the default domain). This is a JMS queue in a JMS server. An async service request processor pulls work from the async request queue, calls the service adapter, and enqueues the response in the async response queue. The async service request processor is configured as a pool of JMS listeners in the wlai startup class. The pool size can be configured by a property in the wlai.properties file (wlai.numAsyncServiceRequestProcessors). Setting the pool size of the async service request processor is the best way to control the amount of work that a service adapter can perform when using asynchronous service invocations. Events The following figure illustrates the information flow of an event. Figure 1-6 Events
An event adapter generates events and places them in a temporary topic created at run time. The temporary topic is a JMS Topic associated with a JMS Server. The events are forwarded to an EngineMgr that is listening on the temporary topics. The EngineMgr is a JMS listener that is initiated by the EngineMgr EJB. A subscribing application, such as a workflow, receives the forwarded event on a JMS queue. In a workflow, the application integration plug-in determines the queue on which the event should be received for a start or event node—it need not be the default BPM EventQueue. The workflow processor represents a client application. Relational Database Management System Resources WebLogic Integration 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 WebLogic Integration performance. For more information, see Tuning Databases. Hardware, Operating System, and Network Resources Hardware, operating system, and network resources play a crucial role in WebLogic Integration performance. Deployments must comply with the hardware and software requirements described in the BEA WebLogic Integration Release Notes. For more information about configuring these resources for maximum performance in a production environment, see Tuning Hardware, Operating System, and Network Resources.
Roles in Integration Solution Deployment
The deployment team for an integration solution fulfills the following roles:
A successful deployment requires input from all of these participants. Note that one person can assume multiple roles and that not all roles are equally relevant in all deployments.
Deployment Specialists
Deployment specialists coordinate the deployment effort. They are knowledgeable about the features and capabilities of the WebLogic Integration product. They provide expertise in designing the deployment topology for an integration solution, based on their knowledge of how to configure various WebLogic Integration features on one or more servers. Deployment specialists have experience in the following areas:
WebLogic Server Administrators
WebLogic Server administrators provide in-depth technical and operational knowledge about WebLogic Server deployments in an organization. They have experience in the following areas:
Database Administrators
Database administrators provide in-depth technical and operational knowledge about database systems deployed in an organization. They have experience in the following areas:
Key Deployment Tasks
Deploying WebLogic Integration may require some or all of the following tasks:
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|