Free University of Bolzano/Bozen Faculty of Computer Science Bachelor of Science in Applied Computer Science Configurable JMX-based Monitoring Tool for JBoss on top of Eclipse Rich Client Platform Cristiano Maria Cumer Supervisor: Prof. Werner Wild Academic Year 2003/2004 1st Graduation Session - July 30, 2004
ABSTRACT The aim of this project is to develop a simple yet configurable management tool for a JBoss application server. Some tools performing this task are already available, but none is targeted to Eclipse or is open-source, and the web-based management tool included in JBoss is dispersive and insufficient. The management tool is written as an Eclipse plugin and is hosted inside the Eclipse application portal, as Eclipse with JBossIDE is the IDE of choice of the JBoss Group. The proposed monitoring tool communicates with the JBoss application server using JMX (Java Management Extension) and uses GEF (Graphical Editor Framework) of Eclipse to display information about the monitored server(s). The displayed information is fully configurable, so that the user can focus only on the really important data, without being distracted by nonrelevant information. 2
ACKNOWLEDGEMENTS I want to thank Prof. Werner Wild (Data Communication I Programming Languages Project Management Free University of Bolzano/Bozen) for supervising my thesis and the thesis project. I am also very grateful for the great lessons he gave here at the Free University of Bolzano: during them I have learned to be a better applied software developer. I also express my gratitude to the staff of the faculty secretary, particularly Federica Cumer, Dott.ssa Stefania Fiorese and Dott.ssa Sara Mani, for the great and kind support provided during this three years of studies. I am grateful to all my company colleagues, Dott. Giovanni Barone, Lorenzo Paccagnella, Eleonora Gelmo, Dott.ssa Ornella Rosoli, Massimo Colella, Christian Esposito for the help and the comprehension expressed during my studies, allowing me to conclude successfully this learning experience. I am also thankful to my friend Ana Stojanović and again my sister Federica for revising the English of this thesis. I also want to thank Dr. Barbara Weber of the University of Innsbruck for the great programming experience we had together. Someday this war's gonna end. That would be just fine with the boys on the boat. Captain Willard, Apocalypse Now, 1979 3
TABLE OF CONTENT ABSTRACT... 2 ACKNOWLEDGEMENTS... 3 TABLE OF CONTENT... 4 LIST OF FIGURES... 5 LIST OF TABLES... 5 INTRODUCTION... 6 WHY A MONITORING CONSOLE FOR JBOSS... 6 USING ECLIPSE AS DEVELOPMENT AND DEPLOYMENT PLATFORM... 6 EXTENSIBILITY... 6 BACKGROUND... 7 JMX... 7 What is JMX... 7 JMX Components... 7 Architecture... 7 MBean Notifications... 8 MBean Types... 8 MBean Metadata Classes... 9 RCP... 10 GEF... 10 The GEF MVC paradigm... 10 GEF Structure... 11 JBOSS... 13 JBoss architecture... 13 PROBLEM DESCRIPTION... 14 REQUIREMENTS FOR THE APPLICATION... 14 IMPLEMENTATION FOR THE THESIS... 15 PROPOSED SOLUTION... 16 TOOLS... 16 APPLICATION ARCHITECTURE OVERVIEW... 16 JMX CONNECTION MANAGEMENT... 17 JMXBROWSER... 17 Introduction... 17 Implementation... 17 THE MANAGEMENT PANELS... 18 Introduction... 18 Implementation of the Management Panels (GEF Editor)... 19 Persistency of the management panels... 21 THE BEAN VIEW... 21 Introduction... 21 Implementation... 21 MONITORING OF MBEAN ATTRIBUTES... 21 CONCLUSION & FURTHER STUDIES... 23 CONCLUSIONS... 23 FURTHER STUDIES... 23 GLOSSARY... 24 TECHNOLOGY SPECIFIC TERMINOLOGY... 24 REFERENCES... 25 4
LIST OF FIGURES FIGURE 1: JMX SERVICES LEVEL 8 FIGURE 2: UML MODEL OF THE MBEAN METADATA CLASSES [PERRY02] 9 FIGURE 3: THE STANDARD MVC [ECLI04] 11 FIGURE 4: THE GEF IMPLEMENTATION OF MVC. NO DIRECT CONNECTION FROM THE VIEW TO THE CONTROLLER [ECLI04] 11 FIGURE 5: EDITPART AND INSTALLED EDITPOLICIES [ECLI04] 12 FIGURE 6: THE JMX PERSPECTIVE, DISPLAYING THE JMXBROWSER, THE BEAN VIEW, THE PROPRIETIES VIEW AND THE MANAGEMENT PANEL. 16 FIGURE 7: UML DIAGRAM OF THE CLASSES INVOLVED IN JMX CONNECTION MANAGEMENT 17 FIGURE 8: DETAIL OF THE JMXBROWSER 17 FIGURE 9: DETAIL OF THE MANAGEMENT PANEL 18 FIGURE 10: UML DIAGRAM OF THE GEF EDITOR MODEL 19 FIGURE 11: UML DIAGRAM OF THE GEF CONTROLLER IMPLEMENTATION 20 FIGURE 12: THE BEAN VIEW 21 LIST OF TABLES TABLE 1: IMPACT VALUES AND MEANING OF JMX OPERATIONS... 10 5
INTRODUCTION Why a monitoring console for JBoss JBoss is becoming one of the most used J2EE application server platforms and is gaining strong support from the open source community. Several integration and development tools have been created and more are in the works, but only few of them address the monitoring during the testing/deployment stage. Monitoring is an essential activity during the lifecycle of a JBoss application, fostering correct operation, optimization and profiling. Although JBoss itself provides an integrated web-based management console, this tool is not suitable for serious management, as it lacks the possibility to be configured and does not provide a synthetic overview of the JBoss process. Other monitoring tools, like extremej or mc4j, are either not open source or not targeted to the platform of choice for JBoss development, Eclipse. So there is a need for a simple but efficient tool for monitoring JBoss directly from the developer seat, without the need to introduce new tools that would have to be acquired and understood by the user. Using Eclipse as development and deployment platform Eclipse is one of the most successful open source projects. It s mostly know to the user community for its JDT plugin, that enables Eclipse to act as a Java IDE. But Eclipse is in fact a platform development framework. Eclipse exposes a wide set of APIs and pre-built functionalities that can be exploited by a developer to produce either a new plugin that adds functionalities to Eclipse or to create a new application via the Eclipse Rich Client Platform (RCP). A RCP plugin can also work together with other Eclipse plugins, allowing the creation of a customized application on the basis of the Eclipse portal. The choice to use Eclipse as development and deployment platform is almost a must, since the JBoss community has chosen this IDE as the official development platform for JBoss. Furthermore, the strong and vast community of users assures a large installed base and a quick response in case of development problems. Extensibility The plugin is strictly targeted to monitoring a JBoss application server. However, since it uses JMX as the underlying messaging protocol, it could be easily adapted to monitor and control other application or tools that are exposing a management interface via JMX. The application is structured in the way that all the calls to a specific JMX implementation are abstracted. 6
BACKGROUND JMX What is JMX JMX is a unified framework to instrument different pieces of Java code. Before JMX was introduced, there was no standard approach to start, stop and manage Java applications and software tools. Software was managed through collections of custom tools and procedures. JMX allows the introduction of more standardized management code, thus reducing the costs and the complexity of management tools. JMX Components MBeans are the components that are implementing a management interface, either statically by implementing a Java interface, or dynamically by defining the interface that uses a set of metadata classes. The JMX specifications define four types of MBeans. The four different types are Standard MBean Dynamic MBean Model MBean Open MBean Standard MBean is created by declaring a Java interface that holds the management information the MBean must implement. The other three types of MBeans are maintaining their management interface trough a set of metadata classes. Model MBeans extend the Dynamic MBeans by allowing additional descriptors to be attached to the management interface. Open MBeans restrict the object types to be used in the management interface to the basic object types. Architecture The JMX architecture is divided in three separate levels. Each of this levels has a distinct role and addresses a different aspect of the management systems. The tree levels are Instrumentation Level Agent Level Distributed Service Level The Instrumentation Level defines how to implement the MBean to make resources manageable by JMX compliant tools. Four types of MBeans (Standard, Dynamic, Model and Open) are defined at this level. At the Agent Level the role of the MBean server is defined by the JMX specifications. The MBean server is responsible for delegating invocations and messages between the managing application and the managed MBeans. The MBean server isolates the managing application from the managed MBeans. This is necessary in an high-availability (HA) architecture where resources can be moved from a host to another. MBeans can be updated, redeployed or moved between MBean servers without detaching the communication between the client and the managed MBean. The managing application does not directly reference the managed MBeans: at the Agent Level the concept of objectname is 7
introduced. The managing application uses objectnames to indirectly reference a specific MBean trough the MBean server. The Distributed Services Level defines how the communication between the managed agent and the managing application or in between agents is implemented. Figure 1: JMX services level [LiFl02] MBean Notifications Notifications emitted by MBeans are used to notify management applications or other MBeans about state changes and important events. JMX notifications are based on the Java event mechanism, which involves listeners and broadcaster. The JMX notification system is based on four classes: Notification NotificationListener NotificationBroadcaster NotificationFilter The Notification object extends the java.util.eventobject and represents a generic event. Listeners implement the NotificationListener interface. The NotificationBroadcaster interface is implemented by all MBeans that are sending management events. This interface allows registration and de-registration of notification listeners and displays metadata information about the emitted notifications. This metadata can be queried by the managing application to get information about the type of notifications that are emitted by a particular MBean. A class implementing the NotificationFilter interface can be passed as argument together with a listener when it is registered, and acts as a filter for the events the listener reacts to. MBean Types To clarify MBeans and JMX, two types of MBeans will be analyzed and described: the Standard MBean and the Dynamic MBean. Standard MBeans Standard MBeans must be public, concrete classes: the agent must be able to instantiate an MBean. For the same reason each MBean must have at least one public constructor. The Standard MBean class must implement its own Java interface. This interface must declare both attributes and operations exposed by the MBean. The naming conventions used for defining this interface follow closely the JavaBean model. The name of the interface is very important and has to be the name of the class followed by MBean. For example if the class name is Foo 8
the corresponding MBean interface would be FooMBean. The MBean server then uses Java introspection to determine the corresponding management interface at runtime. In order to expose attributes, these have to be declared as getters and setters in the MBean interface. Read-only attributes only have getters, write-only attributes only have setters and read/write attributes have both setters and getters. The overloading of a setter is not permitted and will have the effect to create a not complaint MBean. Operations are all the methods in the interface that are not recognized as getters and setters. Exceptions that are thrown by reading or writing attributes or by performing an operation are encapsulated and forwarded to the caller. This applies to checked, unchecked and runtime exceptions. Dynamic MBeans Dynamic MBeans do not rely on a static interface, but, as the name suggest, they can change their management interface dynamically. Dynamic MBeans implement a generic interface that provides methods for the agent to discover attributes, operations and notifications: the DynamicMBean interface. The methods defined in the interface allow retrieval and setting of attributes and the invocation of operations. An additional method, also declared in the DynamicMBean interface, getmbeaninfo(), returns an object of type MBeanInfo, that describes the management interface of the Dynamic MBean. MBean Metadata Classes MBean Metadata Classes are used by the Dynamic MBeans to expose their management interface. The MBeanInfo class is an aggregate of several Metadata classes: MBeanAttributeInfo MBeanOperationInfo MBeanConstructorInfo MBeanNotificationInfo MBeanParameterInfo MBeanNotificationInfo MBeanAttributeInfo MBeanFeatureInfo MBeanOperationInfo * * MBeanInfo * * * MBeanParameterInfo * MBeanConstructorInfo Figure 2: UML model of the MBean metadata classes [Perry02] 9
Each of the metadata classes, with the exclusion of the MBeanInfo class, inherits from the MBeanFeature class, that defines two methods for returning name and description of an element. These two proprieties are inherited by all other metadata classes. The MBeanAttributeInfo class is used to describe an attribute and contains information about the attribute type, name, access type and description. The MBeanParameterInfo class describes parameters used in constructors and operations and contains information about the parameter type. The MBeanOperationInfo class describes the management operations that can be performed by a Dynamic MBean and contains information about the method signature, parameters and impact. The impact is used to give the management application information about the relevance of the operation on the system. Table 1: Impact values and meaning of JMX operations Value INFO ACTION ACTION_INFO UNKOWN Meaning Indicates that the operation is read-like, it basically returns information. Indicates that the operation is write-like, and would modify the MBean in some way, typically by writing some value or changing a configuration. Indicates that the operation is both read-like and write-like. Indicates that the operation has an "unknown" nature. The MBeanConstructorInfo class describes the constructors of an MBean by listing the parameters of the constructor using arrays of MBeanParameterInfo. The last class, MbeanNotificationInfo, is used to describe notifications emitted by the MBean. The use of the name field differs from the other metadata classes; it is used to contain the fully qualified class name of the notification the MBean broadcasts. Additionally, the class describes the notification types that the MBean is emitting. [LiFl02] RCP The Eclipse Rich Client Platform is a spin-off of the Eclipse Project. As Eclipse is a great tool integration platform, the RCP team aims to create a platform to develop generic applications based on a common set of Eclipse functionalities that are not explicitly targeted to IDEs. In order to do that, all IDE related and non-essential plugins have been stripped out from the RCP distribution. Changes to the overall architecture of the Eclipse tool have also been suggested, in order to remove the IDE specific look and functionalities from the base Eclipse workbench; these include features like debugging and project menus. Developers can use a generic workbench with the usual views, editors, perspectives and services provided by the Eclipse framework to build applications as plugins for the RCP. Several plugins can be combined to build user-customized applications that are composed of different independent tools. GEF The Eclipse Graphical Editor Framework (GEF) allows the developer to create a graphical editor from an existing application model. GEF provides pre-built actions and operations to the developer, who can use them directly or extend them to implement the editor. GEF is based on the SWT-based draw2d plugin. Draw2d provides a standalone rendering package for SWT, including common shapes and layout managers. GEF is based on a Model-View-Controller (MVC) architecture that allows interaction between the model and the view. The GEF MVC paradigm MVC is a common architecture in GUI applications. Generally speaking, the model represents the data to be displayed, the view displays the data, and the controller reacts to user actions modifying the data in the model. 10
Normally views and models are tightly coupled, meaning that they have to be coded explicitly to interact which each other. The consequence is that a model that is rendered by a specific view has to conform strictly to a precise set of APIs or has to be wrapped in an other class. In GEF, on the contrary, there is no direct link between the model and the view. This allows almost any model to be displayed by any view. The roles of model, view and controller in GEF are: Model The model should not know anything about its view or controller. It should be modified by commands, and permit the view and controller to be referenced as listeners. They both listen for the notifications sent by the model when changes occurs in the model itself. View The view is composed by figures from draw2d and essentially includes the visual representation of the model. But the view is not limited to a mere representation of a model, it also displays means for the user to interact and modify the model. Those means include handles, tooltips and feedback: anything that is visible to the user. It is the controller s responsibility to construct and manage all the components of the view. Controller Controllers are implemented as EditParts. EditParts have the responsibility to assembly and manage the view and also to modify the model via commands. In order to create and manage commands, the EditParts use a set of roles. Roles are implemented via EditPolicies, and an EditPart can have many Policies installed, one for each role. Figure 3: the standard MVC [Ecli04] Figure 4: the GEF implementation of MVC. No direct connection from the view to the controller [Ecli04] GEF Structure EditParts An EditPart represents a single high-level object with whom the user can interact. It represents the model object and also assembles the view, as the EditPart itself is not directly visible to the user. Thus, important functions of the EditPart are to assembly the view and display it to the user, keeping it up-to-date with the model. Another important role of the EditPart is to allow graphical editing. Graphical editing is provided by set of actions that the user can perform: 11
Manipulate the model: modify the model by issuing commands that are generated by requests Display feedback: show feedback during operations Delegation: the previous tasks can be delegated to other EditParts Figure 5: EditPart and installed EditPolicies [Ecli04] During graphical editing many types of interaction are possible. Some involve more than one EditPart, like for example when adding or removing children in a model, some are only feedback or graphical operations like resizing a part, some are context sensitive operations. To solve the complexity of manipulating all those different kinds of operations, instead of managing the editing directly inside the EditParts, EditParts install one or more EditPolicies of different roles. Then the EditPart forwards requests to all installed EditPolicies that return commands to be performed as a response to the request. EditPolicies An EditPolicy provides an editing role to an EditPart. The role is defined by the kind of requests that the EditPolicy can understand and process. An EditPart iterates over all installed EditPolicies and forwards a request to appropriate EditPolicies. EditPolicies ignore requests that are not applicable to them. Roles EditPolicies are installed in EditParts using a string as a key. This string is called Role and identifies a single EditPolicy inside an EditPart. The purpose of Roles is to permit EditPolicies to be swapped, replaced, added or removed. This is necessary since subclasses of an EditPart may need different EditPolicies for the same Role, or the installed EditPolicies may be determined and changed at runtime. Requests Communication with EditParts is performed using Requests. The EditPart then delegates the Requests to its installed EditPolicies. Requests are identified by type, and the type is used for routing and processing the Request. Commands In response to a Request that an EditPolicy can accept and understand, it issues a command and passes it back to the EditPart. Commands can be chained and can manage actions like redo and undo. The retrieved commands are then passed to a processing queue and executed by the system. GEF provides a common set of EditPolicies, Commands, Requests and Roles: the developer can use them directly or extend them. Roles and EditPolicies are of two basic types: graphical and non-graphical. Non-graphical Roles handle operation that can be performed without knowledge of the view. Graphical Roles handle operations that need knowledge of the view, as for example graphical feedback [Ecli04]. 12
JBoss JBoss is an open source J2EE 1.4 compliant application server based on a JMX microkernel. It is one of the most successful application servers both for the quality of the product, being on par with commercial tools like WebSphere or WebLogic, and for its particular licensing strategy: the application server itself is available at no cost, but the documentation and the training have to be paid for. JBoss architecture The JBoss architecture can be divided in four layers: Microkernel layer Services Layer Aspect layer Application Layer Microkernel Layer At the core of JBoss is a small footprint microkernel. The microkernel uses JMX and delivers capabilities like hot deploy and advanced class loading. By using JMX the kernel can be managed and monitored remotely. Services Layer On top of the microkernel services are implemented. Services are hot deployable and selfcontained. Services like transaction managing, messaging, security and mail are available. The user can remove standard services in order to improve the JBoss performance and reduce its footprint. New services can be created by the user and are packaged in a Service Archive (SAR). The user can then deploy a new service and extend JBoss. Aspect Layer The Aspect layer is based on the Aspect-Orient programming model (AOP). JBoss uses interceptors to transparently implement behaviors offered by services in objects of the application. A developer can add and remove interceptors to its code, and this way implement the behaviors. Application Layer The user applications and Enterprise Java Beans (EJB) are deployed and running at the Application Layer. User applications can use all the capabilities offered by the JBoss infrastructure directly, by accessing them programmatically or via the AOP layer [JBos04]. 13
PROBLEM DESCRIPTION Requirements for the application The plugin has to provide the means to remotely manage and configure applications running on a JBoss application server and the server itself. In order to fulfill this tasks following requirements have been identified: Connecting to remote servers and browsing their management interface Building and configuration of different monitoring consoles Persistency for the monitoring console Interaction with the monitored MBeans Feedback and reaction for selected events and notifications Operational statistics and graphs Connecting to remote servers and browsing their management interface The user has to be able to connect to a given remote JBoss server. Connection is based upon three parameters: username, password and server URL. Upon connection the user must be able to view the JMX structure of the remote server and browse different JMX Domains and MBeans. When the user selects a Domain or a MBean, basic data about the selection has to be displayed: attributes, operations and notifications. The user must also be able to connect to multiple remote servers. Building and configuration of different monitoring consoles The amount of data and operations provided by the JBoss remote management interface is very high. The user must be able to extract and select only the data and the operations that are necessary for the correct operation of the JBoss Application Server. Flooding with information should be avoided. This is achieved by displaying significant MBeans only, and, for each MBean, by displaying significant attributes, operations and notifications. To achieve this goal the user can create multiple panels and for each panel select the MBeans to be displayed. Selected MBeans can be arranged arbitrary and configured to display only the necessary attributes, operations and notifications. Persistency for the monitoring console After creating different management panels, the user must be able to save work done and retrieve it later. Not only the panel configurations have to be saved, but also the connection parameters, as username, password and connection URL. At the time of writing no considerations have been made regarding the security of the proposed model. A balance between user friendliness and security has to be found. Interaction with the monitored MBeans The user must be able to interact with the MBeans displayed on the management panel. Interaction comprises reading and modifying attributes, invoking operations, and receiving notifications. Values should be updated both automatically at predefined time intervals and upon explicit user request. 14
Feedback and reaction for selected events and notifications The monitoring tool has to be able to automatically provide feedback for selected events or notifications. The feedback can be visual, sending an e-mail or a combination of the previous two. Candidate events are crossover of threshold values for attributes, determined values for attributes, or notifications broadcasted by MBeans. The management tool should also be able to react automatically on events by taking simple management decisions on the monitored JBoss server. Operational statistics and graphs To allow better understanding of the server and of the deployed applications, graphing for selected attributes must be possible. This allows monitoring of the values over time and gives a strong visual feedback. The collected data should be exportable both as a csv-formatted and xml-formatted file to allow interoperability with other applications. Also persistency for the collected data has to be implemented. Implementation for the thesis Due to time constraints some features are not implemented in the thesis project. An outline of the features not implemented in the current iteration of the project is: Statistics and graphs Security model for saved management panels Automatic reaction upon events Email feedback Notification management Other limitations Other limitations are present in the current iteration of the managing tool. The most relevant is the limitation on the type of parameters and values that can be passed to the MBean operations and attributes. Only basic types such as String, Number and Boolean can be used as values, as there is no efficient method to generate instances of complex types. 15
PROPOSED SOLUTION Tools Eclipse 3 is the only development tool used. It is a given choice, as only Eclipse is able to host Eclipse plugin development. Additional plugins have been used, specifically GEF, Metric 1.3.5, a metric analysis tool for checking the code quality available at http://metrics.sourceforge.net/, and Junit, a tool for performing automated unit testing available at http://www.junit.org. Additionally, a JBoss Application server (version 3.x) has been deployed for testing purposes. Application architecture overview The application is composed of a set of views and editors that are directly interacting with the user and of one application-logic package that manages the low-level tasks to connect to remote JMX servers. Editors and views are comprised in a unique perspective, called JMX perspective. The views are: JMXBrowser MBean view Properties JMXBrowser is a hierarchical JMX server navigator. The MBean view displays attributes, operations and notifications of the MBean that is selected in the management console. The Properties view is the standard Eclipse Properties view used to display the properties of selected MBeans, both in the JMXBrowser and in the management console. A unique kind of editor, called JMXEditor is used as management console. Multiple instances of the editor can be open at the same time. In the management panel multiple MBeans can be deployed and monitored. Figure 6: The JMX perspective, displaying the JMXBrowser, the Bean View, the Proprieties view and the 16
management panel. JMX connection management Connections to JBoss are managed by three classes: JMXConnector JMXWrapper JMXManagerPlugin JMXConnector is an interface containing generic operations that can be performed on a JMX server. JMXConnector introduces two kinds of exceptions, JMXRemoteException and Unexpected- JMXRemoteException. Specific implementations of the JMXConnector interface have to map expected and unexpected exceptions in the two defined exception types, that are simply wrappers for the exceptions thrown by the classes. JBossConnector implements JMXConnector and contains the JBoss specific connection methods, implemented via RMI. This class is specifically tailored for JBoss. It is possible to write other classes that implement JMXConnector in order to extend the possible choice of remote servers to which the user can connect. Each different implementation has to provide specific code to call the specific remote server implementation. JMXWrapper handles all communications between the application and different JMXConnector instances. JMXWrapper handles all remote exceptions and is an abstraction layer between a specific JMX implementation and the rest of the program. For each remote server only a single instance of a JMXConnector class is created and then stored in JMXManagerPlugin, which manages connection pooling. Connections are retrieved using a numeric id that is the hash of the connection parameters. This type of identification assures that no two connections with the same characteristics are created. JMXBrowser Figure 7: UML diagram of the classes involved in JMX connection management Introduction The JMXBrowser allows connections to multiple remote JMX servers and navigation through the domains/mbeans exposed by the servers. The browser is organized as a tree, with servers at the top level, domains at the intermediate levels and MBeans as leaves. Implementation The browser is implemented as an Eclipse view. Views can provide menus, both static and contextual: in this case a simple menu for Figure 8: detail of the JMXBrowser removing and adding remote servers is provided. The tree is built using a JFace component. JFace provides high-level widgets in form of simple MVC structures on top of SWT, the native Eclipse graphic library[sdfk03]. Items displayed in the view are organized in a simple hierarchical model and must implement the JMXViewTreeElement interface, that provides a set of common functionalities related to the tree representation. The model of the tree is in fact a meta-model, where objects are only pointers to instances. In the case of the domain level, a tree is a totally new construct, as there is no domain class in the JMX specifications. Moreover, MBeans live only on the remote server 17
and cannot be transferred to the management console, so the MBean model is implemented using a Decorator pattern in the MBeanDecorator class. The MBeanDecorator class holds data about the MBean internally, and reveals only the attributes and methods that are necessary for the view to work. The JMXBrowser directly interacts only with the JMX connection management classes. All other interactions with the management tool are done either via drag and drop or via selections that are passed to the Eclipse Workbench. Eclipse has a selection notification mechanism that can be used by all components, views and editors. If an element is selected, the view notifies the Eclipse workbench about this event. All selection listeners registered in the workbench are notified and can provide adequate feedback. This feature is used to provide information to the proprieties window regarding selected servers, domains and MBeans. Properties displayed in the properties view are usually provided by objects implementing the IPropertySource interface. IPropertySource defines a set of methods used by the properties view to read and display data. Classes in the JMXBrowser are instead implementing the IAdaptable interface [GaKe03], that defines only a single method, getadapter(). The IAdaptable interface allows adding the functionalities by expansion. Thus, instead of implementing several interfaces and their methods, classes are offloading responsibilities to other classes that are retrieved via the IAdaptable interface. This keeps the complexity of the original classes on the low level. As Eclipse itself does not use the standard Java AWT/Swing graphic toolkit, but SWT, which is a wrapper of the platform graphic widgets, drag and drop is implemented using native APIs. In order to support drag and drop of java types/classes, objects must be serialized to a byte array and then de-serialized. The MBeanDecorator class itself is not serialized and de-serialized, as Eclipse provides methods to generate specific data-transfer classes based on the current user selection. In this case only BeanTransferData, a specific data transfer object containing data about the connection id of the server holding the MBean and the ObjectName of the MBean itself, is transferred. The Management Panels Introduction Management panels are implemented as editors, namely GEF editors. A graphical editor might, at a first glance, not seem the ideal tool to display and manage MBeans: some kind of a hierarchical tree view would seem the best choice. However, since the goal of the tool is to be highly configurable and permit maximum flexibility for the end-user by displaying only relevant MBeans, attributes and operations and by allowing any kind of arrangement, graphical editing and a flexible layout are needed. MBeans are added to the panel by dragging them from the JMXBrowser. As previously explained, only connection data and ObjectName are passed to the editor, not the whole MBean. Similarly, when a user drags an attribute or an operation to an MBean, only basic data is transferred to the editor, which is Figure 9: Detail of the management then used by an object factory to create the right object in the model being displayed by the editor. Multiple editors can be open and active at the same time, so the user can split the work area over multiple panels. However, just one editor is visible, as Eclipse can display only one at a time. The editor class JMXEditor extends the abstract GraphicalEditor class of GEF, a commodity class providing basic functionalities of an editor, like for example saving and restoring. 18
Implementation of the Management Panels (GEF Editor) GEF is based on a MVC paradigm, so the whole editor is structured according to the MVC pattern. But, unlike the standard MVC pattern, in GEF models views and controllers are nested. Model The model structure is hierarchic, and controllers and views have to reflect this characteristic. JMXEditorModel is the parent class of the model hierarchy and is stored inside the JMXEditor editor class in the model attribute of the GEF editor. Model classes are: JMXModel JMXElement JMXEditorModel BeanModel AttributeModel NotificationModel OperationModel As shown in Figure 10, all model classes inherit from the JMXModel class. This class provides a set of common behaviors, like for example the ability to be a source of data for the proprieties view or the ability to register listeners that listen for changes in the model. JMXElement is a specialization of the JMXModel class, and adds support for graphical representation. More precisely it provides support for layout data, like position and size of elements, and notifications of changes of these attributes. All model objects are generated and removed by the user trough controllers, the EditParts. When a new object has to be created in the model, a controller asks a Figure 10: UML diagram of the GEF Editor model factory, the JMXModelFactory, registered in the editor, to instantiate the model object. The EditPart asking the factory to generate an object is always a step higher in the editor hierarchy than the generated object. Changes in the model structure are notified to the appropriate controller, which then refreshes the view [MDGW04]. Controller Controllers in GEF are EditParts. The classes composing the controller structure are: JMXEditorEditPart JMXEditPart BeanEditPart AttributeEditPart NotificationEditPart OperationEditPart Figure 11 represents the hierarchy of the classes that are the controllers of the editor. The hierarchical structure of the model is not directly mapped to the controller hierarchy, which is also not needed, as EditParts are generated directly from the model. The editor registers an EditParts factory, JMXEditPartFactory, responsible for generating the EditParts for the model. 19
When the model is loaded or an item is added to the model, there is no need to explicitly create the corresponding EditParts, as the editor takes care of it by using the EditPart factory. All EditParts inherit from a class provided by the GEF framework, the AbstractGraphicalEditPart. JMXEditorEditPart is the root EditPart, and is the controller of the canvas of the editor. It has two EditPolicies classes installed. These are responsible for managing the controller behavior: one for handling the creation of new Beans and one for moving and resizing elements on the canvas. Policies react on requests generated from the user input by responding with commands that are passed back to the EditParts and then executed by the editor. Here the separation between graphical and non-graphical policies is extremely clear. Creation and deletion commands received by the EditParts are managed via double dispatch, as it is a much cleaner and more object-oriented solution in respect to having a sequence of conditions. This way the responsibility to create and delete parts is passed back to the model and is not directly performed in the command itself. BeanEditPart, AttributeEditPart, OperationEditPart and NotificationEditPart all inherit from JMXEditPart. JMXEditPart implements methods for handling modifications of the size and location of the figures representing the model. It also implements PropertyChangeListener, similar to JMXEditPart- Factory, since the parts are registered in the model as listeners. These listeners wait for notification of structure and properties changes from the model. EditParts are responsible for removing themselves from the canvas and the model, thus they register an EditPolicy for managing their deletion. AttributeEditPart and OperationEditPart must also provide means for the user to interact with attribute values and operations. This is implemented through specific EditPolicies that responds to specific user requests. The last responsibility of the EditParts is to draw the view. Values from the model and user inputs are redirected to the view in order to display data and Figure 11: UML diagram of the GEF controller implementation feedback to the user actions. As indicated earlier, EditParts are registered as listeners, so every change in the model is notified and then redirected to the view for displaying. View Views associated with models and controllers are responsible for creating a graphical representation of the model and for registering event listeners to detect low-level user inputs, like mouse events on buttons. Higher-level interactions, like display and react to contextual menus or graphical editing, are handled directly by EditParts. No application logic is contained in the views, as this would break the strict separation between model, view and controller. Figures, the graphical elements of the GEF framework, do not need to have other methods except for registering event handlers and constructors, as all their proprieties are managed by the corresponding EditPart. The classes representing the views are: BeanFigure AttributeFigure NotificationFigure OperationFigure There is no corresponding class for the JMXEditorModel, as the root view is generated implicitly in the GEF editor. 20
All the view classes are subclasses of Figure, a generic graphical class provided by the GEF framework. Persistency of the management panels Persistency is obtained by serializing and de-serializing JMXEditorModel instances. The standard GEF editor provides hooks and methods for saving and restoring itself, simply by writing and reading the object stream representing the editor s model. In the restoring phase the Editor performs reconnection to the remote servers, if needed, via the newly restored JMXEditorModel instance. Here the advantage of using the hashcode of the connection environment as identifier is extremely clear, as there is no possibility of clash of ids coming from different editor instances. Additionally, if more than one editor refers to the same server, only a single connection is created. In the model classes there are temporary attributes that are not essential for the model itself, like registered listeners. Those attributes have to be declared transient, so that they are not serialized. This solution also offers the advantage of breaking dangerous dependency chains and to serialize only relevant data. The Bean View Introduction Figure 12: the Bean View The Bean view works closely together with the management console. Its purpose is to provide a comprehensive view of the features of the MBean selected in the panel. From there, attributes, notifications and operations can be dragged onto a MBean on the panel to build the specialized monitoring console. The user can also directly modify values or invoke operations, without constructing a custom MBean on the console. Implementation The implementation is similar to the one of the JMXBrowser, as both are Eclipse views. The Bean View is registered in the Eclipse Workbench as a selection listener and reacts to selections in both the management panel and the JMXBrowser. Drag and drop is allowed only if the selection provider is an MBean placed on the management panel. Drag and drop is implemented like in JMXBrowser. The only difference is that in the BeanView there are three classes that handle draggable objects: AttributeTransferData NotificationTransferData OperationTransferData Similarly to the JMXBrowser case these classes are only references for the recreation of the transferred items, as the serialization of the items themselves would be too cumbersome. Graphical elements are composed using a combination of simple SWT widgets and JFace elements. Monitoring of MBean Attributes JMX provides native monitoring of attributes. It is possible to register listeners in a JMX server to watch attribute values and notify changes. This solution has a big disadvantage: for every monitored attribute, a new thread is started on the server. This solution works only when just a few attributes are monitored, but if a certain number of attributes has to be monitored by multiple consoles the JMX server will soon be flooded with threads. 21
Unlike the native approach, the application works by polling the server at fixed rate, and then displays changes and alerts to the user. In order to do this a single separate timer thread is started. This thread does not perform the polling. Instead AttributesEditParts are implementing the TimedOperation interface, that defines a single method for executing an operation: executetimedoperation(). AttributesEditParts are then registering themselves as listeners in the timer thread. The timer thread wakes up at scheduled execution time and calls the executetimedoperation() method for all registered AttributesEditParts. The polling and update are then performed from the EditParts. 22
CONCLUSION & FURTHER STUDIES Conclusions The result of this thesis project is a working and user configurable management tool for JBoss. The user is able to choose a remote server, authenticate, connect, and create multiple management panels. The user can then configure the panels with MBeans, Attributes and Operations so that he can monitor attributes, receive notifications and issue simple operations. The user can save and restore the management panels used in order to continue working with them later on. Developing this application I gained an in-depth knowledge of the Eclipse platform and the GEF framework that will facilitate further experience with the same tools, as both Eclipse and the Rich Client Platform will probably play a big role in the future. A metric analysis tool has been used in order to assure quality of the code and there are no metrics value range violations in the project s code. This, along with the unit and acceptance tests, should guarantee confidence in the code assuring maintainability and correct working. Further studies The presented solution is specifically targeted to the JBoss application server. However, due to its modular approach, it could be easily extended to support different tools, simply by writing the right connectors. For example, the next release of Java, J2SE 1.5, is JMX instrumented, so the management tool could be used to manage and monitor the Java virtual machine itself. Further enhancements could be done in the graphical representation of values over time, that are missing in this release, but that could give great value to the user. Security is also a concern, as no mechanism for protecting login/password pairs is provided. A keychain-like tool could be used: each console could have a master password for unlocking all connections login/password pairs contained in the console itself. The persistency mechanism of the consoles seems simple and ideal. In fact, a serialization to a XML file would be a much better choice than the direct serialization of the classes in an object stream, for two reasons: the first is that XML can be easily edited by humans and programs, and the second is that every change in the model class structure renders saved editors unusable, as they cannot be restored anymore. A possible evolution of the tool is a headless version, without the graphical editor. It could be a lightweight application for dispatching alerts and taking actions on the base of the files saved by the graphical counterpart, that in this case would be mainly used as an editor for generating configuration files. 23
GLOSSARY Technology specific terminology Application Server: An infrastructure or a set of frameworks that provides the building blocks for developing applications. AOP: Aspect Oriented Programming. A programming paradigm that cross-cuts the code of a program for inserting common instructions for groups of common behaviors. Eclipse: A java based open source multi-language IDE developed initially by IBM. EJB: Enterprise Java Bean. One of the Java APIs defined in the J2EE. Specifies how an application server provides server-side objects implementing persistency, transactions, and events. GEF: Eclipse s Graphical Editor Framework. A lightweight framework used for developing graphical editors inside Eclipse. HA: High Availability. Error and crash resilient server or program configuration. IDE: Integrated Development Environment. A tool that comprises source code editor, compiler, debugger and other development tools. J2EE: Java2 Platform, Enterprise Edition. A standard for developing distributed multi-tier applications based in modular components. Java: An object oriented multi-platform programming language based on a virtual machine specification developed by Sun. JavaBean: A specification developed by Sun for assuring interoperability among Java components. JFace: Library of high-level GUI components developed on top of the SWT graphics library, JMX: Java Management Extension. A Java technology supplying tools to remotely manage and monitor applications, tools and devices. JMX Domain: Namespace in the JMX specifications MBean: Message Bean. A Java component that exposes a management interface conforming to the JMX standards. RMI: Remote Method Invocation. A Java technology for accessing remote objects and calling their methods over a network connection. SWT: Simple Widget Toolkit. Eclipse s widget library. It is based on top of calls to the native widget library of the hosting platform. URL: Uniform Resource Locator. A standardized web address locating a resource. 24
REFERENCES [Ecli04] The Eclipse Project - Eclipse 3 help system, 2004 [GaKe03] [JBos04] [LiFl02] [MDGW04] Erich Gamma, Kent Back Contributing to eclipse Principles, Patterns and Plug-Ins, Addison-Wesley, 2003 The JBoss Group - The JBoss Application Server <http://www.jboss.org/products/jbossas> Juha Lindfors and Marc Fleury JMX Managing J2EE with Java Management Extensions, Sams, 2002 Bill Moore, David Dean, Anna Gerber, Gunnar Wagenknecht, Philippe Vanderheyden - Eclipse Development using the Graphical Editing Framework and the Eclipse Modeling Framework IBM Red Books, 2004 [Perry02] J. Steven Perry, Java Management Extensions, O Reilly, 2002 [SDFK03] Sherry Shavor, Jim D Anjou, Scott Fairbrother, Dan Kehn, John Kellerman, Pat McCarty, The Java Developer s Guide to ECLIPSE, Addison-Wesley, 2003 25
Date Release Iteration Description Estimated Time Real Time Deviation Week1 R0 I0 JMX spike 30 40 33% Week3 R0 I0 Eclipse PDE spike 30 40 33% Week5 R0 I0 Swt/Jface spike 10 20 100% Week6 R0 I1 JMX connection logic 30 40 33% 100 140 40% Week7 R1 I2 JMX Browser 40 60 33% Week10 R1 I3 Refactoring of code 10 10 0% Week10 R1 I3 Ecipse spike (seclections) 10 15 50% Week11 R1 I3 Proprieties view 10 15 50% Week12 R2 I4 Itegration in Eclipse 10 10 0% 80 110 38% Week13 R2 I5 Gef Spike 40 70 75% Week17 R2 I6 JMX Editor (MBeans) 40 60 50% Week20 R3 I7 Itegration in Eclipse 10 10 0% 90 140 56% Week21 R3 I8 Gef Spike 10 15 50% Week21 R3 I8 Eclipse PDE spike 10 10 0% Week22 R3 I9 MBean View 20 30 50% Week23 R3 I10 JMXEditor (attibutes) 20 20 0% Week24 R3 I11 JMXEditor (attibutes-monitoring) 40 60 50% Week27 R4 I12 Itegration in Eclipse 10 15 50% 110 150 36% Week29 R4 I13 JMXEditor (Operations) 20 15-25% Week29 R4 I13 JMXEditor (Operations-invocation) 10 15 50% Week30 R5 I14 Itegration in Eclipse 10 15 50% 40 45 13% Weeks are 20h each Appendix A - Project Plan - Iteration and Releases
Appendix B - Metrics extracted from the monitoring tool code LOC - Lines of Code method 2759 4,900533 7,066599 47 NSM - Number of Static Methods type 23 0,25 1,273689 10 CA - Afferent Coupling packagefragment 6,25 6,514407 22 RMD - Normalized Distance packagefragment 0,271391 0,246996 0,88 NOC - Number of Classes packagefragment 92 5,75 4,534589 18 SIX - Specialization Index type 0,4148 0,649991 3 RMI - Instability packagefragment 0,615586 0,26608 1 NOF - Number of Attributes
type 179 1,945652 2,261993 14 WMC - Weighted methods per Class type 898 9,76087 9,177441 68 NORM - Number of Overridden Methods type 80 0,869565 1,353075 6 NSF - Number of Static Attributes type 46 0,5 1,913908 17 NBD - Nested Block Depth method 1,330373 0,700863 5 NOM - Number of Methods type 540 5,869565 4,273827 18 LOCC - Lines of Code type 2759 29,98913 42,52148 261 LCOM - Lack of Cohesion of Methods type NaN NaN 1 VG - McCabe Cyclomatic Complexity method 1,595027 1,33784 8
PAR - Number of Parameters method 0,591474 0,823758 4 RMA - Abstractness packagefragment 0,113023 0,160316 0,5 NOI - Number of Interfaces packagefragment 8 0,5 0,707107 2 CE - Efferent Coupling packagefragment 6 3,937004 17 NSC - Number of Children type 9 0,097826 0,552854 4 DIT - Depth of Inheritance Tree type 2,26087 1,082163 6