Understanding the Administrator

Administrators are people who tend to be picky, or at least they're picky if they do their job well. Being detail-oriented is part of the administrator's job description because his task is to keep things running smoothly. In essence, a good administrator makes his job look easy. The reality, however, is that being a good administrator is hard. And developers do not make the administrator's job any easier. Many developers consider that an installation manual and an install file are good enough for an administrator. However, the installation manual will typically be half-written and will often be inaccurate. The result is that the administrator has to learn about the system. Until he learns it, the administrator will not be keen on letting more pieces of the application be installed. As a result, conflicts and disasters between the developers and administrator will inevitably happen.

Now there is an irony. Open Source, which is complex, command line-oriented, and compile-it-yourself, is preferable to Closed Source GUI-based applications. The reason why is simple. The program RedHat , which is a Linux distribution with Release 8.0, for example, made huge strides in ease of use as compared to previous versions of RedHat. The newest release of RedHat is very GUI friendly and allows a normal user to use Linux without having to know all of the configuration files and configuration programs. However, an administrator would reply to this information about RedHat by saying, "That sounds good, but it's not for me." Administrators are generally not interested in GUIs because GUIs are useful only when a single person is involved. When administrators are responsible for about 100 desktops, GUIs make it extremely difficult to manage the configurations on the different machines. As a result, administrators generally prefer using the command line and scripts, where everything can be automated. So, while learning the command line and script is initially more complicated than learning a GUI, in the long run, using the command line is simpler.

Open Source administrators are not programmers, even though they might write some shell scripts. However, Open Source administrators can configure, tweak, and debug applications because Open Source programs are tuned for that purpose. The programs are tuned towards helping the administrator do their job.

A Checklist of What an Administrator Wants

An administrator's wish list is simple: give me something that works. That is a typical and very vague response. However, with some prodding, you can get a more accurate list of things that administrators want in a program. They are:

1. Good documentation : The administrator does not just want documentation that explains the terms like a dictionary; he wants a cookbook. Included in this category is documentation that defines where further help, in terms of a FAQ, mailing list, or support, is available.

2. Tweaking abilities , using either configuration items or command line options : The tweaks must also be documented in terms of task-based solutions. For example, the documentation should use the notation "To solve problem X, use option Y," and not "Option Y is used to do task X." The difference lies in how the administrator can solve problems; the documentation must describe the situation so the administrator doesn't have to read each option.

3. A guide to set the program up quickly : This is for the impatient. The administrator would like to know how to set the program up quickly, although it might not be the ideal configuration, because the administrator may need other settings.

4. An overview of all the files required in an installation: The administrator doesn't need to know what the application files do; rather, he needs to know which configuration requires which files.

5. A modular application : The administrator needs the application to be modular so that different configurations can be installed and maintained . The modules should be created in layers . An example of a simple and modular application is Apache Web Server. This is popular because non-programmers can set up a Web Server. Modules can be easily added using configuration definitions or compile time options. For an administrator, a reliable system is a simple system that can be understood . That way, if anything goes wrong, the administrator can figure out what is wrong on his own on.

6. Definition of the build process : This build process should be kept simple.

7. Not too many features : The administrator prefers a minimalist approach here.

Administrators have simple requests . Administrators are not developers, and this has a very important ramification. The administrator does not really care why program A exists, nor what business need it solves. It is as if you took your car to the mechanic and explained to him that the car is used to drive along a road with five curves and two stop signs. The mechanic wants to know only what noises are made in what context. Likewise, the administrator wants to know only when the application is needed and in which context. This is a hard thing for developers to swallow. Developers take pride and joy in watching the program run, and they want to talk about how well it works and solves the business process. The administrator could not care less, since in his eyes, it's just another application to keep running.

Plug-ins Equal a Happy Administrator

When you write programs that use configuration items, you will most likely include the ability to dynamically load plug-ins. Plug-ins are formalized Commons Bridge implementations. The main difference between a plug-in and a Commons Bridge implementation lies in the distribution. A plug-in implements an interface defined in another package. The implementation of the interface is stored in the plug-in package. This means that any application contains three packages: application, plug-in definitions, and plug-in implementations . To realize such a solution, you can use the Discovery package, which we discussed in Chapter 3. We didn't, however, address the details of implementing a plug-in framework. A sample plug-in framework is shown in Listing 8.1.

Listing 8.1

 URL url = new URL( Configuration.getClassPath()); URL[] urls = new URL[] { url }; ClassLoader classloader = new URLClassLoader( urls); ClassLoaders classloaders = new ClassLoaders(); classloaders.put( classloader); DiscoverClass discoverClass = new DiscoverClass( classloaders); Properties props = new Properties(); props.setProperty( InterfaceToBeShared.class.getName(), Configuration.getDefaultImplementation()); InterfaceToBeShared interf = (InterfaceToBeShared)discoverClass.newInstance( InterfaceToBeShared.class, props); interf.availability(); 

 

The code from Listing 8.1 is similar to code shown in Chapter 3. The small differences involve the use of a class loader and a configuration class. The code in Listing 8.1 would be located in the application package. It would be assumed that the plug-in definitions package would be referenced statically on the class path , like the application package. What is dynamically referenced and loaded is the plug-in implementation package. The class Configuration contains the information on what classes and paths the plug-in implementation package requires.

The class Configuration exposes two static methods : getClassPath and getDefaultImplementation . The method getClassPath returns a path or jar filename that contains the plug-in implementation package. To load the plug-in implementation package, you use the class ClassLoader . The class ClassLoader is part of the Java runtime and allows a developer to dynamically load Java classes on the fly. To make use of the class ClassLoader in the Discovery package, you add the class ClassLoader to the class ClassLoaders . This, in turn , is added to the class DiscoverClass .

The method getDefaultImplementation returns a class name that implements the plug-in definitions package. It is added to the class Properties, which is then referenced to find a default implementation for the plug-in. In Listing 8.1, the plug-in definition is the interface InterfaceToBeShared .

What Should Be Configured

Listing 8.1 contains the basics of what is needed to implement a plug-in architecture. However, a good application is not only about converting an application into a plug-in architecture. A good application is an application that can be tuned and managed. The following are items that you can tune:

• Database connection : This specifies who the provider is, as well as what connection settings are necessary to connect to the database.

• Pool size : This is the maximum and minimum size of the objects that are kept in the collection, and the length of time before an object is collected.

• Threads : This is how many threads the application will start.

• Factory : This is a dynamic specification of the objects that will be instantiated .

• Serialization : This specifies where the files will be saved and how the objects will be read and written.

• Messaging : This specifies which objects will receive messages, as well as which queues and topics are used.

• Collections : This is the type of collection used and the maximum and minimum size of the collections.

• Logging : This defines the levels of errors and warnings that need to be logged and written to some storage device.

The list presented is only a small example of what could be configured. If you consider Open Source programs like Apache HTTP Server or Jakarta Tomcat Server, it is very obvious that many additional items can be configured.

So, now comes the question that all developers need to ask themselves : what things should be configurable? Some administrators say that everything should be, so that the application is as flexible as possible. Other administrators say that everything that has affects how the application acts should be configurable. For example, allowing only three threads has a different reaction than allowing as many threads as necessary. Finally, other administrators say that developers should sit down with the administrator and ask him what he wants to be able to do.

In this last case, if the developer sits down with the administrator, he can extract the administrator's requirements, which are not user requirements. Administrator requirements are related to how to make the application run as efficiently as possible on a given set of hardware. The administrator wants to control the application, and hence those controls are specific to the administrator. The developer of the application may not know what the controls of the administrator are if he doesn't sit down with the administrator.

Command Line Management

Many people have a hard time with command line parameters. To many people, using the command line is nonintuitive, complex, and downright confusing. This may be true. Command line parameters are not intuitive and they are hard to learn. However, command line parameters are still necessary. Command line parameters are used to bootstrap a process.

For example, when a process starts, a configuration file needs to be read. However, how does the process know where the configuration file is? Some operating systems use strategies like managing a registry of configuration settings. The process uses method calls to hook into the registry and retrieve the necessary configuration items. A registry is OK, but the problem with registries is that it is extremely difficult to manage multiple configurations. A registry is a central location for all items, which also makes it a central place for failure. Time has shown that there are advantages and disadvantages to both a registry and configuration files.

If a registry is not available, then a command line parameter can reference the location of the configuration file. A command line parameter can also define certain items relating to how the application should execute. Overall, a command line parameter should not replace a configuration file but complement it.

Technical Details for the cli Package

Tables 8.1 and 8.2 contain the abbreviated details necessary to use the cli package.

Table 8.1: Repository details for the cli package.

Item	Details
CVS repository	jakarta-commons
Directory within repository	cli
Main packages used	org.apache.commons.cli

Table 8.2: Package and class details (legend: [cli] = org.apache.commons.cli).

Class/Interface	Details
[cli].Options	A class that contains a collection of acceptable command line options represented by the class Option .
[cli].Option	A class that defines an option. This class is a core class that defines an individual command line option and is used to fine-tune the definition.
[cli].CommandLineParser	An interface used to define a specific type of command line parser. Available implementations are BasicParser, GnuParser, and PosixParser.
[cli].CommandLine	A class that is returned when the parser has processed the command line arguments. Contained with the class are the processed options and arguments.
[cli].OptionBuilder	A helper class to assist creating an Option class instance.
[cli].HelpFormatter	A class used to output a help message that defines the available options and command line usage.
[cli].PatternOptionBuilder	A class used to retrieve available supported class types for type-specific arguments.