The MBean Architecture

Every WebLogic instance owns an MBean Server that hosts a number of MBeans. The MBean Server acts as a registry for the MBeans and provides services for accessing and manipulating MBeans running on the server. Because a WebLogic domain may be distributed across multiple machines with differing deployments and domain resources targeted to different servers, the MBean Server for each WebLogic instance will hold different types of MBeans. For instance, the runtime statistics for a JDBC connection pool on a server can be obtained only from an MBean running on that server. WebLogic makes a distinction between three different sets of MBeans:

Configuration MBeans

These expose attributes and operations for the configuration of a resource.

Runtime MBeans

These provide information about the runtime state of a resource.

Security MBeans

These reflect the SSPIs, providing direct access to the configuration of WebLogic's security framework.

To fully understand the MBean architecture as implemented in WebLogic, you need to understand the different types of MBeans and how WebLogic distributes these MBeans across MBean Servers within a domain.

20.1.1 Configuration MBeans

A Configuration MBean holds the configuration for a managed resource or service within a WebLogic domain. WebLogic captures the configuration settings for all kinds of domain resources and services: web servers, clusters, JDBC connection pools, J2EE components (EJBs, web applications, resource adapters), JMS destinations, XML Registries, web services, and many more. The definitive list of Configuration MBeans can be found within the API documentation under the weblogic.management.configuration package. Here are a few examples:

DomainMBean

This MBean represents a WebLogic Domain. You can use it to access various attributes of the domain (e.g., Administration Port), or even explore subcategories of configuration settings such as JTA, Security, Logging, and others. In addition, you can access the configuration settings for the managed servers within the domain.

ServerMBean

This MBean represents a WebLogic Server instance. You can use it to access virtually all the attributes for the server: server name, listen address and port, external DNS name, and many more. You also can use the MBean to acquire configuration settings for the web server, the cluster to which the server belongs, the machine that hosts the server, the XML Registry, and other related resources that have been configured for the server.

JDBCConnectionPoolMBean

This MBean represents a JDBC connection pool configured within a domain. It can be used to access the various configuration settings for a connection pool, such as its capacity, driver name, and database URL.

The configuration of a managed resource is described entirely by the state of the MBean representing that resource. As we learned in Chapter 13, the Administration Server is responsible for managing the configuration of a domain and distributing the relevant portions of the configuration to different Managed Servers. The config.xml file that is used by the Administration Console to persist the current state of the domain's configuration is nothing more than a serialization of all the Configuration MBeans on the Administration Server. When the Administration Server starts up, it reads this domain configuration file and reconstructs the set of Configuration MBeans in its local MBean Server. So, the Administration Server is the prime host for all Configuration MBeans, and using the Administration Console is one of the easiest ways of manipulating these MBeans.

When a Managed Server starts up, it asks the Administration Server for its own server configuration. The Administration Server responds by sending back a subset of those MBeans that are relevant to the Managed Server. This includes the MBeans that reflect the configuration of all resources and services deployed to that server. Hence, the Administration Server holds the master copy of all Configuration MBeans for all resources within a domain, while the MBean Server on each Managed Server hosts local replicas for all resources that are targeted to the Managed Server.

This replication of Configuration MBeans hosted on the Administration Server occurs for performance reasons as well. Local clients of the Managed Server can simply use the local replicas of the Configuration MBeans, without having to contact the MBean Server running on the Administration Server. Figure 20-1 illustrates this process.

Figure 20-1. Distribution of Runtime and Configuration MBeans in a domain

The Configuration MBeans hosted by the Administration Server are called Administration MBeans, while the replicas hosted on the Managed Servers are called Local Configuration MBeans. Any permanent changes to the configuration of a domain must be made through the Administration MBeans. These changes then will propagate through to the Local Configuration MBeans on all running Managed Servers.

The Administration Server periodically serializes the state of its Administration MBeans to the domain's config.xml configuration file, making them permanent. This serialization also occurs when the Administration Server detects that one or more configuration settings have been changed. Sometimes, a domain resource instantly is updated to reflect any changes made to its configuration settings. In other cases, the resource may define configuration settings whose value changes come into effect only after you restart the server that hosts the resource. In this case, the changes to the configuration won't dynamically alter the behavior of a resource. The Administration Console gives you an indication of which configuration settings require a server restart by placing a caution icon (a yellow triangular icon) next to the attribute name. Although the changes to these attributes are persisted instantly, the actual change to the resource occurs only after you restart the server to which the resource or service has been targeted. The JavaDoc documentation also indicates explicitly which attributes of the MBean are dynamically configurable.

Though Administration MBeans have a persisted state, the Local Configuration MBeans are transient. If the server instance hosting the Local MBeans is shut down, then their in-memory state is lost. This is not a problem because the Local MBeans are reinitialized the next time the server boots and makes contact with the Administration Server. You can, however, make temporary changes to particular server instances. For example, you could use the command-line option -Dweblogic.ListenPort=7501 during server startup to change the listen port of a Managed Server. This option temporarily updates the listen port information in the local ServerMBean running on that Managed Server only, and the change lasts as long as the server is alive. Moreover, this setting has no effect on the master copy of the ServerMBean on the Administration Server.

The same distinction between Local and Administration MBeans is maintained even if you deploy applications to the Administration Server. In this case, the Administration Server hosts both Administration and Local Configuration MBeans.

Chapter 13 shows how a Managed Server can be configured to start up in Managed Service Independence (MSI) mode, in the absence of an Administration Server. This mode effectively replicates the domain's configuration file; when the Managed Server starts up, it creates its own copy of the Administration MBeans. It then extracts its own Local Configuration MBeans, allowing it to start up as usual. You should not interact with the Administration MBeans on a server running in MSI mode, as it does not host the definitive configuration, and any changes you make will not be replicated to the rest of the domain.

20.1.2 Runtime MBeans

Runtime MBeans reflect the runtime state of resources. As such, they are not replicated like Configuration MBeans, but rather exist only on the same server as the underlying managed resource. Figure 20-1 shows how each server instance holds its own set of Runtime MBeans and Local Configuration MBeans. WebLogic maintains the runtime state of a whole range of domain resources, including servers, clusters, EJB instance pools, JTA transactions, servlets, JMS producers and subscribers, and many more. The definitive list of Runtime MBeans can be found in the API documentation under the weblogic.management.runtime package. Here are a few examples of Runtime MBeans provided by WebLogic:

ServerRuntimeMBean

This MBean holds the runtime state of a WebLogic instance. It can be used to find the state of the server instance and the number of open sockets.

EJBPoolRuntimeMBean

This MBean can be used to access the runtime state of an EJB pool, providing access to an array of runtime statistics, including the total number of bean instances in use and the number of threads waiting for a bean instance to be made available.

JDBCConnectionPoolRuntimeMBean

This MBean can be used to access the runtime information of a JDBC connection pool, providing access to the total number of current connections.

A Runtime MBean provides runtime information on a resource, as well as operations that can modify its runtime state. For instance, the ServerRuntimeMBean allows you to restart a suspended server. Runtime MBeans are transient, so when the hosting server instance is shut down, all of the MBean's associated state is lost.

20.1.3 Security MBeans

The third category of MBeans reflects the SSPIs provided by WebLogic's security framework, which we covered earlier in Chapter 17. These MBeans can be found in the weblogic.management.security package hierarchies. The security framework uses the MBeans to access and configure the security within a domain, so any implementation of the SSPIs must be accompanied by an implementation of the MBeans as well. Naturally, the default security implementation that ships with your WebLogic distribution does just this.

The Security MBeans comprise sets of required and optional MBeans. The required MBeans provide access to the main interfaces. For instance, the AuthenticatorMBean is used by the authentication services. The base MBean implementation merely lets you retrieve and set the control flag setting. Custom implementations of the Authenticator SSPI also are required to provide an MBean with which to manage the implementation. This custom Security MBean must extend the AuthenticatorMBean, and may even provide additional management attributes and operations. Security SSPI implementations may implement additional MBean interfaces, such as the UserAddEditorMBean and UserRemoverMBean that can be used to create, edit, and remove users from the security realm.