Viele Vorteile, die bereits aus der Objektorientierung bekannt sind gelten auch für Componentware. Sie läßt sich als die konsequente Fortführung der Software-Entwicklung bezeichnen: Entwickler können quasi wie aus einem Baukasten durch vorgefertigte Komponenten sehr schnell neue Programmsysteme zusammenstellen.
Komponenten von Fremdanbietern, die auf Basis der geltenden Standards DCOM (Distributed Component Objekt Model) oder Corba (Common Object Request Broker Architecture) implementiert wurden, lassen sich plattformübergreifend direkt einbinden. Damit sinken auch die Integrationskosten dramatisch.
Es ist wegen der vielen Querverweise innerhalb des programmierten Codes in der Regel teuer, zeitaufwendig und risikoreich, monolithische Softwaresysteme zu modifizieren. "Never change a running system" war lange eine Maxime. Handelt es sich hingegen um eine Komponentensoftware, geht dies ungleich schneller, da nur einzelne Bauteile verändert, getestet und neu implementiert werden müssen.
Der Standardanwender von Winword nutzt in der Regel lediglich 30 Prozent der angebotenen Funktionalitäten. Softwarehersteller neigen dazu, alle denkbaren Anforderungen in ihren Softwareprodukten abzubilden, um einen möglichst großen Kundenkreis anzusprechen. Da in der Regel Funktionalitäten nicht entfernt oder entsprechend den eigenen Anforderungen hinzugefügt werden können, ist die Folge häufig ein unübersichtliches, überladenes, monolithisches Softwaresystem. Komponenten dagegen lassen sich wie Bausteine sukzessive zu einem Gesamtsystem "zusammensetzen", das exakt den individuellen Anforderungen des Kunden entspricht.
Es liegt auf der Hand, daß Dokumenten-Management Unternehmen erst durch ein Workflow-System den vollen Wert bringt. Trotzdem schrecken viele Firmen vor einem solchen Projekt zurück, weil es in einer klassischen Umgebung sehr groß wäre. Componentware bietet die Möglichkeit, im ersten Schritt ein Dokumenten-Management-System mit einer Archivkomponente einzuführen. Erst nach ihrer Etablierung könnte man - und zwar im laufenden Betrieb - die Lösung um eine Workflow-Komponente und damit um ganz neue Funktionalitäten erweitern.
Die ansonsten so gefürchteten Probleme an den Schnittstellen treten hier nicht auf. Insbesondere für Anwendungen, die eine Querschnittsfunktion innerhalb des Unternehmens erfüllen, sind diese Vorteile ungleich gewichtiger als für isolierte Insellösungen, die keinen anderen Bereich tangieren. Das ist zum Beispiel bei Dokumenten-Management oder Workflow-Systemen der Fall.
Durchweg bestehen in den Unternehmen sehr heterogene, historisch gewachsene IT-Strukturen. Da arbeitet beispielsweise die Entwicklungsabteilung bereits mit Windows NT, während die Konstrukteure und die Dokumentation Unix-Terminals verwenden. Jeder Firmenbereich setzt seine eigene Software ein. Das Sharing von Funktionalitäten unter den Anwendungen ist beinahe unmöglich und der Datenaustausch nur mittels aufwendiger Schnittstellen-Programmierung möglich.
Softwarekomponenten, die nach den Standards DCOM oder Corba programmiert wurden, gestatten eine plattformübergreifende Zusammenarbeit. Gerade in Zeiten der Intranets beziehungsweise des Internet ist eine solche Integration über Plattformgrenzen hinweg erwünscht. Mittels solcher Komponenten können Legacy-Systeme plattformübergreifend Daten und Funktionen austauschen und beispielsweise über das Internet mittels Java-Beans oder Active-X-Controlls zur Verfügung stellen. So könnte in einem Data-Warehouse ein Layer von Komponenten Daten der einzelnen Legacy-Anwendungen sammeln und zusammenführen.
Als Quasistandards im Bereich Komponentensoftware haben sich DCOM von Microsoft und Corba von der Object Management Group (OMG) etabliert. Leider arbeiten beide Standards bisher noch nicht zusammen, was für die Zukunft allerdings angekündigt ist. Trotz gänzlich unterschiedlicher Konzeption bieten sie dem Anwender etwa gleiche Funktionalität.
Wie nicht anders zu erwarten, unterstützen Unternehmen wie Netscape und Sun, die ein eher verschnupftes Verhältnis zu Microsoft pflegen, den Standard Corba, während Firmen wie Fabasoft, SAP und Software AG Komponenten nach DCOM-Standard entwickeln. Die Mehrzahl der Firmen (so etwa Oracle) aber bieten Komponenten beziehungsweise Entwicklungs-Tools für beide an.
Nicht jeder Anbieter, der Komponentensoftware im Angebot führt, entwickelt jedoch nach einem dieser Standards. In der Regel handelt sich um proprietäre modularisierte Anwendungen, die nicht in der Lage sind, mit Komponenten anderer Hersteller plattformübergreifend zu kommunizieren. Es ist Vorsicht geboten, denn diese Produkte können die genannten Vorteile der Standards DCOM und Corba bei weitem nicht bieten.
Fundamentaler Bestandteil der Corba-Architektur sind die Object Request Brokers (ORBs), über die jeder Client und Server verfügen muß, um mit anderen Corba-Objekten zu kommunizieren. Die einzelnen ORBs tun dies untereinander über TCP/IP und das Internet Inter-ORB-Protokoll (IIOP).
Mittels ORBs hat man nicht nur Zugriff auf die Dienste der anderen Komponenten, sondern auch auf solche, die die Corba-Architektur bieten. Dazu gehören Naming-Services zur eindeutigen Identifizierung einzelner Komponenten, Event-Services zur asynchronen Kommunikation sowie Transaktionsdienste. Die einzelne Corba-Komponente kann sowohl als Client (Nutzung der Services anderer Objekte) als auch als Server-Objekt (stellt anderen Objekten Dienste zur Verfügung) agieren. Da Corba-Objekte verteilt auf einer Vielzahl von Systemen residieren können, spricht man von "multi-tiered" Applikationen.
Im Gegensatz zu DCOM verfügt Corba erst seit kurzem über Sicherheitsstandards. Viele Entwickler haben deshalb ihre eigenen Sicherheitsmechanismen implementiert. Ein weiterer Nachteil von Corba besteht darin, daß IIOP nicht direkt über Firewalls hinweg kommunizieren kann. Bisher diente dazu HTTP-Tunneling als Ersatz. Allerdings wird an einer Lösung gearbeitet.
Mit DCOM hat Microsoft eine effektive und einfach zu handhabende Komponententechnologie entwickelt. Sie unterstützt TCP/ IP, IPX/SPX, Apple-Talk, HTTP und "Named Pipes". Die Komponenten kommunizieren untereinander über Object Remote Procedure Calls (ORPC). Jedes COM-Objekt stellt bestimmte Services zur Verfügung, die andere COM-Objekte nutzen können.
Eine zentrale Rolle bei der Kommunikation zwischen den COM-Komponenten spielt die Component Object Library, die beispielsweise Bestandteil des Betriebssystems Windows NT 4.0 ist. Sie hat die Aufgabe, die gesuchten Komponenten aufzufinden und einen Pointer auf das entsprechende Objekt zu liefern, über den der Aufruf der gewünschten Methoden erfolgt. Für das Client-Objekt spielt es dabei keine Rolle, ob die Server-Komponente auf dem gleichen oder auf einem beliebigen anderen Rechner im Netz residiert.
Ebenso wie bei Corba wurde auf sprachenneutrale Entwicklungsmöglichkeiten Wert gelegt. Das heißt, Komponenten können beispielsweise unter MS VC++, MS Visual Basic, Powerbuilder oder MS J++/Java erstellt sein und trotzdem miteinander kommunizieren. Alle Active-X-Controlls unterstützen automatisch den DCOM-Standard und bieten den plattformübergreifenden Zugriff unter anderem mittels Internet-Browser.
DCOM bietet heute schon den Einsatz von Applikationen über das Internet, ohne daß kommunikationsspezifischer Sourcecode oder sonstige Zusätze nötig wären. Für verschiedene Unix-Derivate, MVS und OS/400 stehen Komponenten und Entwicklungs-Tools zur Verfügung oder sind bald zu erwarten.
Da in Zeiten des Internet der Netzwerksicherheit eine große Bedeutung zukommt, sind neben der NT-4.0-Security, Secure Socket Layers (SSL) und Kerberos als Sicherheitsmechanismen vorhanden.
DCOM integriert sich nahtlos in die Windows-Welt und wird somit innerhalb kürzester Zeit wesentlich weiter verbreitet sein als Corba. Heerscharen professioneller Entwickler verfügen über das nötige Know-how und erstellen Komponenten, die teilweise kostenlos zu haben sind.
Das Internet hat Technologien den Weg geebnet, die die Art und Weise, wie wir Computer nutzen, grundlegend verändern werden. Statt der traditionellen Client-Server-Netzwerke entstehen netzwerkzentrierte Systeme, deren einzelne Objekte auf verschiedenen Computern verteilt liegen, die unabhängig vom Betriebssystem, der Plattform oder der Programmiersprache miteinander kommunizieren können.
Und jedes einzelne Komponentenobjekt kann Bestandteil einer einzelnen oder eines Dutzend Applikationen sein. Im Zusammenspiel der Komponenten entstehen komplexe Softwaresysteme, die auf die speziellen Bedürfnisse des Anwenders zugeschnitten sind.
Der hohe Stellenwert, der der Komponenten-Technologie mittlerweile eingeräumt wird, zeigt sich an den neuesten Entwicklungen. SAP kündigte bereits den DCOM-Connector an, der für eine nahtlose und hochperformante Integration von DCOM und Business Application Programming Interfaces (BAPIs) sorgt; Oracle bietet mittlerweile Entwicklungswerkzeuge an, die beide Standards unterstützen.
Microsoft verkauft mit jedem NT-Server und -Client DCOM-Komponenten und das zugehörige Management-System gleich mit. Der Message Queue Server (Falcon) und Transaktions-Server basieren auf der DCOM-Komponententechnologie und kommunizieren über DCOM mit anderen Komponenten. Netscape hat die Corba-Technologie in jede Client- und Server-Software integriert und will mit Sun und IBM Corba Internet-weit etablieren.
Namhafte Hersteller von Dokumenten- und Workflow-Management-Applikationen haben erkannt, daß sie sich nur durch das komplette Re-Engineering ihrer Applikationen gegenüber komponentenbasierenden Systemen halten können. Für den Anwender und Kunden wird durch den Einsatz komponentenbasierter Software das Werkzeug DV zu einem angemessenen und wertvollen Erfolgsfaktor, der schnell verfügbar ist und trotzdem mitwächst.
Einige schöne Komponentenlösungen bieten 70 bis 90 Prozent der benötigten Funktionen "out of the box". Der Aufwand, um sie an die Bedürfnisse eines Unternehmens anzupassen, liegt effektiv bei zirka 30 Prozent gegenüber herkömmlicher Software.
Angeklickt
Derzeit erfährt Komponentensoftware einen bemerkenswerten Aufschwung. Einige Projekte belegen deutlich bessere Preis-Leistungs-Verhältnisse als mit herkömmlicher Software möglich. Die zur Zeit am Markt erscheinenden Komponenten lassen sich nahezu beliebig in andere Umgebungen integrieren - aber nur, wenn sie tatsächlich einem der zwei alternativen Middleware-Standards entsprechen. Der Preis und der Einführungszeitraum für leistungsfähige Software werden auf der Grundlage dieser Technologien in den nächsten Jahren dramatisch sinken, was den eher konservativ orientierten Softwareschmieden nicht unbedingt gefällt.
Eigenes und Gemeinsames
Ein Beispiel soll die Vorteile von Componentware veranschaulichen: Ein Unternehmen setzt im Vertrieb ein Sales-Management-System ein, das als Komponentensoftware konzipiert wurde. Dementsprechend arbeitet jeder Verkaufsbereich mit einer eigenen Softwarekomponente, die den jeweiligen individuellen Bedürfnissen angepaßt wurde. Da für alle Verkaufsbereiche jedoch dieselbe steuerliche Gesetzgebung gültig ist, wäre es nicht sinnvoll, fiskalische Funktionalitäten in die einzelnen Komponenten zu integrieren.
So greifen zur Berechnung von Steuerbeträgen alle spezifischen Anwendungen auf ein und dieselbe für diese Funktionalität zuständige Komponente zu. Ändert sich nun die Steuergesetzgebung, muß lediglich diese einzelne Komponente umprogrammiert, getestet und neu installiert werden, während alle anderen unverändert bleiben können.
Durch die Aufsplitterung der Funktionalitäten in diskrete Komponenten bieten sich kostengünstige und effiziente Möglichkeiten, Upgrades zu einzelnen Komponenten zu entwickeln und zu verteilen, ohne das ganze Softwaresystem anpassen zu müssen. Die Evolution einer Komponente ist also unabhängig von der Entwicklung anderer.
*Michael Gerhard ist Projekt-Manager, Christian Uhrig ist Geschäftsführer bei der Beratungsgesellschaft Dr. Böhmer, Uhrig & Partner in Dreieich.