email article printer friendly get the code

Monitor Multitiered Apps in One Location
Take advantage of a solution that gives you one place to view the status of all applications running within the network
by Mark Nadelson

April 2003 Issue

Life would be so much easier for developers if we could go back to the days of the one- or two-tiered system architectures. I would sleep much better at night if I knew my applications had none of the network interactions and 24/7 application run-time requirements required by today's newfangled and quite prolific n-tiered architectures. But software development is like life (I know, very deep for a technical article): the more process interactions you add, the more complicated it gets, and the harder it is to pinpoint what is wrong. Unfortunately, this perception is not an excuse for system failures that our users want to hear.

The situation quickly goes from bad to worse. For an example of a problem within a complicated system, suppose a bizarre bug in the client GUI causes a message to be sent to a Java Message Service (JMS) server that in turn issues an invalid request to an Enterprise JavaBeans (EJB) entity bean to persist data to the database, which violates a unique constraint. The user of course can't remember what he or she did to cause the error, and the system is now stuck in an invalid state. The next time a user accesses the system, the problem causes the JMS application to crash, and the user's GUI hangs—but you don't know that the application crashed because it is running in the server room in a building across the street. Good luck debugging that!

The problem of monitoring and debugging a company-wide network of multitiered applications across many locations, both nationally and internationally, motivated me to develop an application capable of monitoring and administering the activity of an ever-changing array of applications. A further complication is that not all of my applications are written in Java. Some are written in C++, some are written in Delphi, and some are third-party applications written in who knows what.

I never want to write code unless I have to. I know there are monitoring tools that come with application servers, but they monitor only those applications running on that particular app server. If you happen to have the JBoss application server running at your local site in New York, servlets running under Tomcat running in London, and a few stand-alone RMI and TCP socket-based applications in another location, there is no one monitoring tool (at least none that I'm aware of) that can administer such a diverse group—especially if you throw in a mix of non-Java-based applications.

Simple and stupid is always my approach to systems engineering, and I have tried to use this approach when developing my application-monitoring architecture. I don't want to have to implement 15 interfaces from a hierarchy of a half-dozen levels to enable an application I've already written to register and interact with the application monitor. It's too much work and too much to remember. Don't get me wrong; there is complexity but it is all within the centralized Application Monitor Server. The client implementation is thin and simple.