mValent Integrity provides configuration management support in an area where it is very much needed, managing the configuration of a J2EE application infrastructure environment. Key features of this unique tool include:

• the ability to display a consolidated view of the configuration files, spread across servers, that comprise an application infrastructure,
• the ability to compare the same configuration file on two servers,
• the ability to monitor changes to configuration files and to trigger an alert notification when a change occurs, and
• the ability to save a working configuration of application infrastructure configuration files and use this configuration when building a new environment.

These well thought-out features, implemented in a robust software tool, represent a significant advancement for viewing, troubleshooting, monitoring, and configuring a J2EE application infrastructure.

Introduction

I am a J2EE build and release engineer. Typically, I work on a team with other build and release engineers to support J2EE applications and test environments. My colleagues and I spend our days (and sometimes our nights and weekends) building and deploying J2EE applications. We also spend considerable time configuring new test environments and troubleshooting problems that arise in these environments. When not working these tasks, we automate manual build, deployment, and configuration procedures by creating or enhancing scripts.

Managing the configuration of test environments is a challenge when change is frequent and fast-paced. This seems to be common for J2EE application environments, especially when the environment contains an organization's Web site or corporate intranet. These test and production environments can be updated frequently as a J2EE application moves through the software development lifecycle.

Adding to this challenge, the critical configuration files needed to support an application infrastructure can be located in different directories on a server, or on different servers. For example, application server, Web server, Java properties, and database configuration files that comprise a J2EE application are unlikely to reside in the same directory on a server, or even on the same server. Troubleshooting a problem in a J2EE application infrastructure environment can be problematic and time consuming because of the effort required to isolate the problem to specific configuration settings, in particular files, on one or more servers. More often than I want, I spend hours locating the configuration files that I need to modify to resolve an application infrastructure problem.

While development organizations employ leading-edge technologies to build J2EE applications, often they rely on rather primitive tools to manage the configuration of J2EE test and production environments. An electronic spreadsheet seems to be a popular choice for maintaining critical configuration settings needed for J2EE applications to function properly. Even when critical configuration files are maintained under version control in a traditional software configuration management tool, build and release engineers may struggle to establish and maintain working configurations in test and production environments.

Product Overview

mValent Integrity is a new breed of configuration management tool designed specifically to manage changes to the application infrastructure used to run J2EE applications. The tool provides application server administrators and J2EE build and release engineers with a GUI-based view of critical configuration files on managed servers. More importantly, mValent Integrity parses the content of these configuration files to display critical configuration data in visually recognizable attribute-value pairs. From the GUI, mValent Integrity users can examine, compare, and monitor changes to each configuration setting. Additionally, application infrastructure administrators and J2EE build and release engineers can use mValent Integrity to maintain working configuration settings under version control, and then configure new test and production environments using these configuration settings.

Product Architecture and System Requirements

mValent Integrity is a client server application that runs under Apache Tomcat. The client is built on top of Eclipse, the open-source IDE for Java and J2EE development. The headless server uses an Oracle database for persistence.

For this evaluation, I installed both the client and server on a 1.7 GHz Intel Pentium M notebook computer with 1.25 GB of RAM and a 40 GB disk drive. The notebook was running Windows XP Professional, Service Pack 1.

Usually, the server software component is installed on a server running Windows Server 2003, RedHat Enterprise Linux WS 3.0 or ES 3.0, or SuSE LINUX Enterprise Server 9. The client software component is installed on a desktop or notebook computer running Windows XP Professional or Windows Server 2003.

Installation

Installation of the mValent Integrity database, server, and client is straightforward. The installation manual shipped with the software contains step-by-step instructions for each component to be installed.

The first component to install is the embedded Oracle database. This step is not required if you plan to use an existing Oracle database. Installation on a Windows platform consists of installing the setup files and executing the installation file. A wizard steps through the installation of the setup files. Then the installation file needs to be executed from the Windows GUI. While the database installation is black box, it is helpful to have access to an experienced Oracle DBA. (I needed to consult with an Oracle DBA to determine how to completely remove all the components from a previous installation of Oracle server software.)

After installing the embedded Oracle database, or electing to use an existing Oracle database, the next step is to configure the database. Using the Windows command prompt, you execute a SQL script to configure the database. The installation manual identifies the inputs you need to provide when running the SQL script.

The second component to install is the mValent server. A wizard steps through the installation of the mValent server. When installing the mValent server you need to identify the existing Oracle database to use if you elected not to install the embedded Oracle database. Also, you need to specify the mechanism that the mValent server will use to authenticate clients. The two choices on a Windows platform are Windows NT and LDAP (AD-JNDI). Finally, you need to specify the mail server that the mValent server will use to send email notifications.

The third component to install is the mValent client. Like the mValent server installation (on a Windows platform), a wizard steps through the installation of the mValent client.

Once the mValent database, server, and client are installed, you need to start Apache Tomcat to start the mValent server. For this evaluation, I elected to configure the mValent server to run as a Windows service. After starting the Windows service for Apache Tomcat, I launched the mValent client from the icon that was installed on my Windows desktop.

Key Features of mValent Integrity

Like information meticulously formatted into a spreadsheet, mValent integrity provides a consolidated view of the settings in configuration files that are spread across the servers that comprise an application infrastructure. Unlike the information in a spreadsheet, the information presented on the mValent Integrity GUI does not need to be updated manually. Rather, it is obtained automatically from the servers managed by mValent Integrity.

Figure 1 shows a comprehensive, yet consolidated picture of an application infrastructure configuration in the mValent Integrity GUI.



The left pane in Figure 1 is the Navigator view. The Navigator view depicts the configuration files on different servers across application infrastructure environments. The information presented in the Navigator view, and the way in which the information is organized, is configured by an mValent Integrity user. In this figure, the left pane depicts the configuration files on the servers in two test environments: Test Environment 1 in Austin and Test Environment 2 in San Jose. Each test environment consists of a BEA WebLogic application server, an Apache HTTP server, and an Oracle client. Notice that the information in the Navigator view is organized into a hierarchy of containers. Each container represents a project, an environment, a layer, or a folder. At the top of the hierarchy is the container for the project named Corporate J2EE Application. Beneath the project are the containers for the two environments: Test Environment 1 - Austin and Test Environment 2 - San Jose. Each environment consists of containers for the technology layers: Application Server, Web Server, and Database. Each technology layer consists of an asset. WebLogic 8.1 is the asset in the Application Server layer. Apache HTTP Server is the asset in the Web Server layer. Oracle is the asset in the Database layer. Each asset in a technology layer consists of the critical configuration files that allow the asset to function. Depending on how the asset is modeled (by an mValent Integrity user), the configuration files for the asset may or may not be organized into folders.

The upper right pane in Figure 1 shows the Editor area. The Editor area displays the contents of the selection in the left pane. Additionally, the Editor area is where the selection can be edited. The Editor area in Figure 1 shows the contents of the selected configuration file, httpd.conf. Notice that the contents of httpd.conf are displayed as a set of attribute-value pairs. mValent Integrity parses the information in the file so that it is easy to identify and modify.

Since the mValent Integrity client is built on top of Eclipse, the panes and information displayed on the GUI can be rearranged to match user preferences.

Viewing the configuration settings across all environments is extremely useful, but there are other features of mValent Integrity that make the tool far more valuable than the combination of an  information saturated spreadsheet and native command line utilities. Specifically, three features of mValent Integrity make the tool indispensable for isolating configuration problems and for configuring new test and production environments. These features are

• the ability to compare the same configuration file on two servers,
• the ability to monitor changes to configuration files and to trigger an alert notification when a change occurs, and
• the ability to save a working configuration of application infrastructure configuration files and use this configuration when building a new environment.

Before examining these features, it is important to understand how mValent Integrity captures and displays the information stored in application infrastructure configuration files.

Displaying an Application Infrastructure Environment in mValent Integrity

The first step to displaying an application infrastructure environment in mValent Integrity is to load data. The building blocks for loading data are connectors called authentication packs and resource specifications.

An authentication pack accesses the server whose configuration settings will be managed and monitored by mValent Integrity. One authentication pack is needed for each server to be modeled in, and managed by, mValent Integrity. To create an authentication pack, you specify the server name and the mechanism to use to connect to that server. The available mechanisms are FTP and SSH. Additionally, you need to specify the username and password of an account that can log on to the server then view or edit configuration files. Figure 2 shows the dialog used to create an authentication pack.



A resource specification identifies the files, and configuration settings in those files, to be managed by mValent Integrity. In addition to the file names, you need to specify the path to the files to be included in the resource specification. Resource specifications are flexible because you can use wildcards and regular expressions to locate and identify files. The strength of resource specifications is that they use mappings to parse configuration data in these files so that it can be displayed as meaningful attribute-value pairs. mValent Integrity contains mappings for a wide variety of configuration file types including XML, Java properties, Httpd, and Ora. Figure 3 shows the dialog used to create a resource specification.



After creating authentication packs to access servers and resource specifications to identify the files and data to be managed, you model the application infrastructure environment by creating organizational containers. Recall from the discussion of Figure 1 that containers model projects, environments, technology layers, and folders.

Projects are the top-level containers that model software development projects, such as the project to create a J2EE application for a Web site. Projects consist of environments. Environments model physical environments like a test environment. Alternatively, environments can model a geographic location like the Austin software development office, the Boston QA lab, or the San Jose server farm.

Environments contain technology layers with assets. Alternatively environments consist of assets only. Examples of technology layers include Web servers, application servers, and databases. Assets model the specific entities in an environment, such as the configuration files for a particular Web server, application server, or database.

Comparing Two Configuration Files

When troubleshooting a problem involving an application infrastructure configuration it is often useful to compare the same configuration file on two servers. However, this can be a tedious and painful task if you must concatenate each file in a separate telnet session. Even if you view the two concatenated files side-by-side, there is not an easy way to highlight the differences between the files.

However, this type of comparison is both quick and straightforward with mValent Integrity. Simply, locate the two assets to be compared in the Navigator view. For example, locate two servers that are running an Apache HTTP server. Expand each asset. Select the configuration file from each asset then select Compare from the context menu. mValent Integrity displays three columns. The first column lists the properties found in the union of the two files. The values of these properties from the two files are displayed in the second and third columns. This side-by-side comparison makes it easy to spot properties that are in one file, but not in the other. The side-by-side comparison also makes it easy to spot property values that differ between the two files. Figure 4 shows the information displayed on the mValent Integrity GUI when comparing the same configuration file, httpd.conf, from two environments.



Monitoring Changes to Configuration Files

Viewing and comparing the settings in configuration files is useful for troubleshooting problems, but the ability to detect file changes before a problem occurs is even more beneficial. J2EE applications often fail when the setting in a configuration is changed accidentally or when a required change is missed during a deployment. For example, a configuration file may be overwritten when the contents of a tar or zip file are extracted on a test server. Alternatively, a configuration setting may need to change when a new build is installed in a test environment.

mValent integrity makes it simple to watch configuration files and trigger alerts when these files change. Select the file to be tracked in the Navigator view then specify the tracking schedule on the Track tab in the Editor area. mValent Integrity checks the file for changes according to the schedule then displays an alert and sends an email notification if the file is modified. The lower right pane in Figure 1 shows the alerts triggered when a managed configuration file was modified.

Storing Configurations in mValent Integrity

While mValent Integrity is a great aide for troubleshooting problems with an infrastructure configuration, the tool shines because of its ability to save configuration settings for use in configuring a new environment.

Sometimes there is no task more painful to a build and release engineer than creating a new environment. Ideally, this should be a cookbook task. However, in practice it is rarely straightforward. The frequent changes that seem to pervade J2EE application infrastructures mean a build and release engineer needs to keep track of the correct configuration settings for each environment. More J2EE application failures probably result from incorrect configuration settings than from anything else.

mValent Integrity provides a provision feature that can assist build and release engineers when configuring a new environment. The provision feature extends from mValent Integrity's ability to store the configuration of an asset in a template. When a new environment needs to be configured, a build and release engineer can use the provision feature to create an asset on a server from the template. For example, the build and release engineer may wish to save a known good WebLogic config.xml file so that it can be used whenever a new WebLogic instance needs to be created. While it is possible to save a configuration file in a traditional SCM tool, mValent Integrity has the advantage that it knows where to write the file when provisioning it to a server.

Strengths and Limitations

mValent Integrity 3.0 contains significant improvements from the previous release. In particular, one key improvement in this release is the client server architecture. One limitation that I encountered while evaluating mValent Integrity 3.0 was my need to create an authentication pack that could access one server through another. Since this capability does not yet exist, I could only monitor servers that I could access directly. Unfortunately, many servers that I maintained could only be accessed by logging in to a "jump" server. To monitor the servers in these environments, I would need to install a separate mValent server in each remote environment.

Pricing

mValent Integrity is priced at $50,000 for the server software license with an initial 20 CPU pack of target servers priced at $10,000. The vendor can be reached at

mValent, Inc.
8 New England Executive Park
East Wing
Burlington, MA 01803
781-272-5650
sales@mvalent.com 

Conclusion

Configuration problems with your application infrastructure may not disappear if you use mValent Integrity. However, mValent Integrity represents a significant step forward for viewing, troubleshooting, monitoring, and configuring application infrastructure environments. mValent Integrity provides configuration management in an area where it is badly needed, managing the configuration of an application infrastructure.

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment