Komponentensoftware wird sich als das richtungsweisende Konzept für zukünftige Softwarestrategien durchsetzen, glauben die Analysten der Ovum Ltd., London. Von heute drei Milliarden Dollar Umsatz für Tools, Services und Anwendungen soll der Komponentenmarkt im Jahr 2002 auf mehr als 60 Milliarden Dollar anschwellen. Wie der Titel "Componentware: Building it, Buying it, Selling it" verrät, soll die jüngste Studie der Marktforscher Anwendern, Anbietern und Dienstleistern gleichermaßen als Richtschnur dienen. Die Auguren stellen in ihrem mehr als 300 Seiten starken Werk Architekturen, Softwareplatt- formen, betriebswirtschaftliche Standardsoftware, Entwicklungs-Tools und Integrationsdienstleister vor.
Der Einsatz von Komponententechniken birgt laut Ovum sowohl für die Neuentwicklung als auch für die Verwendung bestehender Anwendungen Vorteile:
- Schon bei der Analyse und dem Design von Softwarebausteinen kann die Wiederverwendung geplant werden;
- die Schnittstellen zwischen Modulen werden transparent, Grenzen zwischen Anwendungen werden durchlässiger, auch für Drittanbieter;
- Altanwendungen lassen sich kapseln und weiter betreiben;
- es ist oft leichter, Altanwendungen mit Komponenten-Tools zu sanieren, als auf der grünen Wiese mit objektorientierten (OO) Werkzeugen neu zu starten.
Anwender sollten sich laut Ovum bei der Auswahl von Werkzeugen nicht der strengen OO-Lehre unterwerfen, sondern pragmatisch vorgehen. Entscheidend sei schließlich, daß die Softwaremodule nach der Kompo- nentisierung über saubere Schnittstellen verfügten und sich so für einen Zugriff öffneten. Um in den Genuß dieser Vorzüge zu kommen, sei es unerheblich, ob die Applikationen mit Hilfe objektorientierter Methoden oder nach klassischen prozeduralen Ansätzen gebaut sind. Für viele stabil laufende Legacy-Applikationen steigt damit die Überlebenschance.
Die Analysten warnen jedoch davor, sich bei der Wiederverwendung von Softwaremodulen allein auf technische Hilfsmittel zu verlassen. Die praktische Anwendung habe gezeigt, daß zusätzlich ein hohes Maß an Organisation wie Projekt-Management erforderlich ist. Selbst für die Objekt- oder Komponentenverwaltung, die mit Hilfe von Tools unterstützt werde, müssen Mitarbeiter verantwortlich sein. Ansonsten kann das Komponenten-Management schnell in ein Chaos ausarten. Der Nachweis, ob es überhaupt wirtschaftlicher ist, einen Baustein wiederzuverwenden anstatt ihn neu zu entwickeln, müsse sowieso im Einzelfall erbracht werden.
Den stärksten Schub für die Verbreitung von Komponentensoftware leisten Anbieter von Enterprise-Resource-Planning-(ERP-)Systemen: Softwareschmieden wie SAP, Baan und Oracle zerlegen ihre monolithischen Anwendungen in handlichere Module. Zwischen den einzelnen Bausteinen entstehen Schnittstellen in Komponentenmanier, deren Spezifikation Partnern und Kunden zugänglich ist.
Seit kurzem stellt beispielsweise die SAP AG ihre Personalwirtschaftslösung "Human Resources" (HR) als separate Einheit lose gekoppelt mit dem Kernsystem R/3 zur Verfügung. Die Bottom-up-Bewegung von Komponenten-Tools-Anbietern wie Select, Sterling und Inprise (ehemals Borland) leistet ebenfalls einen Beitrag zur stärkeren Verbreitung (siehe Tabelle "Tools im Vergleich" auf Seite 14).
Verbunden mit Komponententechnik ist unweigerlich die Frage nach der zugrundeliegenden Architektur. Die Ovum-Analysten nennen drei Trends: Microsofts Component Object Model (COM), Suns Javabeans und die Common Object Request Broker Architecture (Corba) der OMG. Bei letzterem handelt es sich allerdings um ein theoretisches Modell, in dem Empfehlungen ausgesprochen werden, wie Anbieter eine Komponentenarchitektur und dazugehörige Tools und Anwendungen zu bauen haben. Object Request Broker von Firmen wie Iona oder Inprise entsprechen diesen Standards. COM und Javabeans dagegen sind Implementierungen und als Softwarebausteine verfügbar.
Die Auguren kommen zu dem Schluß, daß sich COM aufgrund seiner starken Präsenz durch Microsofts Desktop-Programme behaupten wird. Gleichzeitig werde sich jenseits der Microsoft-Welt Corba als Architekturmodell durchsetzen. Corba zeichnet sich nach Meinung der Auguren durch seine Plattformunabhängigkeit aus. Der zur Zeit hochstilisierte Kampf zwischen Javabeans und COM ist laut Ovum kein wirklicher Architekturstreit, denn das Sun-Konzept ist zwar plattformunabhängig, lebt aber einzig und allein von der Programmiersprache Java. Und diese werde niemals zur einzigen Entwicklungssprache werden. Laut Ovum wird die OMG das Javabeans-Konzept in der Corba-Spezifikation mit berücksichtigen. Das Gremium werde aber auch Services definieren, die über den Leistungsumfang der Sun-Technik hinausgehen.
Corba kann mehr als Javabeans
Die Corba-Festlegungen in der Version 3.0, die Ende des Jahres erwartet wird, werden auch weiterhin hersteller- und plattformneutral ausgerichtet sein, allein um ein Gegengewicht zu COM zu bilden. Der Seitenhieb der Auguren in Richtung Microsoft fehlt hier natürlich nicht, denn COM ist bislang ausschließlich in der Betriebssystem-Welt der Gates-Company zu Hause. Die Software AG ist derzeit zwar bemüht COM auch auf Unix-Plattformen anzubieten. Zur Marktrelevanz dieser Lösungen äußern sich die Auguren allerdings nicht.
Eines ist den Ovum-Autoren Katy Ring und Neil Ward-Dutton jedenfalls klar: Die essentiellen Bestandteile der unterschiedlichen Techniken, zu denen die Schnittstellen-Beschreibungssprachen gehören, werden sich künftig gut verstehen können. Ganz gleich, ob Anwender auf COM mit der dazugehörigen Interface Definition Language (IDL) von Microsoft schwören oder Corba-Verfechter sind: Über sogenannte Bridges werden beide Glaubensbekenntnisse bis spätestens 2001 zusammengewachsen sein. Ein Miteinander unterschiedlicher Anwendungen, egal ob sie in COM oder Corba realisiert sind, ist dann möglich.
Achten sollten Anwender darauf, daß ein Anbieter von Ablaufumgebungen für Komponentensoftware (Component Execution Plattforms = CEP), ein Entwicklungs-Tools-Lieferant oder auch der Hersteller von Standardsoftware einen der beiden Standards unterstützt. Zumindest sollte man sich ein Konzept vorlegen lassen, in dem deutlich wird, welcher Standard berücksichtigt wird.