bea.com | products | dev2dev | support | askBEA |
|
e-docs > WebLogic Platform > WebLogic Integration > Deploying Solutions > Introduction |
Deploying Solutions |
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
WebLogic Integration 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 WebLogic Integration solutions, consider the following goals:
You can achieve these goals and others with every WebLogic Integration deployment.
Key Deployment Tasks
Deploying WebLogic Integration may require that you complete some or all of the following tasks:
Roles in Integration Solution Deployment
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 a successful deployment requires input by people in each role.
Deployment Specialists
Deployment specialists coordinate the deployment effort. They are knowledgeable about the features 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 knowledge of the hardware and platform, and experience managing all aspects of a WebLogic Server deployment, including installation, configuration, monitoring, security, performance tuning, troubleshooting, and other administrative tasks
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:
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 each of the resources illustrated in the preceding figure.
Key Deployment Resources
This section provides an overview of resources that can be modified at deployment time:
WebLogic Server Resources
This section provides general information about BEA WebLogic Server resources that are most relevant to the deployment of 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:
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 Understanding 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 destinations 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/docs70/jms/intro.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/adminguide/jms.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. (For information about configuring pool and cache sizes, see Configuring Other EJB Pool and Cache Sizes.) The following table describes types of EJBs and their associated tunable parameter.
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. You can tune WebLogic Integration performance by configuring the size of JDBC connection pools. For information about determining the size of a JDBC connection pool on each node in a WebLogic Integration cluster, see Configuring JDBC Connection Pool Sizes. 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:
1. The WebLogic Server documentation recommends setting the number of execute threads rather than setting max-beans-in-free-pool. However, in a WebLogic Integration environment, 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.
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/jdbc/intro.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/adminguide/jdbc.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.
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. 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 for reading sockets and can sometimes lead to a deadlock. Monitor your running system to empirically determine the best value for the execution thread pool.
For information about configuring the execution thread pool, see Configuring the Execution Thread Pool.
Following these recommendations for tuning your execution thread pool will help optimize the performance of WebLogic Integration. However, in a WebLogic Integration environment, the best way to throttle work is by controlling the number of message-driven beans—see EJB Pooling and Caching.
J2EE Connector Architecture
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, Proposed Final Draft 2, from Sun Microsystems, Inc.
For 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/docs70/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 is managed as a single unit. For more information about clustering and BPM, see Understanding 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
The next section, Types of BPM Resources, describes the resources represented in the preceding figure. 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 can create custom message queues using the WebLogic Server Administration Console, then run the MDB Generator utility to generate an event listener bean to listen on the queue, and subsequently update the BPM configuration to recognize the new event listener bean. For more information, see Creating New Pools. 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 a stop/event node (quiescent state to quiescent state). Workflow processor beans accept work from event listener beans, Worklist clients, and from other workflow processor beans (when subworkflows are used).
Because workflow processor beans are instantiated at run time, based on the system load, 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 bean in the pool becomes available. In general, a pool size that is too large is preferable to one that is too small. For tuning information, see Configuring Other EJB Pool and Cache Sizes.
Workflow processor beans are deployed to the cluster. WebLogic Server optimizes a clustered system such that each node in a cluster uses a local copy of a workflow processor bean.
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 be executed.
Business processes are saved as workflow templates in a database. These templates are essentially empty containers for storing different workflow versions.They can be associated with multiple organizations. Templates contain template definitions, which serve as different versions of the same workflow, and are distinguished by effective and expiry dates. For information about business processes and workflows, see Using the WebLogic Integration Studio.
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
A single JAR file contains both ordered and unordered event listener message-driven beans for a particular queue. The WebLogic Integration installation provides the wlpi-mdb-ejb.jar file, which contains message-driven beans that consume messages from the default EventQueue. This JAR file must be targeted to the cluster. You can also create new event queues, as described in Creating New Pools. For information about BPM event queues in a cluster, see Load Balancing BPM Functions in a Cluster.
Note: To scale BPM functionality in a cluster, you must create new event queues.
Worklist Console (Deprecated)
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 When you deploy WebLogic Integration to a clustered domain, all B2B integration resources, with the exception of resources for the administration server, must be deployed homogeneously in the cluster. That is, to achieve high availability, scalability, and performance improvements, B2B integration resources must be targeted to all clustered servers in a domain. For more information about B2B integration resources and clustering, see Designing a Clustered Deployment. Many B2B integration resources are allocated dynamically, as needed; a 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. A shared file system is required for a cluster that uses B2B integration functionality. We recommend either a Storage Area Network (SAN) or a multiported disk system. Note: WebLogic Integration applications that are based on the XOCP business protocol are not supported in a clustered environment. Application Integration Resources The following sections describe the types of application integration resources that WebLogic Integration supports:
For information about clustering and application integration, see Understanding WebLogic Integration Clusters.
Application integration functionality is integrated in the WebLogic Integration product, but it is also available packaged in a single, self-contained J2EE ear file. This enables you to deploy application integration on any valid WebLogic domain. For example, Web services developers and WebLogic Portal developers can use application views to interact with EIS applications. For more information about deploying application integration outside of a WebLogic Integration environment, see Modular Deployment of Application Integration in Using Application Integration.
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 Common Client Interface (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 asynchronous service processing in WebLogic Integration. Figure 1-5 Asynchronous Service Invocations
Note: The WLAI_ASYNC_REQUEST_QUEUE and WLAI_ASYNC_RESPONSE_QUEUE queues are deployed as distributed destinations in a WebLogic Integration cluster. The Asynchronous Service Request Processor is a message-driven bean (wlai-asyncprocessor-ejb.jar), which is also deployed to the cluster. For more information about how application integration resources are deployed for high availability, see Highly Available JMS. The preceding diagram illustrates the following process flow for an application integration asynchronous service:
The client has the option of supplying a durable client ID at the time of construction. The durable client ID is used as the correlation ID for asynchronous response messages.
The client invokes the invokeServiceAsync method and passes the request IDocument to an AsyncServiceResponse Listener to handle the response.
The AsyncServiceRequest object contains the name of the destination to which the response listener is pinned. The AsyncServiceProcessor message-driven bean uses this information to determine which physical destination to which it should send the response.
If a request object does not contain the name of a response destination, the AsyncServiceProcessor message-driven bean uses the destination specified for the JMS message (using a call to the JMSReplyTo() method).
Suppose, however, that only the client supplies an AsyncServiceResponseListener to the Application View:
invokeServiceAsync(String serviceName, IDocument request,
AsyncServiceResponseListener listener);
In this scenario, the Application View establishes a receiver to the JMS queue that is bound at the JNDI location provided by the Application View EJB method getAsyncResponseQueueJNDIName(). The Application View instance uses QueueReceiver.getQueue() to set the ReplyTo destination on the request message.
It is not sufficient to send a message to a distributed queue and expect the message to be received by a QueueReceiver of that queue. Because the message is sent to only one physical queue, there must be a QueueReceiver listening on the physical queue. To satisfy this requirement, the AsyncServiceProcessor (wlai-asyncprocessor-ejb.jar) must be deployed on all nodes in a cluster.
The AsyncServiceProcessor message-driven bean receives the message from the queue in a first in, first out (FIFO) manner.
The AsyncServiceProcessor uses the AsyncServiceRequest object in the JMS ObjectMessage to determine the qualified name, service name, request document, and response destination for the Application View.
Note that the AsyncServiceProcessor must send the response to a specific physical destination (WLAI_ASYNC_RESPONSE_QUEUE_myserver1) and not to the distributed destination (WLAI_ASYNC_RESPONSE_QUEUE). The physical destination queue was established by the Application View instance running on the client when it called the Application View EJB getAsyncResponseQueueJNDIName() method. (See step 2.)
Note: It is possible for a client application to fail before it receives all the response messages it expects. If, after recovery, you want to make sure that the client is associated with the same JMS response queue with which it was associated before the failure, you must use the same client ID that you used before the failure, after recovery. The following listing is an example of recovery code, which facilitates this association of the client with the JMS response queue by using the same unique client ID before the failure and after recovery:
String uniqueClientID = "uniqueClientID";
ApplicationView myAppView = new ApplicationView(jndiContext,
"MyAppView", uniqueClientID);
myAppView.recoverAsyncServiceResponses(new MyAsyncResponseListener());
Events
Application integration adapters generate events that are consumed by BPM or WebLogic Workshop. Events are forwarded from an Application View to a JMS queue (WLAI_EVENT_QUEUE). This queue is a distributed destination containing multiple physical destinations. A message-driven bean (the WLI-AI Event Processor) listens on the WLAI_EVENT_QUEUE distributed destination.
The WLI-AI Event Processor does the following:
Exactly one copy of each event is delivered to BPM or WebLogic Workshop.
The WLAI_EVENT_TOPIC is a distributed JMS topic and handles the delivery of events to remote Application View clients. The Application View class creates an EventContext on the WLAI_EVENT_TOPIC. The EventContext class filters messages based on the name of the Application View, which is stored in the SourceKey JMS header property. The SourceType is ApplicationView.
The following figure illustrates event processing in WebLogic Integration.
Figure 1-6 Events
The preceding figure illustrates the following sequence of steps for event processing:
In a cluster, WLAI_EVENT_QUEUE is deployed as a distributed JMS queue. However, each message is sent to a single physical queue and is only available from the physical queue to which it was sent. If that physical queue becomes unavailable before a given message is dequeued, then the message (that is, the event) is unavailable until that physical queue comes back on-line.
It is not enough to send a message to a distributed queue and expect the message to be received by a QueueReceiver for that distributed queue. Because the message is sent to one physical queue, there must be a QueueReceiver listening on that physical queue. To satisfy this requirement, the WLI-AI Event Processor message-driven bean (wlai-eventprocessor-ejb.jar) must be deployed on all nodes in a cluster.
Application Views and Connection Factories
The run-time application integration features (synchronous service invocations, asynchronous service invocations, and events) described in preceding sections can be clustered for scalability and high availability. Design-time application integration features (Application Views and connection factories) can be clustered for scalability, but not for high availability. This means that you cannot deploy or undeploy (edit) Application Views if any server in a cluster is not running. In other words, you can deploy and undeploy (edit) only in a healthy cluster.
The resource adapter (RAR) is uploaded by deploying the wlai-admin.ear archive file to the administration server, not to the clustered managed servers. Two-phase deployment is used. The WebLogic Deployer utility on the administration server controls the deployment to managed servers.
The following figure illustrates connection factory deployment at design time.
Figure 1-7 Connection Factory Deployment
Application View deployment depends on successful connection factory deployment. For more information about deploying application integration adapters in clustered environments, see Load Balancing Application Integration Functions in a Cluster and Deploying Adapters. 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 Recommended Hardware and Software, and Tuning Hardware, Operating System, and Network Resources.