Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Seite 1 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG© März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG To Boldly Go......

Ähnliche Präsentationen


Präsentation zum Thema: "Seite 1 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG© März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG To Boldly Go......"—  Präsentation transkript:

1 Seite 1 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG© März 2004 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 Thorsten Fink, Ph.D. Wolfgang Metzner GmbH & Co KG

2 Seite 2 © 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]

3 Seite 3 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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- IDEs keinen Support in der notwendigen Richtung bieten. Hier beginnt unsere Vision!!

4 Seite 4 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Die Vision Unsere Vision ist eine Erweiterung der Eclipse Java Entwicklungsumgebung (JDT), welche die folgenden Funktionalitäten bietet Komponenten-Abhängigkeiten über Id und Version Manifest-Dateien für Komponenten, Module, Applikationen (inklusive Editoren) IDE stellt Infrastruktur-Klassen zur Verfügung, die in die Applikation eingebunden werden (zur Unterstützung von Komponenten-Erweiterungen) Kenntnis von Komponenten, Modulen (mehrere Komponenten) und Applikationen (mehrere Module) in der IDE verankert 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 Komponenten kommunizieren ihre Parametrisierbarkeit, Konfigurierbarkeit und Erweiterbarkeit über ihre Manifest-Datei

5 Seite 5 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Komponenten-Hierarchie: Beispiel ain ain-clientain-persistence dbo.coredbo.ain util client.coreclient.ain Komponenten Module Applikation 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.

6 Seite 6 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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

7 Seite 7 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Komponenten-Manifestdateien: Beispiel (S.1)

8 Seite 8 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Komponenten-Manifestdateien: Beispiel (S.2)

9 Seite 9 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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.

10 Seite 10 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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.

11 Seite 11 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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.

12 Seite 12 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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.

13 Seite 13 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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 Application.properties -- es werden die linken Seiten (Parameternamen) erstellt ## Parameters of component: dbo database.url= database.user= database.password=

14 Seite 14 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Build: Komponenten-Konfiguration Eine Komponente kann spezifizieren, dass sie über ein XML-Instanzdokument konfiguriert werden kann. 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.

15 Seite 15 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Module Module bestehen aus (konfigurierten) Komponenten. Module sind nicht konfigurierbar. Sie werden durch Manifest-Dateien mit Namen module.xml beschrieben.

16 Seite 16 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Applikationen Applikationen bestehen aus Modulen und ggf. (konfigurierten) Komponenten. Applikationen sind nicht konfigurierbar. Sie werden durch Manifest-Dateien mit Namen application.xml beschrieben.

17 Seite 17 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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.

18 Seite 18 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG Literatur [Bolour] Azad Bolour, Notes on the Eclipse Plug-in Architecture, in: Eclipse Corner Article, Juli 2003http://www.eclipse.org/articles/index.html [Gamma, Beck] Erich Gamma, Kent Beck, Contributing to Eclipse, Addison-Wesley, 2004

19 Seite 19 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG 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.


Herunterladen ppt "Seite 1 © März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG© März 2004 Thorsten Fink, Ph.D., Wolfgang Metzner GmbH & Co KG To Boldly Go......"

Ähnliche Präsentationen


Google-Anzeigen