JMX for .NET

JMX is a Java technology, which enables management and monitoring of Java applications. JMX is widely supported among software vendors. Many Java frameworks, including almost all application servers, provide access to the monitoring and management information via JMX, both as providers and cosumers. JMX consumer tools include JConsole, Hyperic HQ, Zenoss. But the main advantage of this technology is simplicity of using it to manage and monitor custom application.

Having this great technology in Java, it is not unusual to hear the question about which technology in .NET provides the same functionality. Generally, there is no exact clone .NET of JMX, however, there are some technologies, which can be used as an equivalent of JMX in .NET world. This technologies include Windows Management Instrumentation (WMI), Performance Counters, and .NET Profiling API. To be honest, first two technologies are related with Windows, but they can be used from .NET too, as it usually happens. Let's have a look at these tools:

.NET Profiling API
Unlike JMX, which covers both monitoring and management, .NET Profiling API deals only with monitoring. The API is pretty complex, but this complexity is repaid, because it allows developers to track every moment of application's life. Obviously, it is not a full equivalent of JMX in .NET, but it will cover use cases, where fine-grained and extensive monitoring is required.

Performance Counters
Performance Counters also deal only with monitoring application performance. Each counter is registered globally in Windows and can be used by applications, which fill the counter with performance information, and by applications, which track this information. Consumers of peformance counters include Performance Monitor (similar to JConsole to a some extent), Hyperic HQ with required plugins, etc. If developer's main goal is monitoring, Performance Counters can be freely used as an equivalent in .NET applications.

Windows Management Instrumentation
WMI is a Microsoft technology used for monitoring and management of devices and applications running on Windows. From the previous options, WMI resembles JMX the most. It looks a bit complex than JMX from the archtecture and .NET end-user points of view, but it also should provide more features. WMI was initially based on COM, so first implementation for .NET was pretty complex in terms of WMI providers' development, and the entire functionality was limited to monitoring. However, in WMI extensions for .NET 3.5 limitations were removed and writing WMI provider became easier. Like JMX, WMI is used by many monitoring tools, so, it can be treated as almost equal to JMX in Windows and .NET environment.

Custom Implementation
The fourth option can suite developers, who uses JMX in their applications, but doesn't use other JMX-enabled tools. It can happen when both JMX provider and consumer applications are home-grown and the power of the fact, that JMX is standard, is not used. In this case, custom objects exposed through WCF, Remoting, ASP.NET web services, or other communication means can be used.

So, if developer migrates from Java to .NET and searching for equivalent of JMX, he have a number of options. The exact choice will, as always, depend on the concrete use case.

Getting Started with .NET Profiling API

In a couple of words, .NET Profiling API allows writing a program, which can monitor other CLR program's execution. Tools like JetBrains dotTrace and the similar can be written using this API.

There is a lot of detailed information about .NET Profiling API in the Internet, so I will just try to list existing sources.

1. .NET Internals: The Profiling API. Introduction to monitoring of .NET applications using performance counters and .NET 1.0 Profiling API. Contains theory and source code samples. Unfortunately, samples are written in Delphi and there is no project, which is ready-to-compile-and-work.
2. Under the Hood: .NET Profiling API and the DNProfiler Tool. Little amount of theory with a couple of practical hints of profiler implementation with 1.0 version of API. Unfortunately, link to DNProfiler is broken.
3. Inspect and Optimize Memory Usage with the .NET Profiler API. Acticle regarding memory monitoring with sample application and source codes, written with 1.0 version of API. Sample builds well, but doesn't work in my environment, maybe because I tried to build samples with .NET 2.0 and profiler was implemeted version 1.0 of profiling API.
   
4. Creating a Custom .NET Profiler. A couple of hints with working profiler sample in compiled and source code forms. Profiler is written using .NET 2.0 version of API.
5. No Code Can Hide from the Profiling API in the .NET Framework 2.0. Description of new features in 2.0 version of API and working piece of sample code.
6. Profiler Stack Walking in the .NET Framework 2.0: Basics and Beyond. Piece of theory about Profiling API without working sample. Version 2.0 is covered.
7. Rewrite MSIL Code on the Fly with the .NET Framework Profiling API, Modifying IL at Runtime, Modifying IL at Runtime (step II), Modifying IL at Runtime (step II+), Modifying IL at Runtime (step III). A set of articles on using .NET Profiling API for generating code at runtime. Covers version 1.0 of API.