From time to time I hear people say "those who can, do; those who can't, manage." Usually a developer mutters this as he begins another 80-hour week courtesy of a slip in the project plan. Of course, once you get to be management yourself, you realize there's more to it than simply ticking off hours on a project plan.

This holds true for application servers as well as development teams. It seems that development features often take precedence over management in the planning of release cycles for application servers. To a certain extent, this can be pushed up a little in origin, to the J2EE specification itself, which up until now has been somewhat sketchy on the management aspect.

While we're on the subject of the specification, let me throw my usual plug in for management nirvana - standardize the deployment and management console please! JMX is all well and good for instrumenting applications, but we need a standard set of properties, appearances, and behaviors to make it easier for an application developer to move from one server to another.

I realize that the console is one area where vendors tend to differentiate themselves, but as a veteran of successive versions of WebLogic, and of J2EE, I can speak for the vast majority who are tired of relearning how to deploy an application with every new version of the specification or the server. Enough is enough.

But enough of that rant. Back to management itself. We need to be able to do three things in an application server - monitor an application, manage aspects of the application's behavior, and maintain the application through successive releases of code.

From a monitoring perspective we need to know how many transactions (I use the word transactions to indicate a completed logical unit of work by the container, but others may disagree) have taken place, how many per second, the average throughput, the peak throughput, peak sustained load, refused connections, exceptions, etc. The whole concept of monitoring is being able to look at specific concepts around an application to determine how well it is running, over a variety of metrics.

Monitoring would be of little value if we were unable to do something about it - that's what management is all about. From the basics of being able to add another server, or deploy a component on another machine, to being able to change the routing of messaging, management allows us to control and change aspects of an application in real time. Some of these aspects are generic, such as locations and distribution of queues, beans, and pages. Others are specific, and must be engineered through JMX, which again will be fed back to the console.

Finally, we need to maintain applications - throughout their life cycle. Some of this has to do more with source code control and configuration management, but the ability to deploy into an application server and maintain an application is also crucial.

Of course, this doesn't imply that BEA hasn't done a good job on creating a management environment for WebLogic - it has. Many of the features I've cited are part of the WebLogic environment. What I want is for the environment to stay stable in the future - not switch from command line, to console, to JSP app, to whatever is next. Granted, that is somewhat the nature of the JCP, which is why we need BEA to be pitching for a management standard.

Enough ranting. Time for me to tell a project team they have three days to do an entire application. Ah, the joys of management.