|
|
The following sections describe how WebLogic Integration is configured and deployed in a clustered environment. It contains the following topics:
For general information on Deploying Applications Deploying Applications To WebLogic Server.
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 cluster 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 normally 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.
| Note: | WebLogic Integration domains can support multiple clusters. However, you must still target WebLogic Integration system resources and applications on a single WebLogic Integration cluster in a multiple cluster domain. |
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:
The following sections provide the information you need to design a clustered deployment:
Before you begin designing the architecture for your clustered domain, you need to learn how WebLogic Server clusters operate.
Domain and cluster creation are simplified by a Configuration Wizard that lets you generate domains from basic and extension domain templates. Based on responses to 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 Template References.
The domain you create with the Configuration Wizard must have one and only one target which will contain WebLogic Integration system components and applications. You can specify this target by setting the value of weblogic.wli.WliClusterName in wli-config.properties. If you do not specify a value for weblogic.wli.WliClusterName, the WebLogic Integration target defaults to the first WebLogic Integration cluster or, in the absence of a cluster, the first managed server. For more information about the wli-config.properties file, see wli-config.properties Configuration File.
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 WebLogic Server 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 about WebLogic clusters, see Using WebLogic Server Clusters in the WebLogic Server documentation set. This document includes details regarding recommended basic, multi-tiered, and proxy architectures. For information about security considerations in the design of WebLogic clusters, see "Security Options for Cluster Architectures" in Cluster Architectures in Using WebLogic Server Clusters.
All the managed servers in a WebLogic Integration domain must be a part of the WebLogic Integration cluster, you cannot have a stand alone managed servers.
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 and security domain.
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 automatically when you create a WebLogic Integration domain using the Configuration Wizard. You can also configure these attributes manually using the Servers node in the WebLogic Server Administration Console.
| Note: | When using WebLogic Integration Application, it |
For a list of configurable WebLogic Integration deployment resources, see WebLogic Integration Deployment Resources. It describes the default targeting of each resource in a clustered WebLogic Integration domain and provides instructions on how to navigate to each resource in the WebLogic Server Administration Console.
This section contains the following topics regarding additional WebLogic Integration deployment configuration requirements:
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 the two-phase deployment of WebLogic Integration.
<Domain Name="MyCluster">
...
<Application Name="WebLogic Integration" Path="WL_HOME/lib"
TwoPhase="true">
...
Trading Partner Integration components must be deployed homogeneously to a cluster. You must configure Trading Partner Integration resources identically on every managed server so that there is no single point of failure.
When configuring Trading Partner Integration in a cluster, keep in mind the following considerations:
You can only change configuration for a cluster (for example, add new nodes to the cluster or modify Trading Partner Integration configuration) while its administration server is active.
If the administration server for a cluster is down, deployment or undeployment requests are interrupted, but managed servers continue serving requests. You can boot or reboot managed servers using an existing configuration, as long as the required configuration files (msi-config.xml, SerializedSystemIni.dat, and optionally boot.properties) exist in each managed server's root directory.
Managed servers that start without an administrative server operate in Managed Server Independence (MSI) mode. For complete information about MSI mode, see "Managed Server Independence Mode" in Managing Server Startup And ShutDown.
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 proportionally among all the servers in a cluster so that each server can run at full capacity. The following sections describe load balancing for various functional areas in a WebLogic Integration cluster:
For more information, see Load Balancing in a Cluster in Using WebLogic Server Clusters.
Both Web services (SOAP or XML over HTTP) and WebLogic Trading Partner Integration protocols can use HTTP load balancing. External load balancing can be accomplished through the WebLogic HttpClusterServlet, a WebServer plugin, or a hardware router.
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.
Most JMS queues used by WebLogic Integration or WebLogic Integration applications are configured as distributed destinations. The exceptional cases are JMS queues that are targeted to single managed servers.
For detailed information on JMS load balancing, see "Tuning Distributed Destinations" in Tuning WebLogic JMS.
If your WebLogic Integration solution includes communication between a synchronous client and an asynchronous business process, the weblogic.jws.jms.QueueConnectionFactory must have server affinity enabled. This is the default setting.
| WARNING: | Attempting to tune JMS load balancing by disabling server affinity for a solution that includes communication between a synchronous client and an asynchronous business process will result in unpredictable behavior. |
The RDBMS Event Generator has a dedicated JMS connection factory (wli.internal.egrdbms.XAQueueConnectionFactory). Load balancing is enabled for this connection factory by default. To disable load balancing for RDBMS events, you must disable load balancing and enable server affinity for wli.internal.egrdbms.XAQueueConnectionFactory.
Application integration allows for load balancing of both services and events within a cluster. Each type is discussed in a following section.
Synchronous services are implemented as method calls on a session EJB. As such, they will be load balanced within the cluster according to EJB load balancing rules. After being published at design-time, each application view is represented as two session EJBs: one stateless and one stateful.
In normal operation, the services are invoked using the stateless session EJB, and thus load balancing will occur on a per-service basis. This means that each time you invoke a service on an application view, you may actually be routed to a different EJB on a different WebLogic managed server instance.
When using the local transaction facilities of the application view and during a local transaction, services are invoked using the stateful session EJB. The stateful session EJB is used to hold open the connection to the EIS, so that the local transaction state can persist between service invocations. In this mode, service invocations become pinned to a single EJB instance on a single managed server within the cluster. Once the local transaction completes (either through a commit or rollback), normal per-service load balancing applies.
Asynchronous services are always invoked as method calls on a stateless session EJB. You cannot use the local transaction facility of the application view for asynchronous service invocations.
A single asynchronous service invocation translates to two method invocations on up to two different stateless session EJB instances. Thus, load balancing for asynchronous service occurs on two occasions: upon receipt of the request, and in the execution of the request and delivery of the response.
In addition, both the asynchronous service request and response are posted to a distributed JMS queue. As a result of this, JMS load balancing applies to both the request and response. This means that the invokeServiceAsync method of the application view may be serviced on one managed server, the request delivered to a second managed server where the request is processed and the response generated, and the response delivered to a third server for retrieval by the client.
| Note: | When using the application view control from a WebLogic Integration process or WebLogic Workshop Web service, the asynchronous response is delivered directly to the EJB for the process or Web service without being posted to the asynchronous response JMS queue. |
Application integration adapters generate events that are consumed by WebLogic Integration processes or by WebLogic Workshop Web services. Events are generated inside an EIS instance outside the WebLogic Integration cluster. Application integration is made aware of these events by event objects created by event connections within adapter instances. Those adapter instances reside on individual managed servers within the cluster.
The behavior of event delivery from the point of origin in the EIS to the point where they are handed off to application integration is adapter-specific and not defined by application integration. However, once an event generator has delivered the event into application integration, the event is load balanced for delivery to clients on any managed server in the cluster.
The behavior of event delivery within a cluster depends on whether or not the following conditions exist:
If both of these conditions exist, event delivery and the subsequent processing of those events by processes and Web services will scale as the number of managed servers in the cluster scales.
Support for multiple event connections within a cluster for a single application view or event type depends on the design of the adapter. For example, the DBMS sample adapter included in the Adapter Development Kit does provide this support. Consult your adapter vendor or adapter documentation to determine if the adapter you are using provides this support.
Deployment of the event connection to more than one managed server in the cluster depends on how you have configured the event connection and adapter instance. Using the WebLogic Integration console, WebLogic Integration administrators can target an event connection at zero or more managed servers in the cluster. If the adapter supports multiple event generators in a cluster, it is best practice to deploy the event connection to all managed servers in the cluster.
For information about how WebLogic Integration processes adapter events, see Events.
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 the resource type of Services—JMS in Table D-1, WebLogic Integration Deployment Resources, on page D-2.
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. (This is the way the Configuration Wizard generates domains for a cluster.)
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).
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. 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.
The following sections describe examples of how WebLogic Integration uses distributed destinations and server affinity to achieve high availability in a clustered deployment:
Application integration uses a distributed JMS queue (wli.internal.ai.async.request) to manage asynchronous requests entered by application view clients. The Asynchronous Service Request Processor is the message-driven EJB that processes these requests, and this bean is deployed to all servers in a cluster. The method that application integration uses to return the asynchronous response to the application view client depends on the type of the client that submitted the request:
wli.internal.ai.async. response).If a physical queue fails before an asynchronous service request is received by a message-driven bean, the request is unavailable until the physical queue returns to normal operation. The same scenario is true for asynchronous service responses. In the event of a managed server failure, the messages being managed by the JMS server on that managed server become unavailable. Messages being managed by JMS servers on other managed servers remain available and will be processed normally.
| Note: | Asynchronous service requests that have not yet been enqueued to the asynchronous request queue will be lost if the managed server on which the application view instance resides fails. |
All asynchronous requests registered on the asynchronous request queue are dequeued and processed in the scope of a JTA transaction. Applications requiring highly available processing of requests should use the ApplicationView control to invoke the asynchronous service. This will cause the asynchronous response to be delivered to the containing process and web service instance in the same transaction that dequeued the asynchronous request and processed that request against the EIS.
When a server fails, asynchronous requests being processed at that time will be rolled back onto the request queue. When WebLogic transaction manager performs transaction recovery for the failed server, any XA-capable resource managers that have been used by the application view will be asked to rollback their work.
WebLogic Integration process client service invocations made through the application view control occur in a JTA transaction. When a managed server fails, the process will be rolled back to the last commit point. If the process was started using the MessageBroker or other persistent message system, then the entire process can be retried after the start message is delivered.
Application view clients using an AsyncServiceResponseListener instance are actually receiving those messages using the JMS client acknowledge mode. If the server hosting the asynchronous response fails, the message is not acknowledged and will remain on the server.
For information about processing of synchronous and asynchronous invocations for application integration functions, see Application Integration Capabilities and Clients.
Application integration adapters generate events that are consumed by WebLogic Integration processes or by WebLogic Workshop Web services. Events are generated inside an EIS instance that is located outside of the WebLogic Integration cluster. Application integration is made aware of these events by event objects created by event connections within adapter instances. These adapter instances reside on individual managed servers within the cluster.
The behavior of event delivery from the point of origin in the EIS to the point where events are handed off to application integration is adapter-specific and not defined by application integration. For information about how adapter events are processed once the event is delivered to application integration, see Events.
In the case of a single managed server failure, any event in the process of being delivered to application integration on the failed node may be lost. Uninterrupted delivery of other events will continue if the following conditions exist:
Support for multiple event connections within a cluster for a single application view or event type depends on the design of the adapter. For example, the DBMS sample adapter included in the Adapter Development Kit does provide this support. If your adapter does not support multiple event generators, then deploying them in such a configuration could lead to multiple events being delivered to subscribers for a single EIS event. Consult your adapter vendor or adapter documentation to determine if the adapter you are using provides this support.
Deployment of the event connection to more than one managed server in the cluster depends on how you have configured the event connection and adapter instance. Using the WebLogic Integration Administration Console, WebLogic Integration administrators can target an event connection at zero or more managed servers in the cluster. If the adapter supports multiple event generators in a cluster, it is best practice to deploy the event connection to all managed servers in the cluster.
For information on how to target event connections using the WebLogic Integration Administration Console, see Application Integration in Using The WebLogic Integration Administration Console.
For information about how adapter events are processed by WebLogic Integration, see Events.
Applications are deployed in production after creating EAR files from a workshop application. Deploying a process application uses the same steps as deploying a Web service application.
When deploying a WebLogic Integration application to a cluster, keep in mind the following considerations:
wlw-manifest.xml be configured as JMS Distributed Queues, with a member of the distributed queue configured on each managed server. wlw-manifest.xml.For a full overview of application deployment, see Deploying Application To WebLogic Server.
An application integration adapter is typically composed of two components:
The resource adapter (RAR) file should be deployed to the cluster. At a minimum, the resource adapter (RAR) file must be deployed to those managed servers where any application view using the adapter will be deployed. If an application view is deployed to a managed server that lacks the required adapter, the deployment of any adapter instances used by the application view and the application view deployment itself will fail.
The design-time Web application (WAR) file should not be targeted within the cluster. The design-time Web application file is used for development purposes only. WebLogic Integration production environments do not utilize this file.
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.
WebLogic Integration event generators (Email, File, HTTP, JMS, MQSeries, RDBMS, and Timer) can be deployed through the WebLogic Integration Administration Console. For information about how to deploy event generators using the WebLogic Integration Administration Console, see "Creating and Deploying Event Generators" in Event Generators in Using The WebLogic Integration Administration Console.
Event generators can also be deployed using the WebLogic Scripting Tool (WLST). The following three pieces of WLST script show how to create, deploy, and configure an event generator.
| Note: | WLST Offline and WLST Online are available for download and evaluation form BEA's dev2dev site, but have not been formally included in the WebLogic Platform 8.1 product. WLST is supported through BEA newsgroups only, and the utility and APIs are subject to change. BEA intends to formally support this capability in a future release of WebLogic Platform. |
The following excerpt from a WLST script shows how to create a JMS event generator:
import com.bea.wli.mbconnector.jms as eggen
...
eggen.JmsConnGenerator.main([
"-inName", "myEgName",
"-outfile", "mydomain/myEgName.jar",
"-destJNDIName", "myQueueName",])
Once you have created the event generator, you can deploy it to the appropriate target using script similar to the following example:
wlst.deploy( "WLIJmsEG_myEgName", "mydomain/myEgName.jar", myServer )
To configure the properties of the deployed event generator, use a script similar to the following example:
import com.bea.wli.management.configuration as wlicfg
...
# Must have wli.jar in classpath
egCfgMBean = wlst.getTarget("JMSEventGenerators/JMSEventGenerators")
egMBean = egCfgMBean.newJMSEventGenConfigurationMBean( "myEgName")
cData = jarray.zeros( 1, wlicfg.JMSEventGenChannelConfiguration )
cData[0] = wlicfg.JMSEventGenChannelConfiguration()
cData[0].setChannel( "myChannel" )
cData[0].setComment("Default channel")
egMBean.setChannels(cData);
For more information about automating deployment with WLST and other utilities, see "Automating the Promotion Progress" in Overview of WebLogic Platform Deployment in Deploying WebLogic Platform Applications.
| Note: | Code samples and utilities are posted on dev2dev for your convenience. They are not products supported by BEA. |
The following sections provide additional guidelines for event generators.
The email, file, and timer event generators should be targeted to the cluster. They will be active on the managed server containing the migratable server with the queues associated with the specific event generator (for example, wli.internal.egmail.queue for an email event generator).
The sections below describe targeting and error handling issues to take into consideration when you deploy the JMS event generator.
The JMS event generator should be targeted depending on the destination JNDI name of the JMS event generator as indicated in the following table:
|
|||
The JMS event generator has no explicit error handling mechanism. Error handling is provided by associating the JMS event generator queue with an error queue. .
| Note: | It is important to set the Redelivery Limit for a JMS error queue to a number of messages that is practical for your environment. By default, a JMS queue will redeliver error messages and warnings an infinite number of times. |
| Note: | For information about how to set the Redelivery Limit for messages, see JMS-->Queue-->Redelivery in the WebLogic Server Administration Console Online Help. |
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.
The HTTP event generator is a servlet, which takes HTTP requests, checks for the content type, and then publishes the messages to Message Broker channels.
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.
When deploying the RDBMS event generator in a cluster, you need to manually set the Redelivery Delay Override value to 20000 (20 seconds) and the Redelivery Limit to -1 (indicating no limit) for each of the RDBMS event generator JMS queues. You must configure these redelivery settings before generating any events on the cluster.
| WARNING: | Leaving the Redelivery Delay Override and Redelivery Limit set to their default values causes two immediate redelivery attempts for a JMS message when an error condition is encountered. If the second redelivery attempt fails, the message is discarded. |
To configure the redelivery settings for the RDBMS event generator JMS queues in a cluster, complete the following procedure:
For the procedure to start the WebLogic Server Administration Console (and the administration server, if necessary), see "Starting the Administration Console" in Overview of WebLogic Server System Administration in Configuring and Managing WebLogic Server.
ServicesJMSDistributed Destinationsdist_wli.internal.egrdbms.queue_autoMembers.dist_wli.internal.egrdbms.queue_auto_1 through n), select the Redelivery tab, and then enter the following values:
You must also set the Redelivery Delay Override value to 20000 (20 seconds) for single-server deployments. To configure the Redelivery Delay Override value for single-server deployments, complete the following procedure:
For the procedure to start the WebLogic Server Administration Console (and the administration server, if necessary), see "Starting the Administration Console" in Overview of WebLogic Server System Administration in Configuring and Managing WebLogic Server.
ServicesJMSDistributed Destinationswli.internal.egrdbms.queue.20000 in the Redelivery Delay Override field.It is not necessary to manually configure the Redelivery Limit setting for single-server deployments. The Redelivery Limit setting defaults to the correct values in single-server deployments.
|