Understanding WebLogic Domains

A WebLogic domain is an important administrative feature for a WebLogic Server administrator to understand because it defines the administrative boundaries of a WebLogic Server's environment. All applications that are deployed to WebLogic Server are deployed and managed in the context of a WebLogic domain. A WebLogic domain is composed of one or more WebLogic Servers, where one server is configured as the administration server and all additional servers in the same domain are configured as managed servers , which can exist independently or in the context of one or more WebLogic clusters. A WebLogic cluster is essentially two or more managed servers that share their resources to provide scalability and high-availability solutions for applications. WebLogic clusters are discussed in more detail in Chapter 25, "Implementing Highly Available and Scalable Solutions Using the WebLogic Cluster."

The types of WebLogic Server instances that constitute a WebLogic domain are shown in Figure 24.1.

Figure 24.1. This WebLogic domain contains an administration server, two independent managed servers, and a WebLogic cluster.

If a WebLogic domain contains a standalone administration server, that WebLogic Server instance will function as an administration server as well as a managed server. This is a common configuration for developers who require their own WebLogic development environment, or for anyone who is becoming familiar with WebLogic Server because this is the easiest WebLogic domain configuration to implement.

WebLogic administrators have the option to manage their entire WebLogic Server environment as a single domain. Alternatively, administrators can opt to define multiple mutually exclusive domains based on different administration/monitoring, business, or technical criteria. Scenarios in which it may be necessary to define multiple domains include the following:

• There is a need to create separate development, test, and production WebLogic Server environments.

  This is the de facto standard for staging applications and their operating environments through a software development life cycle.

  Tip

  Alternatively, you can achieve the same objective by having one WebLogic domain and different managed servers configured for development and testing. A production WebLogic domain should always be kept separate from nonproduction WebLogic domains.

  
  

• The applications to be deployed possess varying service-level agreements or grades of criticality.

  Separate domains can be used to deploy mission-critical applications, where the degree of administration and monitoring diligence will differ from non “mission-critical type applications.

  Tip

  Alternatively, you can configure different managed servers with varying service-level agreements in the same domain.

  
  

• The WebLogic Server environment is dispersed across multiple machines that are physically and geographically disparate.

  The concept of domains can be used to create localized WebLogic Server administration environments (units), which for example can be based on the physical location of WebLogic Servers.

• There is a need to manage large mission-critical applications.

  Mission-critical applications always require extensive administration and monitoring, and sometimes partitioning the applications into manageable, tightly coupled functional domains is the most efficient solution. For example, if an application has distinct functional modules such as Accounting, Sales, and Human Resources, each of these modules can be managed by a separate WebLogic domain.

Having multiple mutually exclusive WebLogic domains does not imply that applications in those domains cannot communicate with each other. It just defines independent administration environments for a select number of WebLogic Server instances.

If you decide to create multiple domains to manage your WebLogic environment, you should keep the following caveats in mind:

• All WebLogic cluster instances in a WebLogic domain must be of the same version and service pack of the WebLogic Server software.

  Note

  The WebLogic Server 7 administration server can be used to manage WebLogic Server 6.x managed servers.

  
  

• WebLogic clusters cannot span across multiple WebLogic domains.

• WebLogic resources, such as JDBC connection pools, security configurations, and J2EE applications, in one domain cannot be shared with other domains.

The Relationship Between Administration and Managed Servers

The role of the administration server is to run the administration service for the entire domain, providing a central control for configuring, managing, and monitoring all aspects of a WebLogic domain, including

• Logging critical activities and events related to the WebLogic domain

• Configuring and managing the WebLogic domain security policies

• Monitoring the health of the managed server instances in the WebLogic domain, such as the JDBC, JMS, Web, and EJB container subsystems

• Configuring and managing the WebLogic domain resources and J2EE services, such as machines, network channels, JDBC, JMS, JNDI, JTA, and JavaMail

• Managing (deploying and monitoring) J2EE Web and enterprise applications

• Starting up and shutting down the managed servers and WebLogic clusters within the domain

The configuration information for the entire WebLogic domain is maintained by the administration server in a configuration repository, which currently exists as an XML file named config.xml . The config.xml file is, by default, located in the root of the directory from which the administration server is launched, and can be viewed using a Web browser or any XML editor. The config.xml file is discussed in detail in the next section.

The role of a managed server is to execute the applications that are deployed to its WebLogic domain and make available their status to the administration server. Upon startup, managed servers

• Retrieve their configuration and application deployment settings from their designated administration server.

• Register themselves with the administration server, at which point the administration server will begin to gather runtime state and monitoring information from them.

The configuration settings that are received by a managed server from an administration server include the config.xml and the SerializedSystemIni.dat files. Upon receiving these files, a managed server always caches them to its root directory on the local file system. You also have the option to manually copy these files from the administration server's root directory to the managed server's root directory. By default, the directory from which an administration or managed server is launched is considered its respective root directory. Without the presence of these files, you cannot start a managed server.

By default, the encrypted boot.properties file, which enables WebLogic Server to start up while bypassing the startup prompt for username and password, is not automatically copied from the administration server to any managed server. If you want to use this file in the startup of your managed servers, you will need to manually copy the file from the root directory of the administration server to the root directory of your managed server.

After the initial startup and shutdown of a managed server, if the administration server becomes unavailable before a managed server is started, these cached configuration files are used to start the managed server. However, the managed server cannot persist any changes of its state or even be managed or monitored until its designated administration server is available again. Managed servers that are started in this manner are in Managed Server Independence ( MSI ) mode. When an administration server is started, it queries its running-managed-servers.xml file to identify the managed servers that were registered with it so that they can be notified to reregister with the administration service.

Tip

If a managed server runs on the same machine as its administration server, the cached configuration files will be located in the same root directory of the administration server. If these files are not located in a directory from which the managed server is started, you can explicitly specify the location of the configuration files by using the -Dweblogic.RootDirectory= path startup option.

It is only at startup that managed servers have a slight dependency on the availability of an administration server. When they are operational, the only consequence for shutting down an administration server is that the administration service will not be running, which has no effect on the execution of an application on the managed servers.

Note

When the administration service is not running, no changes can be made to the WebLogic domain's configuration.

The relationship between the administration and managed servers is summarized in Figure 24.2.

Figure 24.2. The relationship between the administration and managed servers in a WebLogic domain.

Tip

To ensure the administration service does not present a point of failure or impede the performance for an application in a domain, BEA recommends you use a dedicated WebLogic Server instance within a domain as an administration server, with all applications deployed on the domain member managed servers.

Administering a WebLogic Domain from an Infrastructure Perspective

The management of a WebLogic domain is, in essence, a collective management effort of all the subsystems (resources and services) of WebLogic Servers that constitute a domain. The management capabilities (configuration and monitoring) of these subsystems as well as the applications they support are represented within WebLogic Server as MBeans (managed beans), which are implemented as Java classes in compliance with the Java Management Extension (JMX) specification as defined by Sun. The WebLogic administration service institutes management of subsystems such as the Web and EJB containers, JDBC, JMS, SNMP, and JTA, through their respective MBeans.

Each WebLogic Server subsystem has a set of attributes that can be configured and monitored, with some subsystems providing additional management capabilities through administration methods. The role of an MBean is to provide an administration interface to these attributes and methods of a WebLogic Server subsystem, decoupling the subsystem from its management interface.

As shown in Figure 24.3, one or more MBeans can be associated with each WebLogic subsystem, and can include the following elements:

Figure 24.3. The elements of a WebLogic Server MBean.

• A set of attributes that define parameters for various management functions, which are persisted to the config.xml domainwide configuration file

• A suite of methods used to execute management functions such as listing, setting, and getting the MBean attributes

• Methods for executing additional WebLogic Server resource administration operations

• A notification system for broadcasting MBean events

The following three types of MBeans are used to manage a WebLogic domain:

• Administration MBeans ” These MBeans reside only in the administration server of a domain. They initially contain preset configuration parameters for the management functions for all WebLogic Servers in a domain. When an administration server is started, these default parameter values are overridden by their associated values from the config.xml file, which provides persistent storage of Administration MBean attribute values. Every five minutes, the administration service determines whether the Administration MBeans have been modified, with any changes persisting to the config.xml file.

• Configuration MBeans ” These MBeans are used to configure the managed servers in a WebLogic domain and are resident only on managed servers. They are copies of the Administration MBeans that are received from the administration server by the WebLogic managed servers when they are started.

  To provide a central management system of Configuration MBeans on managed servers, the administration server hosts an Administration MBean for each Configuration MBean in a WebLogic domain. When changes occur to these Administration MBeans, they are propagated to their counterpart Configuration MBeans on the managed servers.

  The Administration MBeans attribute values can be overridden by specifying attributes directly on the command line while starting the managed server. If any of the configuration attributes in a Configuration MBean are overridden by specifying the value of the Mbean attribute at the command line while starting the Managed server, the values do not persist to the domainwide config.xml file of the administration service.

  Note

  The interface types for Administration and Configuration MBeans are located in the weblogic.management.configuration package, which can be reviewed in the BEA JavaDocs.

  
  

• Runtime MBeans ” These MBeans contain attributes that specify the runtime information of a WebLogic Server resource or an application in a domain. They are primarily used to provide monitoring information and hence cannot be directly set by the Administration Console or the weblogic.Admin utility.

Note

The interface types for Runtime MBeans are located in the weblogic.management.runtime package.

Because the administration server can also behave as a managed server, it also hosts the Configuration MBeans and Runtime MBeans that pertain to its own resources and applications.

The system administration tools provided with WebLogic Server ”the Administration Console and weblogic.Admin utility ”provide an interface to the administration service, allowing you to manage a WebLogic domain without requiring any knowledge of the JMX API. However, knowledge of the WebLogic MBean interfaces is required to use the weblogic.Admin utility to interface with the administration service.

The Administration Console is the preferred Administration tool, allowing you to manage and view the attributes of Administration and Runtime MBeans through a graphical interface (such as a Web browser). The Administration Console can manage only one WebLogic domain at a time; therefore, multiple WebLogic domains require their own instance of the Administration Console. From the Administration Console, you can also determine the MBean attribute you are working with by clicking the question mark next to an attribute field. However, the Administration Console enables you to manage and view only the attributes of Configuration MBeans.

Alternatively, the weblogic.Admin tool enables you to manage and retrieve the attributes of Administration and Configuration MBeans, as well as invoke the methods of Runtime MBeans through the CREATE , DELETE , GET , SET , and INVOKE commands.

Note

For the syntax and usage of the weblogic.Admin commands, refer to the MBean Management Command Reference in the WebLogic Server Administration Guide.

Both the Administration Console and the weblogic.Admin tools should provide you with the initial administration and monitoring capabilities you need for your environment. However, if you have administration requirements that are not satisfied by these tools, you can either write your own JMX extensions to the Administration Console, or you can purchase a suitable WebLogic Server administration tool provided by one of BEA's solution partners , which are listed on the BEA Web site.