From today's integrated J2EE applications through the emergence of service-oriented architectures (SOA), enterprise Web applications are becoming more complex, dynamic, and vital to business success. The payoff is huge, but so are the new risks that have materialized. IT teams have an increasing need for new management solutions that provide visibility, analysis, and control of all tiers - from the application runtime environment to data, and through to Web services and business processes.

What's a Web Application?
Web applications today can take many forms. They can be .NET- or Java based, a Web service, an SOA component, a composite application, or a business process constructed through the orchestration of independent business functions. They can be customer-facing or a behind-the-scenes application. Any number of these applications can exist in a given environment, making the management of these applications even more difficult.

Business Process Mapping
It's imperative to be able to map business processes to the underlying Web applications that support it. Doing so provides the context necessary to evaluate the impact a particular transaction may have on a business process. For example, a Web service could be invoked from an online environment providing real-time access to back-end data and that same Web Service may be invoked in a batch process at night. The real-time transaction would require a higher level of service since a user is typically waiting on that transaction to complete and would therefore have a lower alert threshold than that of the batch application. Only by understanding this IT-to-business mapping would a management tool be able to make the distinction between the two different invocations of this Web Service.

Cross-Tier Application Tracing
Web applications will typically invoke multiple application components, including Web services, which in turn may talk to other Web services or application components. It becomes critical for the management of these Web applications to be able to trace the application flow as it crosses these application components, or tiers, in order to have a composite view of the application as well as an application's performance. Otherwise, performance data would have to be viewed in silos according to a physical server containing no application context to piece together a transaction's flow. While perhaps valuable at some level, viewing data this way lacks the information necessary to see what the application is actually doing during a transaction.

Root-Cause Analysis
The need for root-cause analysis is readily apparent when talking specifically about where a problem is actually occurring. Rapid triage is a necessity when managing a Web application as every minute the application is unavailable can literally cost a company thousands of dollars. The ability to compare and contrast Web application data with the environment in which it runs is critical to this triage. In fact, a problem with a Web application could have been caused by an environmental issue that occurred several minutes before but has now cleared up. The ability to compare and contrast this historical environmental data with the current application performance data is crucial to finding out where the problem actually lies. The mere queuing of requests for an application service can sometimes overload a Web application so badly that it will take some period of time before the server can process requests in a reasonable period of time.

End-User Experience Monitoring
The monitoring of an end user's experience usually occurs in two forms: active and passive. Active monitoring is where a product executes what is referred to as a synthetic transaction (thought of as a modeled transaction) to measure response time. To determine if the problem is network-related the same synthetic transaction will be run from a different geographical location to see if the response time problem is pervasive or just related to a certain Internet provider. A passive monitoring solution actually looks at the transactions as they occur to determine if the network component of overall response time is occurring. This type of solution is typically paired with a solution that can measure the host-based part of the transaction with the network time being calculated at the delta between the two. This passive view or access to timing data at the browser can also be used to see how well the client-side technologies, such as image loads and renderings, are doing.

Proactive Versus Reactive Management
In every problematic situation, whether it's performance-related or availability-related, it's imperative to operate in a proactive mode versus reactive mode, especially when you have composite applications involving Web Services. A failure at the Web Service level could impact several distinct transactions as they might all depend on the same Web Service. These types of proactive actions could be to initiate or suggest to the system that it perform a degree of memory management and recovery if it's determined that an application server is running low on memory. Another example of a proactive action would be to start an additional application server if it's determined that the current number of application servers can't process the incoming workload. Similarly, if it's determined that more application servers are running than is necessary to handle the current workload then one or more of the application servers could be shut down.

The Web Application's Environment
A Web application can only be managed in the context of its operating environment. Meaning that if an application is experiencing some sort of problem, either performance- or availability-related, the root cause may be environmental in the sense that it may be a problem with the CPU, IO, or a memory-related problem on the server or machine itself. Rogue processes, excessive paging or swapping, or IO-bound database operations can all impact the performance of Web applications while masking the true cause of the problem.

Rich Internet Applications and Their Impact on Web Application Management
Rich Internet Applications can slow down an application because of their client-side intensive computing or rendering. This makes a Web application appear slow to the end user when in fact no server-side processing may be taking place. This is typically found when a Web application is using a gratuitous amount of these technologies to try and make a Web application feel like a desktop application. While these types of applications are often viewed as a lower overhead alternative to traditional Web applications, they can, in fact, cause more Web traffic if the number, and size of the data returned, would exceed that of a single Web page being returned and rendered.

Conclusion
Never has it been so important to align business processes with their supporting IT infrastructure. Today this most often takes the form of a Web-based application, in some fashion, whether it's a traditional application or one that invokes one or more Web services. Several factors are pushing more and more business logic to the Web in the form of Web services including code reuse and the ability to componentize technology offerings in a business environment. This creates an environment that's dynamic and complex making it all the more difficult to manage. To properly manage these environments, tools and processes that provide the necessary visibility and control to proactively manage these environments must be in place.

Further Reading

• http://en.wikipedia.org/wiki/Web_application
• http://en.wikipedia.org/wiki/Rich_Internet_application
• http://en.wikipedia.org/wiki/Web_service