Clustering Workshop Web Services
Clusters are used to provide scalability and support failover for web resources. The basic clustering model consists of the following elements:
One administration server that manages state and configures the other servers in the cluster
One HTTP proxy server—either a hardware or a software proxy server—which receives requests from clients and distributes jobs to the other servers in the cluster
Any number of managed servers that actually do the work of servicing requests from clients
All configuration of the cluster takes place on the administration server. All servers in the cluster use the copy of config.xml on the administration server. There may be local copies of config.xml on the managed servers in the cluster, but, these copies of config.xml are ignored in favor of the copy on the administration server.
When Workshop EARs are deployed to a cluster, the managed servers must be homogeneously configured. That is, all managed servers must run the same set of JWS resources: it is not possible to have one set of servers handle some JWSs in an EAR and another set of servers handle other JWSs in an EAR. The following required Workshop resources must also be deployed homogeneously across all servers in a cluster: JDBCConnectionPool, JDBCTxDatasource, JMSQueueConnectionFactory. A JMS Server is also a required Workshop resource, however, it can only be deployed to one server in the cluster.
Complete syntax for the config.xml file can be found at WebLogic Server Configuration Reference in the WebLogic Server 7.0 documentation.
The following section hightlights some of the most import elements within a cluster-defining config.xml file (located on the administration server).
The ClusterAddress attribute specifies a DNS name that maps to the list of IPs of the servers. ClusterAddress does not give the DNS name of the multicast address, which does not require a DNS name. The cluster as a whole can be used as a deployment target. To deploy a J2EE resource to the entire cluster, use the value of the Name attribute as the target of the deployment. See the -targets parameter of the deployment tool, weblogic.Deployer, in the WebLogic Server 7.0 documentation.
Resources in the cluster—such as database connection pools, data sources, and JMS servers—are defined in the administration server's config.xml file. Resources are not by default universally available across the cluster. The servers they are deployed to are specified by their Targets attributes.
Workshop resources must deployed homogenously across the servers in the cluster. That is, the same Workshop resources must be distributed to each server on the cluster. The connection pool and conversational datasource that Workshop relies on is defined on each managed server in the cluster. For example, the Targets attribute on the JDBConnectionPool and JDBCDataSource elements specifies each managed server, and each managed server has its own pool of connections.
The queue connection factory that Workshop relies on is defined on each managed server.
However, the JMSServers can only be targeted at one WLS server. Currently Workshop only uses one JMSServer that is targeted, by convention, at the first managed server in the cluster.
Workshop clusters currently only support Oracle 8.1.7. To change the supported database edit the JDBC elements within config.xml.
Clusters can use a software proxy server to distribute HTTP requests across the cluster. The proxy server is also called the sprayer or load balancer. This software proxy is implemented as a web application deployed to the proxy server. You configure the proxy by editing the web.xml descriptor in the proxy application’s WAR file. There are entries in the descriptor for specifying what IP addresses and ports the proxy should distribute requests to. For more information about configuring the proxy server see Configure Proxy Plug-Ins in the WebLogic Server 7.0 documentation.