AOP Monitoring Frameworks
Already, some interesting frameworks have appeared that use JMX and AOP to implement monitoring in Java enterprise applications. These frameworks can monitor run-time system optimization, application performance, SQL profiling, and other application areas. Here are a few of these monitoring frameworks, along with brief explanations of what you can accomplish with each.
- SONAR is an acronym for System Optimization and Navigation with Aspects at Runtime. Developed using XML, dynamic AOP, and JMX technologies, SONAR provides a unified framework for runtime system optimization and navigation to monitor the enterprise applications at application, framework/middleware/virtual machine and operating system levels. You can use SONAR to add dynamic instrumentation to an application, and to monitor HTTP requests, database access calls, and JSP pages.
- AWare is basically a set of reusable Aspects and AOP components for the AspectWerkz framework. It includes add-on Aspects for performance reporting with JMX, exposing runtime application performance to MBeans. The AWare framework offers Aspect components for various cross-cutting concerns such as management (using MX4J tool), search indexing (Lucene), role-based security, transaction demarcation, and persistence (Hibernate). Check out the AWare Web site for more details on these Aspect components.
- The Chires framework uses AOP to introduce JMX MBean support into plain Java objects. It instruments the Java classes through byte code manipulation and by registering the objects when they are instantiated or when Java EE application lifecycle events occur. Developers can configure the monitoring functions using Annotations or XML. Chires provides JMX interfaces to monitoring statistics, state and operations without any code changes to existing application.
- The DRIPS (which stands for Dynamic Rule based Instrumentation of Production Systems) project is part of BEA's dev2dev CodeShare community. The DRIPS framework has a profiler tool that dynamically calculates the response time of methods in a Java class using AOP techniques (based on the Aspectwerkz tool). The profiling data can be broadcast via JMX notifications to other applications interested in the data.
Also, in a recent article
on aspect-oriented performance monitoring framework, Ron Bodkin talked about the Glassbox Inspector tool developed using AspectJ and JMX technologies. He explained how this framework can be used for SQL profiling, monitoring the performance of database calls, and capturing statistics such as total number of SQL requests, total time taken, and worst-case performance for DB requests etc.
Cache Monitoring Using AOP
Adding the power of Aspects in the object cache monitor provides a loosely coupled and highly flexible and reusable module. Implementing an object cache monitor involves defining Aspects to intercept the calls to the cache at three join points:
- Before an entry is added to the cache.
- Before an object is explicitly removed from the cache
- Both before and after an object expires or times out
For example, by intercepting the calls, you can check object size (in bytes) and raise warnings if an object exceeds the allowed size.
AOP Cache Monitor Framework
An ideal cache monitoring framework should not only be able to understand the cause of any cache management problems, but also proactively predict the problems related to cache size, memory usage, number of cached objects, etc. before they actually occur. In other words, the framework should accommodate the following requirements:
- It should provide a GUI based administration console for monitoring and managing the object cache with the ability to view and edit cache behavior.
- It should notify appropriate individuals or groups when exceptions are thrown when storing and purging the data stored in the cache.
- It should provide the ability to expire the cached data on demand (via a Web-based JMX console).
- It should allow transparent cache configuration for changing settings such as the maximum number of objects allowed in the cache, expiration time, eviction policy, and memory cap (in MB).
- It should provide reports and auditing information to monitor cache trends.
- It should be transparent to the other application layers.
- It should provide a loosely coupled architecture between the application code and cache monitoring code.
- It should be easy to maintain; cache monitoring code should be able to change without having any impact on application logic and vice-versa.