10.4.1 The Base Managed-Object ModelAs shown in Figure 10.1, all objects modeled in JSR 77 inherit from the J2EEManagedObject model. So regardless of the specific attributes and operations they provide, all managed resources include at least an objectName String attribute and three boolean attributes that give a little more information about the capabilities of the object (see Table 10.1). Figure 10.1. Overview of the J2EE Managed-Object Model
The objectName attribute for J2EEManagedObject is a subclass of the Java String type that complies with the JMX ObjectName format. The objectName attribute is used to locate the managed object within the J2EE management domain, so application server vendors must ensure that it is unique within that domain. Like any other instance of the JMX ObjectName class, this one contains a domain part and a properties part. Table 10.1. J2EEManagedObject Attributes
The domain part of the name identifies the scope of the management system. If the management program is connected with two or more J2EE environments, this attribute can be used to distinguish the managed objects that belong in one environment from those that belong in the other. JSR 77 does not specify how this domain identifier is calculated or structured ”only that it cannot contain characters that are used as separators in JMX ObjectName syntax. The restricted characters are the colon (:), comma (,), equal sign (=), asterisk (*), and question mark (?). There are several properties required by JSR 77 that the application server vendor will set for all managed objects in their domain. These required properties further identify the managed object, as well as place it within the containment hierarchy of the J2EE management domain:
Table 10.2. J2EEManagedObject Parent Properties
Note that the application server vendor may include additional objectName properties beyond what is required for JSR 77. These properties would be used by the server vendor's internal implementation, and you should not count on any properties other than those defined by JSR 77 to be available to portable J2EE management programs. As for the remaining J2EEManagedObject attributes, stateManageable lets the management program know whether this object can have its state altered through explicit operations such as start() and stop() . The statisticsProvider attribute lets the management program know that this object returns performance statistics in the form defined in JSR 77 for the type of object. The eventProvider attribute lets the management program know that this object generates events for significant situations that occur during the lifecycle of the object. We'll look at the details of the standard management functions for state management, statistics, and events later in this chapter. Right now, let's focus on the rest of the managed resources represented in the model. 10.4.2 The Management Domain ModelJSR 77 contains an object hierarchy. The top object in the hierarchy is J2EEDomain . J2EEDomain is the entry point to the application server management system. It is the object from which all other managed objects are obtained by the management tool. J2EEDomain is intended to represent a complete management domain for the application server environment. This domain may contain one or many application servers. The domain may span networks and computer systems, or it may encompass only a single operating system process. The application server vendor determines the scope of J2EEDomain . Methods on the J2EEDomain object allow management tools to query the object in order to learn how many servers are part of the domain. Table 10.3 contains the attributes defined in JSR 77 for the J2EEDomain object. As illustrated in Figure 10.2, the J2EEDomain object can provide a management tool with the list of all J2EEServer instances in that management domain. Figure 10.2. Top-Level Model Hierarchy of JSR 77
10.4.3 The J2EE Application Server ModelWith its contained resources and components , J2EEServer provides a topological view of the management environment. It is meant to represent the server runtime components. J2EEDeployedObject (described in Section 10.4.4), and its subparts, provides an application-centric view of the environment. Taken together, management programs have a lot of flexibility for how they query the application server, display its data, and navigate its various levels of management detail. Figure 10.3 illustrates all of the J2EEServer subcomponents. Figure 10.3. J2EEServer Subcomponents
Table 10.3. J2EEDomain Attributes
Table 10.4. J2EEServer Attributes
Table 10.4 contains the attributes defined in JSR 77 for the J2EEServer object. It is important to understand that the JSR 77 models are abstract representations of how the vendor has implemented the application server product. A particular application server product may not have a single J2EEServer object. The functions represented by the JSR 77 J2EEServer objects may be spread out among several different objects in the product architecture. But a compliant application server must find a way to direct management requests addressed to J2EEServer to the real managed resources in the product. That's the challenge to platform vendors. Let's look at the details underneath the J2EEServer object. The JSR 77 model for J2EEServer includes three required attributes, the JVM, the vendor name, and the version of the application server. The platform vendor sets the serverVendor and serverVersion properties. These properties identify the server. If J2EEDomain supports multiple versions of the server runtime, then these different J2EEServer instances can be recognized through their serverVersion attributes. If the management program maintains a list of J2EEServer instances from different domains, the servers can be distinguished from each other by their serverVendor attributes. Two parallel sets of information are encapsulated within J2EEServer . A management program can take an application-centric view of the domain, or it can take a physical runtime view of the domain. The lists maintained in J2EEServer support either view. There is an operation defined on J2EEServer that returns a list of J2EEDeployedObject instances (applications or application components, depending on the vendor implementation) associated with that server. The other lists maintained by J2EEServer are for more physically oriented objects. There are operations to return a list of Java Virtual Machines (one or more, depending on the product) associated with this server. And another operation provides a list of J2EEResource objects that are used by the server or applications running within the server. 10.4.4 J2EE Application Component ModelsJ2EEDeployedObject is the base class model for all application module components. Table 10.5 lists the attributes of this base class. We assemble J2EE applications by combining several application modules. The application modules are sets of application components of the same type. For instance, EJBModule is a collection of one or more Enterprise JavaBeans. WebModule is a set of servlets, JSPs, and Web application content items. Java 2 Connector architecture implementations are packaged as instances of ResourceAdapterModule . Application client code is separated from the server-side logic into instances of AppClientModule . All J2EEDeployedObject subclasses provide the base attributes for server and deploymentDescriptor . The server attribute is the objectName String attribute of the J2EEServer on which the object is deployed. The deploymentDescriptor attribute is the String representation of the standard J2EE deployment descriptor, an XML file that includes all of the information covering the details of how the application component is configured. An instance of J2EEDeployedObject can represent an entire application or a single module of an application. As Figure 10.4 shows, there are specific subclasses of J2EEDeployedObject for each type of module and one for the overall application. Figure 10.4. J2EEDeployedObject Subcomponents
A J2EEApplication object represents the overall application. This object provides a list of all of the modules that make up the application. Table 10.6 shows the attributes for the J2EEApplication object. The list of modules returned by J2EEApplication (in the modules attribute) may include any of the various module types. Those types are all subclasses of the J2EEModule type. Table 10.5. J2EEDeployedObject Attributes
Table 10.6. J2EEApplication Attributes
As shown in Table 10.7, every module provides a list of the JVMs on which it is running. We will look at the JVM managed object model in more detail later in this chapter. There are four subclasses of J2EEModule : WebModule , EJBModule , ResourceAdapterModule , and AppClientModule (see Figure 10.4). AppClientModule has no attributes defined by JSR 77. However, as with all other JSR 77 models, vendors may extend this managed object to expose proprietary attributes that may be of interest to management programs. Table 10.7. J2EEModule Attributes
A J2EE Connector architecture (JCA) [12] ResourceAdapterModule contains one or more JCA resource adapters. Resource adapters provide the logic to link an application with some back-end enterprise information system (EIS) resources. Examples of such EIS resources are customer information control system (CICS) applications, database systems, customer relationship management (CRM) programs, or any kind of resource manager that returns data of use to the J2EE application. ResourceAdapterModule maintains a list of the resource adapters that are deployed as part of that module. This list is exposed as the resourceAdapters attribute (see Table 10.8). WebModule represents a Web application. Web applications are composed of servlets, JSPs, and other content that is delivered to a Web browser over an HTTP connection. The JSR 77 WebModule subclass of J2EEModule , supports an attribute that is the list of servlets contained in the module (see Table 10.9). An EJBModule instance encapsulates one or more Enterprise JavaBeans (EJBs). EJBs come in a variety of types. EntityBean EJBs represent persistent data stored in a database. SessionBean EJBs represent an interactive session between the application client and the application logic in the server. And MessageDrivenBean EJBs represent the listener end of a messaging system, and provide a mechanism by which requests from an asynchronous messaging system can be delivered to the system. SessionBean is further subdivided into stateful and stateless types, depending on whether persistent data is associated with the client session. The EJBs that are combined in one instance of EJBModule may be of different EJB types. Instances of SessionBean and EntityBean can be mixed in the same module. MessageDrivenBean instances can be part of the same module also. The ejbs attribute of EJBModule (see Table 10.10) returns a list of all of the EJBs deployed in the module, regardless of EJB type. Table 10.8. ResourceAdapterModule Attributes
Table 10.9. WebModule Attributes
Table 10.10. EJBModule Attributes
Table 10.11. J2EEModule Subclasses and Application Components
Table 10.11 lists the various J2EEModule subclasses and the application components that each module type may contain. 10.4.5 J2EE Server Runtime ComponentsThe J2EEDeployedObject model provides the management tool with an application-centric view of the system. The topology represented covers all of the information related to applications that may be running within the management domain. The other perspective on the domain is one oriented toward the physical resources in use to provide the operating environment in which the applications are served . The JVM class and subclasses of the J2EEResource model provide this server runtime view of the system. In addition to a list of deployed objects, J2EEServer provides a list of JVMs and a list of J2EEResource instances. Table 10.12 shows the attributes of the JVM object. Each application server is associated with at least one Java Virtual Machine (JVM). Some application servers run in several JVMs concurrently. The JSR 77 models provide for this implementation by exposing the JVM attribute of the server as a list rather than a single object instance. Table 10.12. JVM Attributes
The JVM model includes attributes for identifying the version of the virtual machine and the vendor that implemented the JVM. The node attribute of JVM is the fully qualified host name of the system on which the JVM is executing. The J2EEResource objects represent system resources that are used by the server or its applications. These can be external resources, such as databases, messaging systems, transaction monitors , naming directories, or mail servers. J2EEResource instances can also be internal to the server, such as the object request broker (represented by the RMI-IIOP model in JSR 77). Figure 10.5 illustrates the set of J2EEResource instances defined in the specification. Figure 10.5. Subclasses of J2EEResource Defined in JSR 77
The JSR 77 management models do not include much detail for the various subclasses of J2EEResource . Most application server vendors are likely to extend these models with specific implementations that match their internal runtime. The importance of the J2EEResource classes is to provide a structure for management programs to navigate the server runtime. The J2EEResource classes also provide an important hook for exposing performance data that will be discussed in Section 10.5. The following list covers the J2EEResource subclasses, including an explanation of what each model represents:
|