1.2 J2EE applications management

< Day Day Up >

Application management is one of the fastest growing areas of infrastructure management. This is a consequence of the focus on user productivity and confirms the fact that more and more we are moving away from device-centric management. Within this segment today, J2EE platform management is only a fairly small component. However, it is easy to foresee that J2EE is one of the next big things in application architecture, and because of this, we may well see this area converted into a bigger slice of the pie, and eventually envision much of the application management segment being dedicated to J2EE.

Because J2EE based applications cover multiple internal and external components, they are more closely tied to the actual business process than other types of application integration schemes used before. The direct consequence of this link between business process and application is that management of these application platforms must provide value in several dimensions, each targeted to a specific constituency within the enterprise, such as:

The enterprise groups interested in the different phases of a business process and in its successful completion
The application groups with an interest in the quality of the different logical components of the global application
The IT operations group providing infrastructure service assurance and interested in monitoring and maintaining the services through the application and its supporting infrastructure

People looking for a J2EE management solution must make sure that any product they select does, along with other enterprise-specific requirements, provide the data suited to these multiple reporting needs.

Application management represents around 24% of the infrastructure performance management market. But the new application architecture enabled by J2EE goes beyond application management. The introduction of this new application architecture has the potential not only to impact the application management market, but also, directly or indirectly, to disrupt the whole infrastructure performance market by forcing a change in the way enterprises implement infrastructure management. The role of J2EE application architectures goes beyond a simple alternative to traditional transactional application. It has the potential to link applications and services residing on multiple platforms, external or internal, in a static or dynamic, loosely coupled relationship that models a business process much more closely than any other application did. It is also a non-device platform, yet it is an infrastructure component with the usual attributes of a hard component in terms of configuration and administration. But its performance is also related and very dependent on the resources of supporting components, such as servers, networks, and databases. The consequences of this profound modification in application architecture will ripple, over time, into the way the supporting infrastructure is managed.

The majority of today's infrastructure management implementations are confined to devices monitored in real time for fault and performance from a central enterprise console.

In this context, application management is based on a traditional agent-server relationship, collecting data mostly from the outside, with little insight into the application internals. For example:

Standard applications may provide specific parameters (usually resource consumption) to a custom agent.
Custom applications are mostly managed from the outside by looking at their resource consumption.

In-depth analysis of application performance using this approach is not a real-time activity, and the most common way to manage real-time availability and performance (response time) of applications is to use external active agents.

Service-level management, capacity planning, and performance management are aimed at the devices and remain mostly "stove-piped" activities, essentially due to the inability of the solutions used to automatically model the infrastructure supporting an application or a business process.

This proved to be a problem already in client/server implementations, where applications spanned multiple infrastructure components. This problem is magnified in J2EE implementations.

1.2.1 The impact of J2EE on infrastructure management

J2EE architecture brings important changes to the way an application is supported by the underlying infrastructure. In the distributed environment, a direct relationship is often believed to exist between the hardware resources and the application performance. Consequently, managing the hardware resources by type (network, servers, and storage) is often thought to be sufficient.

J2EE infrastructure does not provide this one-to-one relation between application and hardware resource. The parameters driving the box performances may reflect the resource usage of the Java™ Virtual Machine (JVM), but they cannot be associated directly with the performance of the application, which may be driven either by its own configuration parameters within the JVM, or by the impact of external component performances.

The immediate consequence on infrastructure management is that a specific monitoring tool has to be included in the infrastructure management solution to care for the specificities of the J2EE application server, and that the application has to be considered as a service spanning multiple components (a typical J2EE application architecture is described in 3.6, "Putting it all together" on page 80), where the determination of a problem's origin requires some intelligence based on predefined rules or correlation. This requires expertise in the way the application is designed and the ability to include this expertise in the problem resolution process.

Another set of problems is posed by the ability to federate multiple applications from the J2EE platform using Enterprise Application Integration (EAI) to connect to existing applications, the generation of complementary transactions with external systems, or the inclusion of Web Services. This capability brings the application closer to the business process than before since multiple steps, or phases, of the process, which were performed by separate applications, are now integrated. The use of discrete steps in a business process allowed for a manual check on their completion, a control that is no longer available in the integrated environment and must be replaced by data coming from infrastructure management. This has consequences not only on where the data should be captured, but also on the nature of the data itself. Finally, the complexity of the application created by assembling diverse components makes quality assurance (QA) a task that is both more important than ever and almost impossible to complete with the degree of certainty that was available in other applications. Duplicating the production environment in a test environment becomes difficult. To be more effective, operations should participate in QA to bring infrastructure expertise into the process and should also be prepared to use QA as a resource during operations to test limited changes or component evolution.

The infrastructure management solution adapted to the new application architecture must include a real-time monitoring component that provides a "service assurance" capability. It must extend its data capture to all components, including J2EE and connectors, to other resources, such as EAI, and be able to collect additional parameters beyond availability and performance. Content verification and security are some of the possible parameters, but "transaction availability" is another type of alert that becomes relevant in this context close to the business process.

Root-cause analysis, which identifies the origin of a problem in real time, must be able to pinpoint problems within the transaction flow, including the J2EE application server and the external components of the application.

An analytical component, to help analyze problems within and without the application server, is necessary to complement the more traditional tools aimed at analyzing infrastructure resources.

1.2.2 Importance of JMX

In the management of J2EE platforms, the JMX model has emerged as an important step in finding an adaptable management model.

The Java Management Extensions (JMX) technology represents a universal, open technology for management and monitoring that can be deployed wherever management and monitoring are needed. JMX is designed to be suitable for adapting legacy systems, implementing new management and monitoring solutions, and plugging into future monitoring systems.

JMX allows centralized management of managed beans, or MBeans, which act as wrappers for applications, components, or resources in a distributed network. This functionality is provided by a MBean server, which serves as a registry for all MBeans, exposing interfaces for manipulating them. In addition, JMX contains the m-let service, which allows dynamic loading of MBeans over the network. In the JMX architectural model, the MBean server becomes the spine of the server where all server components plug in and discover other MBeans via the MBean server notification mechanism.

The MBean server itself is extremely lightweight. Thus, even some of the most fundamental pieces of the server infrastructure are modeled as MBeans and plugged into the MBean server core, for example, protocol adapters. Implemented as MBeans, they are capable of receiving requests across the network from clients operating in different network protocols, like SNMP and WBEM, enabling JMX-based servers to be managed with tools written in any programming language. The result is an extremely modular server architecture, and a server easily managed and configured remotely using a number of different types of tools.

Impact on IT organizations

The addition of tools requires adequate training in their use. But the types of problems that these tools are going to uncover also require skills and organizational groups with IT operations. For example:

The capability to handle more event types in the operation center. Transaction availability events and performance events are typical of the new applications. This requires that the operation center understand the impact of these events and the immediate action required to maintain the service in a service assurance-oriented, rather than "network and system management"-oriented, environment.
The capability to handle and analyze application problems, or what appears to be application problems. This requires that the competency groups in charge of finding permanent "fixes" understand the application architecture and are able to address the problems.
A stronger cooperation between QA and operations to make sure that the testing phase is a true preparation of the deployment phase, and that recurring tests are made following changes and fixes. Periodic tests to validate performance and capacity parameters are also good practice.

While service assurance and real-time root-cause analysis are attractive propositions, the J2EE management market is not yet fully mature. Combined with the current economic climate, this means that a number of the solutions available today may disappear or be consolidated within stronger competitors tomorrow. Beyond a selection based on pure technology and functional merits, clients should consider the long-term viability of the vendor before making a decision that will have such an impact on their infrastructure management strategies.

J2EE application architectures have, and will continue to have, a strong impact on managing the enterprise infrastructure. As the future application model is based on a notion of service rather than a suite of discrete applications, the future model of infrastructure management will be based on service assurance rather than event management. An expanded set of parameters and a close integration within a real-time operational model offering root-cause analysis is necessary.

Recommendations

The introduction of J2EE application servers in the enterprise infrastructure is having a profound impact on the way this infrastructure is managed. Potential availability, performance, quality, and security problems will be magnified by the capabilities of the application technology, with consequences in the way problems are identified, reported, and corrected. As J2EE technologies become mainstream, the existing infrastructure management processes, which are focused today mostly on availability and performance, will have to evolve toward service assurance and business systems management. Organizations should look at the following before selecting a tool for transaction monitoring:

The product selected for the management of the J2EE application server meets the following requirements:
1. Provides a real-time (service assurance) and an in-depth analysis component, preferably with a root-cause analysis and corrective action mechanism.
2. Integrates with the existing infrastructure products, downstream (enterprise console and help desk) and upstream (reuse of agents).
3. Provides customized reporting for the different constituencies (business, development, and operations).
The IT operation organization is changed (to reflect the added complexity of the new application infrastructure) to:
1. Handle more event types in the operation center. Transaction availability events and performance events are typical of the new applications as well as events related to configuration and code problems.
2. Create additional competency groups within IT operation, with the ability to receive and analyze application-related problems in cooperation with the development groups.
3. Improve the communication and cooperation between competency silos within IT operations, since many problems are going to involve multiple hardware and software platforms.
4. Establish or improve the cooperation between QA and operations to make sure that the testing phase is a true preparation of the deployment phase, and that many integration and performance problems are tackled beforehand.

< Day Day Up >