According to Gartner, Java has penetrated as many enterprises as Visual Basic. The implications of this evolution in Java adoption highlight some cruel realities. Java, and by extension J2EE, are no longer niche technologies. The benefits of Java - combining code reuse and scalability - are well understood and validated. Enterprises worldwide have been investing billions of dollars in Web-based applications for years, and it's time to demonstrate a return on investment. For IT organizations to best leverage their investment in J2EE technologies, there are five important application development and deployment challenges to consider. How your organization addresses these challenges will impact the performance and success of your applications.

Visibility Challenge
As you progress from development to QA and into production, you lose visibility into your J2EE applications. The J2EE applications run inside the Java Virtual Machine (JVM), which runs on a J2EE application server, which runs on the operating system optimized for the hardware platform. There isn't an easy way to monitor these components to understand what each is contributing to performance and how interactions among them compound performance problems.

Visibility Performance Considerations
A mechanism for understanding what Java elements are contributing to performance overhead is needed. For example, organizations need to understand how the presentation layer communicates with the business logic layer. An understanding of how JSPs, servlets, EJBs, and JDBC calls are interacting in the context of application execution is needed. Visibility is important, and correlation of the total application context is required to isolate the root cause of performance bottlenecks.

Knowledge Gap Challenge
One of the greatest frustrations IT organizations face is finding qualified J2EE developers. No one will equate Visual Basic development with Java development, yet Java development is becoming equally pervasive. A common solution is to outsource J2EE development to specialized consultants and integrators. However, outsourced application development introduces an additional challenge: organizations are scrambling to find the resources necessary to develop and deploy J2EE applications.

Knowledge Gap Performance Considerations
Developing J2EE applications is only the first step; the applications also need to be tested and supported in production. One of the biggest oversights impacting the performance of J2EE applications is the lack of application knowledge in QA and production. This is extremely problematic in production environments where fast problem identification is required. What's needed is a way for less-experienced professionals to quickly identify problems, drill down and isolate the bottlenecks, and accurately recommend necessary changes. Automated correlation, analysis, and interpretation are necessary to bridge the application knowledge gap.

Performance Management Challenge
The most eloquent application architecture doesn't benefit an organization if the application doesn't meet service-level expectations. The real challenge in J2EE performance management is measurement. The tools and probes used in development are excellent developmental aids but can't be used in QA under load or in production. These development tools are too obtrusive and introduce too much performance overhead to be considered a viable solution for measuring application performance.

Performance Management Considerations
The best solution for measuring the performance of your J2EE applications is a tool that introduces very little overhead while profiling the performance of your application. More important, you should use a solution that has been designed for QA under load and production environments. Efficient data collection and correlation of the important performance metrics will reveal a true picture of application performance.

Communication Challenge
Have you developed the perfect application yet? What happens when things go wrong? One of the biggest challenges organizations face is the "blamestorm." The blamestorm is the inevitable finger-pointing that takes place when there are problems with the application. "It's not the application, it must be the database!" "It's not the database, it must be the network!" The one constant in the communication challenge is the lack of actionable information. Problem identification (e.g., the application is too slow) is not the challenge; the challenge is isolating the problem and identifying the responsible group to take corrective measures.

Communication Considerations
Multiple constituencies are involved in solving J2EE application performance problems. Two key factors contribute to resolving problems; the first is actionable information. The QA and production staffs need a solution that clearly highlights and isolates the performance problem. These groups need to provide detailed information to development. The second factor is easy information exchange. Performance management solutions that promote sharing performance information help address communication challenges best. With today's geographically distributed development and operations staffs, the ability of all parties to simultaneously view the same data and root-cause analysis facilitates rapid problem resolution.

Complexity Challenge
It's not uncommon for organizations to have five, six, or even seven tiers in their application architecture. The more complex the infrastructure, the more difficult it is to isolate performance overhead and bottlenecks. Two common elements in these complex Web-based applications are the J2EE application server and the database. Research has shown that many application bottlenecks occur in either the J2EE application or the database.

Complexity Considerations
The best way to address performance management bottlenecks in complex architectures is to identify where the bottleneck exists. The ideal solution will provide the ability to look at performance from an end-to-end perspective. The requirement is to understand what each application tier is contributing to overall performance overhead. Once the problematic tier has been identified, the next step should be an in-depth analysis to isolate the root cause of the problem. To fully understand the performance overhead, there should also be some correlation between the application tiers. For example, poor performance on the J2EE tier may actually be only a symptom; the root cause could be in the database. Only a solution that tracks, measures, and correlates performance across a complex application architecture will provide optimal application performance management.

Conclusion
J2EE application performance management should be proactive. It's infinitely better to find performance problems in development and QA before the application reaches production. However, given the complexity of J2EE applications, performance problems will arise. The degree to which organizations can address the challenges of visibility, knowledge gap, performance, communication, and complexity will determine the efficiency of application performance. Finding the right performance management solution will help organizations in any stage of development or deployment better meet the service level goals of their applications.