Vorstellung des Drittmittelprojektes PLUGIN.NET

Präsentation zum Thema: "Vorstellung des Drittmittelprojektes PLUGIN.NET"—  Präsentation transkript:

1 Vorstellung des Drittmittelprojektes PLUGIN.NET
Thorsten Busse, Nicolas Denz Projekt Simulationsmodellierung und -werkzeuge Exkursion Vielen Dank für die Einleitung. In diesem Vortrag möchte ich unser Drittmittelprojekt Plugin.Net vorstellen, in dem ich seit Oktober 2007 tätig bin, während mein Kollege Thorsten Busse, mit dem ich diesen Vortrag gemeinsam erstellt habe, bereits seit dem Projektbeginn im März dabei ist. Dieser Vortrag stellt die gekürzte Fassung eines Vortrags dar, den wir bereits im Dezember in unserem Oberseminar gehalten haben. Ich möchte dabei hauptsächlich einen Überblick über die Zielsetzungen und Zwischenergebnisse des Projekts geben und nicht zu tief in technische Details eintauchen. Falls Ihrerseits Interesse besteht, können wir dies im Anschluss noch tun.

2 T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET
Gliederung Projektumfeld und Ziele Grundlagen .NET und Plugin-Frameworks Vorgehen bei der Entwicklung Vorstellung des entwickelten Plugin-Frameworks Gesamtarchitektur Persistenz und Fachsprache für Stoffstromanalyse Zusammenfassung und Ausblick Hier ist eine Übersicht über meinen Vortrag. Zunächst werde ich kurz das Umfeld und die Ziele des Projekts vorstellen. Anschließend möchte ich in einem Grundlagenteil die Schlagworte aus dem Projekttitel mit Inhalt füllen und einen sehr kurzen Überblick über unser Vorgehen bei der Softwareentwicklung im Rahmen des Projekts geben. Im Hauptteil stelle ich das in Kooperation entwickelte Plugin-Framework für .NET vor, wobei ich sowohl die Gesamtarchitektur als auch die von der Uni Hamburg übernommenen Arbeitspakete vorstelle. Ich schließe mit einer Zusammenfassung und einem Ausblick auf die weiteren Arbeiten, wobei ich auch den Aspekt der Verteilung ansprechen möchte, der nach meinem Wissen für Sie besonders relevant ist. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

3 T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET
1. Einführung Projektumfeld Zielsetzung des Projekts Quelle Förderantrag Innovationsstiftung (2006) Ich beginne mit einer Einführung in Umfeld und Ziele unseres Projekts. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

4 Projektumfeld: Eckdaten
Förderung durch Innovationsstiftung / RIS Hamburg Laufzeit für Uni-HH: März 2007 bis Juni 2008 Kooperationsprojekt ifu Hamburg GmbH Universität Hamburg, FB Informatik technisch aufbauend auf Projekt Emporer (FHTW Berlin) Industrieprojekt angewandte Forschung vermarktbares Ergebnis Das Projekt Plugin.Net wird durch die Innovationsstiftung Hamburg gefürdert und läuft seit März 2007 noch bis Juni 2008. Es handelt sich um ein Kooperationsprojekt, bei dem die Firma ifu Hamburg und die Uni Hamburg direkt beteiligt sind, während die entwickelte Software technisch auf dem Partnerprojekt Emporer aufbaut, das unter der Leitung von Prof. Volker Wohlgemuth an der FHTW Berlin stattfindet. Wie bereits aus der engen Firmenkooperation ersichtlich wird, handelt es sich um ein Industrieprojekt, bei dem angewandte Forschung und auch ein vermarktbares Ergebnis im Vordergrund stehen. Demenstprechend sind die im Projekt behandelten Forschungsthemen auch weniger grundlegender, als vielmehr technischer und praktischer Natur. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

5 Projektumfeld: Umweltinformatik
ifu Hamburg GmbH mittelständisches Software-Unternehmen Stoffstrommanagement betriebliche Umweltinformationssysteme (BUIS) Randbedingungen und Anforderungen effiziente Entwicklung umfangreicher Softwareprodukte Flexibilität kontinuierlicher Wandel im Anwendungsbereich globale Ausrichtung (Sprachen, Regelungen, Standards) kundenindividuelle Lösungen Zielplattform MS Windows Plugin-Frameworks können vielseitig eingesetzt werden, aber unsere spezielle Motivation zur Entwicklung eines solchen ergibt sich aus dem Bereich der Umweltinformatik. Die Firma Ifu ist als mittelständisches Hamburger Softwareentwicklungs-Unternehmen, seit 15 Jahren in diesem Bereich tätig und hat ihre Wurzeln am FB Informatik der Uni Hamburg. Schwerpunktmäßig wird Software aus den Bereichen Stoffstrommanagement (insbesondere basierend auf dem Formalismus der Stoffstromnetze) und betrieblichen Umweltinformationssystemen (kurz BUIS) entwickelt. Dabei stellen sich einige Anforderungen, die insb. die Entwicklung eines Plugin-Frameworks motivieren: Einerseits muss ein mittelständisches Unternehmen besonderen Schwerpunkt auf Effizienz bei der Entwicklung komplexer Software legen. Andererseits muss die entwicklete Software flexibel änderbar sein, bedingt z.B. durch den kontinuierlichen Wandel im Anwendungsbereich, die globale Ausrichtung der entwickelten Software hinsichtlich unterschiedlicher Sprachen, Regelungen und Standards und die Forderung nach kundenindividuellen Lösungen. Sowohl Entwickler-Know How als auch Kundenanforderungen sind stark an der Zielplattform MS Windows orientiert. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

6 Zielsetzung des Projekts
Entwicklung eines Plugin-Frameworks bausteinartige Zusammenstellung neuer Software vereinfacht Entwicklung, Anpassung und Verteilung Microsoft .NET-Plattform als technische Grundlage Bereitstellung unter Open Source-Lizenz Arbeitspakete Universität Hamburg Fachsprache für die Stoffstromanalyse Datenbankpersistenz Exemplarischer Einsatz im BUIS-Bereich Umberto, e!Sankey, Stoffstromsimulator MILAN, ... Um flexibel Software entwickeln zu können, liegt offensichtlich der Einsatz eines Komponenten- bzw. Plugin-Frameworks nahe, das durch die Möglichkeit zur bausteinartigen Zusammenstellung von Software deren Entwicklung, Anpassung und Bereitstellung erleichtert. In der Java-Welt stellt in diesem Bereich Eclipse einen De Facto Standard dar. Aufgrund der engen Bindung an die MS Windows-Welt liegt es jedoch nahe, auf der .NET-Plattform aufzubauen, die Microsofts aktuelle Technologie zur Softwareentwicklung darstellt. In diesem Bereich ist ein vergleichbares Rahmenwerk bislang nicht vorhanden. Ziel ist also, die Entwicklung eines solchen Rahmenwerks, das sowohl als Basis für die kommerziellen Prodúkte der Firma ifu genutzt, als auch unter einer Open Source Lizenz zur Verfügung gestellt werden soll. Innerhalb dieses Vorhabens hat die Uni Hamburg 2 Arbeitspakete übernommen, welche die Entwicklung einer schnittstellenbasierten Fachsprache für die Stoffstromanalyse, und die Umsetzung von Datenbankpersistenz in einer dynamischen Plugin-Architektur umfassen, Die Evaluation des Rahmenwerks erfolgt durch exemplarischen Einsatz in verschiedenen Softwaresystemen aus dem BUIS-Bereich, die ich im folgenden kurz vorstellen werde. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

7 Exemplarischer Einsatz in BUIS
e!Sankey Umberto MILAN Ich beginne unten rechts mit der ifu-Software Umberto, die eine Entwicklungs- und Berechnungsumgebung für Stoffstromnetzt darstellt. Stoffstromnetze wurden von Andreas Möller in Hamburg entwickelt sind eine spezielle Form von Petrinetzen, mit denen Materialflüsse, z.B. im Rahmen von Produktionsprozessen betrachtet werden können. Entsprechend der PN-Semantik repräsentieren Transitionen elementare Umwandlungsprozesse und Stellen(Zwischen)lager. Diese werden zu einem Netz verbunden, welches den Gesamtprozess darstellt und als Grundlage für detaillierte Berechnungen z.B. zur Ökobilanzierung dient. Ergebnisse können dann wie hier gezeigt in Form von Sankey-Diagrammen dargestellt werden, wobei Farben unterschiedliche Stoff- oder Energieformen und Pfeildicken Mengen codieren. e!Sankey ist ein niedrigpreisiges ifu-Produkt, welches nur die Darstellung von Sankey-Diagrammen ohne Berechnung unterstützt. Milan ist kein ifu-Produkt, sondern ein in Volker Wohlgemuths Dissertation entwickelter sog. Stoffstromsimulator, der die Stoffstromanalyse mit der eher an ökonomischen Fragestellungen orientierten klassischen diskreten Simulation verbindet. Die vorgestellte Softwarepalette besitzt also eine gewisse gemeinsame Grundfunktionalität mit speziellen Anforderungen im Detail. Dies legt wiederum eine komponenten- oder Plugin-basierte Entwicklung nahe. Quellen der Screenshots: Milan: V. Wohlgemuth: Einführung Simulationsprojekt WS 06/07 e!Sankey: Umberto: T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

8 T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET
2. Grundlagen .NET-Plattform Plugin-Frameworks Quellen Förderantrag Innovationsstiftung (2006) P. Jahr, S. Simroth (2007): Entwicklung von Teilbereichen eines Software-Frameworks im Einsatzkontext betrieblicher Umweltinformationssysteme F. Simmendinger (2007): Referenznetze zur Modellierung von wissenschaftlichen Workflows Bevor ich unser Rahmenwerk im Detail vorstelle, möchte ich kurz auf einige Grundlagen im Zusammenhang mit der .NET-Plattform sowie Plugin-Frameworks eingehen. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

9 .NET-Plattform Implemen- tationen Microsoft .NET Portable.Net MONO
Base / Framework Class Libraries (BCL, FCL) Bibliotheken Zwischen- sprache Common Intermediate Language (CIL) C# C++ VB F# ... übersetzt in läuft auf virtuelle Maschine Common Language Runtime (CLR) realisiert Common Language Infrastructure (CLI) Da die .NET-Plattform ist sicher einigen, aber nicht allen hier im Detail bekannt ist, werde ich zunächst einige Worte dazu sagen. .NET ist Microsofts aktuelle Plattform zur Entwicklung von Windows-Software und wird manchmal als „Microsofts Interpretation der Java-Plattform“ bezeichnet, da die Grundkonzepte recht ähnlich sind und auf dem Konzept der virtuellen Maschine basieren. Ein wesentlicher Unterschied von .NET gegenüber Java ist die grundlegende Auslegung auf Sprachunabhängigkeit, d.h. Es stehen eine ganz Reihe von Hochsprachen zur Verfügung, die in eine sog. Zwischensprache oder CIL übersetzt werden können. Der CIL-Code wird dann auf der als CLR bezeichneten virtuellen Maschine unter Einsatz von JIT-Compilierung ausgeführt. Neben der Laufzeitumgebung umfasst .NET noch umfangreiche Klassenbibliotheken, die ebenfalls stark an den Java-Frameworks orientiert sind. Genau genommen ist .NET übrigens kein reines Microsoft-Produkt, sondern eine als CLI bezeichnete offene Spezifikation einer sprachunabhängigen Softwareplattform. Es gibt daher neben Microsoft .NET weitere, auch plattform-unabhängige Implementationen. Das Mono-Projekt ist davon wohl am weitesten ausgereift, verfügt allerdings über weniger umfangreiche Klassenbibliotheken als Microsoft .NET. Common Type System (CTS) Common Language Specification (CLS) Spezifikation Metadata Virtual Execution System (VES) Hochsprachen basierend auf en.wikipedia.org/wiki/.NET_Framework T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

10 Plugin-Frameworks: Begriffe
Komponente wiederverwendbarer Softwarebaustein „eine sinnvoll einsetzbare Funktionalität“ (Harris, nach Wohlgemuth 2005, S. 45) standardisierte Schnittstelle erlaubt Interoperabilität Plugin spezielle Komponente erweitert Anwendung um beliebige Funktionalität jederzeit zu ergänzen / entfernen (ohne Rekompilierung) plugin-fähige vs. plugin-basierte Anwendungen Nachdem ich den zweiten Teil unseres Projektnamens erläutert habe, komme ich zum ersten. Die Möglichkeit zur Erweiterung durch Plugins findet man heute in vielerlei Software von Clients bis zu Musikproduktions-Programmen. Prinzipiell basiert der Plugin-begriff auf dem Konzept der Software-Komponente als wiederverwendbarem Softwarebaustein, der eine klar umrissene und sinnvoll einsetzbare Funktionalität bietet und über standardisierte Schnittstellen mit anderen Komponenten innerhalb einer Laufzeitumgebung interagieren kann. Unter einem Plugin versteht man dabei eine spezielle Komponente, die eine Anwendung um eine beliebige Funktionalität erweitert. Die Besonderheit des Plugin-Konzepts ist die dynamische Erweiterbarkeit, d.h. Plugins können oftmals zur Laufzeit der Anwendung ergänzt und entfernt werden, was natürlich bestimmte Anforderungen an die Softwarearchitektur stellt. Wir unterscheiden hierbei plugin-fähige und plugin-basierte Anwendungen. Plugin-fähige Anwendungen sind monolithische Softwaresysteme, die über eine oder mehrere Schnittstellen verfügen, an denen sie um Plugins erweitert werden können. Plugin-basierte Anwendungen verfügen dagegen im Kern nur über eine minimale Laufzeitumgebung und ihre gesamte Funktionalität wird durch Plugins bereitgestellt. Quellen: Jahr+ 2007, S. 19f; Simmendinger 2007, S. 15; Förderantrag T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

11 Plugin-Frameworks: Praxis
Beispiele aus dem MS Windows-Umfeld MS Visual Studio (VS-Add-In, VSPackage), #develop (plugin-fähig) MILAN Stoffstrom-Simulator (plugin-basiert) Eclipse Rich Client Platform Plugin-Infrastruktur basierend auf Java und OSGi erweiterbare IDE → Universal Tools Platform umfangreiche Sub-Projekte und Erweiterungen GEF (Grapheneditor), EclipseLink (Persistenzdienste), ... Keine vergleichbare Plattform im .NET-Umfeld ! Im MS Windows-Umfeld findet man wie bereits erwähnt zahlreiche Plugin-fähige Systeme (z.B. die .NET Entwicklungsumgebungen Visual Studio und #develop), dagegen weniger plugin-basierte Systeme. Ein Beispiel ist hier der bereits erwähnte in Delphi programmierte Stoffstromsimulator Milan. Dieser besteht aus einer 'leeren' Rahmenanwendung, der verschiedene Funktionen zur Modellierung und Simulation sowie anwendungsspezifische Simulationsbausteine als Plugins hinzugefügt werden könne. Die bekannteste plugin-basierte Software ist sicher die auf Java basierende Eclipse Rich Client Platform. Eclipse wurde von IBM zunächst als erweiterbare Entwicklungsumgebung ähnlich Visual Studio oder #develop konzipiert, über die Jahre jedoch zu einer „Universal Tool Platform“, also einer Plattform zur Entwicklung beliebiger Softwarewerkzeuge, weiterentwickelt. Ein wichtiger Aspekt ist dabei, dass Eclipse-Komponenten wie z.B. die grafische Workbench, der Projektnavigator, usw. in fast jeder Art von Softwarewerkzeugen verwendbar sind. Zudem gibt es viele Erweiterungsprojekte wie z.B. GEF für Grapheneditoren oder EclipseLink für Persistenzdienste. In einem unserer anderen Projekte erweitern wir selbst Eclipse um Plugins für diskrete Simulation. Im .NET-Umfeld existiert jedoch bisher keine vergleichbare Plugin-Plattform. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

12 Plugin-Frameworks: Evaluation
Nutzung von Eclipse ? Zielplattform MS Windows (Know How / Code vorhanden) seinerzeit attraktivere (Sprach-)konzepte bei .NET Performanz, GUI-Bibliotheken, OS-Integration überlegen Re-Implementation für .NET ? (zu) mächtiges Framework in ständiger Weiterentwicklung Projekt „Eclipse.NET“ unausgereift und inaktiv seit 2005 etwas andere Ausrichtung durch IDE-Bezug Reflektierte Übernahme, Modifikation und Erweiterung bewährter Konzepte aus Eclipse! Wie steht nun Eclipse unseren vorab definierten Anforderungen gegenüber? Einerseits könnte man versuchen, zukünftig einfach Eclipse zu nutzen. Dem stehen die vorhandene Codebasis und das Know How der Firma ifu im Windows-Bereich gegenüber. Zudem finden sich neben der Sprachunabhängigkeit weitere attraktive Konzepte bei .NET. Ein Beispiel sind sog. Attribute zur Selbstbeschreibung von Komponenten, oder Delegaten zur Realisierung des Beobachtermusters. Außerdem sind .NET Anwendungen für den reinen Windows-Anwender natürlich besser in das Betriebssystem und die Benutzungsoberfläche eingebettet. Eine andere Idee ist die Re-Implementation von Eclipse für .NET. Das Problem besteht hier jedoch in der Größe des Frameworks und seiner ständigen Weiterentwicklung, wobei die .NET-Version nachgezogen werden müsste. Ein vergleichbarer Versuch einer Einzelperson existiert, ist jedoch anscheinend gescheitert. Außerdem sind in Eclipse trotz der Allgemeinheit die auf Entwickler ausgerichteten Wurzeln als IDE zu erkennen, die unseren Anforderungen aus der Umweltinformatik zum Teil entgegenstehen. Unser Ansatz ist daher eine reflektierte Übernahme bewährter Konzepte aus Eclipse, wobei diese an unsere Anforderungen angepasst und erweitert werden. Im Prinzip entspricht dies ein wenig dem Vorgehen der Entwickler von .NET in Bezug auf Java. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

13 Vorgehen bei der Entwicklung
Vorgehensmodell: eXtreme Programming testgetriebene Entwicklung und kontinuierliche Integration Verteilte Entwicklung Mehrere abhängige Projekte (Platform, Umberto, usw.) geplant: stable- und testing-Zweig Bevor ich nun zur Architektur unseres Plugin-Frameworks komme noch einige Worte zum Vorgehen bei der Entwicklung. Prinzipiell verfolgen wir den Ansatz des Extreme Programming, wobei Aspekte wie testgetriebene Entwicklung, kontinuierliche Intergration des entwickelten Codes und teilweise auch Pair Programming zum Einsatz kommen. Als Entwicklungswerkzeuge werden MS Visual Studio sowie gängige aus Java-Projekten abgeleitete freie .NET Software wie z.B. NANT als Build-Tool und Nunit als Test-Framework eingesetzt wird. Eine Besonderheit besteht in der Verteilung, da die Software wie erwähnt parallel an drei Orten entwickelt wird. Wir verfügen daher über eine Infrastruktur, die aus einem SVN-Repository für den entwickelten Code, einem auf dem System Cruise Control basierenden Build Server sowie mehreren Wikis zur Dokumentation und Kommunikation besteht. Ein weiteres Problem besteht darin, dass mehrere voneinander abhängige Softwaresysteme entwickelt werden, also das Plugin-Framework selbst und die darauf basierenden Softwarewerkzeuge, die ständig abgeglichen werden müssen. Zur Vereinfachung planen wir, einen stabilen Code-Zweig einzuführen, auf dem die stabilen Versionen der abhängigen Projekte basieren und einen experimentellen, der immer die aktuellen Neuerungen enthält. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

14 4. Vorstellung Plugin-Framework
Gesamtarchitektur Fachsprache für Stoffstromanalyse Persistenz Abstraktes Rahmenwerk für Graphen-Editoren Quelle P. Jahr, S. Simroth (2007): Entwicklung von Teilbereichen eines Software-Frameworks im Einsatzkontext betrieblicher Umweltinformationssysteme Ich werde nun zunächst die Gesamtarchitektur des Plugin-Frameworks und anschließend die an der Uni-Hamburg entwickelten Beiträge vorstellen. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

15 Plugin-Framework Struktur
(4st draft, incomplete (project state, Nov 26, 2007) Plugin-Framework Struktur Indendent Applications (Layer 3) (Application-Layer) Milan Reference Application Umberto Fachsprache Platform (Layer 2) (Domain-Model-Layer) Graphical Net Editor Support MessageBus Rule Engine DomainModelService Platform (Layer 1) (Service-Layer) WinForms.UI Web.UI User-Assistance Scripting Search Persistence Die Grundstruktur des Frameworks, das ich im Folgenden als Platform bezeichnen werde, unterteilt sich in 3 Ebenen. Dabei wurden die orange unterlegten Komponenten komplett oder anteilig an der Uni Hamburg entwickelt. Auf der untersten Ebene finden wir einerseits die Laufzeitumgebung, welche die Plugins verwaltet und bestimmte Basisdienste zur Verfügung stellt. Andererseits finden wir Komponenten für verschiedene allgemein nutzbare Funktionalitäten. Dies umfasst die Bereitstellung der Oberfläche, für die eine Desktop-Variante existiert und eine Web-basierte Variante in Planung ist sowie Unterstützung von Suche, Scripting, Benutzerführung durch grafische Assistenten und Persistenz. Auf der zweiten Ebene haben wir Komponenten zur Unterstützung der Erstellung domänenspezifischer Modelle. Dies umfasst einen von konkreten Persistenzmechanismen abstrahierenden Dienst zur Bereitstellung persistenter Domänenobjekte, einen Nachrichtenbus, an dem Plugins Informationen über Änderungen an Domänenobjekten erhalten können, Unterstützung für graphstrukturierte Modelle, sowie einen noch einzubindenden Regelinterpreter zur Durchsetzung semantischer Regeln über Domänenobjekten. Auf der obersten Ebene finden wir schließlich die auf der Platform basierenden Anwendungen Platform.Runtime (multiple bundles) Quelle: In Anlehnung an Schnackenbeck, Panic, Wohlgemuth: Eine offene Anwendungsarchitektur als Fundament eines Methodenbaukastens für BUIS, Berlin 2007, Workshop „Simulation in den Umwelt- und Geowissenschaften, Medizin und Biologie“ T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

16 Grundkonzepte der Platform
Plugin-basierte Architektur minimale Kernfunktionalität (Plugin-Lader) alle weitere Funktionalität bereitgestellt durch Plugins Erweiterungspunkte und Erweiterungen Erweiterungspunkte eines Plugins sind durch Beiträge (contributions) anderer Plugins erweiterbar Bundles Zusammenfassung aller Bestandteile eines Plugins XML-basierte Deklaration, Implementation und Ressourcen entspricht physikalisch einer .NET-Assembly Ich möchte zunächst auf einige Grundkonzepte der Platform eingehen, die wie erwähnt an Konzepte aus Eclipse angelehnt sind. Zunächst haben wir eine Plugin-basierte Architektur mit der Runtime-Komponente als minimalem Kern und diversen Plugins zur Bereitstellung weiterer Funktionalität. Das Zusammenspiel der Plugins wird wie in Eclipse durch das Konzept der Erweiterungen und Erweiterungspunkte geregelt. Plugins definieren Erweiterungspunkte, an denen andere Plugins Erweiterungen bereitstellen, die vom zu erweiternden Plugin über eine registrierung abgefragt werden können. Grob gesagt stellt z.B. das Plugin für die grafische Oberfläche einen Erweiterungspunkt zur Verfügung, an dem andere Plugins Menü-Einträge mit zugehörigen Kommandos beitragen können. Beim Aufbau der Oberfläche wird dieser Punkt abgefragt und die entsprechenden Menü-Einträge werden an der Oberfläche angezeigt und können von dort aus die Kommandos aufrufen. Ebenfalls aus Eclipse stammt das Strukturierungsmittel des Bundles als Zusammenfassung aller Bestandteile eines Plugins. Ein Bundle beinhaltet die XML-basierte Deklaration der Erweiterungen und Erweiterungspunkte sowie die Implementation der zugehörigen Funktionalität in C#. Physikalisch entpricht jedes Bundle einer .NET-Assembly, die vom Plugin-Lader inspiziert und geladen wird. Quelle: Jahr+ 2007 T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

17 Aufgaben der Platform.Runtime
Laden und Starten von Plugins Verwaltung von Diensten und Erweiterungen Dienst-Registrierung (service registry) Erweiterungs-Registrierung (extension registry) Auflösen von Abhängigkeiten zwischen Plugins lose Kopplung durch Inversion of Control (IoC) Registrieren von Verträgen (Interfaces) und deren Implementationen (Klassen) in einem IoC-Container Verwendung des Open Source Frameworks Castle ( Den Kern der Platform bildet die Laufzeitumgebung, deren Aufgabe einerseits das Laden und Starten der Plugins ist. Andererseits werden allgemein nutzbare Registrierungen für Dienste und Erweiterungen bereitgestellt. Dienste bezeichnen dabei Komponenten, die systemweit genau einmal vorhanden sind und beim Hochfahren der Platform gestartet und initialisiert werden. Eine weitere Aufgabe der Runtime ist die Auflösung von Abhängigkeiten zwischen Plugins. Das Problem in einer dynamischen Architektur ist, dass Abhängigkeiten prinzipiell erst zur Laufzeit aufgelöst werden können, da zur Compilezeit nicht unbedingt bekannt ist, welche Instanzen von Plugins wann vorhanden sind. Daher verwendet die Platformeinen sogenannten Inversion of Control Container, der die Abhängigkeiten zwischen Plugins befriedigt. Zur Laufzeit werden Komponenten im Container registriert, indem man die bereitgestellte Funktion als Vertrag in Form eines Interfaces spezifiziert und dazu die implementierende Klasse angibt. Möchte eine Komponente die Funktionalität nutzen, gibt sie z.B. das entsprechende Interface als Konstruktor-Parameter an. Bei der Objekterzeugung stellt der Container sicher, das die benötigten Komponenten vorhanden sind und stellt entsprechende Referenzen her. Als IoC-Container verwenden wir eine vorhandene Komponente aus dem Open Source Framework Castle. Quelle: Jahr+ 2007 T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

18 Weitere Dienste der Runtime
Fehlerbehandlung konfigurierbarer Platform Error Service Logging basierend auf log4Net Befehlsausführung: Command Service Konfiguration & Ausführung parameterisierter Kommandos Undo-/Redo-Funktionalität in Arbeit Konfiguration von Erweiterungen XML-basierte Beschreibung Beitragen eigener XML-Schemas für Konfigurations- Syntax Die Laufzeitumgebung stellt darüber hinaus eine Reihe weiterer Basisdienste zur Verfügung, die von anderen Plugins genutzt werden können. Dies umfasst Fehlerbehandlung und Logging auf Basis des freien log4net Frameworks. Weiterhin gibt es einen Dienst, der die Konfiguration und Ausführung parametrisierbarer Kommandos innerhalb der Platform unterstützt. Hierbei ist auch eine allgemein nutzbare Undo/Redo-Funktionalität geplant, die aber noch nicht vollständig umgesetzt wurde. Außerdem unterstützt die Runtime das Einlesen XML-basierter Konfigurationsdateien zur Beschreibung von komplexeren Erweiterungen. Dabei ist es möglich, Syntax-Definitionen zur Beschreibung eigener Erweiterungen in Form von XML Schemas beizutragen. Quelle: Jahr+ 2007, S Quelle: Jahr+ 2007, S T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

19 T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET
Platform.UI Unterstützung von Benutzerinteraktionen Actions: grafische Repräsentation von Kommandos SelectionService: grafische Auswahl von Objekten Workbench als grafischer „Arbeitsplatz“ Parts: Toolbars und Views Perspektive: aufgabenspezifische Anordnung der Elemente Abstrakte Oberflächenelemente Navigator: baumartig strukturierte Daten GridView: tabellarische Daten PropertyEditor: Objekteigenschaften, ... Bevor ich zu den Arbeitspaketen der Uni Hamburg komme, möchte ich noch kurz auf die grafischen Bestandteile der Platform eingehen. Diese sind zunächst abstrakt in Form von Interfaces definiert, so dass sie prinzipiell durch verschiedene grafische Toolkits implementierbar sind. Dadurch kan man mit relativ geringen Aufwand eine Desktop-Oberfläche gegen eine Web-Oberfläche oder einen einfachen freien Texteditor durch einen komfortablen kommerziellen austauschen. Unterstützt werden insbesondere Benutzerinteraktionen wie das Anstoßen von Kommandos auf verschiedene Weise. Außerdem gibt es einen Selektionsdienst, der die grafische Auswahl von Objekten und das Abfragen der aktuellen Auswahl unterstützt. Wie in Eclipse gibt es eine sogenannte Workbench als zentralen grafischen Arbeitsplatz, der sich aus Toolbars und Fenstern zusammensetzt. Zur Laufzeit können verschiedene frei definierbare Perspektiven ausgewählt werden, die aufgabenspezifische Anordnungen grafischer Elemente innerhalb der Workbench beschreiben. Es gibt zudem komplexere Oberflächenelemente wie Navigatoren zur Darstellung baumstrukturierter Daten, einen GridViews für tabellarische Daten und Property Editoren zum Bearbeiten von Objekteigenschaften. Quelle: Jahr+ 2007, S T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

20 Beispiel: Umberto 6 Prototyp
Navigator Toolbar mit Actions Anwendungs- spezifische Views Als praktisches Beispiel sehen wir hier einmal die auf der Platform basierende Workbench eines sehr frühen Prototypen des neuen Umberto-Systems. Wir sehen zwei anwendungsspezifische Views, von denen der erste einen Editor für Stoffstromnetze und der zweite eine einfache Materialverwaltung darstellt. Die Hauptanwendung und der Netzeditor verfügen über je eine Toolbar mit verschiedenen Aktionen. Links oben sehen wir einen Navigator, der den Inhalt eines Datenbank-Repositories mit verschiedenen Stoffstrom-analyseprojekten anzeigt. Darunter befindet sich ein generischer Property-Editor, der die Eigenschaften der im Stoffstromnetz selektierten Stelle anzeigt. Durch eine andere Implementation der PropertyEditor-Schnittstelle könnte man hier z.B. auch eine anwendungsspezifischere Darstellung der Eigenschaften erreichen. Property Editor T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

21 Arbeitspakete der Uni Hamburg
Stoffstromanalyse-Werkzeug (z.B. Umberto) als klassische Drei-Schichten-Architektur Präsentation Abstraktes Rahmenwerk für Graphen-Editoren Modell / Logik Fachsprache für Stoffstromanalyse (insb. Stroffstromnetze) Ich komme nun zu den Bestandteilen der Platform, die komplett oder teilweise an der Uni-Hamburg entwickelt wurden. Als kleinen Leitfaden zur Strukturierung dieser Beiträge sehen wir hier den Aufbau eines Stoffstromwerkzeugs als klassische Dreischichten-Architektur. Ich werde zunächst auf die Beschreibung des Domänenmodells in Form einer Fachsprache für die Stoffstromanalyse eingehen. Anschließend stelle ich die (natürlich auch außerhalb von Stoffstromanalyse nutzbaren) abstrakte Persistenzschicht für Domänenobjekte vor, die von meinem Kollegen Thorsten Busse entwickelt wurde. Abschließend gehe ich als Schnittstelle zur Präsentationsschicht noch kurz auf ein abstraktes Framework zum Editieren von graphbasierten Modellen ein, an dessen Entwicklung ich beteiligt war. Persistenz Abstrakter Persistenzdienst für Domänen-Objekte vgl. z.B. de.wikipedia.org/wiki/Mehrschichtige_Architektur T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

22 Fachsprache für Stoffstrom-Plugins
Schnittstellenbasierte Fachsprache anwendungsspezifische Zusammenarbeit von Plugins aus dem Bereich Stoffstromanalyse Zwei wichtige Komponenten Umsetzung von Begriffen in Schnittstellen Festlegen von Regeln für korrekte Interaktionen Automatische Codegenerierung aus XML-Beschreibung Mappings für ORM etc. Interfaces und Klassen Beliebige weitere Artefakte (z.B. Dekoratoren) Eine Fachsprache für Stoffstromanalysen dient dazu, die Zusammenarbeit zwischen Plugins zur Stoffstrom-Analyse in Form einer standardisierten fachbezogenen 'Sprache' zu unterstützen. Solche Fachsprachen kennen wir in der Informatik heutzutage unter den Begriffen Ontologie oder Domain specific language. Sie setzt sich aus zwei Komponenten zusammen, einerseits Schnittstellen, welche die Begriffe der Sprache beschreiben, und andererseits Regeln, welche die korrekte Verwendung der Begriffe sicherstellen. Die Fachsprache wird in einem XML-Format beschrieben, aus dem sich durch Codegenerierung verschiedene Artefakte generieren lassen. Dies umfasst die Interfaces und implementierenden Klassen selbst, Abbildungsvorschriften für das objektrelationale Mapping im Rahmen der Persistenz oder grafische Dekoratoren für die Darstellung in einem Navigator oder Property Editor. Aus Eclipse kennt man Beispiele, wo aus solchen Beschreibungen auch komplette grafische Editoren erzeugt werden. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

23 Beispiele für Schnittstellen
Hier sehen wir beispielhaft einige Schnittstellen, die verschiedene Begriffe der Sprache beschreiben, z.B. ein Material oder eine Einheit. Man sieht, dass diese Schnittstellen aus programmtechnischer Sicht sehr Eigenschafts-lastig sind, da sie hauptsächlich die Attribute und Relationen der Begriffe beschreiben. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

24 T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET
Einsatz von Regeln Gültige Interaktionen/Nutzung über Regeln festlegen Rule engine zur Durchsetzung von Vor- und Nachbedingungen, Invarianten („programming by contract“) Generierung des entsprechenden Codes Wirkungsbereiche von Regeln für Domänenobjekte einzelne, verschiedene Eigenschaften eines Objekts Objekt-übergreifende Regel innerhalb eines Plugins Objekt- und Plugin-übergreifende Regeln Eine neue DSL? Schnittstellen und Regeln erfüllen wichtige Anforderungen Der Einsatz von Regeln zur Beschreibung der Semantik der Sprache steht wie gesagt nocham Anfang. Prinzipiell wird es hier eine Rule Engine geben, welche Vor- und Nachbedingungen sowie Invarianten über den Elementen der Sprache durchsetzt. Der entsprechende Code wird wiederum aus den XML-Beschreibungen generiert. Die Regelmenge soll dabei in verschiedene Wirkungsbereiche strukturiert werden, wobei Regeln über einzelne oder verschiedene Eigenschaften eines Objekts, objektübergreifende Regeln innerhalb eines Plugins, sowie plugin-übergreifende Regeln denkbar sind. Hinsichtlich der Frage, ob man die Stoffstrom-Fachsprache nach ihrer Vollendung als domänenabhängige Programmiersprache für Stoffstromanalysen verstehen kann, muss man sagen, dass dies zwar nicht das explizite Ziel ist, mit Schnittstellen und Regeln jedoch schon wesentliche Anforderungen an eine DSL erfüllt wären. Die entwickelten Konzepte können dann natürlich auch in andere Domänen übertragen werden. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

25 T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET
Persistenzdienst Bereitstellung und Verwaltung von persistenten Objekten Erweiterbarkeit durch andere Plugins dynamisches Hinzufügen von neuen Eigenschaften zu Objekten anderer Plugins Abstraktion von konkreten Backends Kapselung objektrelationaler Mapper (z.B. NHibernate) Speicherung von Daten an verschiedenen Speicherorten Undo/Redo fortlaufende und gezielte Speicherung Zur Persistierung von Domänenobjekten in relationalen Datenbanken oder anderen Repositories dient innerhalb der Plattform ein Persistenzdienst, der zur Zeit von meinem Kollegen Thorsten Busse entwickelt wird. Die Anforderungen an einen Persistenzdienst innerhalb einer Plugin-basierten Anwendung sind relativ hoch. Zunächst muss er anderen Plugins persistente Objekte bereitstellen und diese verwalten. Daneben soll er durch andere Plugins erweiterbar sein, d.h. Es soll einfach möglich sein, neue Persistenzmechanismen mit ihren jeweiligen Abfragesprachen sowie neue Typen von Persistenten Objekten hinzuzufügen. Man sollte auch zu bereits bestehenden Typen persistenter Objekte neue Eigenschaften hinzufügen können. Die Nutzung der Persistenzmechanismen soll für den Klienten transparent sein, d.h. Es soll von konkreten Backends, OR-Mappern und Speicherorten abstrahiert werden. Undo/Redo Operationen sollten auf persistenten Daten möglich sein und es sollte sowohl die implizite fortlaufende als auch die gezielte Speicherung eines Modells im Repository möglich sein. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

26 Domain Model Service Plugin Plugin MessageBus PersistenceDomainStore A DomainObject(s) DomainModelService PersistenceDomainStore B PersistenceDomainStore n Ich werde einerseits aus Zeitgründen, andererseits, weil Thorsten Busse hier der bessere Ansprechpartner ist, nur kurz auf die technische Umsetzung eingehen. Prinzipiell hat Thorsten hier mehrere Stufen der Abstraktion vorgesehen. Zentrale Anlaufstelle zur Bereitstellung persistenter Objekte ist der sogenannte DomainModelService. Dieser verwaltet mehrere PersistenceDomainStores, welche mit Hilfe des Persistenzdienstes auf unterschiedliche Datenbank-Backends und Repositories zugreifen können. Implementiert wurde hierbei insbesondere eine Bindung für die Firebird-Datenbank mit NHibernate als objektrelationalem Mapper. Änderungen an persistenten Domänenobjekten wie z.B. deren Erzeugung werden über den sogenannten MessageBus signalisiert, an dem sich Plugins unter Rückgriff auf den DomainModelService als Beobachter anmelden können. Neben der Signalisierung von Ereignissen stellt der MessageBus noch Filterfunktionalität zur Verfügung, wodurch Plugins eine genaue Selektion der für sie relevanten Ereignisse möglich ist. Da auf dem Message Bus prinzipiell alle Operationen an persistenten Objekten aufgezeichnet werden können, unterstützt er außerdem die Umsetzung der Undo/Redo-Funktionalität. Plugin T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

27 Abstrakter Graphen-Editor
Abschließend möchte ich noch kurz auf die Schnittstelle zur Präsentation eingehen. Da graph-basierte Modelle in der Umweltinformatik gängig sind, haben Stefan Simroth von der FHTW Berlin und ich ein abstraktes Rahmenwerk für Grapheneditoren implementiert. Dieses dient dazu, beliebige fachliche Graphenmodelle durch beliebige grafische Toolkits darstellen und editieren zu können. Diese Bindung wird wiederum mit Hilfe einer XML-basierten Konfiguration definiert. Das Framework besteht aus Schnittstellen und abstrakten Klassen, die in Anlehnung an das MVC-Paradigma beschreiben, wie ein beliebiges logisches Netz und ein beliebiges grafisches Netz bidirektional miteinander synchronisiert werden. Auf der Ebene des Modells haben wir Adapter-Schnittstellen, welche standardisierten Zugriff auf die Elemente des logischen Netzes bieten und logische Änderungsereignisse in Events für den grafischen Editor umwandeln. Als Mittler dient eine Controller-Schicht, die einerseits auf Änderungen am logischen Netz lauscht und diese in Editor-Befehle umsetzt, und andererseits Oberflächenkomponenten Zugriff auf die Erzeugung und Modifikation der logischen Objekte bereitstellt. Die Editor-Schnittstelle kann schließlich durch ein konkretes grafisches Toolkit zum Editieren von Graphenmodellen implementiert werden. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

28 5. Zusammenfassung und Ausblick
Offenes Plugin-Framework unter .NET orientiert an Kernkonzepten aus Eclipse im Kontext betrieblicher Umweltinformationssysteme UHH: Arbeitspakete Stoffstrom-Fachsprache und Persistenz Ausblick weitere Evaluierung an Umberto 6-Prototyp Unterstützung von Transaktionen Backend-neutrale Abfragesprache für Domänenobjekte Entwurf / Implementierung von Regeln für Domänenobjekte Verteilung ...? Ich komme nun zum Abschluss meines Vortrags. Zusammenfassend haben wir im Projekt Plugin.Net in Kooperation mit der Firma ifu und dem Emporer-Projekt der FHTW-Berlin ein offenes Plugin-Framework unter .NET entwickelt, welches sich an Kernkonzepten aus Eclipse orientiert. Im Gegensatz zu Eclipse steht bei uns das Anwendungsfeld der betrieblichen Umweltinformatik im Vordergrund. Die Uni Hamburg steuert hierzu hauptsächlich eine Fachsprache für die Stoffstromanalyse sowie einen allgemein nutzbaren Persistenzdienst für Domänenobjekte bei. Im weiteren Verlauf des Projektes werden wir das entwickelte Framework am Beispiel der neuen Umberto-Version evaluieren. Bezüglich unserer Arbeitspakete stehen verschiedene Punkte uaf der tagesordnung, wie z.B. die Unterstützung von Transaktionen, die Entwicklung einer Backend-neutralen Abfragesprache sowie der Einsatz von Regeln innerhalb der Fachsprache. Das für sie relevante Thema der verteilten Ausführung haben wir bisher nicht behandelt, obwohl es natürlich für umweltinformatische Berechnungen und Simulationen relevant ist. Die verteilte Ausfürhung von Plugins wäre nach meinem ersten Eindruck allerdings denkbar, da der verwendete IoC-Container des Castle-Frameworks auch die transparente Verteilung von Komponenten unterstützt. T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET

29 Vielen Dank für die Aufmerksamkeit !
Fragen...? T. Busse, N. Denz: Drittmittelprojekt PLUGIN.NET