Who’s On Phirst

Being the honorary dev environment manager at Phurnace is a lot like being the employee of the month at a pig farm. Sure it sounds prestigious, but it really just means that you are able to deal with a lot of crap and you never mention how much it stinks. On the plus side, holding this title has given me a lot of insight into what our customers experience on a day to day basis. J2EE web application environments are difficult to manage. While the common commercial offerings provide great performance and availability for your web applications, the management and configuration of these platforms seems to have escaped the consideration of vendors for the most part. It doesn’t take long to become hopelessly mired in a deep directory tree digging through XML or a labyrinthine administration console that might as well be written in cuneiform.

The inclusion of Properties File Based Configuration (PFBC) in WebSphere 7.0 signifies a change in how platform providers view configuration challenges. They have recognized the pain and are now starting to address it. The aim of PFCB is to make the configuration data more accessible to users by storing it in key value pairs that are a little easier to read and understand than XML might be. The interface between these properties files and your application server configuration is a command line tool aptly named the Properties File Based Configuration Tool (PFBCT). The PFBCT is an extension of the wsadmin scripting interface and has 4 main modes of operation:

• applyConfigProperties - applies properties in a specific properties file to the configuration
• deleteConfigProperties - deletes properties in your configuration as designated in a properties file
• extractConfigProperties - extracts configuration data in the form of a properties file
• validateConfigProperties - verifies that the properties in the properties file are valid and can be safely applied to the new configuration

On the surface this sounds great. We have the methods we need to collect, test, update, and delete configuration information, and it seems pretty straight forward. This approach is similar to the approach of Phurnace Deliver because it abstracts the configuration data from the configuration mechanism. This makes configuration data easier to propagate in a large environment or port during environment updates.

Ultimately, I have to chalk this one up as a swing and a miss for IBM. PFCB (and its associated ‘T’) fails to simplify configuration management. In light of the following, I feel it complicates it further.

• The implementation is woefully inefficient - One of our fundamental beliefs as a company is that SCRIPTING IS NOT THE ANSWER and IBM has not given us a reprieve with this new tool. The implementation relies on the CLI and is very reminiscent of the wsadmin interface. In fact the only palpable difference is that the wsadmin syntax has been replaced with a different, but equally confusing PFBCT syntax. For example, to create a properties file for a server object you’d have to execute the following using the tool:
  AdminTask.extractConfigProperties('-propertiesFileNserver1Config.props, -configData Server=server1')
• The abstraction stops at resource attributes. You’ll notice from the example above, the object ‘server1’ must be explicitly declared in order to act on it. So if you have dozens of application servers and you need to collect configuration data from all of them, it requires dozens of individual PFBCT executions. In Phurnace Deliver, you just need to supply connection information and Deliver interrogates the server, gives you a choice of nodes to work with, and you’re off to the races, collecting the configuration data for all servers on the node or a subset of servers that you define. You also can get all the configuration data from Cluster, Cell, and Node scoped resources in your environment in the same shot.
• PFBCT supports only the most commonly used configuration attributes. Most notably absent are the attributes pertaining to Service Integration Busses.
• Absolutely no reporting of changes made. Nothing has been done to provide administrators with a summary of the changes made on execution. Instead, the PFBCT assumes you’re cool with “no news is good news.” When your company’s point of transaction is on the line, is that really sufficient?

On the one hand it’s heartening that IBM recognizes and has started addressing the problems associated with managing complex application server environments. On the other hand, this solution is anything but complete and seems like little more than an afterthought. I’ll be interested to see where they go from here. In the meantime I’ll stick with Phurnace Deliver.