Flexibilisierung von Komponentenarchitekturendurch das Managed Extensibility FrameworkEin Teil des Anfang 2010 erscheinenden .NET-Frameworks 4.0 wird das Managed Extensibility Framework (MEF) sein. MEF dientzur einfachen Erweiterung von Anwendungen und ermöglicht einen reibungslosen Austausch einzelner Komponenten. Von Hausaus bietet MEF ein Programmiermodell, welches mit Attributen arbeitet, um angebotene und benötigte Schnittstellen einerKomponente direkt im Quellcode zu definieren. Diese werden anschließend von MEF mittels Reflektion zur Auflösung vonKomponentenabhängigkeiten ausgelesen und verarbeitet. MEF bietet als integraler Bestandteil des .NET-Framework 4.0 alsoeine Möglichkeit zur standardisierten Beschreibung von Komponenten und deren Schnittstellen. So können Komponenten überProjekt- und unter Umständen sogar Firmengrenzen hinweg wiederverwendbar gestaltet werden.

Komponenten und ist somit für dieKomposition von Komponenten zuständig.Die Composition Primitives kapseln diekonkreten Programmiermodelle vom Kernab. Somit bedarf es bei der Erstellung eineseigenen Programmiermodells keinerleiAnpassung in der Container-Schicht. DasAttributed Programming Model wirdbereits mit MEF ausgeliefert. Parallel zudiesem kann ein eigenes, hier als Custom

ren. Einzelne Projektteams möchten jedochnicht auf die Vorzüge ihres speziellenModells verzichten. MEF bietet durch einsehr anpassbares Programmiermodell einenguten Ansatz zur Flexibilisierung von kom-ponentenbasierten Ansätzen. So könnendie Komponenten eines Modells in anderenverwendbar gemacht werden.

Dieser Artikel soll eine Einführung in dasManaged Extensibility Framework und dasvorhandene Attributed Programming Mo -del liefern. Anschließend wird gezeigt, wieein eigenes Programmiermodell erstellt undgenutzt werden kann, um MEF inVerbindung mit einem eigenen Kompo -nentenmodell (COMPASS) nutzen zu kön-nen.

Überblick über das ManagedExtensibility FrameworkDas MEF teilt sich in drei Schichten (vgl.Abbildung 1). Der Kern, die Container-Schicht, bietet Funktionalitäten zur Auf -lösung von Abhängigkeiten einzelner

EinleitungIn vielen laufenden Projekten werdenbereits Frameworks eingesetzt, die eineähnliche Funktionalität bieten wie dasManaged Extensibility Framework. Sehrverbreitet in diesem Segment sind Frame -works wie Spring [spr], Castle [cas] oderUnity [uni], die allesamt auf dem Depen -dency Injection (DI) Prinzip, einer Spezia -lisierung des Inversion of Control (IoC)Musters [Fow04], basieren. Die dort ver-wendeten Prinzipien haben sich in dermodernen Softwareentwicklung bewährt.Abhängig von den Projektanforderungenhaben sich verschiedene DI-Container eta-bliert.

Dieses sehr heterogene Feld von DI-Containern senkt das Maß an Wieder -verwendbarkeit einzelner Komponentenenorm. Eine Komponente kann nur inner-halb des speziellen Modells wiederverwen-det werden. Ein projektübergreifendes odersogar globales Komponenten-Repositoryist durch diesen Umstand kaum zu realisie-

der au tor

Ralf Kruthoff-Brüwer

(E-Mail: r.kruthoff-bruewer@fh-osnabrueck.de)schloss 2009 das Studium der Medieninformatik abund war anschließend in einem 6-monatigenProjekt der Science to Business GmbH beschäftigt,in dem es um den Entwurf eines skalierbarenServersystems zur Auslieferung von Daten an PVR-Systeme ging. Seit September 2009 arbeitet er imProjekt "Strategische Flexibilität durch komponent-enbasierte Software-Entwicklung" an Modellen zurkomponentenbasierten Softwareentwicklung.

Prof. Dr. Frank M. Thiesing

(E-Mail: f.thiesing@fhos.de)ist Professor für Software-Engineering undMathematik in der Fakultät Ingenieurwissen -schaften und Informatik der Stiftung Fachhoch -schule Osnabrück. Sein Forschungsschwerpunkt istdie komponentenbasierte Softwareentwicklung.

Frank Nordemann

(E-Mail: info@franknordemann.de)hat sein Studium der Medieninformatik an derFachhochschule Osnabrück im Sommersemester2008 abgeschlossen. In seiner Diplomarbeit hat ersich mit der Entwicklung eines leichtgewichtigenKomponentenmodells befasst und in diesemZusammenhang Methoden zur Komponenten -komposition, -aggregation und -introspektion ent-wickelt. Mit seiner Tätigkeit in einem Forschungs -projekt führt er Untersuchungen im Bereich derkomponentenbasierten Softwareentwicklung fort.

1 www.objektspektrum.de

fachartikel

Abb. 1: Architektur des ManagedExtensibility Framework

Programming Model bezeichnetes, Pro -gram miermodell erstellt werden.

Imports und ExportsUm Abhängigkeiten unter Komponenten inMEF auszudrücken, werden sogenannteImports und Exports verwendet. EinImport definiert eine benötigte Funktio -nalität einer anderen Komponente. EinExport definiert eine Schnittstelle die dieseAbhängigkeit erfüllen kann. Schnittstellenwerden MEF-intern durch einen Vertrags -namen und selbstdefinierte Metadaten aus-gedrückt.

Das Attributed Programming ModelDas bereits mit dem MEF ausgelieferteAttributed Programming Model bieteteinem Entwickler die Möglichkeit, dieDefinition von benötigten und angebote-nen Schnittstellen direkt im Quellcode vor-zunehmen. Somit kann man auf sehr einfa-che Weise Komponenten definieren.

Code-Ausschnitt 1 zeigt die Definitioneiner angebotenen Schnittstelle durch dasExport-Attribut. Als Parameter wird derTyp der Schnittstelle als Vertragsname ver-wendet. Hier kann auch eine einfacheZeichenkette (String) eingesetzt werden,um die Bezeichnung der Schnittstellenunabhängig vom echten C#-Interface zudefinieren.

[Export(typeof(IMovieLister))]

public class XML_MovieLister {...}

Code-Ausschnitt 1: Export-Definition nachdem Attributed Programming Model

Um diese durch das Export-Attribut definier-ten Schnittstellen zu nutzen wird das Import-Attribut verwendet (siehe Code-Ausschnitt2). Auch hier gibt es weitere Möglichkeitenden Vertragsnamen anzugeben.

[Import]

public IMovieLister lister { get; set; }

Code-Ausschnitt 2: Import-Definition nachdem Attributed Programming Model

Die Composition PrimitivesBasis des Attributed Programming Modelund auch des zu erstellenden eigenenProgrammiermodells sind die CompositionPrimitives (siehe Fehler! Verweisquellekonnte nicht gefunden werden.). Sie kap-

seln das Programmiermodell von den MEF-Kernklassen. Zur Erstellung eines eigenenProgrammiermodells müssen die Compo -sition Primitives zumindest teilweise imple-mentiert oder erweitert werden.

Im MEF wird jede Instanz einerKomponente durch einen ComposablePartrepräsentiert. Er enthält z. B. Informatio -nen zu den benötigten und angebotenenSchnittstellen (ImportDefinition, ExportDe finition).

Vor der Instanziierung wird eine Kompo -nenten durch eine ComposablePartDefinition beschrieben. Eine Composa -blePartDefinition stellt eine Fabrik füreinen speziellen ComposablePart bereit.Durch die Methode CreatePart wird einekonkrete Instanz der Komponente erzeugt.Zwischen einer ComposablePartDefinitionund einem ComposablePart steht in gewis-ser Weise eine Art Typ-Instanz-Beziehung.

In den beiden Primitiven Compo sablePartund ComposablePartDefinition werden zurBeschreibung der angebotenen und benötig-ten Schnittstellen die KlassenImportDefinition und ExportDefinitionbenutzt. Eine ExportDefinition besteht ausdem Feld ContractName (String), das denVertragsnamen enthält, und einer Liste vonMetadaten (Dictionary). Um nun entscheidenzu können, ob eine ExportDefintion dieAnforderungen einer ImportDefinitionerfüllt, wird in der ImportDefinition einLINQ-Ausdruck (Constraint) [msd] definiert.

Code-Ausschnitt 3 zeigt beispielhaft einensolchen Ausdruck. Hier wird ähnlich wie beieiner Datenbankabfrage eine ExportDefinition selektiert, die im Feld ContractName den Wert „IMovieLister“ enthält.

(ExportDefinition) def =>

def.ContractName == “IMovieLister”;

Code-Ausschnitt 3: LINQ-Ausdruck für Import-Constraint

Für den Kompositionsvorgang müssen nunalle ComposablePartDefinitions in denMEF-Container eingefügt werden. Dieskann manuell geschehen oder alternativautomatisiert über einen sogenanntenKatalog, mit dem sozusagen direkt mehrereComposablePartDefinitions adressiert wer-den. Ein ComposablePartCatalog beinhal-tet also Auswahl von ComposablePartDefinitions. Wie diese Auswahl getroffenwird, hängt von der konkreten Imple -mentierung des Katalogs ab. Im AttributedProgramming Model werden z. B. Katalogezum Sammeln aller Parts in einemAssembly oder in einem Verzeichnis ange-boten.

Das COMPASS-KomponentenmodellDas im Rahmen eines Forschungsprojektsder Fachhochschule Osnabrück in Zusam -

2Online-Themenspecial Architekturen 2009

Online-Themenspecial Architekturen 2009 fachartikel

Abb. 2: Composition Primitives

Komponente, wie dieser ein in MEF ver-wendbarer Export hinzugefügt werdenkann. Die so erstellte Komponente könntenun von anderen Komponenten importiertwerden. Dabei spielt es keine Rolle, ob die-ser Import durch ein Attribut, über eineCOMPASS-Konfigurationsdatei oder einvöllig anderes Programmiermodell definiertist.

Entwurf des MEF ProgrammiermodellsZu erstellen ist die in Fehler! Verweisquellekonnte nicht gefunden werden. gezeigteStruktur. Die abstrakten PrimitivenComposablePartCatalog, ComposablePartund ComposablePartDefinition müssenimplementiert werden. Diese werden imFolgenden als COMPASS_ComposablePartCatalog, COMPASS_ComposablePartund COMPASS_ComposablePartDefini -tion bezeichnet.

Um nun aus den COMPASS-Kompo -nenten für MEF verwertbare COM-PASS_ComposableParts zu erstellen, mussdurch die Listen der Imports und Exportsaus dem COMPASS-Container iteriert wer-den. Für jede Komponente, die einen MEF-Export oder –Import enthält, wird eineCOMPASS_ComposablePartDefinition inden COMPASS_ComposablePartCatalogeingefügt. Diese werden vorher mit den inden Listen aufgeführten Imports undExports versehen. Repräsentiert werden dieImports und Exports durch die KlassenImportDefinition und ExportDefinition.Diese Klassen können ohne eigeneImplementierung aus den CompositionPrimitives übernommen werden. Die aufdiese Art und Weise erstellte Katalog -struktur kann genau wie die bereits in MEFvorhandenen Kataloge in den Komposi -tionsvorgang eingebunden werden. So ist esmöglich, COMPASS-Komponenten mitMEF-Schnittstellen zu versehen. Diese sindnun kompatibel zu anderen MEF-Pro -

Zum einen muss ein eigenes MEF-Programmiermodell mithilfe der Compo -sition Primitives erstellt werden und zumanderen muss das COMPASS-Modell soangepasst werden, dass eine Definition vonSchnittstellen zu anderen MEF-Kompo nentenmöglich wird. Ziel ist es, Schnittstellen zudefinieren, die nicht nur innerhalb des COM-PASS-Modells gültig sind.

Anpassungen im COMPASS ModellUm keine Eingriffe in die internenStrukturen des Spring.NET-Frameworksund dessen XML-Parser vornehmen zumüssen, ist die Erstellung zweier Hilfs -klassen ratsam, die zum einen das zuexportierende oder zu importierendeObjekt (Typ Object) enthalten und zumanderen ein Feld, in dem der Vertragsnamehinterlegt ist (Typ String). DieObjektinstanziierung wird von Springübernommen. Dabei kann mithilfe desInterface IObjectPostProcessors [spf]Einfluss genommen werden. Hier kannüberprüft werden, ob es sich bei dem zuerstellenden Objekt um eine derHilfsklassen handelt. Ist dies der Fall, wirddas in der Hilfsklasse gekapselte Objektzusammen mit dem Vertragsnamen in eineListe eingefügt. Für Imports und Exportswerden zwei separate Listen erstellt. Sindalle Objekte erstellt, können die beidenListen, die alle für MEF gültigen Importsund Exports enthalten, an das MEF-Programmiermodell gereicht werden oderdort später durch einen Katalog verwaltetwerden.

...

<object id="XML_MovieLister" type="Example.XML_MovieLister, Example">

...

<object id="MEF_Export " type="MEF_Helper.MEF_Export, Example">

<property name="ExportedObject" ref="XML_MovieLister"/>

<property name="ContractName" value="XML_MovieLister"/>

</object>

...

Code-Ausschnitt 5:MEF-Export inCOMPASS-Konfiguration definieren

Der Code-Ausschnitt 5 zeigt am Beispielder Konfiguration einer COMPASS-

menarbeit mit der ROSEN Technology andResearch Center GmbH entwickelteKompo nentenmodell COMPASS (COMPonent based and Architecture centricdevelopment of Software Systems) verwen-det in umfangreicher Form das Spring.NET-Framework, um Komponenten zubilden und deren Abhängigkeiten aufzulö-sen. Es zeichnet sich besonders durch dieLeichtgewichtigkeit des Programmier -modells aus. Entwicklern ist mithilfe desCOMPASS-Modells ein sehr schnellerEinstieg in die komponentenbasierte Soft -wareentwicklung möglich.

Komponenten und deren Abhängig keitenwerden durch XML-Strukturen beschrieben,die den Komponenten beigelegt werden. Einebeispielhafte Spring-Konfiguration ist inCode-Ausschnitt 4 gezeigt. Hier wird einProgramm erzeugt, das Filminformationenaus einer XML-Datei lädt und sie in einergrafischen Oberfläche anzeigt. DasProgramm besteht aus zwei Komponenten.Dem XML MovieLister, der das Lesen ausder Datei übernimmt, und der MovieGUI,die für die Anzeige der Daten zuständig ist.Über das Tag property wird der Oberflächeeine Referenz auf den XMLMovieListerübergeben. Bei Ausführung des Programmsist eine Instanz des XMLMovieLister nunüber die Member-Variable Lister derMovieGUI verfügbar.

<?xml version="1.0" encoding="utf-8" ?>

<objects xmlns="http://www.springframework.net">

<object id="MovieGUI " type="Test.MovieGUI, Example ">

<property name="Lister" ref="XMLMovieLister"/>

</object>

<object id="XMLMovieLister" type="Example.XMLMovieLister, Example"/>

</objects>

Code-Ausschnitt 4: Beispiel einer Spring-Konfiguration

Ziel der Kombination mit MEF ist es, in derKonfiguration einer COMPASS-basiertenSoftware nun Schnittstellen definieren zukönnen, die MEF zur Komposition nutzenkann. Es sollen also MEF-Imports und -Exports in der Spring-Konfiguration abgebil-det und bei Ausführung verarbeitet werden.

Kombination derProgrammiermodelleDie Kombination der Programmiermodellebeinhaltet Anpassungen in beiden Mo dellen.

fachartikel

3 www.objektspektrum.de

Abb. 3: Das zu erstellendeProgrammiermodell

grammiermodell (z. B. dem AttributedProgramming Model) oder zu Kompo -nentenmodellen mit MEF-Anbindung, wiez. B. dem Unity-Container.

ZusammenfassungAlles in allem bietet das ManagedExtensibility Framework eine solideGrundlage zur Entwicklung komponenten-basierter Software. Mit dem AttributedProgramming Model ist ein sehr einfacherEinstieg in MEF möglich und die erstenAnwendungen lassen sich in kürzester Zeitentwickeln. Auch die Erstellung eines Plug-In-Mechanismus für bestehende Anwen -

dungen ist mit dem Attributed Program -ming Model problemlos möglich.

Ist bereits ein komponentenbasierterAnsatz, z. B. durch ein externes Frameworkgegeben, kann durch die Erweiterung derComposition Primitives Funktionalität vonMEF in die bestehende Architektur einge-bracht werden. Durch eine Anbindung deseigenen an das MEF-Komponentenmodellwird also eine erhebliche Flexibilisierungdes bestehenden Ansatzes erreicht. Dieseäußert sich in einer gesteigertenInteroperabilität. Die Vorteile des im .NET-Framework integrierten MEF-Komponen -ten modells können genutzt werden, ohneeigene Konzepte verwerfen zu müssen. n

4Online-Themenspecial Architekturen 2009

Online-Themenspecial Architekturen 2009 fachartikel

Quellen

[spr] http://www.springframework.net/

[cas] http://www.castleproject.org/

[uni] http://www.codeplex.com/unity/

[Fow04] Fowler, M. (2004, Januar 23).

Inversion of Control Containers and the

Dependency Injection pattern. Retrieved

November 7, 2009, from http://martinfowler.

com/articles/injection.html

[msd] http://msdn.microsoft.com/en-us/netframe

work/aa904594.aspx

[spf] http://www.springframework.net/doc-latest/

reference/html/objects.html#d4e1794