Komponentenmodell

Komponenten ermöglichen eine Strukturierung von komplexen Software-Systemen. Unter einer Software-Komponente versteht man ein Teil einer Software, die über Schnittstellen eine kohärente Funktionalität darlegt und die durch eine Kapselung ihrer Implementierung eine gewisse Eigenständigkeit bietet. Die umfassende Verwendung von Komponenten wirkt sich sowohl wirtschaftlich wie auch auf die angewendeten Entwicklungsprozesse aus. Dabei sind mögliche Vorteile u.a. geringere Kosten durch die schnellere Entwicklung, eine höhere Qualität oder eine bessere Erweiterbarkeit und Anpassbarkeit einer Software.

Ein Komponentenmodell definiert einen Rahmen für die Entwicklung und Ausführung von Komponenten. Im Zusammenhang mit dem Komponentenmodell werden noch die Begriffe Komponenten-Umgebung und Komponenten-Architektur unterschieden. Einige bekannte Komponentenmodelle sind: JavaBeans, CORBA, ActiveX/(D) COM, Enterprise JavaBeans, .NET oder das von der OSGi spezifizierte Komponentenmodell. Die folgenden Erläuterungen berücksichtigen die Sicht einer singulären Software-Komponente und eines übergeordneten Komponentenmodells.

Der Begriff der Software-Komponente wird in der Literatur häufig in Abhängigkeit vom Kontext mit unterschiedlicher Bedeutung versehen. Deshalb wird an dieser Stelle im allgemeinen Sinne eine Software-Komponente als eine zusammengesetzte Einheit mit vertraglich spezifizierten Schnittstellen in ihrem jeweiligen Kontext verstanden. Dabei kann eine Software-Komponente immer auch unabhängig von Dritten verwendet werden und wiederum auch Bestandteil anderer Komponenten sein. Software-Komponenten haben eine kohärente Funktionalität und durch deren Kapselung in einer Implementierung besitzen Komponenten eine authentische Eigenständigkeit, die mit einer losen Kopplung an ihre Umgebung gebunden ist. Im Folgenden eine Zusammenstellung der Charakteristika von Komponenten:

Komposition. Thematisiert die innere Struktur einer Komponente. Dabei kann eine Komponente immer auch aus weiteren Komponenten bestehen, was auch als Containment bezeichnet wird. Da dieses Prinzip ebenso rekursiv top-down angewendet werden kann, spricht man auch von Containment Trees.

Schnittstellen. Hier wird die Interaktion zwischen Komponenten und weiteren Software-Elementen - das können wiederum Komponenten sein - beschrieben. Häufig wird die Syntax von Komponentenschnittstellen mittels einer Interface Definition Language (IDL) beschrieben.

Verbindungen. Diese legen fest, welche Komponenten miteinander kommunizieren. Man unterscheidet hier Schnittstellen-Adapter für die Anpassung von Interfaces, asynchrone sowie Push and Pull-Verbindungen.

Kommunikation. Mechanismen zur Kommunikation sind notwendig für die Kommunikation von Komponenten untereinander. Beispielsweise unterstützt die Sprache Java mit Remote Method Invocation (RMI) einen Mechanismus zur Kommunikation von externen Komponenten oder Software-Elementen. Kommunikationsmechanismen sind ein wichtiger Aspekt im Zusammenhang mit Komponenten, da diese Einfluss auf die Integrationsfähigkeit von Komponenten in Software-Systeme haben. Besonders durch das Internet bedingt, wird die Integration von Applikationen und damit auch die Entwicklung von Kommunikationstechnologien weiter voran getrieben - Beispiele dafür sind .NET oder Simple Object Access Protocol (SOAP).

Kontextabhängigkeiten. Eine Komponente sollte immer eine Kontextbeschreibung haben. Darin werden die Annahmen bezüglichen des Kontextes zusammengestellt, in der die Komponente verwendet werden soll. Dabei schränken diese Annahmen immer die Zahl der Umgebungen ein, in der die Komponente verwendet werden kann. Typische Annahmen können sein: die Verwendung von Variablen und Parametern, besondere Schnittstellentypen oder Angaben zum Kommunikationsmechanismus.

Ein im Zusammenhang mit Komponenten häufig verwendeter Begriff ist die sogenannte Granularität. Aus Sicht der Komponenten unterscheidet man im Allgemeinen:

• Feinkörnige Granularität für eher passive Komponenten.
• Mittelkörnige Granularität für aktive Komponenten, die Interaktionen und die Wiederverwendung von komplexeren Funktionen er-möglichen.
• Grobkörnige Granularität für aktive Komponenten deren Funktionen zwar direkt wiederverwendet werden können, jedoch komplexe Schnittstellen und eine aufwändige Parametrisierung vorweisen. Auch sind grobkörnige Komponenten zumeist mit steuernden oder kontrollierenden Funktionen ausgestattet.

Durch Komponentenmodelle wird der Rahmen für die Entwicklung und Ausführung von Komponenten bestimmt. Durch das Modell werden festgelegt:

• Die Zusammensetzung und Verknüpfung von Komponenten.
• Die Kommunikation und das Zusammenwirken von Komponenten.
• Welche Mechanismen und Dienste - zum Beispiel für Verteilung, Persistenz oder Sicherheit - eine Komponente von seiner Infrastruktur bereitgestellt werden.

Demnach muss ein Komponentenmodell die folgenden Aspekte hinsichtlich der Entwicklung und Verwendung von Komponenten berücksichtigen:

Schnittstellen. Definieren die Eigenschaften sowie das Verhalten von Komponenten und basieren häufig auf Sprachen zur Schnittstellen-Spezifikation (IDL).

Namen. Es werden eindeutige Namen für Komponenten, Variablen, Schnittstellen u.a. im globalen Umfeld vereinbart.

Meta-Daten. Definieren Dienste für den Zugriff auf Informationen über Komponenten und Schnittstellen.

Interoperabilität. Belegen Kommunikation und Datenaustausch zwischen Komponenten im heterogenen Umfeld verschiedener Hersteller.

Konfiguration. Dadurch werden die Möglichkeiten zur Anpassung und Konfiguration von Komponenten festgelegt.

Komposition. Vorgaben für die Kombination von Komponenten zu größeren Strukturen.

Evolution. Regeln für das Updating von Komponenten.

Deployment. Berücksichtigung aller für die Verteilung, Installation und Konfiguration notwendigen Informationen.

Auf einige bekannte Komponentenmodelle soll hier noch skizzenhaft näher eingegangen werden: Java Beans.

• Das sind sogenannte visuelle manipulierbare Java-Komponenten, wobei eine Bean jeweils durch eine Klasse implementiert wird.
• Die Schnittstelle wird gemäß den Vorgaben gestaltet.
• Hauptsächlich für GUI-Elemente mittlerer Granularität.
• Verteilung sowie Verbunddokumente werden nicht direkt unterstützt.

CORBA.

• Common Object Request Broker Architecture ist Bestandteil der Object Management Architecture (OMA), wurde von der Object Management Group (OMG) spezifiziert und findet Anwendung in verteilten, heterogenen Systemen.
• Es sind Objektmodell und Object Request Broker (ORB) der Infrastruktur implementiert ( Middleware).
• Schnittstellenbeschreibung ist unabhängig von einer bestimmten Programmiersprache in CORBA-IDL (Interface Definition Language) definiert.

Enterprise JavaBeans.

• Ist ein Server-basiertes Komponentenmodell, das plattformunabhängig und für verteilte Systeme gedacht ist.
• Ist Java-spezifisch und über CORBA sind auch heterogene Komponenten möglich.
• Die Spezifikation definiert Basisdienste u.a. für Persistenz, Sicherheit sowie Kommunikation.