... Where No IDE Has Gone Before Thorsten Fink, Ph.D. Wolfgang Metzner GmbH & Co KG To Boldly Go ... ... Where No IDE Has Gone Before Komponentenbasierte Entwicklung mit Eclipse – eine greifbare Vision © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG

Ein Zitat zu Beginn “ The plug-in extension model of Eclipse provides a powerful and general paradigm for architecting extensible systems based on loosely-coupled components.” [Bolour]

Hier beginnt unsere Vision!! Hintergrund Wir stimmen dem Zitat zu, sind aber der Meinung, dass das Plugin Development Environment (PDE) von Eclipse sehr viel mehr bietet als nur ein Paradigma. Denn: PDE ist die einzige uns bekannte IDE, die komponenten-basierte Entwicklung aktiv unterstützt. Die Entwickler von Eclipse hatten viele Probleme zu bewältigen, um Eclipse wirklich komponentenbasiert entwickeln zu können, also haben sie sie sich eine eigene Entwicklungsumgebung geschaffen (PDE). Entwickler von Java-Anwendungen haben ähnliche Probleme, falls sie komponenten-basierte Entwicklung anstreben. Die Realität ist, dass oftmals nicht komponenten-basiert, sondern monolithisch entwickelt wird, weil die heutigen allgemeinen Java-IDE‘s keinen Support in der notwendigen Richtung bieten. Hier beginnt unsere Vision!!

Die Vision Unsere Vision ist eine Erweiterung der Eclipse Java Entwicklungsumgebung (JDT), welche die folgenden Funktionalitäten bietet Kenntnis von Komponenten, Modulen (mehrere Komponenten) und Applikationen (mehrere Module) in der IDE verankert Manifest-Dateien für Komponenten, Module, Applikationen (inklusive Editoren) Komponenten-Abhängigkeiten über Id und Version Komponenten kommunizieren ihre Parametrisierbarkeit, Konfigurierbarkeit und Erweiterbarkeit über ihre Manifest-Datei Build berücksichtigt Komponentenabhängigkeiten, prüft, dass alle notwendigen Konfigurationen vorgenommen wurden Erstellt automatisch eine Property-Datei (nur „linke Seite“) mit allen von den Komponenten benötigen Parametern IDE stellt Infrastruktur-Klassen zur Verfügung, die in die Applikation eingebunden werden (zur Unterstützung von Komponenten-Erweiterungen)

Komponenten-Hierarchie: Beispiel Applikation ain Module ain-persistence ain-client dbo.ain dbo.core Komponenten client.ain client.core util enthält hängt ab Eine Applikation besteht aus Modulen. Module bestehen aus Komponenten. Nur Komponenten sind erweiterbar und konfigurierbar (durch andere Komponenten). Im Beispiel konfiguriert dbo.ain die Komponente dbo.core.

Manifest-Dateien: Überblick Jede Komponente verfügt über eine Manifest-Datei mit Namen component.xml Eine Komponente entspricht einem Eclipse-Projekt. Die Manifest-Datei component.xml enthält die folgenden Informationen Hauptinformationen: Id, Name, Version Abhängigkeiten zu anderen Komponenten Runtime-Informationen: Name des Komponenten-Jars (und ggf. enthaltene Jars) Parametrisierungsinformationen: durch welche Parameter wird die Komponente parametrisiert (z.B. Datenbank-URL)? Konfigurationsinformationen: wie kann die Komponente durch eine andere konfiguriert werden? Z.B. durch in einer XML-Datei abgelegte Metadaten. Listener: welche Listener können registriert werden? Listener-Registrierung: welche Listener werden bei einer anderen Komponente registriert? Mögliche weitere Erweiterungsmöglichkeiten und Nutzungen derselben

Komponenten-Manifestdateien: Beispiel (S.1) <component> <component-id="de.vfst.persistence" /> <component-name="dbo" /> <component-version="2.5" /> <requires> <import component="util" version="1.4"> <import component="jaxb-lib" version="1.0"/> </requires> <runtime> <library name="dbo.jar"> </runtime> <!-- Necessary Parameters --> <param-point name="database.url" description="URL der Datenbank" /> <param-point name="database.user" description="Benutzer der Datenbank" /> <param-point name="datbase.password" description="Passwort des Benutzers" /> <!-- geht weiter auf der nächsten Seite) -->

Komponenten-Manifestdateien: Beispiel (S.2) <!-- Configuration --> <configuration-point name="attribute-names" fileName="attribute-names.xml" schema="attribute-names.xsd" description="Metadaten ueber persistente Attribute" /> <configuration-point name="record-names" fileName="record-names.xml" schema="record-names.xsd" description="Metadaten ueber persistente Records" /> <!-- 3. Startup --> <startup className="de.vfst.server.persistence.dbaccess.Initializer" /> <startup className="de.vfst.server.persistence.ormapper.Initializer" /> <startup className="de.vfst.persistence.entity.Initializer" /> <startup className="de.vfst.persistence.query.Initializer" /> <startup className="de.vfst.persistence.object.Initializer" /> <!-- 4. Plugins (Stecker) --> <!-- 5. Plugs (Buchse) --> </component>

component.xml: Die Elemente Hauptinformationen component-id: Eindeutige Id der Komponente component-name: Name der Komponente component-version: Version der Komponente requires: Abhängkeiten zu anderen Komponenten (unter Angabe von Id und Version) runtime: Name des produzierten Jars (und ggf. enthaltener Jars) param-point: Name von Parametern, die zur Parametrisierung dieser Komponente notwendig sind. Aus diesen Parameternamen wird die Property-Datei der Gesamtapplikation erstellt. configuration-point: Name einer Datei, die zur Konfiguration dieser Komponente herangezogen werden. Diese Komponente enthält die Datei nicht, sondern genau eine andere Komponente nimmt die Konfiguration dieser Komponente vor (siehe auch nächstes Element configuration). configuration: Lokation der von einer anderen Komponente spezifizierten Konfigurationsdatei. Hiermit wird eine andere Komponente konfiguriert.

component.xml: Die Elemente startup: Klassen, die zum Zeitpunkt des Systemstarts instanziiert werden, und deren initalize(Properties properties)-Methode aufgerufen wird. listener-point: Hier können andere Komponenten Listener registrieren. listener: Hier registriert eine Komponente einen Listener bei einer anderen Komponente. Wahrscheinlich sind noch andere Erweiterungselemente sinnvoll. Wir bevorzugen diese Elemente auszumodellieren (wie bei listener-point, listener geschehen), damit wesentliche Kommunikationsmerkmale zwischen Komponenten nicht in allgemeinen extension-point-, extension-Elementen verloren gehen. Wir glauben, dass dies für Anwendungen möglich ist, da es nicht so viele Formen dieser Kommunikation gibt, bzw. da man sich auf einige wenige beschränken kann.

Build: Überblick Die Manifest-Dateien der Komponenten, Module und Applikationen werden im Build-Prozess, sowohl Eclipse-intern als auch Eclipse-extern (Ant), herangezogen. Wir betrachten hier nur den Eclipse-internen Build-Prozess (siehe aber Anhang). Zum einen werden die Abhängigkeiten analysiert und genutzt. Bei Inkonsistenzen werden Problems (Tasks) erzeugt. Beispiele für Inkonsistenzen: Eine Komponente liegt in der referenzierten Version nicht vor. Eine Komponente wird in einem Modul oder in einer Applikation in zwei unterschiedlichen Versionen referenziert. Eine konfigurierbare Komponente wird innerhalb eines Moduls oder innerhalb einer Applikation nicht (oder mehr als einmal) konfiguriert. Ansonsten werden alle Komponenten wie in den Manifest-Dateien dokumentiert ge-builded. Die Parameter (in param) werden in eine Property-Datei geschrieben. Die Startup-Informationen (in startup) werden in einer startup.xml gesammelt. Diese Datei steht der Applikation beim Systemstart zur Verfügung.

Build: Überblick Auch die restlichen Informationen werden gesammelt und Infrastruktur-Klassen zur Verfügung gestellt. Der genaue Prozess und die Funktionalität dieser Infrastruktur-Klassen ist noch zu detaillieren. Die Infrastruktur-Klassen müssen sowohl Eclipse als auch der Java-Applikation zur Verfügung stehen.

Build: Komponenten-Parametrisierung Die param Elemente aller Komponenten einer Applikation werden im Rahmen des Build-Prozesses ausgewertet. Auf der Grundlage dieser Elemente wird eine Property-Datei erstellt bzw. kann eine vorhandene validiert werden (in Bezug auf Vollständigkeit). component.xml <!-- Necessary Parameters --> <param-point name="database.url" description="URL der Datenbank" /> <param-point name="database.user" description="Benutzer der Datenbank" /> <param-point name="database.password" description="Passwort des Benutzers" /> Application.properties -- es werden die „linken Seiten“ (Parameternamen) erstellt ## Parameters of component: dbo database.url= database.user= database.password=

Build: Komponenten-Konfiguration Eine Komponente kann spezifizieren, dass sie über ein XML-Instanzdokument konfiguriert werden kann. <configuration-point name="attribute-names" fileName="attribute-names.xml" schema="attribute-names.xsd" description="Metadaten ueber persistente Attribute" /> Im Kontext eines Moduls oder einer Applikation kann genau eine andere Komponente diese Konfiguration vornehmen. Diese Komponente enthält zum Zwecke der Konfiguration das verlangte XML-Instanzdokument, welches dem spezifizierten XML-Schema genügt. <configuration point="de.vfst.persistence.attribute-names" path="de/vfst/persistence/metadata/ain" />

Module Module bestehen aus (konfigurierten) Komponenten. Module sind nicht konfigurierbar. Sie werden durch Manifest-Dateien mit Namen module.xml beschrieben. <module> <module-id="de.vfst.ain-persistence" /> <module-name="ain-persistence" /> <module-version="2.1" /> <component id="de.vfst.persistence" version="2.5" /> <component id="de.vfst.persistence.ain" version="1.5" /> <component id="de.vfst.util" version="1.4" /> <component id="de.vfst.libs.jaxb" version="1.0" /> </module>

Applikationen Applikationen bestehen aus Modulen und ggf. (konfigurierten) Komponenten. Applikationen sind nicht konfigurierbar. Sie werden durch Manifest-Dateien mit Namen application.xml beschrieben. <application> <application-id="de.vfst.ain-application" /> <application-name="ain" /> <application-version="1.0" /> <module id="de.vfst.ain-client" version="1.8" /> <module id="de.vfst.ain-persistence" version="2.1" /> </application>

Ausblick Es gibt sicherlich noch viele Probleme zu bewältigen und Lücken zu füllen auf dem Weg zu einer vollständigen Unterstützung komponenten-basierter Entwicklung. Der in diesem Dokument vorgestellte Weg ist aber sicherlich gangbar und unseren Erachtens vielversprechend. Ausgewählte Funktionalitäten sind möglicherweise durch Migration von PDE nach JDT oder durch „Monkey See, Monkey Do“ recht schnell zu implementieren. Nicht unerwähnt sollten angenehme Seiteneffekte bleiben, wie z.B. das „Reverse Engineerung“ von Komponenten-Diagrammen auf Grundlage der Manifest-Dateien und weitere noch zu entdeckende Möglichkeiten. Dies gibt den Architekten die Gewissheit, dass ihre Architektur auch gelebt wird. Konkrete Dateien (die Manifest-Dateien) über deren Inhalt Entwickler diskutieren können. der Anreiz produkt-unabhängige oder plattform-unabhängige Komponenten zu erstellen, die dadurch einen höheren Grad der Wiederverwendbarkeit erlangen.

Literatur [Bolour] Azad Bolour, Notes on the Eclipse Plug-in Architecture, in: Eclipse Corner Article, http://www.eclipse.org/articles/index.html, Juli 2003 [Gamma, Beck] Erich Gamma, Kent Beck, Contributing to Eclipse, Addison-Wesley, 2004

Anhang: Build-Management Die Vision für das Build-Management sieht wie folgt aus Zum Build einer Applikation genügt Zugriff auf das ConfigurationsManagementSystem (CMS) sowie die Manifest-Datei application.xml der Applikation. Im Rahmen des Build-Prozesses werden die benötigten Komponenten in der korrekten Version vom CMS bezogen, die Komponenten-Abhängigkeiten validiert und der eigentliche Applikations-Build vorgenommen, in dessen Rahmen die Property-Datei und die Systemstart-Datei erstellt, die Konfiguration der Komponenten vorgenommen und Infrastruktur-Klassen für bspw. die Listener-Registrierung bereitgestellt werden.