Suitable for SOA?

Jan 13, 2009 at 6:17 PM
I'm building an SOA, and I need an extensibility mechanism. I realize that this is not exactly the use case for which MEF was intended, but I am considering all of my options. Here are my requirements:

1) Quickly deploy targeted business logic to the data center. Avoid regression testing.
2) Separate conditions from business logic. (E.g. run this code only for these customers.)
3) Audit transaction history to determine which extensions were run.

I like the way that MEF handles quick deployment of extensions as compared to an IoC container. Most IoCs require that you modify the config and reload the container. However, this strength is also a weakness in this scenario. In order to ensure that an extension has no unintended consequences, QA would insist on a regression test.

It appears that any qualifiers that you attach to an extension are part of the code itself. I would like to separate the code from the conditions under which it runs. That would allow us to turn features on and off by customer, for example, without recompiling. This can be accomplished in an IoC by putting those conditions into the config rather than the code.

The third requirement is a biggie. One of the most common questions from enterprise customers is "What happened?" I don't know of any out-of-the-box solution for this, so we'll probably roll our own.

Given this analysis, I'm leaning toward an IoC with a custom auditing facility. But I'd like your take on this scenario.
Jan 15, 2009 at 3:01 PM
Remember that the current incarnation of MEF loads extension assemblies into the same application domain as the main code, meaning you cannot overrite it at runtime because it's being used by the host process. You cannot either unload it at runtime without tearing down the entire application domain.