Apr 19, 2010 at 9:35 PM
Edited Apr 19, 2010 at 9:38 PM
First time I saw OSGi (java standard) I thought, well, a .net version would be a nice open source project to work on... But several details on the framework impairs that from being realistic, such as the inpossibility to unload assemblies from the domain
dinamically (as you would in OSGi when services/components are no longer needed) Have you been able to bypass this limitation? if yes, I'd be wildly interested in knowing how. If not, I would be equally interested in knowing how would you address the problem
for service applications that need hot plug but also hot unplug/restart/update components without shutting down the whole thing. That's a serious limitation which would confine mef to be an utterly complex plugin system for big UI apps. On the other hand and
after experiencing both worlds, I mean .net and java (and osgi). Having gone through DI containers, including my own when it wasn't a mainstream concept in .net as it was in java. There's still something missing in a truly componentized and modular software
architecture. It is not only how you wire your objects, but how you communicate information among them. In a very recent hardcore experience with OSGi, I have come to realize that the feature I liked the most is the local message bus (event adming in osgi
jargon), which allows you to send messages between components in a really decoupled way. At the end of the day, is that level of decoupling what really pays off. I mean, all the DI container and wiring and complex config has a value, but when you face the
challenge of mixing software from third parties, taking care of dependencies, matching types, transforming data. It's simply a hell and all those wires increase the cost of maintenance dramatically sometimes. But when you communicate your components (coarse
grain features) through a message bus the service runtime suddenly becomes something truly decoupled that delivers on the promises of scalability, portability, maintenability and all those things we are all looking for. So question is, have you thought about
a feature like that in the framework together with MEF? cheers
Loading and unloading of assemblies is definitely something we think a lot about. MEF doesn't provide anything specific for handling this. There are some approaches like shadow copying / app-domains to allow this, but it is quite painful getting there today.
We are looking into better solutions in the future though there is not a solution in sight as of yet. We do believe that addressing the problem actually requires significant changes in the core runtime of the CLR.
As far as component messaging, there are ways to achieve it today through injection of a messaging service. You can create your own, use
Prism's EventAggregator or Laurent Bugnion's
MVVM light which includes a Messenger class for loosely coupled communication. Folks are also looking to the ReactiveFramework's
IObservable as a possible solution as well.
We are also looking into a possible message based solution in the future. Can you give us more details on your specific scenarios?
Dear Glenn, About the use case, I can think of many industrial class applications, such as high availability web apps, with the need to update components without having to restart the whole app. In my case it is an industrial control system where each
device is an OSGi agent or component interacting with infrastructure components through regular OSGi services (fine grain framework features) and with other agents through the normalized message bus (functional contracts/coarse grain functionalities). The
architecture allows you to do crazy things, such as mixing two different runtimes from different vendors and make them work together through a simple bus adapter, whatever the dependency tree of each one of them. On the other hand, if you look at how OSGi
is evolving in the java community, you can expect that to progressively substitute j2ee as runtime for high end enterprise apps in a short time. I think the main reason is because we are all looking at initiatives like this, such as mef and osgi. We all realize
the benefits of componentization and soa, but there should be a sort of runtime as a base, it's hard to do that from scratch. I emphasized the bus approach because once you get all this wiring done in such an elegant way (and mef is really elegant and clean
I think) you then have to call your "contracts" in your code, hardcoding the cardinality of your object's relationship in a way. Thanks to the component framework (such as mef) you are able to say "I use one of this contracts called IFunctionality",
but then you have to hardcode the relationship with the aggregated component in the way "iFunctionalityInstance.DoSomething()". That's a step in extensibility, but not a giant leap in modularity. When you introduce the bus in the equation you go
one step further, going to a more behavioural design based on publishing behaviors on the bus (dinamically thanks to your extensible component framework) and then subscribing whatever you want to those behaviours. At that point you break the one to one barrier
of the di container approach towards a fully decoupled one to many approach. If you add native features for scalability, clustering, high avalability, and so on, to that framework, you have something unbeatable for industrial enterprise apps. Cheers. (ps:
how do you do to format line breaks in your posts, mine looks horrible... :-)