.NET lacks support for Microkernel architectures

In yesterdays post I bemoaned VS.NET constraining how we develop software. Now, that I´ve thought about this a little bit more, I came to the conclusion, what I´m looking for is support for Microkernel architectures.

Microkernels (although primarily known from the OS world) are a general architecture pattern. They allow a software to be extended without recompilation/relinking.

However, the CLR primarily supports static binding with dynamic loading. Assemblies get dynamically loaded when needed, but you need to statically reference them from your project.

Of course, the CLR also allows dynamic binding by loading assemblies by hand and using Activator.CreateInstance(). But these features are not tight together into a dedicated infrastructure to set up Microkernel architectures. For example there is no concept of a "registry" for implementations of interfaces by which you could instanciate implementations indirectly thus decoupling client and service.

To reach new levels in parallel/independent development and decoupling of components, though, we must move to "Contract First" design for intra-application "boundaries". (The SOA world has recognized this already for inter-application boundaries. See Christian Weyer´s postings on his tool for Web Service Contract First programming as an example.) Currently, the services of a component are (mostly) implicitly described/determined by its implementation, the actual assembly we are referencing.

But what we need, is an independet explicit description (a formal interface definition) against which we programm. And which only at runtime is dynamically linked to an implementation.

This of course entails changes in how we test/integrate our applications. But it also allows for many improvements in the process of application development from design to maintenance.

5 Comments

  • Sounds like you're describing COM, and .NET is an improvement over that.

  • Couldn't this be accomplished by having a layer on Application Domain classes/methods/properties? Perhaps similar to an Enterprise Library framework (e.g.,Data Access App) that crosses App Domains?

  • I guess the folks at the .NET Fx went a different aproach than the COM guys. They definitely did not want to have a registry, because of all the deployment problems that arise with it. Instead, .NET encourages you to ship your components in the same directory or a sub-directory of your applications installation directory. Then do a search on this directories for assemblies at runtime and search them for the interface you are looking for via reflection. After you found that interface, you can instantiate the assembly and - voila - you got dynamic linking. In this aproach, the file system takes over the role of the "registry".



    I think, even the COM aproach does not really help for a general component oriented architecture. Standard registry ProgIDs do not help, because they point only towards one specific implementation. Instead, in COM, you could create component categories. But did that really help? It only helped microsoft for some operating system components. But did it establish a standard, lets say for word processors? No. And that is the problem of todays lack of generally usable components: The big players are not interested in defining and implementing commonly supported interfaces for such components. Neither with COM nor with .NET nor with SOA nor with XML.

  • @Mio: When I used the term "registry" I did not mean a registry like the old Windows registry. I just wanted to use a neutral term for some sort of directory. Instead I could have used "directory" or "database" - but both are overloaded with meanings already.



    What I´m talking about is orthogonal to XCOPY or GAC deployment. It´s about finding implementations at runtime without knowing them at development time. It´s about dynamic binding (not to be confused with late binding or dynamic loading).



    For dynamic binding there is no need for "commonly supported interfaces". Dynamic binding needs a discovery infrastructure (like Fusion) which takes an interface and returns an implementation. The CLR takes a class and returns an implementation (objecc) - but for that the implementation has to be statically (!) bound to the client.



    Microkernels like the Castle project or Spring.NET point in the right direction - although they are lacking some features I´d like to see or are very comprehensive and thus take some time to learn.

  • @ouch: IoC is the foundation behind the Microkernel idea I´m pursuing. But IoC is not a solution. And still, there is no real IoC support in .NET. Spring.NET, Castle, Picocontainer are available solutions. But still, each is lacking something. Nevertheless they provide a starting point.

Comments have been disabled for this content.