An Architecture-Based Runtime Management Tool for PKUAS

Index

PKUAS ("Peking University Application Server") is a J2EE application server developed by the research group of PKU-Bell Labs Software Technologies Joint Lab. PKUAS had implemented J2EE 1.4 and EJB 2.0 specifications. PKUAS provides a platform to experiment with innovative ideas on new generation of software in the Internet environment. Besides the standard services listed in the specifications, e.g. Communication, Naming, Transaction, Security, etc., PKAUS has several distinguished features, including the on-line evolution of components, a flexible and extensible interoperability framework, and a reflective management framework.

Reference:

Source code

PKUAS provides a powerful, JMX-based management API for monitoring and reconfiguring the server and applications running on the server, at runtime. This management API is original designed for senior developers to write runtime management programs, while its not convenient for common users or maintainers. Even if they just want to read a simple attribute value of a runtime element, they still have to write lines of complex java codes to invoke the API, provided they have already mastered JMX and PKUAS management. To resolve this problem, we need an intuitive and convenient user interface for runtime management. Cooperating with a member in PKUAS development team, we defined and generated an architecture based user interface for managing PKUAS. This management tool is based on an architecture modeling tool we have developed before, named ABCTool.

The above figure is a snap shot of our architecture-based runtime management tool for PKUAS. The central editor shows the architecture model of a Java PetStore (JPS) application running on PKUAS currently. Many of the elements in this architecture model are actually the images of resources at runtime, like applications, EJBs, interceptors, etc. For example, the component SignOn is an image of the EJB named SignOnEJB running on PKUAS, and some of the attribute values displayed in the bottom attribute view are actually retrieved at runtime. Maintainers can make their diagnosis for the running application on the basis of the attribute changes or element emergences or disappearances, and they can manipulate the running application by directly change some of the attribute values, e.g. they can change the value of MaxInstancesCached, and the instance pool allocated for SignOnEJB will be resized, when the maintainers finally launch the synchronize command.

We even tried to use this newly constructed user interface to dynamically correct a defect in JPS's original design. The early version of JPS do not block brute force attracts, that means a malicious user may access the store by trying passwords for many times. We know that it is caused by inadequate constraints on the SignOn Component, so we instantiate a new Constraint element in archi- tecture model, assign it with a simple prototype implementation (a jar file with a java class for an interceptor), and insert it into the constraint list of SignOn Component. When we launch the synchronization command, the interceptor will be dynamically inserted into the container of SignOnEJB, without restarting the server.

Video demonstration:

Reference:

To manage a running system under its architecture model, there need to be a causal connection between the architecture and the system. Here "causal connection" means that the change on architecture states must cause instant and corresponding change on the running system, and vice versa. We implement an extensible infrastructure to maintain causal connection, as an Eclipse plugin. Relative resources are as follows.

We extend the above infrastructure by three specifications for architecture model, running system and the causal connection, respectively.

The specification of architecture model is derived from our architecture modeling tool named ABCTool, and part of this specification is shown as below.
From this Ecore specification, we use EMF code generation to generate four Eclipse plugins, which provide a tree-based and graphical GUI for editing the architecture model.

PKUAS's runtime management is based on JMX, and it supports getting/setting many kinds of attributes, adding/removing elements like EJB, interceptor, etc. The specification of PKUAS's management capability defines what kinds of elements can be managed, and what attributes or associations of these elements can be changed. We also use this Ecore specification to generate a Eclipse plugin, which wrap PKUAS's JMX-based management capability under standard MOF reflection interface. The extensible infrastructure (and also other EMF-based techniques like ATL, OCL, etc.) can access the management capability just like accessing a common Ecore model.

Finally, we use ATL transformation to specify the required causal connection betwee the architecture model and the running system. For example, we require that for any EJB in the running system, there has to be a corresponing component in the architecture, and vice versa.

Relevant Resource