Logging in a Distributed Environment

This distribution of components presents a difficulty. For example, while there exists a mechanism in the Java Servlet API to log directly to the servlet container's log, in practice it is no more flexible than using the old programmer standby System.out.println(). A solution is needed that can accommodate distributed logging requirements by creating a distributed logging mechanism that allows you to receive application log messages from many machines, and not simply log to the local machine as the above solution does.

The need to run in a distributed environment is now a feature of nearly all software applications. While it may not be readily apparent when developing an application on a single development machine, there will be some different challenges when it comes round to addressing the issue of a system that will scale to many clients, and many server machines.

Most commercial grade application servers provide scalability using server clustering. Clustering is a mechanism where two or more application servers run together and share the load of executing the business application software. For example, say a business is experiencing tremendous growth and its hardware infrastructure is not going to be able to support the number of users expected in the coming months. Rather than having to re-architect the software to run in a distributed environment, all that should need to be done is to add another server to the cluster.

Even if a logging utility is used, the largest problem of distributed application logging is that each application server will be logging messages within its respective environment. Since this is now a clustered environment, and load balancing is used by the servers, there is often no way we can know which application server a specific software component is executing on.

For example, say a client error occurs and it is determined that, based on the type of error, the problem must reside within a specific type of servlet. Even if we had the foresight of using a logging package and we are logging error messages judiciously, we must now figure out which application server is executing the servlet instance and then inspect the log file that resides on that particular system. In a cluster of two machines this is a small inconvenience, but imagine a clustered environment of ten application servers. Finding the machine that is executing that particular software component could be a tedious job.

This is a typical situation where the use of a distributed logging mechanism becomes vital, and where JMS is a prudent choice to solve this problem.

Choosing a Platform

There are many packages available for application logging, but not many that support distributed logging by any method other than direct socket connection. This is OK, but for a more elegant, flexible solution we can turn to JMS.

JMS provides several advantages over using custom direct socket connections for logging:

• It supports transacted and persistent messages, which the system guarantees to deliver. More software would need to be developed for a socket-based solution to provide this functionality.

• It supports the notion of topics, which allow you to manage your log message destinations simply by publishing to a topic created specifically for that message type. If you were to require that in a socket-based solution you would need to filter the messages yourself by creating software that acts in a similar manner.

Obtaining a JMS provider is the first step in creating a JMS logging tool. For our purposes here we will be working with BEA WebLogic Server 6.0, which provides an implementation of Sun's JMS API. The software included with this chapter should work with little modification with other JMS providers. Appendix A gives some guidelines for configuring code for different JMS providers.

Having identified our environment, we must either create or obtain a logging tool that uses JMS for the purpose of logging application messages. When determining whether to buy or build a logging solution, we must look at what tools are available in the marketplace and assess how they fit our needs, both from a requirements standpoint and from a budget standpoint.

JLog

I began investigating many of the various logging implementations that can be found around the Internet, and was fairly certain that I'd have to create JMS logging support myself until I ran across a logging implementation that seemed to fulfill my needs. The tool I ended up selecting is a tool called JLog from a company called JTrack (http://www.jtrack.com).

JLog is designed specifically to be used for distributed application logging. We have selected JLog as our logging implementation, but we still need to do some work to create a configurable logging service that can wrap (in the sense of the Façade pattern below) the functionality of JLog and provide an interface to application developers that will allow us to change logging implementations in the future should we need to.

Note 

From "Design Patterns" by Gamma, et al., 1995 ISBN 0-201633-61-2: "The Façade pattern provides a unified interface to a set of interfaces in a subsystem. This unified interface decouples the subsystem implementation from anyone using the façade."

To obtain the JLog package visit http://www.jtrack.com and download the latest JLog implementation. After downloading the package unzip the package to a chosen directory. The package will contain a JAR file with the JLog implementation, JavaDocs for the classes, and interfaces in the implementation, and another JAR file containing examples of how to use the package. Some of the examples contained with the JLog package are the basis for some of the examples contained within this chapter.

Overview of Basic JLog Concepts

The JLog package makes heavy use of the Observer pattern (see below) and is quite flexible because of the decoupling between objects that is achieved when using this pattern. Many observers can be created to observe a particular log instance without the log instance caring about how many observers there are. This lends great flexibility in the routing of messages to many destinations, perhaps to be interpreted in different formats.

Note 

From "Design Patterns" by Erich Gamma, et al., 1995: "The Observer pattern defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The objects being notified are called the observers and the object that is being observed is called the subject."

Additionally, observer filters can be created to observe a particular log, and only messages that match the filter's criteria are received. This is a very powerful mechanism to have at your disposal when creating a logging system.

Interfaces

The JLog package Observer pattern implementation contains two main interfaces:

• ILogEventProducer – This is the subject being observed. Classes implementing ILogEventListener register with classes implementing this interface.

• ILogEventListener – This is the observer that will register with, and observe the subject implementing the ILogEventProducer interface.

There are many other interfaces and classes in the package that extend or implement these two interfaces. The following class diagram illustrates the main interface relationships:

As you can see from the above diagram there are four main subinterfaces extending the basic event producing and listening interfaces, and two subsidiary ones.

Some of the basic component types implementing these interfaces are given below:

• Writers – which implement ILogWriter – used to write log messages to a specified medium

• Readers – which implement ILogReader – used to read log messages to a specified medium

• Logs – which implement ILog – used for recording log messages

• Filters – which implement ILogFilter – used for filtering messages based on a certain criteria

Additionally there are two more interfaces that extend the functionality of these interfaces:

• IFormattedLogWriter – Implemented by a writer intended to write messages in a specific format

• IMutableLog – Extends the ILog interface and defines how log messages can be removed from a log instance

Any writer, reader, log, or filter created with the logging package implements one or both of the two event interfaces, or one of their subinterfaces.