Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Server-side Java: Patterns for flexible initialization, Part 2

Customizing command targets in your system initialization

By Lennart Jorelid, JavaWorld.com, 03/02/00

  • Print
  • Feedback
.

Page 2 of 4

What are application subsystems?

Despite the minimal modification to the collaboration diagram, it is quite difficult to add less than an extra method call. The modifications and additions to the class diagram and the implications for centralized application state control are far from insignificant, since they provide the application system with the concept of application states (run levels). A goal in providing the structure is, of course, that the existing application system should need as little modification to its existing structure as possible. I have generally found small application system modifications doable and major application system modifications a politically correct way of spelling recode or at least refactor, to appease upper management.

One of the major keys to aptly managing an application system transition is to delegate tasks to subsystems. In this context, a subsystem is a Facade pattern hiding or managing a multitude of other classes behind its method interface. The purpose of the subsystem facade is to reduce centralized management complexity by providing subsystem state information and handling state change requests from the SystemController. Interaction between the SystemController and each subsystem is greatly facilitated by a common public type, so an interface specification is the logical choice for a subsystem type. The subsystem facade is only an interface definition, which needs to be implemented by (a minimum of) one class per subsystem. Moving an entire application system to the centralized setup and state-handling architecture proposed in this article is therefore a relatively painless operation. If your application subsystems are managed in different ways today, the Bridge pattern can facilitate your retrofitting process. Indeed, such a retrofit essentially declares only the type and delegates its method calls to other sets of existing method calls within the subsystem.

Therefore, use subsystems within the application to facilitate centralized management of your whole system. The interface mechanism is a good way to define subsystems, since it is dissociated from any actual implementation and poses no real demands on the implementing class. Use a Delegator pattern to superpose the general subsystem module structure on your existing structure. The message delivery between modules and the module manager follow the Observer/Observable pattern for registration and event notification.

Next, I'll go over a simple approach to creating a subsystem-type hierarchy, shown in Figure 5:

Figure 5. Augmented setup process flow hierarchy

The hierarchy above describes the three interfaces -- SystemController, ModuleManager, and SystemModuleController (together with abstract implementations) -- that are required to create a smaller system for module and system-state management. Although small and subject to much improvement, the application subsystem management structure proposed here is adequate for rather large systems. Note that the two subclasses at the bottom of the hierarchy are test implementations and should be regarded as examples only.

The purpose of each functionality definition interface is:

  • SystemController. This interface defines system status control methods, which brings the system to a specified operation level. Such operation levels correspond to different required system states, such as Halt, Maintenance, Normal, and so forth.
  • ModuleManager. This interface defines an API for managing application subsystem modules. All such managed modules may have their operation states modified centrally by the SystemController.
  • SystemModuleController. This interface defines the interface methods of an application subsystem facade object. The subsystem's responsibility is to register itself with the application's ModuleManager. After this registration, the SystemModuleController must respond to commands and queries from the SystemController regarding its operation state. Each subsystem manages its operation state according to its own needs.

Each abstract implementation is a system adapter, which functions in a manner similar to the event adapter classes of package java.awt.event. You may, without breaking the architecture, choose an implementation standard other than what was obtained from subclassing the abstract adapter implementations in the hierarchy. Implementation or subclassing may be chosen at different levels; if you choose to extend AbstractSystemController, no special requirements have to be met by the subsystem facade classes. Should you select the full power of the Setup pattern by subclassing the AbstractModuleManager, you must implement the SystemModuleController interface for each subsystem facade class. (Granted, this should not be a big task.)

Subsystems tend to depend on the services of other subsystems. For instance, a distributed object lookup service depends on the services of the network subsystem. Any subsystem module management system must make sure that all parent subsystems are brought to a specified higher state before bringing any dependent subsystems to that particular state. The opposite is true if the application system state change is reversed; all dependent modules must be brought down to a lower operation state before bringing down any parent modules. To ensure that no dependency problems remain during system-state shifts, all SystemModuleController objects should register their parent modules. When in need, the SystemController may therefore make certain that all dependencies are acknowledged during state shifts.

Let us take a look at the SystemModuleController interface to better understand a subsystem module.

Listing 1. SystemModuleController interface

// Copyright (c) 1999 jguru.com
// All rights reserved.
package com.jguru.initHandler;
import java.util.Iterator;
import java.util.List;
/**
 * Definition of the interface methods of an application subsystem
 * facade object. The responsibility of the subsystem is to register
 * itself with the application ModuleManager. After such registration,
 * the SystemModuleController must respond to commands and queries
 * from the SystemController regarding its operation state. 
Each
 * subsystem manages its operation state according to its own needs.
 *
 * @author Lennart Jorelid, jGuru 
Europe * @version $Id$
 * @since January 2000
 */
public interface SystemModuleController
{
        /**
         * Method moving the controlled module from the current
         * operation status to a new one. It is the responsibility
         * of the implementing class of this interface to notify
         * all relevant classes/modules in the application system of the
         * change in operation status.
         *
         * @param newStatus Integer giving the new system operation status.
         *                  Most normal states are given as constants in
         *                  the SystemController interface.
         */  
        public void setModuleStatus(int newStatus);
        /**
         * @return The current module operation status.
         */  
        public int getModuleStatus();
        /** 
         * @return An identification string of this module.
         */
        public String getModuleID();
   /**
    * @return The queueOrder of this SystemModuleController.
    */
   public int getQueueOrder();
   /**
    * Sets the queueOrder of this SystemModuleController. The queueOrder
    * is a suggestion for the order of handling when the system as a whole
    * migrates from a lower operation level to a higher one.
    * Lower queueOrder modules are processed before higher queueOrder ones.
    *
    * The opposite is true when decreasing the system operation status.
    */
   public void setQueueOrder(int newQueueOrder);
        /**
         * @return true if the system is changing operation
         *         states. false if the whole application
         *         module is running within a certain operational state.
         */
        public boolean isStatusChangeInProgress();
        /**
         * Adds a direct dependency (parent) module to this 
SystemModuleController.
         * A parent module is one whose services are used by classes 
managed by
         * this SystemModuleController. Before changing the operational 
status
         * of any of the direct parent modules, the status of this 
SystemModuleController
         * must first be changed.
         *
         * @param aModule A SystemModuleController which this 
SystemModuleController
         *                depends upon.
         */
        public void addParentModule(SystemModuleController aModule);
        /**
         * @return A List of all parents of this SystemModuleController.
         */
        public List getParentModules();
}

All subsystem facade objects are created and added to the setupApplicationSubsystems method of the TestClass class. Note that TestClass implements the ModuleManager interface -- the this variable refers to the ModuleManager.

Listing 2. setupApplicationSubsystems method

  /**
   * Method that sets up the subsystems of this application.
   */
  protected void setupApplicationSubsystems()
  {
     // Create two SystemModuleControllers
     SystemModuleController s1 = new 
TestSystemModuleController("BaseModule", 20);
     SystemModuleController s2 = new 
TestSystemModuleController("HighLevelModule", 50);
     // Setup subsystem dependency
     s2.addParentModule(s1);
     // Register subsystems with the 
ModuleManager
     this.addSystemModule(s1);
     this.addSystemModule(s2);
     // Log done.
     System.out.println("[TestClass setupApplicationSystem]: All 
modules registered " +
                        "with automagic module management.");
  }

  • Print
  • Feedback