Many Java EE server projects started at the inception of the enterprise Java specifications many years ago. Such earlier-generation systems were not always constructed with a dynamic environment and clustering in mind. A recent article by Takoua Abdellatif and Jakub Kornas, Reengineering J2EE Servers for Automated Management in Distributed Environments, describes some techniques in which Java EE servers can be made more dynamic and scalable. Their approach to enabling existing servers with scalability and dynamic behavior consists of multiple steps:

First, we need to be able to manage service dependencies. This means that the application server’s architecture must be explicit and the relations between services well defined and exposed to the administrator.

Second, the services must be packaged and deployed independently. The unit of deployment should be the service, not the whole server. Once deployed, a distinct class loader should load each service’s code to allow for service updates and versioning.

Finally, the deployment tools should hide the distributed system’s complexity and automate configuration and installation.

To address these needs, our approach reengineers the legacy system to have an explicit, modular architecture and builds a deployment and reconfiguration system based on sound design principles and using higher-level system representation. So, we use the architecture-based management principle, which separates the management layer from the managed system.

One of the interesting aspects of the article is the authors' description of the Fractal component model:

Fractal is a general component model that distinguishes two types of components: primitive and composite. Primitive components are standard Java classes that conform to certain coding conventions. Composite components encapsulate a group of primitive or composite components. The system architecture, written in the Fractal ADL, is expressed in terms of the component model—bindings between components and containment relationships. Bindings between components can be local (in a single Java Virtual Machine) or remote. These properties are specific to Fractal, which is why we chose it to build our new application server.

What do you think of the authors' approach as outlined in the article?