| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Platform > WebLogic Integration > Deploying Solutions > Understanding WebLogic Integration Clusters |
|
Deploying Solutions
|
Understanding WebLogic Integration Clusters
The following sections describe how WebLogic Integration is configured and deployed in a clustered environment. It contains the following topics:
Understanding WebLogic Integration Clusters
Clustering allows WebLogic Integration to run on a group of servers that can be managed as a single unit. In a clustered environment, multiple machines share the processing load. WebLogic Integration provides load balancing so that resource requests are distributed proportionately across all machines. A WebLogic Integration deployment can use clustering and load balancing to improve scalability by distributing the workload across nodes. Clustering provides a deployment platform that is more scalable than a single server.
A WebLogic Server domain consists of only one administration server, and one or more managed servers. The managed servers in a WebLogic Integration domain can be grouped in a cluster. When you configure WebLogic Integration clusterable resources, you target the resources to a named cluster. The advantage of specifying a cluster as the target for resource deployment is that it makes it possible to increase capacity dynamically by adding managed servers to your cluster.
The topics in this section provide the information you need to configure WebLogic Integration in a clustered environment. Although some background information about how WebLogic Server supports clustering is provided, the focus is on procedures that are specific to configuring WebLogic Integration for a clustered environment.
Before proceeding, we recommend that you review the following sections of the WebLogic Server documentation to obtain a more in-depth understanding of clustering:
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/cluster/index.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/cluster/config.html
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/perform/WLSTuning.html
Designing a Clustered Deployment
The following sections provide the information you need to design a clustered deployment:
Introducing WebLogic Integration Domains
Before you begin designing the architecture for your clustered domain, you need to learn how WebLogic Server clusters operate.
Creating Domains
Domain and cluster creation are simplified by a Configuration Wizard that lets you generate domains from domain templates based on WebLogic Integration, business process management (BPM), or enterprise application integration (EAI) functionality. Based on user queries, the Configuration Wizard generates a domain, server, and enterprise application with the appropriate components preconfigured and assets included. For information about the templates available for different domains, see the Configuration Wizard Template Reference, which is available at the following URL:
http://download.oracle.com/docs/cd/E13196_01/platform/docs70/template/index.htm
For information about creating WebLogic Integration domains using the Configuration Wizard, see Configuring a Clustered Deployment.
Clustered Servers
A server can be either a managed server or an administration server. A WebLogic Server running the administration service is called an administration server and hosts the Administration Console. In a domain with multiple WebLogic Servers, only one server is the administration server; the other servers are called managed servers. Each managed server obtains its configuration at startup from the administration server.
For general information, see Using WebLogic Server Clusters in the WebLogic Server documentation set, at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/cluster/index.html
For details about basic, multi-tiered, and proxy architectures that are recommended, see Cluster Architectures in Using WebLogic Server Clusters.
Note About Cluster and Management Domains
Although it is possible for a WebLogic Server management domain and cluster domain to be different (that is, it is possible for WebLogic Server clusters to have nodes that belong to different management domains), you must design your WebLogic Integration deployment such that the cluster domain equals the management domain.
Deploying WebLogic Integration Resources
For each server in a clustered domain, you can configure a variety of attributes that define the functionality of the server in the domain. These attributes are configured using the Servers node in the Administration Console.
This section describes WebLogic Integration resources and how they can be partitioned and distributed in a cluster. It contains the following topics:
Clusterable Resources
Table 2-1 describes the WebLogic Integration deployment resources. It contains the following information:
There are two types of resource groups:
Note that some resource names contain abbreviations that are a legacy from prior WebLogic Integration releases:
The following table describes the WebLogic Integration deployment resources.
Two-Phase Deployment of WebLogic Integration It is essential to have all WebLogic Integration application components deployed before your system attempts to process messages. To guarantee this, specify the TwoPhase attribute when you deploy WebLogic Integration. The following excerpt from a sample config.xml file illustrates an Application element, which specifies deployment of WebLogic Integration. Listing 2-1 Deploying the WebLogic Integration Application Distribution Guidelines A WebLogic Integration cluster deployment conforms to the following guidelines:
1. Name represents a user-defined package or resource group.
2. You need to deploy wlai-admin.ear only when you deploy WebLogic Integration to a cluster; do not deploy it when you deploy in a single-node environment. For more information about the application integration administration component, see Load Balancing Application Integration Functions in a Cluster.
3. For example, the DBMS sample event adapter is deployed to a single node. For more information, see the documentation for the adapter you are using.
4. Event and service adapters reside in a single EAR file but they are deployed separately and are listed as separate resources in the WebLogic Server Administration Console. For more information, see the following section, Two-Phase Deployment of WebLogic Integration..
<Domain Name="MyCluster">
...
<Application Name="WebLogic Integration" Path="WLI_HOME/lib"
TwoPhase="true">
...
Targeting Resources to a Cluster
As shown in Deploying WebLogic Integration Resources, most WebLogic Integration resources are deployed to all the servers in a cluster. This deployment is specified in the configuration file (config.xml) for your domain.
You can use the WebLogic Server Administration Console to target components to nodes in your cluster. For more information, see Configuring a Clustered Deployment.
The following listing is an excerpt from the configuration file for a clustered domain, in which BPM components are specified. The listing shows how these components are targeted to a cluster named MyCluster.
Listing 2-2 Targeting WebLogic Integration Components to a Cluster
<Application Deployed="true" Name="WebLogic Integration"
Path="C:/bea/weblogic700/integration/lib" TwoPhase="true">
<!--Repository-->
<EJBComponent Name="WLI Repository" Targets="MyCluster"
URI="repository-ejb.jar" />
<!--BPM-->
<EJBComponent Name="WLI-BPM Server" Targets="MyCluster"
URI="wlpi-ejb.jar" />
<EJBComponent Name="WLI-BPM Event Processor"
Targets="MyCluster" URI="wlpi-mdb-ejb.jar" />
<EJBComponent Name="WLI-BPM Master Components"
Targets="MyServer-1" URI="wlpi-master-ejb.jar" />
<EJBComponent Name="WLI-BPM Initialization"
Targets="MyCluster" URI="bpm-init-ejb.jar"/>
...
</Application>
In the preceding listing, note that all BPM components are targeted to the cluster, except the WLI-BPM master components (wlpi-master-ejb.jar). As specified in Table 2-1, the WLI-BPM master components must be deployed to one server in the cluster (in this case, MyServer-1).
Deployment Order in WebLogic Integration Application
The following file specifies all the components of WebLogic Integration:
WLI_HOME\lib\META-INF\application.xml
Because the components are deployed in the order in which they are listed in application.xml, you must not change the order in which they are listed in the file. The specified order is critical because it reflects dependencies among components. EJBs and BPM plug-ins are included in this application because they must be accessible to BPM functions.
If you deploy custom resources (such as custom plug-ins, EJBs, message-driven beans, and so on) to a WebLogic Integration application, you must edit the application.xml file to specify your new component.
Warning: You can specify a custom resource as the last entry in the application.xml file, unless your new resource is a plug-in to BPM, in which case, you must specify the new component as the penultimate (second to last) entry in the file. That is, it must be defined immediately before the bpm-init-ejb.jar module, but after all the other modules in the application.
The bpm-init-ejb.jar module must be the last module specified in application.xml:
<module>
<ejb>bpm-init-ejb.jar</ejb>
</module>
Deploying The Default Web Application
By default, when you create a domain based on any of the WebLogic Integration domain templates, it contains configuration for a Web server deployed to the administration server. The Web server configuration, in turn, specifies the default Web application (DefaultWebApp).
The deployment descriptor (web.xml) for this default Web application resides in the following location:
DOMAIN_HOME\applications\DefaultWebApp_myserver\WEB-INF\
In the preceding line, DOMAIN_HOME represents the pathname of the domain you created.
A Web Application contains an application's resources, such as servlets, Java Server Pages (JSPs), JSP tag libraries, and any static resources such as HTML pages and image files.
Deploying Custom JSP and HTML Pages
If you deploy custom JSP or HTML pages as part of your WebLogic Integration application, your custom JSP and HTML pages should reside in the following directory:
DOMAIN_HOME\applications\DefaultWebApp_node
In the preceding path, DOMAIN_HOME represents the root directory of the custom domain you created using the Configuration Wizard (see Step 2. Create a WebLogic Integration Domain), and node represents the name of a WebLogic Server instance in your cluster.
You must configure a Web server for each node in your cluster. The following excerpt from a config.xml file shows:
(Information of interest is in bold text for emphasis.)
Listing 2-3 WebServer Element for Managed Server in a config.xml File
<Server Name="managedserver1" ...
...
<WebServer Name="managedserver1" DefaultWebApp="DefaultWebApp_node"
HttpsKeepAliveSecs="120" KeepAliveSecs="60"
LogFileName="C:/bea/user_projects/mydomain/logs/access.log"
LoggingEnabled="true"/>
...
</Server>
:
<Application Deployed="true" Name="DefaultWebApp_node"
Path="C:/bea/weblogic700/samples/integration/config/samples/RN2Security/
config/peer2/applications"
StagedTargets="" TwoPhase="false">
<WebAppComponent IndexDirectoryEnabled="true"
Name="DefaultWebApp_node" Targets="managedserver1"
URI="DefaultWebApp_node"/>
</Application>
In the preceding listing, note that the DefaultWebApp attribute in the WebServer element references the default Web application component. The configuration for the default Web application is also shown in the preceding listing. It, in turn, references the directory where your JSP and HTML pages reside (node represents the name of a server in your cluster).
For more information about deploying Web applications, see Assembling and Configuring Web Applications, which is available at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/webapp/index.html
Note About Administration Servers
If the administration server for a cluster is down, deployment or undeployment requests are interrupted, but managed servers should continue serving requests. You can boot or reboot managed servers using an existing configuration. However, you cannot change configuration for the cluster (for example, add new nodes to the cluster) until the administration server is recovered. For more information, see Backup and Failover for an Administration Server.
Load Balancing in a WebLogic Integration Cluster
One of the goals of clustering your WebLogic Integration application is to achieve scalability. In order for a cluster to be scalable, each server must be fully utilized. Load balancing distributes the workload
Load Balancing WebLogic Server Functions in a Cluster
WebLogic Server supports load balancing for HTTP session states and clustered objects. For more information, see Communications in a Cluster in Using WebLogic Server Clusters, which is available at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/cluster/index.html
Load Balancing BPM Functions in a Cluster
BPM workflows require an event queue for processing event-based workflows. For more information, see Business Process Management Resources.
Event Queues and Associated Pools
The following types of pools are associated with each BPM event queue:
The following figure illustrates an event queue and the pools associated with it.
Figure 2-1 Event Queue and Associated Pools
The unordered event listener message-driven beans process messages in a nondeterministic order. Although messages are read in first-in, first-out (FIFO) order, messages can be processed out of order after they are read, depending on thread scheduling and the load at the time they are processed. The ordered event listener message-driven beans guarantee that, for a particular order key (WLPIOrderKey), messages are processed in an ordered sequence. To achieve this, a single event listener message-driven bean in a cluster must be configured to process messages for WLPIOrderKey. An order key must be an integer value, and the value must be the same for each event that you want processed in the order in which it is received. Ordered messages must also be sent to the same JMS queue. The message producer is responsible for delivering the messages in the queue in the correct order. WLPIOrderKey is a custom JMS property that BPM uses. You can set this property in the WebLogic Integration Studio or you can set it programmatically:
A single JAR file (wlpi-mdb-ejb.jar) contains both ordered and unordered event listener message-driven beans for a particular queue. The message-driven beans provided in the wlpi-mdb-ejb.jar file consume messages from the default EventQueue. This JAR file must be targeted to the cluster.
BPM load balancing is achieved by deploying wlpi-mdb-ejb.jar to the cluster. This JAR file contains five ordered event listener message-driven beans and five unordered event listener message-driven beans. The message-driven beans consume messages from distributed destinations for validating and nonvalidating event queues. The distributed destinations contain one physical destination per JMS server, and one JMS server per instance of WebLogic Server. A single message producer on a distributed queue is bound to a single physical destination. Message-driven beans are bound to the physical destination in the server on which they are deployed (server affinity). Making use of server affinity means that a message is kept within the same JVM and WebLogic Server instance while it is being processed. Therefore, ordered messages sent by a given producer to a distributed destination are guaranteed to be consumed by the same ordered message-driven bean. This process guarantees ordered delivery of messages.
Creating New Pools
If you have sufficient processing power on a single server, you can increase the pool size and range for event listener message-driven beans in the wlpi-mdb-ejb.jar file, as described in Do You Have Enough Message-Driven Beans?.
For information about creating a custom JMS queue and event listeners for that queue, see "Configuring a Custom Java Message Service Queue" in Customizing WebLogic Integration in Starting, Stopping, and Customizing BEA WebLogic Integration.
Requirements for Load Balancing BPM Functionality
When you are load balancing BPM functionality in a WebLogic Integration cluster, consider the following requirements:
Note: This description also applies to the validating queue when XML validation is being performed. The default validating event queue is com.bea.wli.bpm.ValidatingEventQueue.
Timed Events
Like the message-driven beans for the event and validating event queues, timed event listeners are also deployed to the cluster in the wlpi-mdb-ejb.jar file. These message-driven beans pull work from com.bea.wli.bpm.TimerQueue.
Timed events are implemented using JMS delivery times. They are executed by two types of pools:
Load Balancing Application Integration Functions in a Cluster
It is possible to configure a homogenous cluster (that is, one in which all resources have the same managed server targets), subject to any constraints in the adapters themselves.
In contrast to BPM functionality, it is possible to load balance application integration functionality in a cluster using the default JMS queues and servers.
In a clustered deployment, you must deploy a single EJB (wlai-admin-ejb.jar) to the administration server only. This EJB is deployed from the wlai-admin.ear archive file. (See Table 2-1 in Deploying WebLogic Integration Resources.)
Note: The wlai-admin-ejb.jar is required only in a clustered deployment. Therefore do not deploy wlai-admin.ear when you deploy WebLogic Integration to a single server.
The following code excerpt is from a config.xml file for a clustered domain. It shows the deployment specification for the wlai-admin.ear file in the cluster.
Listing 2-4 Deploying the wlai-admin EJB in the config.xml File
<Application Name="WLI-AI Admin Server Only"
Path="WLI_HOME/lib/wlai-admin.ear" TwoPhase="true">
<EJBComponent Name="WLI-AI RAR Upload" Targets="admin_server_name"
URI="wlai-admin-ejb.jar"/>
</Application>
Load Balancing B2B Integration Functions in a Cluster
B2B integration functionality does not require partitioning of work within a cluster; to support such functionality, you should configure a completely homogenous cluster. In other words, all B2B resources (JMS consumers, destinations, and producers) are available on all nodes in the cluster.
It is possible to load balance B2B integration functionality in a cluster using the default JMS queues and servers.
B2B integration resources are deployed homogeneously to all nodes in a cluster. Therefore, when shutdown of the B2B engine is requested, the B2B engine on all nodes in a cluster are shut down. It is not possible to shut down the B2B engine on a single node in a cluster; you must first remove the node from the cluster.
By using distributed destinations, WebLogic JMS balances the messaging load across multiple physical destinations, which can result in better use of resources and improved response times. The WebLogic JMS load-balancing algorithm determines the physical destinations (in a distributed destination set) to which messages are sent, as well as the physical destinations to which consumers are assigned. Message-driven beans are bound to the physical destination in the server on which they are deployed (server affinity).When a message is sent to a particular physical destination (or queue) on a particular server, the message is processed by that server.
B2B integration functionality takes advantage of the server affinity heuristic and in-memory caching in a clustered environment. During B2B message processing, the B2B decoder enqueues the message envelope for a B2B message into the BPM JMS event queue. A BPM message-driven bean dequeues the message and a B2B-specific plug-in is invoked to further process the message. The B2B-specific plug-in uses the message ID, the trading partner, and the delivery channel (URI) to retrieve the message payload from the MessageStore in-memory cache. Therefore, B2B integration functions can make use of in-memory caching, resulting in improved performance.
High Availability in a WebLogic Integration Cluster
Message-driven beans consume messages from JMS destinations. A number of message-driven beans are deployed on each WebLogic Integration destination. For a complete list of WebLogic Integration destinations (JMS queues and topics), see JMS Servers and JMS Destinations.
Highly Available JMS
The ability to configure multiple physical destinations as members of a single distributed destination set provides a highly available implementation of WebLogic JMS. Specifically, for each node in a cluster, an administrator should configure one physical destination for a distributed destination. If one node in the cluster fails, making the physical destination for that node unavailable, then other physical destinations configured as members of the distributed destination can provide service to JMS producers and consumers.
In the case of those destinations that must be deployed as singletons in a clustered environment, high availability is still achieved because a JMS server and all of its destinations can be migrated to another WebLogic Server within a cluster. However, destinations deployed as singletons are less desirable because the migration required for them is manual.
Message-driven beans consume messages from distributed destinations. Distributed destinations contain one physical destination for each instance of WebLogic Server. A single message producer on a distributed queue is bound to a single physical destination. Message-driven beans are bound to the physical destination in the server on which they are deployed (server affinity). Therefore, ordered messages sent by a given producer to a distributed destination are guaranteed to be consumed by the same ordered message-driven bean. This process guarantees ordered delivery of messages, and makes possible the B2B caching described in Load Balancing B2B Integration Functions in a Cluster.
When a managed server fails in a cluster, the message-driven beans from the failed server are migrated atomically, but not automatically, to prevent multiple message processing.
The following sections describe examples of how WebLogic Integration uses distributed destinations and server affinity to achieve high availability in a clustered deployment:
High Availability for Asynchronous Service Requests
WLAI_ASYNC_REQUEST_QUEUE and WLAI_ASYNC_RESPONSE_QUEUE queues are deployed as distributed destinations in a WebLogic Integration cluster, and the Asynchronous Service Request Processor is the associated message-driven EJB, which is deployed to all servers in a cluster. Asynchronous requests and responses are processed even after the JMS server that accepted them crashes.
If a physical queue fails before an asynchronous service request is received by a message-driven bean, the request remains unavailable until the physical queue comes back on line. The same scenario is true for asynchronous service responses.
For information about processing of synchronous and asynchronous invocations for application integration functions, see Application Integration Resources.
High Availability for Event Forwarding
Application integration adapters generate events that are consumed by BPM functionality or by WebLogic Workshop. Events are forwarded from an adapter to a JMS queue (WLAI_EVENT_QUEUE).
To obtain metadata about events, an event router communicates with a WebLogic Integration instance, using HTTP. If you want to achieve load balancing and high availability for event router callback communication, but you are not using a DNS name for your cluster address, you must set the wlai.clusterFrontEndHostAndPort property. For information about this property, see Setting the wlai.clusterFrontEndHostAndPort Property (Optional).
The WLAI_EVENT_QUEUE is a distributed destination containing multiple physical destinations. A message-driven bean (the AI Event Processor) listens on the WLAI_EVENT_QUEUE distributed destination. Because multiple servers participate in the processing of messages for this queue, a single server failure can be accommodated. For information about how adapter events are processed by WebLogic Integration, see Events.
Understanding JMS Resources
This section describes how to configure JMS resources for your WebLogic Integration application in a clustered environment. Specifically, it describes how to configure the following resources:
JMS resources are configured in the WebLogic Server Administration Console. To start the console, see "Starting the WebLogic Server Administration Console" in WebLogic Integration Administration and Design Tools in Starting, Stopping, and Customizing BEA WebLogic Integration.
JMS Connection Factories
The following JMS connection factories are configured in a WebLogic Integration domain that contains an administration server and clustered managed servers:
The following listing shows a sample specification for deployment of JMS connection factories in a WebLogic Integration cluster. Note the Targets and JNDI names for the connection factories, which are shown in bold.
Listing 2-5 JMSConnectionFactory Elements in the config.xml File
...
<!--Application Integration Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="false"
DefaultDeliveryMode="Persistent" DefaultPriority="4"
DefaultTimeToLive="0"
JNDIName="com.bea.wlai.JMSConnectionFactory"
MessagesMaximum="10" Name="WLIJMSConnectionFactory"
OverrunPolicy="KeepOld" Targets="MyCluster"
UserTransactionsEnabled="true"/>
<!--B2B Integration Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="true"
JNDIName="com.bea.wli.b2b.server.TopicConnectionFactory"
Name="B2BTopicFactory" Targets="MyServer-1"
UserTransactionsEnabled="true"/>
<JMSConnectionFactory AllowCloseInOnMessage="true"
JNDIName="com.bea.wli.b2b.rosettanet.QueueConnectionFactory"
Name="RNQueueFactory" Targets="MyCluster"
UserTransactionsEnabled="true"/>
<!--BPM Connection Factories>
<JMSConnectionFactory AllowCloseInOnMessage="true"
JNDIName="com.bea.wlpi.TopicConnectionFactory"
Name="wlpiFactory" Targets="MyCluster"
UserTransactionsEnabled="true"/>
<JMSConnectionFactory AllowCloseInOnMessage="true"
JNDIName="com.bea.wlpi.QueueConnectionFactory"
Name="wlpiQueueFactory" Targets="MyCluster"
UserTransactionsEnabled="true"/>
...
JMS JDBC Stores
A JMS JDBC store must be defined for each JMS server in your deployment.
The following listing is an excerpt from a config.xml file, which defines JMS JDBC stores for a cluster (MyCluster) containing two managed servers (MyServer-1 and MyServer-2), administered by the myserver administration server. Note that the target for the connection pool lists both the cluster and the administration server.
Listing 2-6 JMSJDBCStore Elements in the config.xml File
<JMSJDBCStore ConnectionPool="wliPool"
Name="JMSWLCStore-MyServer-1" PrefixName="MyServer_1"/>
<JMSJDBCStore ConnectionPool="wliPool"
Name="JMSWLCStore-MyServer-2" PrefixName="MyServer_2"/>
<JMSJDBCStore ConnectionPool="wliPool" Name="JMSWLCStore-myserver"
PrefixName="myserver"/>
...
<JDBCConnectionPool CapacityIncrement="1"
DriverName="oracle.jdbc.driver.OracleDriver" InitialCapacity="1"
LoginDelaySeconds="1" MaxCapacity="15" Name="wliPool"
Properties="user=scott;password=tiger;dll=ocijdbc8;protocol=thin
RefreshMinutes="0" ShrinkPeriodMinutes="15"
ShrinkingEnabled="true" Targets="myserver,MyCluster"
URL="jdbc:oracle:thin:@machine:port:name"/>
JMS Servers and JMS Destinations
One JMS server must be configured for each managed server in your cluster, and one for the administration server. (Only one destination (the B2B Topic) is deployed to the JMS server configured for the administration server, as shown in Table 2-2.) We recommend the following naming convention for your JMS servers: WLI_JMSServer_node, such that node represents the name of the server on which the JMS server is deployed.
The following table describes the destinations (JMS queues and topics) used by WebLogic Integration and specifies whether they are deployed as single or distributed destinations.
The following listing is an excerpt from a config.xml file. It shows selected JMS elements for a clustered configuration containing two managed servers (MyServer-1 and MyServer-2), administered by an administration server (myserver). Listing 2-7 JMSServer Elements in the config.xml File Note the following information in the preceding listing:
1. The com.bea.wli.FailedEventQueue destination is used by all components of WebLogic Integration. It should be used as the error destination for any JMS destination that consumes messages in a JTA UserTransaction. For more information about the error queue, see Error Destination.
<!--Distributed Destinations-->
<JMSDistributedQueue JNDIName="com.bea.wli.bpm.EventQueue"
Name="WLI_BPM_Event" Targets="MyCluster"> <JMSDistributedQueueMember JMSQueue="WLI_BPM_Event_MyServer-1"
Name="WLI_BPM_Event_MyServer-1"/>
<JMSDistributedQueueMember JMSQueue="WLI_BPM_Event_MyServer-2"
Name="WLI_BPM_Event_MyServer-2"/></JMSDistributedQueue>
<!--Administration Server-->
<JMSServer Name="WLI_JMSServer_myserver"
Store="JMSWLCStore-myserver" Targets="myserver"
TemporaryTemplate="TemporaryTemplate">
<JMSTemplate Name="TemporaryTemplate"/>
<JMSTopic JNDIName="com.bea.wli.b2b.server.B2BTopic"
Name="B2BTopic"/>
</JMSServer><!--Managed Server-->
<JMSServer Name="WLI_JMSServer_MyServer-1"
Store="WLI_JMSJDBCStore_MyServer-1" Targets="MyServer-1 (migratable)" <JMSQueue JNDIName="com.bea.wli.bpm.Event.MyServer-1"
Name="WLI_BPM_Event_MyServer-1" StoreEnabled="true"
Template="WLI_JMSTemplate-1"/>...
<JMSTopic JNDIName="com.bea.wli.bpm.EventTopic"
Name="wlpiEvent" StoreEnabled="false"/>...
</JMSServer>
Error Destination
The com.bea.wli.FailedEventQueue is the error destination for any JMS destination that consumes messages in a JTA User Transaction. For example, it is the error destination for the EventQueue, ValidatingEventQueue, and TimerQueue. Messages that do not find a target BPM workflow instance and those that fail a number of retries, at one minute intervals, are sent to the FailedEventQueue. (The default number of retry attempts is 10, but you can configure a different number.) When a JMS message arrives on the FailedEventQueue, a message-driven bean (com.bea.wli.common.errorlistener.ErrorListenerBean), which listens on the queue, writes log entries to the WebLogic Server log.
You can specify the number of retry attempts to be allowed by configuring attributes for redelivery in the WLI_JMSTemplate-node, which is the JMS template used by the error queue. The error queue is a distributed destination, and the redelivery attributes are configured for a node-specific physical destination, which is named WLI-FailedEvent-node. (For these names, node represents the name of a WebLogic Server instance in your cluster):
For more information about configuring redelivery attributes for a JMS template, see JMS Template
http://download.oracle.com/docs/cd/E13222_01/wls/docs70/ConsoleHelp/domain_jmstemplate_config_redelivery.html
In addition, you have the option of creating your own custom message listener, adding it to the classpath, and referencing it in the FailedEventQueue message-driven bean deployment descriptor. By doing so, you can configure your system to persist error messages.
Creating a Store and Associating It with a Connection Pool
To create a store and associate it with a connection pool, complete the following steps:
Creating a JMS Server and Associating It with the Store
To create a JMS server and associate it with a JMSJDBCStore, complete the following steps:
Deploying Adapters
Run-time application integration features (synchronous service invocations, asynchronous service invocations, and events), described in Application Integration Resources, can be clustered for scalability and high availability. Application integration features that are available at design time (Application Views and Connection Factories) can be clustered for scalability but not for high availability, meaning 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.
An application integration adapter is typically composed of three components:
The resource adapter (RAR) file and the design time Web application (WAR) file should be deployed to the cluster. However the event generator Web application (WAR) file should, in most cases, be deployed to a single node in the cluster. (For specific information, see the documentation for the adapter you are using.)
For example, when a DBMS adapter is used, the DbmsEventRouter Web application must be targeted to a single node in a cluster. The following listing is an excerpt from a config.xml file. It shows an Application element that specifies the configuration for deployment of a DBMS adapter.
Listing 2-8 Configuration for Deploying an Application Integration Adapter
<Application Deployed="true" Name="BEA_WLS_DBMS_ADK" Path="/bea/weblogic700/integration/adapters/dbms/lib/
BEA_WLS_DBMS_ADK.ear" StagingMode="stage" TwoPhase="true">
<ConnectorComponent Name="BEA_WLS_DBMS_ADK" Targets="MyCluster" URI="BEA_WLS_DBMS_ADK.rar"/>
<WebAppComponent Name="BEA_WLS_DBMS_ADK_Web" Targets="MyCluster" URI="BEA_WLS_DBMS_ADK_Web.war"/>
<WebAppComponent Name="DbmsEventRouter" Targets="MyServer-1" URI="BEA_WLS_DBMS_ADK_EventRouter.war"/>
</Application>
Note the following information in the preceding listing. Information of interest is highlighted in bold text for emphasis:
Configuring Adapters for Deployment
WebLogic Integration domains created by the Configuration Wizard define the configuration for resource adapters. In the configuration created by the Configuration Wizard, the three components of an adapter are targeted for deployment to the cluster. However, as described in the preceding section (specifically, Listing 2-8), the event generator Web application (WAR) file should, in most cases, be deployed to a single node in the cluster. You must modify your domain configuration to meet this requirement. For information about how to modify the domain configuration, see Step 5. Configure Event Router WAR File for Adapters.
You can also deploy resource adapters after you start the servers in your cluster. For information about how to set up and start your clustered deployment, see Configuring a Clustered Deployment. For information about using the weblogic.Deployer command-line utility or the WebLogic Server Administration Console to deploy resource adapters to a running cluster, see Deploying Resource Adapters.
For more information about deploying adapters in the WebLogic Integration environment, see Deploying Adapters in Developing Adapters.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
