does MEF apply the SOA paradigm?

in this post I'm going to argue that the Manage Extensibility Framework (MEF),

is actually applying to the 4 tenet of Service Orientation Architecture (SOA),

therefore MEF is actually, in-process implementation of the SOA paradigm.

Background

when we speaking about SOA we used to think about technologies like web services and WCF,

which is cross process technologies.

but does SOA define that services should always be consumed from the clouds?

local services like loggers, rule engine, cache and more are everyday practice for in-process services.

What make your architecture, service oriented?

different architect having different opinions of how to construct SOA architecture,

but most of them agree that SOA design should apply to the 4 tenets of SOA.

The 4 tenets of SOA

  Service should have Explicit Boundaries.

  Service should be Autonomous.

Service API should rely on Contract.

  Service behavior and compatibility should rely on Policy.

How MEF apply to the 4 tenets?

  MEF boundaries define explicitly by the Export definition.

  separating exports into separate dlls will create autonomous unit which has no need

for any reference but the reference for the services contract.

 Imports does not aware of the actual implementation, imports are solely relay on the contract

(composition will find export that mach the import contract).

  MEF has different policies mechanism like metadata, creation policy,

instantiation policy, recomposition.

Summary

despite MEF being an in-process technology it does apply to the 4 tenet of SOA,

therefore it can consider as such.

CLR 4.0 tip (Strong Name)

CLR 4.0 come with some changes of the security API.

one useful new API is a new way of getting evidence without iteration loop.

and this is how it look:

CLR 4.0 transparent security

CLR 4.0 come with some changes to the security model.

in general the CLR 4.0 no longer assume the sandbox for the application.

you can still sandboxed your AppDomain and the CLR 4.0 will onerous that sandbox,

but running the same exe from local computer or from network shared folder

won't grant the exe different privileges (sandbox).

as result the security setting goes back into the administrators hands,

as it was before the .NET era and application restriction will be define equally

for both manage and unmanaged code.

the security is back again done at the OS level.

what you should be aware of the the transparent code concept,

and that security is no longer can be define at the assembly level (all the definition should done at the AppDomain level).

Transparent code concept

the analysis of .NET fundamental operation observe that there are only 2 operation which are dangerous:

• unverifiable code
• calling unmanaged code (P-Invoke / COM)

potentially harm operations define as security critical, and cannot be invoke directly from security non critical (transparent) code.

if non security critical (transparent) code need access for security critical operation,

it should do so by calling security safe critical operation (which play the role of the man in the middle).

this exactly what happens when you need to persist data into file

using in-browser Silverlight application,

the file open define as security critical so you have no direct access to this operation,

and the isolated storage defined as security safe critical, so it give you indirect

access to the security critical file open but only to restricted file paths.

Code snippet

you can get the code snippet from here.

line 1: by default your code consider security critical unless you decorate it with [AllowPartiallyTrustedCallers] attribute.

line 2: setting the security rules to level 2, is the default CLR 4.0 security model (level 1 is CLR 2 backward compatibility).

line 34: decorate the method as security critical (therefore it can be assessed only by security critical or security safe critical operations).

line 12: this invocation won't succeed because security non critical (transparent) operations cannot access security critical operations.

line 26: decorate the method as security safe critical (so this code can target security critical operation and be target by
             security non critical code).

lines 29,30: restrict the access using demand for file permission to the specific folder.

Summary

CLR 4.0 security model is taking one step back from absolute security management,

and one step to the to the side and forward by giving us more simple and understandable security model.

the transparent model dose not restrict malicious code from accessing critical operation,

(because the malicious code can be decorate with security safe critical), what it does is helping the

CLR to put it's security focus on the dangerous code section.

Point of interest

you can learn more about the CLR 4.0 security concepts on this video by Shawn Farkas.

MEF for Beginner (repeatable metadata) - part 9

this is the 9th post of the MEF for Beginner series, the series TOC is available here.

this post will focus on having repeatable metadata definition (cases like definition of multiple categories).

if you not familiar with the MEF metadata concept you may want to read part 8. 

Bad practice for repeatable metadata

In order to explain repeatable metadata, we will start by decorating export with

untyped metadata declaration (which consider as bad practice, use typed metadata

whenever you can, it is mach usable and reducing runtime failure).

the above code snippet decorate the plug-in with categories  metadata for both Travel and City (line 3,4).

notice that we should explicitly declare that those decoration is multiple (IsMultiple=true).

line 1: define the export.

latter on this post we will see the best practice of declaring the metadata using custom attribute.

Metadata view contract for repeatable metadata definition

the metadata view contract properties type, for repeatable metadata decoration, should be Array, or IEnumerable.

the following metadata view contract is capable to handle the above metadata decoration:

as you can see, line 3, define property that match the name of our metadata decoration (Categories)

and it is using array for its data type.

Best practice for metadata definition

as in the previous part, the best practice for metadata definition is

using  typed metadata, which mean to define attribute for the metadata.

as you can see it is almost identical for the definition of non-repeatable metadata attribute,

but with 2 differences:

• we should declare that the attribute allow multiple occurrence (at the end of line 2),
  this definition is equivalent to the IsMultiple definition on the untyped metadata.
• we should derive from Attribute (instead of ExportAttribute, otherwise we will get multiple
  instantiation of our plug-in).

the plug-in decoration will look as follow:

in term of code safety typed metadata leaving less margin for errors,

and it is match more usable because it is easier to understand which value are expected.

The Import decoration

our import should use the Lazy<IPlug, IMetadataView> in order to get the metadata information

(through the IMetadataView contract ).

Interrogating the metadata

the following code will compose and interrogate the metadata.

lines 6-8, is handling the composition.

line 10, iterating for each of the discovered plug-in.

line 13, iterating for each of the items in the metadata categories property upon specific plug-in.

Summary

having multiple metadata on the same export is slightly more challenging.

the main difference between working with repeatable metadata relate to the metadata decoration (AllowMultiple=true)

and having Array or IEnumerable at the metadata view properties level.

Download the code

the full code snippet for the samples covered by this post available in here,

full project download for the post sample and for WPF sample that using this post concept for

dynamic filtering of widgets by categories (as shown bellow), is available here for 2008, and here for 2010.

filtering widgets by categories sample (2010, 2008).

Point of interest

• do not use setter on your metadata view interface.
• do not use the [InheritedExport] because for some some strange reason it doesn't functioning well along with metadata.
• if you want to build advance metadata view contract you can use class instead of interface,
  but that class must have constructor with the following signature:
  public ClassName (IDictionary<string, object> metadata)
  inside the constructor you should map the metadata dictionary to the class properties.

MEF for Beginner (Metadata) - part 8

this is the 8th post of the MEF for Beginner series, the series TOC is available here.

this post will focus on the basics of MEF metadata capabilities,

the next post discuss the ability of multiple metadata decorations.

What is Metadata?

metadata is piece of compile-time information that can be attached to exported part.

• metadata is adding peripheral information to the part,
  (metadata information may define which operation system supported by the plug-in).
• metadata can be read before the instantiation of the part.

Typed metadata

MEF support both typed and non typed metadata, as is the case in other .net component

the best practice suggest using the typed metadata paradigm.

(our series will focus on the best practice of type metadata).

Which steps is needed for working with typed metadata?

the steps is needed is:

• define the metadata (attribute)
• decorate the exported part
• define the metadata view contract
• add the metadata view contract into the import signature

how to define typed metadata

defining metadata is very simple, all its take is to define attribute which

having public properties and is decorated with the [MetadataAttribute]

as you can see it is no different from any other .net attribute definition,

except of the decoration of [MetadataAttribute] in line 1.

Decorate the exported part

as you can see in line 2 the exported part is decorated with some metadata.

line 1 is decorating for the export (see the Improving the usability section for

learning how it can be more usable).

Define the metadata view contract

metadata view present the portion of the metadata that we want to interrogate,

(this contract can be class of interface and it can reflect all or part of the attribute public fields).

in the above case the metadata view contract is reflecting all of the public properties.

Import signature

the import definition should use Lazy type with 2 generics definitions,

the first definition for the plug-in contract, and the second for the metadata view contract.

as you can see in line 2, MEF will create enumerable of lazy plug-ins which having typed weather metadata.

Inquiring the metadata

having the above import we may use Linq query (or any other technique) to filter the plug-in

portion that suite our needs (without having to instantiate the unneeded plug-ins).

the above sample is using the typed metadata to filter the sunny activities.

Behind the scenes

what is happening behind the scenes it that MEF is using reflection emit in order to construct

the typed metadata view.

Improving the usability

we can improve the usability of the previous sample by inheriting the ExportAttribute

(instead of Attribute), that way we can have single simple decoration for our export part.

the above attribute define both typed metadata and export for the PluginBase type.

line 3: is inheriting the ExportAttribute.

the exported type decoration can be define using single simple attribute decoration.

you are no longer having to use different attribute for export and metadata,

and as in this case the export type definition is handled by the attribute,

which enhance the consumer usability by having less area for errors.

Code sample

the code sample is demonstrating scenario were we want to present only plug-ins that suit

the current weather (the sample is using Google API for getting the NY weather).

you can download the sample for VS 2010 from here and for VS 2008 from here.

Changes in the CLR 4.0 security model

The CAS (Code Access Security) model of the .NET is changing in CRL 4.0.

in general Microsoft has obsolete many of the CAS operations, simplify the access

to security related information, and omitting the support for having

security restriction at the assembly level (security restriction will solely manage by the AppDomain sandbox).

using obsolete APIs result with warning at the compilation and exception at run-time.

in general you should be suspicious of any APIs that getting Evidence parameter (especially at the assembly level).

you can read lot more on this topic at the NET Security Blog.

Summary

if you are using CAS or considering using it, you should be aware for the changes, otherwise your

code will fail at runtime.

MEF for Beginner (Recomposition policy) - part 7

this is the 7th post of the MEF for Beginner series, the series TOC is available here.

the current post will focus on the recomposition policy.

What is the recomposition policy?

by default the composition should assign the Import only once

(trying to recompose on already composed import will result with exception).

using the recomposition policy we can define that our Import

is allowing reassignment whenever the container is having changes.

What is it good for?

the recomposition can be handy for dynamic data discovery that can

changed during the application lifecycle

(you can put file watcher upon your DirectoryCatalog folder and refresh the catalog

when the change event occurs, this way you can add new plug-in at runtime).

you can also use it to reduce the pressure on your application startup

(by starting with few most common catalog at startup and latter adding the rest).

How to define recompose-able Import / ImportMany?

the following snippet demonstrate the decoration that needed in

order to define recompose-able Import / ImportMany:

as you can see, all it take is to set the AllowRecomposition to true.

Code Sample

the following code sample can be download from here,

it is demonstrating recomposition scenario.

Exported types:

the above code having 3 classes,

each of the 2 first classes ExpMtd1 and ExpMtd2 is simply exporting 2 string.

class ExpMtdRuntime is exporting single string that initialized at the construction time.

looking at the constructor it has no [ImportingConstructor] decoration which mean that

it won't be construct by MEF (we will manually instantiate it at runtime and then we will

introduce the instance to MEF).

Import

the import is decorated with the AllowRecomposition attribute, which define

that MEF can assign this property upon multiple composition.

Continues composition

the following code will demonstrate multiple compositions,

you can think on scenario like startup plug-ins loading, then latter adding less frequency used plug-ins,

or on demand plug-ins, that maybe adding new plug-ins that was initialize from data source. 

line 1: s_imp is the instance of the class that having the imports.

line 2: this is temporary variable that we use for storing the state of the collection before the recomposition so

we can get the gap of the changes after the recomposition complete.

lines 6-9: standard MEF catalog initialization, at this stage we only adding the import instance (line 9)

and the ExpMtd1 type (line 6), the catalog does not yet includes the ExpMtd2 and ExpMtdRuntime.

lines 12-18: listening to the changing and changed events, so we will able to write the gap of the

newly discovered parts to the console, whenever the container will recompose.

line 21: adding the ExpMtd2 (by adding new TypeCatalog), it will cause recomposition.

line 22-25: continuously adding ExpMtdRuntime instances, it will cause recomposition for each iteration.

Summary

The recomposition can be very useful in real-life scenarios and it is quite simple to implement.

MEF for Beginner (Part Creation Policy) - part 6

this is the 6th post of the MEF for Beginner series, the series TOC is available here.

this post and a few that will follow will cover some of the policies options available with MEF.

we will start with the instantiation policy.

How do we define policy?

we will define policy as instruction that will guide behavioral decisions that related

to the compose-able parts (the imported and exported parts behaviors).

What is instantiation policy (part creation policy)?

the instantiation policy, is the instruction for how parts should be instantiate.

there is 2 instantiation options:

• Shared: is a singleton model, which mean that exported part instantiation will instantiate once
  (not matters how many time this part was requested).
• Non Shared: will create new instance each time we are asking for exportable part.

What is the default instantiation?

the default instantiation model of MEF is the singleton model.

Best practice

the best-practice is to use the Shared (singleton) model.

this bring us to design consideration which suggest that you should design your

exportable parts as stateless and thread safe, so they won't be affected

by multiple calls (maybe on different threads) upon the same instance.

in cases that the singleton model is not suitable for you, it is recommended

to use builder pattern (to separate the exported part from the actual instantiation).

you should remember that using the non shared model is quite costly because

it is using reflection for the actual instantiation (by using the builder pattern you

can gain the same result with less pain).

How to define our instantiation model?

out of the box we having the [PartCreationPolicy] attribute which make it fairly simple

to define instantiation policy.

here is code snippet that using the [PartCreationPolicy] attribute, which I will immediately discuss:

at lines 1,2: we can see the contract definition (the contract does not dictate the creation policy)

the InheritedExport attribute means that any type derived from the contract will be automatically exported.

line 4: is decorating Person1 class to apply to the shared (singleton) model.

so no matter how many times Person1 will be imported it will always be the same instance.

line 7: is decorating Person2 class to apply to the non shared model.

so different instance of Person2 will be assigned for each import.

line 10: at the moment this could be somewhat puzzling but we will shortly clear this out.

in terms of instantiation this is the default and it is equivalent to the shared declaration

(unless the import decoration is explicitly asking for non shared policy).

so you may ask yourself why should they add this option if it equivalent to the shared one?

the answer for this question can be found in the next paragraph.

How to restrict our import discovery for specific instantiation model?

the default setting of Import / ImportMany is equivalent to the next snippet:

CreationPolicy.Any means that our import does not care about the instantiation model

of the parts, so the MEF discovery can assign any parts that match the IPerson contract.

the PersonsDefault property will be assigned with Person1, Person2 and Person3.

sometimes we want to be more explicit about what type of instantiation allowed for the import.

for those scenarios we can use the following decorations:

line 1: restrict the MEF assignment of PersonShared property to exported parts that created

under the shared policy, which is means parts that decorated with CreationPolicy.Shared or CreationPolicy.Any.

PersonsShared property will be assigned with Person1 and Person3.

line2: restrict the MEF assignment of PersonNonShared property to exported parts that created

under the non shared policy, which is means parts that decorated with CreationPolicy.NonShared or CreationPolicy.Any

(in this case the part that decorated with the CreationPolicy.Any will not instantiate as a singleton).

PersonsShared property will be assigned with Person2 and Person3.

Summary

MEF instantiation is singleton by default, but this policy can be altered.

you can find code sample that demonstrate the different creation policies here.

MEF for beginner is a blog series for developers that want to learn

How To use the MEF (Manage Extensibility Framework) technology.

the following post is currently available for this series:

more post is about to be written.

Secured directory catalog

I was discussing the question of how to secure your MEF application on this post 

where I was publishing replica of the MEF bits hopping that the Secured Directory Catalog will

find its way into the MEF core.

but as sad as it is :(, it won't make into the core.

you can read more about the MEF team consideration here.

anyway Glenn Block has suggest a solution for haw to build the secured catalog

without rewriting half of the MEF core, so as you might guessed,

I had created new directory catalog that let you control the assembly loading of your plug-ins.

the implementation of the Secured Directory Catalog can be found here.

it is given without any warranty, but with full source code.

actually it is real small implementation which you should find easy to review.

so enjoy the secured way of the plug-ins injection.

MEF for Beginner – Part 5 (Import)

this is the 5th post on MEF for beginner series, you can see the previous post here, here and here.

this post will focus on the Import aspect.

we will soon learn about the different signature that can be apply with the Import decoration,

but before starting with that, we should introduce the Lazy<T> class

which is a first citizen at the MEF world, and part of the CLR 4 types.

Lazy<T> definition

Lazy<T> is used in order of delaying the actual instantiation until it actually needed.

in fact using Lazy<T> the actual instantiation will occur the first time the Value property is accessed or ToString method is called.

you can use the Lazy<T> when ever you want to delay the actual instantiation of the

object that were discovered by the MEF composition.

The Import / ImportMany decorations

MEF is trying to discover parts that apply to Import definition constraint.

we can think at the Import definition as a where clause of the Linq query

(the from clause will be define by the Catalog / Export provider which will discuss latter on this series).

out of the box MEF offer an attribute model for the Import definition.

Decoration options

out of the box MEF is offering 2 type of Import decorations:

1. [Import] for single discoverable part.

2. [ImportMany] for discovering multiple parts. 

Note: you should use [ImportMany] if there is a possibility that MEF will discover multiple Exported parts

even if you need only one of those parts (you can latter filter one using Linq query).

if you ask for single part and MEF discovering multiple it will throw an exception or return null

(depending on the MEF policy which will discuss in the next post on this series).

Import single instance

as I said in the previous paragraph, you should not use the [Import] attribute unless

you really expecting single discovery (like the case of discovering UI shell).

you apply the [Import] decoration to properties that having a getter and a setter (the setter can be private),

actually you can decorate a private property too (not in Silverlight).

Note: you can also decorate fields but it considered as bad practice.

and you can use the Lazy<T> if you want delay instantiation.

Import decoration may look like the following code:

in the sample above the Import contract is concluded from the type of the property,

while in the next sample it is explicitly define.

note that the Lazy<T> is not part of the contract.

using explicit contract is useful while we want MEF to search for contract of specific derived

type and not for the type of the property itself.

in case that the Imported property can have null value you should add the AllowDefault=true

to the Import decoration ( it will look like the following [Import (AllowDefault=true)] ).

Import multiple values

Importing multiple values is done by using the [ImportMany] attribute.

we can assign this attribute to properties that having IEnumerable<T>, Array ([]) and

any type that derived from ICollection<T>.

the types within the above sets can be Lazy<T> for having delay instantiation.

the following code snippet will demonstrate the use of [ImportMany] decoration:

Construction time import

the last capability I'm going to discuss in this post,

is one that I advice against using whenever you can, because it can lead to

cross composition reference. just for knowing what to avoid from

I will now introduce you to the [ImportingConstructor].

the [ImportingConstructor] can be decorate constructor that should be use by

the MEF composition, so any parameter of this constructor is

treated as import which should be satisfied.

the constructor may look as follow:

Summary

in this post we learn which signature can be apply to the import definitions

and we present the Lazy<T> type and its role under the MEF world.

on the next post at this series we will survey different MEF policies that

can affects the behavior of the MEF composition process.

code snippet (console application) can be download from here.

Securing the MEF Directory Catalog

during my MEF lecture, on of the attendant (a fellow from check-point) ask the following question:

"How can we secure our catalog?"

this is a really good point, because without securing our catalog,

hackers can exploit our extensibility model for injecting malicious code.

so can we defend our MEF gates?

the short answer is yes.

and the long one is yes but…

Secure techniques

I will mention 3 techniques, each defend our code on different layer:

• IT layer
• CAS (code access security) layer
• Catalog layer (which involving some changes to the Directory Catalog)
  (I'm currently speaking with the MEF team trying to convince them to add the 3rd technique into the MEF core).

you may use all the 3 techniques together, for getting a multi layer protection.

IT level protection

the IT layer protection is very simple and straight forward,

all you have to do is to restrict the access privilege to the plug-ins directory,

in order to prevent none authorized  plug-ins deployment.

CAS (code access security) protection

because MEF is contract based (means that MEF will only discover parts that match specific contract),

we can defend our contract by using CAS technique like demanding specific strong name (or any other evidence).

the secured contract may look like:

as we can see in line 1, by restricting the access to our contract we can prevent
none authorized code from implementing it.

Adding predicate to the MEF Directory Catalog

Note: the secured version of the Directory Catalog is not currently in the box,

but i hope it will get in before the release time.

if you want to use it now you can download the modified MEF bits from my sky drive here.

thinking about the security risk I came to conclusion that the

mitigation should handle just before the assembly loading.

first it is more efficient and second we cannot handle the security after the instantiation

because it will be to late (constructor code can be malicious too).

Directory Catalog API modifications

the only change needed in terms of  the public API is to add new constructor

to the Directory Catalog, which will get lambda expressions (predicate)

that will authorize the assembly loading (just before the actual loading).

the new constructor definition is:

all you have to do is give a predicate with AssemblyName parameter so you restrict the

assembly loading upon the AssemblyName information.

using it may look like:

Summary

the MEF release is getting close, but I'm hoping that

this minor yet very important API change will get into the release.

so we will have an elegant way to secure our extension points out of the box.

Point of Interest

the code for the modified MEF code can be download from here.

if you interesting is which modification was needed at the MEF core level

in order to have this new API, I will describe it in this section.

actually as you will shortly see, I was changing only a few lines of code.

the reason that I decided to change the core rather of creating new catalog type was:

1. it seem like a feature that should ship as part of the MEF core.

2. because some of the changes was needed on internal methods,
    building new catalog would result with coping half of the MEF core.

Changes made step by step:

Step 1:

the above is the code of the new DirectoryCatalog constructor that include the authorization predicate.

as you can see in lines 6,7 I'm storing the predicate in private member (line 1)

Step 2:

the DirectoryCatalog class is having private method that responsible for creating AssemblyCatalog.

I was making 2 changes in this class:

1. at line 7, I added the authentication predicate to the AssemblyCatalog creation.

2. at lines 21-23, I added catch for security exception (so none authorized assemblies will be traced while the application will not crash)

Step 3:

adding internal constructor to the AssemblyCatalog

at line 3 you can see that I forward the authentication predicate to the LoadAssembly method.

Step 4:

the last modification was at the assembly loading level

1. at the method signature I added the authorization predicate

2. at lines 17,18 we use the authentication predicate to determine whether the assembly

is authorized (this happens before the actual loading of the assembly)

Conclusion

with a few minor steps we got match secured catalog,

once again i hope that i will manage to get into the release bits.

Code cartoons – MEF 

The super hero agency

Why and When slides from my MEF lecture

some time we are so enthusiastic about the technology,

that we forgot to explain the Why and When.

so I thought it could be nice to share those aspects with you.

when we asking Why to use the MEF technology we can think on the following reasons:

• Simple to understand

• Simple to implement

• The CLR 4 Extensibility standard

• Contract based model (type safe)

• Easy deployment (support copy / paste deployment)

• Zero configuration

• Ease of Maintenance

• Silverlight support

rules of thumb for When should we consider using MEF.

when ever we are using or considering one of the following,

we may use MEF instead:

• Reflection

• Factory pattern

• Command pattern

• Any other creational pattern

• IoC (Inversion of control)

MEF at the SDP

today i was lecturing at the SELA SDP about building composite WPF shell application using MEF.

first I want to thanks all attendant that was there despite of the latency in the schedule.

second I want to thanks Yaniv Rodenski for his part in the lecture.

Yaniv was demonstrating real world solution that combine the

WCF power with the MEF charm :)

as I promised you can find the presentation and the code sample that I was showing

(and Yaniv was kind enough to let me publish his code as-well) ,

at the following location:

http://cid-9bf7c1a515d76a9a.skydrive.live.com/browse.aspx/Code%20Samples/MEF/SDP

if you having question, or any thing else (except junk mail and viruses of course)

you can reach me at bnayae@sela.co.il