How WebLogic Server Updates the JNDI Tree Client Interaction with the Cluster-Wide JNDI Tree

Communications In a Cluster 3-11

3.2.3 How WebLogic Server Updates the JNDI Tree

When a clustered object is removed undeployed from a server instance, updates to the JNDI tree are handled similarly to the updates performed when new services are added. The server instance on which the service was undeployed broadcasts a message indicating that it no longer provides the service. Again, other server instances in the cluster that observe the multicast or unicast message update their local copies of the JNDI tree to indicate that the service is no longer available on the server instance that undeployed the object. Once the client has obtained a replica-aware stub, the server instances in the cluster may continue adding and removing host servers for the clustered objects. As the information in the JNDI tree changes, the clients stub may also be updated. Subsequent RMI requests contain update information as necessary to ensure that the client stub remains up-to-date.

3.2.4 Client Interaction with the Cluster-Wide JNDI Tree

Clients that connect to a WebLogic Server cluster and look up a clustered object obtain a replica-aware stub for the object. This stub contains the list of available server instances that host implementations of the object. The stub also contains the load balancing logic for distributing the load among its host servers. For more information about replica-aware stubs for EJBs and RMI classes, see Section 6.3, Replication and Failover for EJBs and RMIs. For a more detailed discussion of how WebLogic JNDI is implemented in a clustered environment and how to make your own objects available to JNDI clients, see Using WebLogic JNDI in a Clustered Environment in Programming JNDI for Oracle WebLogic Server 3-12 Using Clusters for Oracle WebLogic Server 4 Understanding Cluster Configuration 4-1 4 Understanding Cluster Configuration This following sections explain how the information that defines the configuration of a cluster is stored and maintained, and the methods you can use to accomplish configuration tasks: ■ Section 4.1, Cluster Configuration and config.xml ■ Section 4.2, Role of the Administration Server ■ Section 4.3, How Dynamic Configuration Works ■ Section 4.4, Application Deployment for Clustered Configurations ■ Section 4.5, Methods of Configuring Clusters

4.1 Cluster Configuration and config.xml

The config.xml file is an XML document that describes the configuration of a WebLogic Server domain. config.xml consists of a series of XML elements. The Domain element is the top-level element, and all elements in the Domain descend from the Domain element. The Domain element includes child elements, such as the Server, Cluster, and Application elements. These child elements may have children of their own. For example, the Server element includes the child elements WebServer, SSL and Log. The Application element includes the child elements EJBComponent and WebAppComponent. Each element has one or more configurable attributes. An attribute defined in config.dtd has a corresponding attribute in the configuration API. For example, the Server element has a ListenPort attribute, and likewise, the weblogic.management.configuration.ServerMBean has a ListenPort attribute. Configurable attributes are readable and writable, that is, ServerMBean has a getListenPort and a setListenPort method. To learn more about config.xml, see Domain Configuration Files in Understanding Domain Configuration for Oracle WebLogic Server.

4.2 Role of the Administration Server

The Administration Server is the WebLogic Server instance that configures and manages the WebLogic Server instances in its domain. Note: Much of the information in this section also pertains to the process of configuring a WebLogic domain in which the server instances are not clustered.