MEF and System.AddIns


Several people asked about the relationship between MEF and the technology in System.AddIn namespace. The answer is that these two are independent and complementary features. MEF is a primarily a composition engine. System.AddIn is an add-in activation and isolation technology. MEF’s engine will be able to compose objects that are simple CLR object, COM and DCOM components (more precisely managed proxies to these components), remoting proxies, and finally System.AddIn add-ins.


 


The following is roughly how we see the basic “architecture” (conceptual diagram) of these technologies. As you can see on the diagram, the composition engine works on abstract representations of components currently called ComponentBinders. The composition engine is not concerned with how the parts are actually implemented or activated (COM, simple new operator, or System.AddIns activation). Its only concern is to inspect the binders for dependencies they need (imports) and objects they can give (exports), and provide “matchmaking” services for the binders (blue arrows on the diagram).


 


Comments (8)

  1. Krzysztof,

    I absolutely love the work you have done. It’s so important to our industry. Making the consumption of others work a PLEASURE rather than a burden is quite an important area to focus on. Getting them to do it however (grin)…

    In that spirit, I have focused extensively on Domain Specific topics now for… A while. I care mostly about assisting other developers to achieve more, and this often comes down to how much their work can be leveraged by others and how ‘consumable’ it is.

    In my opinion this is just one of many small steps to move people to the big idea of ‘it’s all about the domain stupid!’. Although your work can be seen in a broad scope, I view it as effective to the software leaders attempting to hide complexity and expose simple abstractions for ‘their domain’.

    Have you reviewed the work in progress by Martin Fowler and his upcoming DSL book?

    I especially am fond of his chapter on what he has termed ‘Expression Builder’. I would of called it ‘Fluent Domain Specific Language API Design’ but that is why he defines things, not me.

    He clearly delineates between what has become a kind of de-facto stylistic approach (most notably in Mock frameworks today)  vs. more traditional OO style in exposing capabilities.

    Linq definitely has elements of this via as well in it’s non-sql styled api

    target.where(x=>x.IsCurrent()).Select…..

    For others who may be interested it can be found here:

    http://martinfowler.com/dslwip/ExpressionBuilder.html

    He defines this as:

    "A layer that provides a fluent interface over a regular API.

    APIs are usually designed to provide a set of self standing methods on objects, ideally these methods can be understood individually. This is in conflict to a fluent interface which is designed around the readibility of a whole expression, which leads to methods that make little sense individually.

    An Expression Builder provides a fluent interface as a separate layer on top of the regular API. This way you have both styles of interface and the fluent interface is clearly isolated, making it easier to follow."

    I find myself now instinctively exposing my API access to my work in this style.

    Thoughts?

    Kind Regards,

    Damon Wilder Carr

    http://damon.agilefactor.com

  2. Hi Krzysztof,

    Indeed, this diagram gives us a clear picture of what MEF is all about.

    Damon, even though the Expression Builder seems very nice, and the concept of transparently adding a Fluent Interface API on top of an OO one seems appealing, I think that a graphical designer (graphical DSL) that allow the wiring of components at design time (whatever their internal implementation is, thanks to MEF) would provide more value to 95% of the developers … and they probably wouldn’t have to read a book of Martin Fowler to understand how to use it (no offense to M. Fowler) ;o)

    Steve

  3. Damon Carr says:

    Steve,

    As always great feedback. In fact I agree with your statement for the most part under the view of what is the most likely to catch on with a caveot that I am not sure ‘Graphical DSL alone; can do it. I think it must be augmented, and I am having a hard time thinking of any strategic work by developers done purely in graphical tools. Perhaps a bad analogy but perhaps not: The Web Form/Controller relationship shows of a great use of GUI Productivity and Necessary complexity.

    My next comments speak to why I do not think we can assume the complexity of this area will get easier, and indeed could get harder (but in ways we do understand well).

    I believe for domains related to ‘configuration’ as it a popular and fun one to discuss (and where I tend to test a lot of ideas)  typically tweaking Castle core stack components to ‘eliminate the old ideas’ of what ‘XML Style assumed’ config is there into absolute (as you said) design time and even non-deterministic resolution strategies…. I really think there is something there but I might have another solution looking for a problem..

    Consider systems that might need to literally have thread-local state always drive the component resolution in guaranteed ways across atomic snapshots and you must lock as late as possible or your resolution could be wrong. You need lazy expression JIT resolution (one way to desribe it) as it will lock the items necessary as late as possible when the elements are rapidly changing on independent axes and you could grab a set of datum that represent a ‘dirty read’ from RDMS parlance.

    Imagine  a system I architected for CBS News for the national election reporting for congress, house, and for the right year president in 1998 and 2000.

    Polls close and a flood of data comes in. You must delay any commitment to the last possible second or you risk going on-air perhaps with no winner for a state declared as you resolved your state too soon and then used the instance. Not the best example as I want to go into biological areas but that would just be more confusing and even perhaps irrelevant.

    Also assume a critical dimension or I am not sure the above makes sense of incomplete decisions (heuristics based) with at least one incomplete or even missing element yet still resolve.

    Now this does make many nervous me included for the wrong usage and most just default to ‘single path in all cases’ model for resolution. The algorithms can be quite complex but they are still utterly deterministic, have no ability to improve/adapt and fail is any data is missing (basic expert system competencies).

    I also realize many cases could never do this do to audit/compliance/fiduciary problems. But I still believe many COULD leverage this as it might often be ‘more good and acceptable’ over say an exception.

    If indeed you can succeed you can provide to your consumer of this framework a ‘way for ‘good enough given highly complex analysis/compromise/fallback with adaptation in the realm of evolutionary type adaptation for ‘evolving and improving systems at the IoC level’ where ‘better instances get build over time from yourt Graphical DSL and textual.

    Behaviors where say XML style configuration could never come close.  

    For me I often work in optimization problems in quantitative finance so I do a lot of simulation work where I must have a lot of adaptive yet unpredictable run-time behaviors (monte-carlo simulation in one concrete example)  in the small (but not in the large). I may only make broad statements about ‘preferences’ for ‘investment approaches’ as strategies injected based on ‘interest rate, bond spreads, and much more

    This is a fantastic DSL Textual example as it is so much about a limited set of point in time, trend (temporal say) movement and more quantatative analysis of the macro ‘world affairs’ perspective yet also allow for strategies that can adapt to say ‘small-cap equity asset class changes in the last week;.

    This to me lends itself in my proof of concepts to fuzzy rules expressed via DSL techniques and then (for just one example) used in IoC areas. Think of all the other possibilities!

    Where I would love anyone’s feedback is ‘what is the killer application’ if any of this?

    Clearly any kind of adaptive system could benefit I believe as at least to me once the infrastructure is there for the domain it beats any existing solution construction techniques I am aware of.

    I am quickly amassing a lot of very interesting code that I would love to share with interested parties. However due to my work in Academia and on Wall St. I have people looking to make money from this as soon as possible, so open source is not possible. Also I cannot do it fast enough as one person and I cannot find resources to help. If your sick and twisted enough to love this work as we all do, lets chat (and if your close to New York City).

    Thanks,

    Damon

  4. ID10T says:

    Does anyone understand Damon Carr’s post from July 17, 2008 2:44 AM? It’s completely incoherent to me.

  5. Damon Carr says:

    sorry about that… I either needed much more content or much less. I tried to compromise and ended upp ot being as clear as I would have liked (GRIN).

    Long story short: DSLs are almost an assumed future ad I cannot see the tools being ‘just graphical’ – think UML but for ‘your company’.

    DSLs will be graphical to a point and textual for delivery with integration.

    Damo

  6. AdMax says:

    I don`t really understand how MEF and AddIns can work together if MEF exposes parts through CompositionContainer and AddIns finds plugins by calling AddInStore.FindAddIns(…)?

  7. Krzysztof Cwalina says:

    There are many ways to do it. I would start with the simplest: write a custom ExportProvider that activates add-ins using AddInStore.FindAddIns and returns them as exports.

    Glenn Block promised to write a sample showing how to do it, but he did not say when :-)

  8. I don’t see how they’re complimentary either.  Visual Studio would have the most comprehensive set of requirements for add-ins, as far as versioning and so forth goes, and yet Visual Studio will be using MEF, not AddIns.  ???

    Why would we want two ways to do add-ins, anyway?  We should have one library to do this, with different options for how it can work based on app needs.