Da die Komponententechnik noch ganz am Anfang steht, bemühen sich Entwicklungsexperten zunächst um Begriffsdefinitionen. Unter einer Komponente versteht etwa Stefan Schreyjak vom Software Labor der Universität Stuttgart einen Softwarebaustein, der ohne Integritätsverlust wiederverwendet werden und aus anderen Komponenten zusammengesetzt sein kann (siehe Abbildung). Für Michael Stahl, Mitarbeiter der Zentralabteilung Forschung und Entwicklung bei der Siemens AG, München, kann eine Komponente neben der Anwendungsrolle auch die eines Containers für andere binäre Bausteine übernehmen. Container-Applikationen bestehen aus einem Anwendungsgerüst und mehreren binären Komponenten.
Auch bei Schreyjak stehen Komponenten in einem größeren Zusammenhang: Sie bilden ein Komponentenmodell, das den Aufbau der Komponente sowie die Kommunikation zwischen Komponenten beschreibt. Die Software-Architektur stellt die Infrastruktur für Komponenten bereit. Unter einer Komponentenanwendung versteht er eine konkrete Applikation, die aus Komponenten aufgebaut ist.
Im Unterschied zur herkömmlichen Programmierung weiß der Entwickler von Komponenten nicht unbedingt, in welchem Zusammenhang die Komponente genutzt wird. Deshalb steht nicht die individuelle Applikation im Vordergrund, sondern "der Entwurf und die Implementierung von wiederverwendbaren Bausteinen", aus denen sich Anwendungssysteme zusammenbauen lassen, faßt Norbert Schuhmacher vom Informatikzentrum der Sparkassenorganisation GmbH, Bonn, zusammen.
Daraus ergeben sich eine Reihe von Anforderungen an diese Softwarebausteine, die im übrigen unabhängig davon sind, ob objektorientiert oder strukturiert programmiert wird. So sollten die Funktionalität eines Bausteins sowie die Voraussetzungen für seine Nutzung dokumentiert sein. Schuhmacher rät zu einer von den einzelnen Programmiersprachen unabhängigen Beschreibungssprache, mit der sich etwa die Schnittstellen skizzieren lassen, ohne die jeweiligen Charakteristika berücksichtigen zu müssen.
Außerdem sollte eine Komponente eine zusammenhängende Gruppe von Funktionen bereitstellen und damit den fachlichen oder technischen Kontext abdecken. Einfache Schnittstellen lassen sich durch Generalisierungen finden.
Eine Komponente müßte, da sie in unterschiedlichen Zusammenhängen eingesetzt werden soll, plattformunabhängig sein. Das ist heute jedoch nur in begrenztem Umfang der Fall. Obwohl Komponenten unabhängig von objektbasierten Methoden und Techniken begriffen werden können, prägen doch hauptsächlich zwei Architekturen die Gestalt der Softwarebausteine: das Component Object Model (COM) von Microsoft und die Common Object Request Broker Architecture (Corba) vom Standardardisierungsgremium Object Management Group (OMG).
Das Corba-Datenmodell definiert Konzepte wie Vererbung, Aufruf und Schnittstelle. Ein Corba-Objekt repräsentiert die Instanz eines Schnittstellen-Typs, der Methoden festlegt, die auf seine Instanzen anwendbar sind. Objekte - Objektreferenz, Basistypen und zusammengesetzte Typen - entstehen und sterben aufgrund von Aufrufen. Ein solcher Aufruf (Request) besteht aus dem Methodennamen, dem Zielobjekt, Parametern und einem optionalen Kontext. Außerdem werden die Objekte durch globale, eindeutige Objektreferenzen identifiziert. Der ORB sendet den Aufruf an das Zielobjekt und liefert Ergebnisse oder Fehler.
Die Schnittstellen werden in der sprachenunabhängigen Interface Definition Language (IDL) beschrieben. Ein Interface enthält keine Datenelemente und kann mehrfach vererbt werden.
Die Komponenten- und Verteilungstechnologie Distributed Component Object Model (DCOM) von Microsoft ist die Basistechnologie von Active X. Sie definiert einen binären Standard für die Interaktionen von Komponenten, die mit Hilfe von Microsoft-Techniken erstellt sind. Dadurch ist DCOM weitgehend unabhängig von Programmiersprachen, jedoch nur bedingt von Plattformen. Die DCOM-Grundfunktionalität läßt sich über Data Link Libraries (DLLs) implementieren.
Wie beim OMG-Standard sind Objekte nur über Schnittstellen zugreifbar. Microsoft versteht unter Interfaces eine Sammlung von semantisch zusammengehörigen Methoden. DCOM-Objekte müssen mindestens eine Schnittstelle "IUnknown" besitzen. Von diesem Standard-Interface "IUnknown" sind alle Schnittstellen abgeleitet. DCOM kennt bei Binärkomponenten eine "Schnittstellen-Vererbung", jedoch keine klassenbasierte. Objekte können durch sogenanntes Containment und Aggregation andere Objekte enthalten.
Durch die Technik "Automation" ist ein dynamischer Zugriff auf Objekte beziehungsweise Active-X-Komponenten möglich. Automation-Objekte dienen zum applikationsübergreifenden Zugriff auf Funktionen und exportieren Methoden und Eigenschaften. Für den Aufruf solcher Objekte ist keine IDL notwendig, Visual Basic, Delphi und Visual J ++ reichen. Active X Controls sind Automation-Objekte mit zusätzlichen Schnittstellen.
CUC 97
In der vergangenen Woche fand die Component Users Conference (CUC), München, zum zweiten Mal statt. Rund 150 Teilnehmer hatten sich registriert. Sigs Conferences veranstaltete die Konferenz, Siemens, Interactive Objects und Take Five gehören zu den Sponsoren. Wer sich einen Überblick über Tools und Techniken für die komponentenbasierte Software-Entwicklung verschaffen wollte, durfte sich beim Konferenzprogramm, das hauptsächlich aus Firmenvorträgen bestand, gut aufgehoben fühlen. Projekt-Management und Praxisberichte kamen zu kurz.
Corba-Services
Zum OMG-Standard gehört bereits ein umfangreiches Service-Set*:- Naming: Es lassen sich Namensräume erstellen und Namen auf Objektreferenzen abbilden.- Lifecycle: Unterstützt das Erschaffen, Verändern, Kopieren, Bewegen und Entfernen von Objekten.- Events: Diese ermöglichen eine asynchrone Nachrichtenübermittlung.- Persistence: Der Service sichert dauerhaftes Speichern und Laden von Objekten.- Concurrency: Dadurch ist ein paralleler Zugriff auf Objekte durch Standardmechanismen wie Semaphore und Locks möglich.- Externalization: Der Service erlaubt den Export von Objekten auf externe Datenströme.- Relationship: Hiermit lassen sich 1:n- und n:m-Objektbeziehungen ordnen.- Transaction: Dieser Service sieht ein zweistufiges Commit für Transaktionen vor.- Licensing: Hierunter versteht man ein Framework zur Spezifikation und Verwaltung von Lizenz-Servern.- Query: Mit diesem Service lassen sich prädikatbasierte, deklarative Operationen auf Objektmengen aufführen.- Time: Um Uhren in verteilten Umgebungen zu synchronisieren, können Corba-Anwender diesen Service nutzen.- Security: Für viele Anwender ganz wichtig: der Service, mit dem eine Autorisierung und Kontrolle auf Objektebene möglich wird.- Properties: Darunter versteht man typisierte Attribute, die sich einem Objekt dynamisch zuordnen lassen.
*Die Aufzählung stammt aus dem CUC-Vortrag "Java und Corba von Michael Stahl.