Auf der Basis von offenen und proprietären Standards

Konzepte und Plattformen für Componentware

10.10.1997

Bei Komponenten handelt es sich im wesentlichen um gekapselte Software-Objekte oder Spezifikationen zu ihrer Erstellung. Sie stellen einen Dienst zur Verfügung. Im Zusammenspiel mit anderen Komponenten lassen sich komplette Softwaresysteme erbauen. Die einzelnen Software-Einheiten sind unterschiedlich granular. Die Spanne reicht von den einfachen, grafischen Bedienelementen bis hin zu komplexen Business-Modulen.

Eine Eigenschaft zeichnet jedoch alle Komponenten aus: Sie lassen sich durch Kapselung wiederverwenden. Der Grad der Wiederwerwendbarkeit erhöht sich, wenn die Komponenten den bekannten Regeln der objektorientierten Programmierung wie Vererbung und Polymorphismus gehorchen.

Komponenten beinhalten Möglichkeiten, ihren Zustand zu beeinflussen, ihre Erscheinungsweisen sowie Verbindungen und Beziehungen zu anderen Programmteilen und Daten. Diese Geschlossenheit wird durch öffentliche Methoden (Interfaces) und Attribute (Properties) erreicht. Komponenten kommunizieren miteinander. Sie reagieren auf Ereignisse (Events). Zustand und Daten lassen sich über die Lebensdauer ihres Prozesses hinaus verfügbar machen. Dieses Prinzip nennt sich Persistence.

Paradigmenwechsel in der Entwicklung

Neben der Abkehr von Softwaremonolithen hin zu Anwendungen, die aus einer variablen Menge an Bausteinen und Funktionen bestehen, lassen sich weitere Programmiertrends ausmachen: Heterogene Programmiersprachen und Entwicklungsumgebungen, lokale und entfernte Datenhaltung sowie verteilte Anwendungssysteme kennzeichnen die Ansprüche an heutige Systeme.

Componentware stellt ein Konzept zur Verfügung, das diesen Paradigmenwechsel im Software-Management unterstützt. Kennzeichnend für Componentware ist eine fast durchweg grafische Entwicklung durch die Kombination verschiedener Komponenten, deren Interaktion mittels einer (Script-)Sprache, wie Visual Basic, Lotusscript, Javascript und Perl realisiert wird. Der Einsatz von standardisierten Schnittstellen und wiederverwendbaren, getesteten Komponenten bietet die Möglichkeit der schnellen und qualitativ hochwertigen Anwendungsentwicklung sowie einfache Änder- und Erweiterbarkeit.

Frameworks für Softwarekomponeneten

Eine Componentware-Umgebung ist per se ein System mit beliebig vielen Freiheitsgraden. Dies kann aus dem wissenschaftlich-experimentellen Blickwinkel heraus interessant sein. Für die Praxis empfiehlt sich jedoch eine Componentware-Plattform. Solche Plattformen stellen Basisdienste bereit. Diese lassen sich von den Komponenten nutzen und müssen nicht erst implementiert werden. Dazu gehören Services für den Transport, die Kommunikation, die Sicherung und die Datenhaltung.

Außerdem fungiert die Componentware-Plattform als Leitprodukt des Gesamtsystems. Sie liefert einen Rahmen mit aufgabenspezifischen Funktionen.

Je nach Ausprägung unterscheidet man konkrete von abstrakten Plattformen. Im ersten Fall wird ein dominantes Softwareprodukt eingesetzt, zum Beispiel ein Dokumenten-Management-System, im zweiten entscheiden sich die Anwender etwa für eine Gruppe von Standards wie die Common Object Request Broker Architecture (Corba) der Object Management Group (OMG).

Die Methode "Design-for-Component" beschreibt die Sicht des Komponentenproduzenten. Der Fokus liegt hier auf der Komponente als Endprodukt. Die Komponente kapselt das Fachwissen der Entwickler. Mit ihr läßt sich eine spezifische Aufgabe lösen. Bei der Entwicklung berücksichtigen die Softwaredesigner die Zielumgebungen sowie problemrelevante Maßgaben.

"Design-from-Component" spiegelt hingegen die Sicht der Käufer wider, die ihre komplexen Anwendungssysteme vor Augen haben.

Durch die Aggregation bereits erstellter Komponenten, mit Hilfe der Framework-Dienste sowie einer Script-Sprache entstehen aufgabenspezifische Anwendungskompositionen. Das Ergebnis dieser Software-Montage kann ein vollständiges Anwendungssystem sein oder eine komplexe Komponente, die sich mehrfach verwenden läßt.

Im Gegensatz zu den beiden ersten Verfahren befaßt sich "Design-to-Component" mit der Migration von monolithischen Altumgebungen zu Componentware-basierten Lösungen. Anhand von Re-Engineering-Methoden wird bestehende Software auf Modularisierungsmöglichkeiten untersucht. Nach einem solchen Zerschlagen der Altanwendung können die Bausteine nach den Regeln des Design-for-Component neu entwickelt werden. Als ein typisches Beispiel einer solchen Vorgehensweise kann das Anwendungspaket "Corel Office für Java" gelten.

Auch größere Altanwendungen, bei denen eine Migration aus Kostengründen nicht sinnvoll erscheint, lassen sich kapseln und als Komponente anbieten. Auf diese Weise wirken Host-basierte Cobol-Anwendungen, die mit einem OLE-Wrapper versehen werden, nach außen wie ein OLE-Objekt und stellen nach innen eine Terminalemulation dar.

Componentware setzt sich aus vier Schichten zusammen (siehe Abbildung). Die erste enthält den Rohstoff späterer Anwendungen: Klassenbibliotheken und Objektsammlungen, deren feine Granularität und relativ niedriger Abstraktionsgrad ein hohes Wiederverwendungspotential garantieren. In diese Componentware-Kategorie gehören etwa die 3GL-Bibliotheken Visual C++, C++-Builder und Smalltalk, proprietäre Klassenbibliotheken im Verbund mit 4GL-Entwicklungsumgebungen von Forté und Dynasty sowie Objektsammlungen. In die zweite Schicht gehören Komponentenmodelle wie Active X und Javabeans.

Die Basis für die Entwicklung komponentenbasierter Anwendungen legen Objektmodelle. Sie beschreiben die Kommunikation zwischen den Komponenten unabhängig von dem Adreßraum, von Rechner- und Betriebssystem-Grenzen sowie der Programmiersprache, in der sie implementiert wurden. In dieser Schicht haben sich das Component Object Model (COM) von Microsoft und Corba-konforme Implementierungen unterschiedlicher Hersteller etabliert. Beide Modelle trennen die Implementierung vom Interface, um Sprachunabhängigkeit zu erreichen.

Dokumentenmodelle ergänzen die Objektmodelle. Sie beschreiben die Integration der Komponenten in die Anwendung und stellen für den Benutzer einen einheitlichen Behälter für Daten und den dazugehörigen Bearbeitungsprogrammen dar. Microsoft verfügt in diesem Breich mit Object Linking and Embedding (OLE) über einen De-facto-Standard. Demgegenüber positioniert CILabs Opendoc als offenen Standard. Dieser konnte sich trotz Verfügbarkeit auf mehreren Plattformen am Markt jedoch nicht durchsetzen.

Die Kooperationsschicht bilden Systeme und Strukturen aus den Bereichen Messaging, Groupware, Datenbanken, Workflow und Dokumenten-Management. Kennzeichnend für den Componentware-Charakter ist auch hier die Modularität der Programme sowie die Unterstützung von diversen Standards wie MAPI, HTML, WfMC, ODMA und SQL. Neben spartenspezifischen Diensten bieten die Systeme Schnittstellen für Funktionserweiterungen sowie eigene Abfrage- und Scripting-Sprachen.

Produkte und Komponenten, die der Bearbeitung von komplexen betrieblichen Abläufen und Geschäftsprozessen dienen, setzen als Aufgaben-Layer auf den darunterliegenden Schichten auf. Hier finden sich Applikationssammlungen und Branchenlösungen wie SAP R/3 oder Standards wie BAPI, Healthcare7 und EDI, daneben aber auch Bürokommunikationslösungen. Als potentielle Componentware-Plattform besitzen sie häufig eine eigene Entwicklungsumgebung, die die Möglichkeit der Integration von Komponenten bietet und die Entwicklung eigener Komponenten erlaubt.