Komponenten-Entwicklungsplattformen

“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.” [WCOP96 1997]

Komponentenentwicklungsumgebungen stellen innerhalb des komponentenbasierten Middleware-Paradigmas ein entsprechendes Komponentenmodell sowie die erforderliche Infrastruktur zur Verfügung, die es erlaubt, nach dem „Lego-Prinzip“ aus einzelnen Software-Bausteinen komplexe verteilte Anwendungen „zusammenzustecken“. Wesentlicher Fokus dieses Ansatzes ist die Erreichung eines höheren Wiederverwendungsgrades von Software-Artefakten durch:

• Kombination von neuen Komponenten aus bereits existierenden
• Konfiguration d.h. Anpassung vorhandener Komponenten an die spezifischen Anforderungen – die jeweilige Komponente muss dazu die erforderlichen Funktionen an der Schnittstelle zur Verfügung stellen (Black Box)
• Ableitung einer spezifischen Komponente aus einer bereits verfügbaren – hierzu ist die genaue Kenntnis der Funktionsweise der Komponente erforderlich (White Box).

Abbildung 1 veranschaulicht das Prinzip der Komponentenorientierung am Beispiel einer typischen 3-Schichten-Applikation, die sich aus einem Zusammenspiel  unterschiedlicher Komponenten in den drei Ebenen „Presentation“, „Business Logic“ und „Data Management“ ergibt. Dabei benutzen die Komponenten zur Erbringung ihrer Leistung die Dienste anderer, die über entsprechende Schnittstellen (Interfaces) zugreifbar gemacht werden (im Bild durch hellblaue „Lollipops“ angedeutet).

Abb. 1: Typische Struktur einer komponentenbasierten Anwendung im 3-Schichten-Modell

Anforderungen an Software-Komponenten

Damit Software-Komponenten diese Funktion erbringen können, müssen sie u. a. folgende Anforderungen erfüllen:

• Komponenten sind so definiert und implementiert, dass sie in verschiedenen Kontexten einsetzbar sind (Kontext-Unabhängigkeit)
• Komponenten können innerhalb einer Gesamtanwendung gegen andere Komponenten mit dem gleichen Funktionsspektrum getauscht werden
• Komponenten besitzen eine klar definierte, von der Implementierung getrennte, Schnittstelle
• Komponenten stellen selbst keine vollständigen Applikationen dar, sondern ergeben erst im Zusammenspiel mit anderen Komponenten eine gewünschte Gesamtfunktionalität
• Komponenten sind versionnierbar d.h. können in verschiedenen Entwicklungsständen zum Einsatz kommen
• Komponenten sind geschlossene, auslieferfähige Software-Einheiten, die alle Informationen enthalten, die sie in ihrem Einsatzumfeld installierbar und ablauffähig machen (independant deployment).

Komponentenmodelle

Damit Komponenten in entsprechenden Entwicklungsplattformen entworfen, implementiert, aggregiert, „verpackt“, ausgeliefert und in einer Zielumgebung installiert werden können, ist ein geeignetes Architekturschema in Form eines Komponentenmodells mit grundlegenden Vorgaben und Rahmenbedingungen erforderlich. Hierin ist u. a. festzulegen, was eine Komponente den anderen Komponenten grundsätzlich anbietet (Schnittstellentypen, Übergabemodalitäten usw.), welche grundlegenden Arten des Zusammenspiels zwischen den Komponenten benutzt werden können (z.B. synchrone Kommunikation oder Ereignis-Benachrichtigung), welche Komponenteneigenschaften auf welche Art und Weise konfigurierbar sind oder welche Managementdienste für die Komponenteninstanzenverwaltung verantwortlich  sind (zugänglich z.B. über ein sog. Home-Interface).

Ähnlich wie in der Objektorientierung zwischen Klassen und Objekten unterschieden wird, wird auch im Komponentenparadigma zwischen dem Komponententyp und einer Instanz, also einer konkreten Ausprägung der Komponente unterschieden, die zur Laufzeit erzeugt, verwaltet und ggf. auch wieder gelöscht werden muss. Hierzu wird eine Komponenteninstanz typischerweise in einen sog. Container eingebettet, der diese Managementaufgaben in der Laufzeitumgebung der Komponente wahrnimmt. Die eigentliche Verknüpfungs- und Transportbasis stellt i. d. R. eine objektorientierte Middleware in Form eines Object Request Brokers (ORB) zur Verfügung.

Abbildung 2 zeigt diese Einbettung am Beispiel des CORBA Component Models (CCM) der Object Management Group [OMG CCM]:

Abb. 2: Das CORBA-Komponentenmodell der OMG [OMG_CCM]

Ähnlich wie die Common Object Request Broker Architecture CORBA beschreibt auch das CCM kein Produkt sondern ein allgemeines Komponenten-Strukturmodell, welches sich in allen heute verfügbaren Komponenten-Entwicklungsplattformen mehr oder weniger tief umgesetzt wiederfindet ([OMG_CCM], [Nanbor, Schmidt, O'Ryan 2000]).

Komponenten benötigen als Laufzeitumgebung eine entsprechende Infrastruktur, die die im Komponentenmodell spezifizierten Basisdienste (Sicherheitsmanagement, Transaktionsmanagement, Persistenzdienste, Lebenszyklusmanagement, Deployment usw.) unterstützen. Diese Funktionen werden als Produkte in Form sog. Application Server von unterschiedlichsten Anbietern zur Verfügung gestellt.

Literatur

Britton, Chris; Bye, Peter: IT Architectures and Middleware: Strategies for Building Large, Integrated Systems; Addison-Wesley 2004

McIlroy, M. Douglas: Mass Produced Software Components; Proceedings of the NATO Software Engineering Conference, October 1968.

Kaib, Michael: Enterprise Application Integration; Deutscher Universitäts-Verlag, Wiesbaden 2002

Linthicum, David S.: Enterprise Application Integration; Addison-Wesley 2000

MICROSOFT_COM: MICROSOFT Component Object Model Technologies http://www.microsoft.com/com (Abruf 16.08.2016)

Nanbor, Wang; Schmidt, Douglas C.; O'Ryan, Carlos: An Overview of the CORBA Component Model; Component-Based Software Engineering, Addison-Wesley, 2000

SUN_JEE: Java Platform, Enterprise Edition (JEE) http://java.sun.com/javaee/ (Abruf 16.08.2016)

Szyperski, Clemens: Component Software: Beyond Object-Oriented Programming; 2nd edition; Addison-Wesley 2002

OMG_CCM: Object Management Group (OMG) – CORBA Component Model Specification Version 4.0 http://www.omg.org/spec/CCM/4.0 (Abruf 16.08.2016)

WCOP96: Summary in ECOOP'96 Workshop Reader; dpunkt Verlag, 1997

Autor