enthaltenen Funktionen gekennzeichnet. Schwierig wird es besonders dann, wenn Anwendungsteile bzw. Module aus unterschiedlichen

Transkript

1 - 7 Ab heute steht CAB nicht mehr für ein veraltetes Dateiformat, sondern für Composite UI Application Block. Er stammt von der Patterns 8 Practices Group bei Microsoft, die auch die Enterprise Library entwickelt hat, und soll künftig als Leitlinie zur Erstellung komplexer Windows-Anwendungen dienen. Auch wenn eine solche Hilfe eigentlich hätte zehn Jahre früher kommen müssen, erscheint CAB als Basis für die Entwicklung von Windows-Anewndungen sehr viel versprechend. Die Komplexität einer Anwendung ist nicht alleine durch die reine Anzahl der enthaltenen Funktionen gekennzeichnet. Schwierig wird es besonders dann, wenn Anwendungsteile bzw. Module aus unterschiedlichen fachlichen Domänen unter einem Dach zusammenarbeiten sollen. Der Model-View-Controller-Ansatz ist dann nur ein Teil der Lösung. Neben dieser vertikalen Struktur müssen die von unterschiedlichen Teams gefertigten Anwendungsteile auch horizontal zusammenarbeiten. Der Composite UI Application Block (CAB) unterstützt dies mit seiner Architektur, seinen Komponenten und Services. In vielen Anwendungen ist es erforderlich, mit Datenquellen und Diensten aus unterschiedlichen fachlichen Domänen zusammenzuarbeiten. Heterogene Funktionalität soll dabei in die eigene Anwendung eingebunden werden oder vormals unabhängige Anwendungen sollen in einer zentralen Anwendung zusammengefasst werden. Kollaboration, Integration und Konsolidierung sind die treibenden Kräfte hinter der Entwicklung solcher Applikationen. Die beschriebenen Anforderungen sind auch von Microsoft längst erkannt und werden auf vielen Ebenen bedient-etwa durch entsprechendeschnittstellentechnologien und Applikationsplattformen. Für Webapplikationen und Portale ist Microsoft SharePoint vorgesehen: So genannte WebParts werden dabei unabhängig voneinander entwickelt und

2 Cmposits U1 Application Block 1- m! können zu komplexenwebanwendungen zusammengesetzt werden. Der Composite U1 Application Block (CAB) ist von diesem Standpunkt aus betrachtet eine Art SharePoint für Windows-Anwendungen" - CAB verwaltet so genannte SmartParts und setzt diese zu Smart- Client-Anwendungen zusammen. Nun ist CAB aber kein Produkt oder Tool im eigentlichen Sinne, sondern eine in Code gegossene Anleitung (Stichwort,,Codified Guidance") der Patterns & Practices Group von Microsoft [I]. Im Gegensatz zu anderenapplicationblocks, wie etwa denen der Enterprise Library [2], ist CAB aber keine Komponente, die einfach in beliebige Anwendungen integriert und nur funktional verwendet wird. Dies gelingt mit den Application Rlocks der Enterprise Library noch recht gut, so etwa mit den Komponenten für Logging, Caching, Exception Handling etc. Im Gegensatz dazu kann CAB immer nur die Basis sein, um ein ganz eigenes, individuelles Framework für zusammengesetzte Smart-Client-Anwendungen zu entwickeln. Sowohl der Anwendungskern als auch die integrierten Module basieren dann intern auf CAB und seinen Services. Aufgrund seiner Komplexität und seines Umfangs eignet sich CAB nicht dazu, spontan loszulegen und mal eben eine Anwendung damit zu bauen. Ohne sorgfältige Planung kommt es sonst spätestens bei der Integration der einzelnen Anwendungsteile zu Schwierigkeiten. Wer die anfänglichen Hürden allerdings nimmt, hat die Chance, auf Basis von CAB ein zukunftssicheres, flexibles Framework für zusammengesetzte Smart-Client-Anwendungen zu schaffen. CAB verlangt übrigens zwingend das.net Framework 2.0 und macht von dessen Möglichkeiten insbesondere bezüglich Generics auch intensiv Gebrauch. Bunt gemischt Der Application Block kennt keine Beschränkungen bezüglich der Arten von Windows-Anwendungen, die auf seiner Basis erzeugt werden können. Geeignet sind Stand-Alone-Applikationen ebenso wie Add-ins für eine gröi3ere Anwendung. Die Benutzeroberfläche kann Portalcharakter haben, aber genauso gut auch auf Datenerfassung, Reporting, Helpdesk oder viele andere Szenarien zugeschnit- ten sein. Die oberste Basisklasse jeder CAB-Applikation heii3t sinnigerweise CabApplication und verlangt noch nicht einmal, dass überhaupt eine Benutzeroberfläche (Shell) vorhanden ist (siehe auch Kasten CAB-Glossar"). Die Vererbuqshierarchie geht dann weiter über CabShellApplication bis hin zur Form- ShellApplication. Jede CabApplication kennt ein root WorkItem und überlässt es externen Modulen, aus weiteren hierarchisch geschachteltenworkitems, Smart- Parts, Services und sonstigen Komponenten eine Anwendung zusammenzusetzen. Diese genannten Möglichkeiten klingen sehr beliebig - und tatsächlich ist es eines der Ziele von CAB, beliebige Anwendungen zu ermöglichen und den Entwickler mit einer sinnvollen Architektur zu unterstützen, aber nicht einzuschränken. Die Klassenhierarchie bietet zwar aktuell nur Windows-Forms-Komponenten, jedoch spricht nichts dagegen, auf der Basis von CAB zukünftig auch UI-Komponenten der Windows Presentation Foundation (WPF) einzubinden und mit bestehenden Anwendungsteilen zu mischen. Im Gegenteil - CAB könnte sich sogar als,,best Practice" erweisen, um Forms und WPF innerhalb einer Anwendung gemeinsam zu verwenden. Teile und herrsche Obwohl CAB eine bestimmte Architektur nicht erzwingt, existiert dennoch eine Empfehlung, wie eine CAB-Applikation sinnvoll aufgebaut wird. Dieser Aufbau wird vom Application Block mit allerlei Komponenten und Services unterstützt. An oberster Stelle steht, wie bereits genannt, eine CabApplzcatzon mit root WorkItem. Es ist dabei dem Entwickler überlassen, ob CAB auch das Wind ows Form der Anwendung erzeugt oder lediglich der Kontext eines bestehenden Windows Forms verwendet wird. Für die Anzeige von SmartParts definiert die Shell typischerweise Workspaces, d.h. Container, die einen bestimmten Bereich Forms Designer von Visual Studio 2005 angelegt und konfiguriert. Ein WorkItem ist unter anderem dafür zuständig, SmartParts in die Shell der CAB-Applikation zu integrieren. Es kann sich dazu den gewünschten Workspace anhand seines Namens aus der Collection aller Workspaces zurückliefern lassen. Dieser Workspace wird dann als Container zur Darstellung eines SmartParts verwendet. Ein SmartPart wird typischerweise als Windows Forms UserControl erstellt und enthält eine Oberfläche zur Anzeige und Bearbeitung von Daten, die per BindingSource automatisch an eine Datenklasse gebunden ist. Auch an die sonstigen typischen Elemente einer Windows-Anwendung wurde gedacht, also an Bereiche wie Menüs, Werkzeugleisten und Statusanzeigen. Diese Funktions- bzw. Darstellungsbereiche werden üblicherweise als UIExtensionSite innerhalb des root WorkItems registriert und können dann von allen darin enthaltenen WorkItems ganz nach Bedarf gefüllt und verändert werden. Die grafischen Schnittstellen, die eine Anwendung beispielsweise in Form von Workspaces und UIExtensionSites anbietet, können bei CAB grundsätzlich über eindeutige Namen identifiziert und aus den WorkItems heraus referenziert werden. Diese Namen müssen also zwischen den Entwicklern der Shell und denen der einzelnen WorkItems als Bezeichner vereinbartwerden, ebenso wie die Semantik dieser Schnittstellen. Zusammengefügt wird die ganze Anwendung dann erst flexibel zur Laufzeit. Die Codezeilen in Listing 1 vermittelneineneindruck davon,wie diese Mechanismenfunktionieren. Das gezeigteverfahren ist zwar dazu geeignet, ein bestimmtes von mehreren Objektenzureferenzieren,istjedochnicht IWobceuintent-motWorWtem.Workspaces["conLent"]: MyWorWtem myworkitem = rootworkitem.work1tems. AddNewcMyWorkItem>(): innerhalb der Shell einnehmen und darin grafische Komponenten Die msn,rkitem.show(sidebarw~rk,pa~e,contentworkspar~~. fünf mitgelieferten Varianten von Workspaces steilen SmartParts beispielswei- ToolsttipMenuItemfunctionA= se als Seiten eines TabControls oder als new Jocrt5bipMenuItem("A Functio~ ro~tw~rkitem.uimen~i~nsites["tooktnp~']. ' dd(functior " faces (MDI) dar. ~ i werden ~ ~ ~ wie herkömmliche Controls imwindows

3 sinnvoll, um damit alle grundsätzlichen Abhängigkeiten von Komponenten abzubilden. Wie beispielsweise erhält ein WorkItem die gewünschte Referenz auf das root WorkItem der CAB-Applikation? Die Antwort lautet Dependency Injection. Der so genannte ObjectBuilder ist selbst ein kleiner Application Block mit dem Spezialgebiet Dependency Injection. Der ObjectBuilder wird allerdings nicht eigenständig herausgegeben, sondern ist bislang nur als Teil von CAB und der Enterprise Library 2.0 verfügbar. Dependency Injection ist ein Entwurfsmuster mit dem Ziel, die Abhängigkeiten zwischen Komponenten zu minimieren, insbesondere bezüglich ihrer Erzeugung und Initialisierung. Klassischerweise wäre jede Komponente selbst dafür zuständig, alle benötigten Objekte zu erzeugen und zu verwalten. Dafür ist allerdings eine gute Kenntnis der Umgebung notwendig. Dependency Injection überträgt die Verantwortung für das Erzeugen von Komponenten daher an eine externe Instanz, in diesem Fall den ObjectBuilder. Dieser ist dann dafür verantwortlich, die Abhängigkeiten einer Komponente zu erkennen, zu interpretieren und alle notwendigen Objekte zur Verfügung zu stellen, was wiederum deren Abhängigkeiten einschliegt. Dievom ObjectBuilder erzeugtenkomponenten werden nicht nur im Konstruktor, sondern auch bezüglich öffentlicher Properties mit allem Notwendigen versorgt. Eine Komponente nutzt spezialisierte Custom Attributes, um ihre Abhängigkeiten bekannt zu machen, wie etwa: [InjectionConstructor] public MyModu[e([Se~ceDependency] WorkItem workitem) I this.rootworkitem = workltem; Auch bei diesem Ansatz muss einer Komponente natürlich die Schnittstelle ihrer benötigten Objekte bekannt sein -nicht jedoch, wann und wie diese Objekte erzeugt werden, in welchen Modulen sie sich befinden oder um welche Implementierung es sich handelt. Ein zentraler Komponentenverwalter, der all diese Informationen besitzt, ist ebenfalls nicht notwendig. Stattdessen ermittelt der Object- Builder alle Informationen zur Laufzeit. Von diesen Möglichkeiten macht CAB selbst auch reichlich Gebrauch - sämtliche internen Komponenten bzw. Services des Application Blocks werden dynamisch geladen und per Dependency Injection zusammengefügt. Puzzlestücke Bisher wurden nur zwei kleine Bereiche von CAB angesprochen: Ein Modul wird geladen, dabei vom ObjectBuilder mit benötigten Komponentenversorgt und kann mithilfe von WorkItems Teile der Oberfläche mit Inhalt füllen. Wer entscheidet aber, dass ein Modul überhaupt geladen wird? Eine direkte Referenz zwischen CAB-Applikation und ihren Modulen ist zu vermeiden. Stattdessen sorgt ein IModuleEnumerator dafür, die gewünschten Module zu ermitteln und dann zu laden. Es bleibt dem Designer des Anwendungs- Frameworks überlassen, ob er dabei vielleicht lieber einen FileCatalogModule- Enumerator einsetzt, der diese Information aus einer XML-Datei ausliest, oder ob eher ein ReflectionModtlleEnumerator verwendet werden soll, der sämtliche Assemblies in einem speziellen Verzeichnis per Reflection untersucht. CAR bringt das Interface IModuleEnumerator sowie die beschriebenen Implementierungen bereits mit - falls beide nicht den Anforderungen entsprechen, muss eine eigene Implementierung erstellt werden. Dieses Laden von Modulen ist nur ein stellvertretendes Beispiel fur die vielen Komponenten und Services, die CAB bereits enthält. Der Application Block selbst ist also intern komponentenbasiert aufgebaut und liefert dem Designer eines Anwendungs-Frameworks viele fertige Lösungen, ohne ihn dadurch einzuschränken.drei weitere Servicesvon CAB werden nachfolgend vorgestellt: Event Broker, Authentifizierung und Persistenz. Der Event Broker Eine Anwendung, die aus vielen unabhängig entwickelten Modulen zusammengesetzt wird,ist ziemlich wertlos,wenn diese Module nicht doch irgendwie miteinander kommunizieren können. Um dabei direkte Abhängigkeiten zu vermeiden, ist n Workspace ist ein Bereich innerhalb der Shell zur Darstellung von SmartParts. 1 Er verwaltet die Aktiviemng und Darstellung mehrerer SmartParts..B. in Form eines TabControls. Tab. 1 : GAB - Glossar mi2

4 ein Mechanismus notwendig, der es den Modulen erlaubt, Nachrichten auszutauschen, ohne den eigentlichen Sender bzw. Empfänger zu kennen. Realisiert ist dies über einen Service von CAB namens Event Broker. Dabei werden - nach dem klassischen Publisher/Subscriber-Schema - beliebige Kanäle durch den Publisher als Nachrichtenthema definiert und von einem interessierten Subscriber abonniert. Das Ergebnis ist eine lose gekoppelte Kommunikation, wobei jeder Sender und Empfänger jeweils mehrere Kanäle gleichzeitig bedienen kann. Es ist beeindruckend, wie einfach und komfortabel der Event Broker verwendet wird: Beide Kommunikationspartner, Publisher und Subscriber,wenden dazulediglich Custom Attributes auf ein Event bzw. einen Event Handler an,um das Nachrichtenthema zu veröffentlichen oder zu abonnieren.diese CustomAttributes beziehen sichnicht nur auf den Kommunikationsmechanismus an sich, sondern berücksichtigen auch, in welchem Gültigkeitsbereich die Kommunikationmöglich sein soll und in welchem Thread (Publisher, Background oder U1 Thread) der Aufruf dann stattfindet (Listing 2). Ganz ähnlich wie der Event Broker funktioniert auch die Verknupfung zwischen U1 Controls und Kommandos, die von ihnen ausgelöst werden. Mithilfe des CommandHandler-Attributes lässt sich eine Methode als mögliches Kommando definieren. Für dieses Kommando können dann beliebig viele aufrufende U1 Controls definiert werden. Authentifizierung Ein weiterer Service von CAB ist Authentifizierung. Gerade der Charakter einer zusammengesetzten Smart-Client-Anwendung legt nahe, dass diese Anwendung nicht für sämtliche Benutzer gleich aussieht und die gleichen Funktionen bietet. Eine Variante wäre, schon bei der Entwicklung festzulegen, welche Module geladen werden sollen und dies bei der Software-Verteilung anhand von Benutzerberechtigungen zu berücksichtigen. Der Software-Entwicklungszyklus wird dadurch aber unnötig kompliziert. Eine elegante Alternative ist, die Rolle des Benutzers zur Laufzeit zu bestimmen und dynamisch auszuwerten. Damit dies gelingt, muss zunächst die Benutzeridentität festgestellt werden. CAB beinhaltet für 1 Pass calls I User lntorection Fires b -.*.*- -1-~m-~ontroiier Abb. 1 : MVC und MVP im Vergleich (aus: CAB-Dokumei diesen Zweck einen Service zur Authentifizierung des Benutzers,zumindest für den einfachen Fall einer Windows-Authentifizierung. Die ermittelten Daten könnten dann dazu verwendet werden, innerhalb eines WorkItems oder innerhalb der eigenen IModuleEnumerator-Implementierung eine Rollenprüfung durchzuführen und die Anwendung entsprechend anzupassen. Persistenz Schließlich sei noch der Persistenz-Service genannt. Viele WorkItems haben typischerweise Daten, die mit ihnen assoziiert sind - und sei es beispielsweise nur die Information darüber, welche Dateien ein Benutzer zuletzt geöffnet hat oder wie die Fenster beim letzten Start der Anwendung angeordnet waren. Damit nicht jedes WorkItem für seinen Zustand (State) einen eigenen Speichermechanismus benötigt, ist in CAB ein zentraler Persistenz- Service vorgesehen - und zwar in Form von ~~tate~ersistence~ervice. Auch hierfür liefert CAB bereits zwei Implementierungen, nämlich eine Variante für das Schreiben in Dateien und eine weitere auf Basis des IsolatedStorage, den.net mitbringt. Als zusätzlichen Bonus lassen sich die gespeicherten Daten auch gleich noch per Data Protection API (DPAPI) verschlüsseln - ein weiterer Service steht dafür als Implementierung von ICryptographyService bereit. Der StatevonWork- Items kann in Form eines Shared State neben Event Broker auch als zusätzlicher Kommunikationsmechanismus zwischen Modulen verwendet werden. User interaction I Entwurfsmuster Die beschriebene Plattform - eine CAB- Shell mit vielfältigen Services für Smart- Parts und WorkItems - dient als Infrastruktur für unabhängig entwickelte Anwendungsteile. CAB-Services wie Event Broker sind in erster Linie für die horizontale" Zusammenarbeit mehrerer, nebeneinander stehender Module gedacht. Es stellt sich die Frage, nach welchen Kriterien eine Aufteilung der Funktionalität in separate Module stattfindet und wie diese Module dann intern aufgebaut sind. Wie bereits in der Einleitung angesprochen, entspricht ein Modul typischerweise einem Anwendungsteil aus einer bestimmten fachlichen Domäne. Zusätzliche Unterteilungen ergeben sich häufig aus organisatorischen Gegebenheiten, wie etwa der Zusammensetzung von Teams oder deren Standorten. Als vertikale" Struktur innerhalb eines Moduls werden die beiden Entwurfsmuster MVC (Model-View-Controller) und MVP (Model-View-Presenter) empfohlen (siehe Kasten CAB-Glossar" und Abbildung 1). Die View wird in diesem Entwurfsmuster jeweils von SmartParts gebildet. Ein Controller oder Presenter kann mithilfe der CAB-Basisklasse Controller erstellt werden. Das Datenmodell schließlich steckt im State eines WorkItems oder in separaten Datenklassen.Die Aufgabe einesworkitems ist, das gesamte Gespann innerhalb der CAB- Shell zu registrieren und zu verankern. Auf diese Weise erzeugt ein WorkItem die eigentliche Funktionalität der Anwendung. Eine sinnvolle Unterteilung ist

5 Abb. 2. BankTelier QuickStart - StruMur und Anwendung irn Vergiech daher,prouse Case jeweils ein WorkItem zu erstellen. Dieses WorkItem kann dann durchaus auf mehrere SmartParts, Controller, etc. zurückgreifen. DiegenanntenKonzeptevon CABsind durchaus komplex und anfangs schwierig zu verstehen. Aus diesem Grund werden mit dem Application Block gleich fünf QuickStart''-Anwendungen im Quellcode mitgeliefert, die dabei helfen, die CAB-Funktionalität nachzuvollziehen. Der SmartPart QuickStart" vermittelt beispielsweise die horizontale und vertikale Struktur einer Anwendung mithilfe zweier WorkItems, die sich allerdings innerhalb eines Moduls befinden und durch einen direkten Aufruf miteinander kommunizieren. Im,,EventBroker Quick- Start" wird dagegen die Kommunikation auf Basis von EventBroker gezeigt. Der komplexeste QuickStart ist die BankTeller"-Anwendung, bei der die wichtigsten CAB-Konzepte integriert gezeigt werden. In Abbildung 2 werden die logische Struktur der Beispielanwendung und ihre Oberfläche direkt gegenüber gestellt. Der gezeigte BankTeller QuickStart" enthält mindestens eine Funktionalität, die bislang noch nicht angesprochen wur- kommt. Eine WorkItemExtension kann so konfiguriert werden, dass sie beim Laden eines bestimmten WorkItems einen vorhandenen Workspace mit eigenen Ergänzungen füllt. In Abbildung 2 wird das Register CUSTOMER MAP auf diese Weise aus einem Zusatzmodul heraus ergänzt. Der Quelltext des ursprunglichen WorkItems bleibt unverändert. Solche Erweiterungen sind mit dem,,dekorierer-entwurfsmuster" (engl. decorator) vergleichbar. Fazit CAB ist der umfangreichste und komplexeste Application Block, der von der Patterns & Practices Group bislang veröffentlicht wurde. Dieser Artikel streift dabei nur die wichtigsten Konzepte und zeigt die Spitze des Eisberges. Eine gute Einarbeitung ist daher zwingend erforderlich, bevor man damit beginnt, die gelieferte Funktionalitat in eigenen Anwendungen einzusetzen. Die in CAB enthaltenen Best Practices sind allerdings auch alleine schon als Ratgeber und Lernhilfe sehr wertvoll. Zusammengesetzte Smart-Client-Anwendungen auf Basis von CAB haben sowohl finanzielle als re Entwicklungs- und Wartungskosten, eine einheitliche Bedienung ohne Medienbrüche und höhere Produktivität. Der Entwicklungsprozess skaliert dabei auch bis hin zu komplexen Anwendungen, unterstützt durch die klare horizontale und vertikale Struktur einer CAB-Anwendung. Dies alles gilt, obwohl die Entwicklung von CAB noch lange nicht am Ende ist. Eine Portierung auf Windows Mobile bzw. das.net Compact Framework ist bereits in Arbeit. Die ersten Planungen zur Integration von Workflow-Funktionalität auf Basis der Windows Workflow Foundation haben bereits begonnen. Damit werden dann wohl die Merkmale des alten User Interface Process Application Blocks (UIP) in die Smart-Client-Welt überführt. Neue UI-Elemente auf Basis der Windows Presentation Foundation können dann ebenfalls integriert werden. CAB hat also noch eine spannende Reise vor sich - es lohnt sich daher, schon jetzt mit dabeizu sein..-.x. '...,...*.,,... Jochen Reinelt arbeitet als Consultant bei Avanade im Bereich.NET-Anwendungsentwicklung - Sie erreichen ihn unter lochenrqavanade.com. de: Über das Konzept einer Workltem- auch technischevorteile. Funktionalität Links & Literatur Extenaon lassen sich bestehende Work- aus verschiedenen fachlichen Domänen,, p~alces,aot~otnet,oom/pi4ects~cab Items erweitern, ohne dass das ursprüng- kanninnerhalb eineranwendung konso- ~~~h~~ Relnelt / Stefan Zi,I.Sieben auf einen liche WorkItem davon selbst etwas mitbe- lidiert werden. Dies ermöglicht geringe- Streich, in: dot.net magazin 7/8.05