Is MEF OSGi for .NET?

Question

I'm just trying to get my head around the Managed Extensibility Framework (MEF) at the moment and digging into a bit. I have an Eclipse background so in my brain I currently have the equation:

MEF =~ OSGi for .NET

Based on what I have heard so far. Am I on the right lines?

Neap

You have accepted the most unrepresentative answer. Not knowing anything about MEF I can't compare the two, but I can firmly confirm that IoC is NOT an issue at all for OSGi, so as such it cannot be used as a distinguishing characteristic. By the way, what did you end up choosing for your project? – Bayberry

Answer 1

Scott Hanselman helped to highlights the specifics about MEF in his podcast 148 with Glenn Block.

Compared to OSGi, MEF is built upon "Inversion of Control" and OSGi is not: it (OSGi) will discover new bundle through a different mechanism based on a Life Cycle Layer.

MEF is focused on application extensibility. It uses DI as a strategy for composing the different extensions, however it is not in itself a generic DI container.

Since the last point can be confusing, the transcripts of the podcast can help:

The way I basically position it though, the difference between the two, is that IoC containers are really about managing a known set of things in different environments, like I want a logger in my disk environment, I want a mock logger in my test environment.

So MEF is really about managing an unknown set of things and what that boils down to is that in an IoC Container I tend to do either a convention-based or a registration, specific registration mechanism, to say here's what logger means, here's what this means, here's what that means.

MEF uses the code and a discovery mechanism and annotations on the code, which are attributes, where whatever shows up in the system, that's what's there.

So again, taking it to a higher level, it's about you use MEF to really manage a set of unknown things, you use IoC Containers to manage a set of known things.

Conclusion: (one of) the main difference is the discovery principle (IoC vs. lifecycle)

Ogata

I think the podcast was slightly mistranscribed: "IoC containers are really about managing UNKNOWN set of things" should be "IoC containers are really about managing A KNOWN set of things" – Marvismarwin

You mention that MEF is built upon "Inversion of Control". ayende.com/Blog/archive/2008/09/25/… says that the Managed Extensibility Framework is not an IoC container. – Topology

It is an framework which solves very specific problems in an "IoC" way, but it is not indeed an "IoC" per se. From Gleen Block: So what I would say is that if you look around a scenario by scenario basis, there are some things we do that overlap with what IoC Containers do and how we do it may be very different but it's really about the end goal of what we build it for. – Ogata

What are you talking about??? OSGi can do IoC in ten different ways backwards and forwards. – Bayberry

@drozzy Read Peter's answer below: "there are multiple IoC containers for OSGi available". OSGi itself doesn't do IoC. It does "broker" (service publication and discovery) and "DI" (Dependency Injection): theserverside.com/feature/… – Ogata

@drozzy: note that I am talking about "framework" here, not "pattern" (DI pattern being a specific form of the more general IoC pattern: martinfowler.com/articles/injection.html). However, IoC Container (the framework) is quite different from a DI framework: pocomatic.com/docs/whitepapers/ioc-vs-di/… – Ogata

You are right. I missread your answer as a criticism of OSGi, but upon closer (more careful) reading, I actually see that you mainly point out the differences between the two. I guess one thing that can be pointed out is that OSGi can be extended to accommodate MEF functionality, but not the other way around (otherwise, there would be something like that already). – Bayberry

@drozzy: "OSGi can be extended to accommodate MEF functionality" I agree, and I believe that's part of what Peter Kriens was pointing out in his answer below. – Ogata

@Ogata Nay, not extended, but built upon. Extending it would mean adding new components, whereas building upon it means using existing OSGi components to provide new functionality. Sorry, just correcting myself, as my wording did not reflect my thoughts. – Bayberry

@drozzy understood. Anyway, interesting comment, and a good way for me to revisit a three-year old answer ;) – Ogata

I'm surprised nobody talks about runtime isolation. Discovery mechanism is a terribly minor implementation detail, all things considered. Each OSGi module is a mini app that runs in its own isolated classloader, and only exports interfaces that it wants other modules to see. OSGi will use these interfaces to bridge communications cross modules. So you can't use reflection to discover/access internal components of other modules. This is a crucial defining feature of an extensibility (i.e. plugin) framework like OSGi, it guarantees a plugin can only access specific resources it's granted to – Gesner

^ ... and because each module is a mini app, it also means that in OSGi you can deploy/undeploy/hot-swap each module without restarting the entire app. Whereas MEF is basically an IoC framework. I.e. similar to Spring/CDI. It's a framework that inject an object exported by one library into another object that imports it - but they're still a single application. It's not meant to provide any separate/secure runtime isolation. – Gesner

Answer 2

Notice that OSGi is designed so that an IoC container can be provided on top of it as a module, actually, there are multiple IoC containers for OSGi available as well as other mechanisms: DS, iPOJO, Blueprint, and undoubtedly others.

Prae

Found an interesting article about using OSGi to address the deficiencies in a pure IOC approach: theserverside.com/feature/…. – Postexilian

Answer 3

Just stumbled upon this, but Prism seems to be the closest thing to OSGi in .NET I've seen! Look at their Modular Application Development section in the docs.

Just look at their example of the module dependencies (almost equivalent to bundles!):

<modules>
  <module assemblyFile="Modules/ModuleD.dll" moduleType="ModuleD.ModuleD, ModuleD" moduleName="ModuleD">
    <dependencies>
      <dependency moduleName="ModuleB"/>
    </dependencies>
</module>

It seems like over at Microsoft, the Patterns & Practices team serves as a kind-of OSGi Alliance equivalent.

Bayberry