On Architecture in IT

Definition of architect and architecture:
Architect is a person, who has a vision of how the system should be built.
Architecture is a specification describing how the system should be built.

Architecture checklist (the things an architect should, at least partially, care about):

• Domain
  
• External interfaces, including UI
  
• Integration with other systems
• Security
• Performance
• Scalability
• Configuration and change management
• Monitoring
• Technology zoo

ICE - Object Grid

Grid computing was born to solve extreme problems using combined power of many servers. Later it came to enterprise in two major forms: computational grids and in memory data grids. First ones were aimed to solve heavy computational problems, anothers' goal was to provide fast and convenient access to large amounts of data by storing it in memory.

But it turned out, that people often needed to solve complex computation problems, which required fast access to a large amount of data. So, they needed to combine these technologies. This was pretty clear for grid providers, so many popular compute grids, like GridGain and DataSynapse, provided functionality to store data in memory in a distributed way. On the other side, many popular data grids, like Oracle Coherence and GigaSpaces, provided features to run parallel computations. However, they still played their own role better: compute grid had better functionality to run distributed computations than data grid, and vice versa. In some cases this problem was solved by maintaining two grid installations: compute grid, running parallel computations, used data grid, where the data for these computations were stored.

Anyway, one problem remained: computations may run on server, different from the server, where the data for this computation is stored. Each vendor tries to solve this problem by providing its own data-aware routing techniques. In case of using multiple grid tools, this required additional efforts.

Recently, one interesting framework, called ICE, have appeared on the horizon. It is a pretty general framework and in a couple of words, it looks like CORBA on steroids. Based on this tool, there is a grid solution, called IceGrid. This grid stores data and computations in the same place in the form of objects (remember, this is just like CORBA). From the documentation it looks like that load balancing, replication, and other important grid-related stuff is in place. This product also has a number of significant installations in a real heavy loaded and highly scalable environments. So, at least, it worth learning.

I do not think that object oriented approach is a killer feature for the world of large-scale systems. For many heavy tasks it is better and clearer to have logic and data separated. But maybe for some tasks, IceGrid's approach will be better.

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.