DV-Fachleute, die Verantwortung für den reibungslosen und kosteneffizienten Betrieb von Informationssystemen tragen, können diesem Marketing-Gerangel nur mit Kopfschütteln zuschauen. Sie wissen, daß viele unternehmenskritische Systeme weder auf Corba noch auf DCOM beruhen, sondern transaktionsorientiert sind. Gerade die IT-Großanwender sind von ihren Systemen für Online Transactions Processing (OLTP) abhängig und setzen verteilte Systeme mit moderner Middleware lediglich ergänzend und für bestimmte Anwendungsbereiche ein. Es wird noch einige Zeit dauern, bis Object Broker OLTP-Systeme verdrängen.

Die Implementierung von komponenten- oder objektbasierten DV-Systemen kann nur auf Basis leistungsfähiger und standardisierter Kommunikationsmechanismen funktionieren. Diese ermöglichen zum einen die Zusammenarbeit zwischen Client-Komponenten und Servern und stellen zum anderen wesentliche Verwaltungsmechanismen zur Verfügung, die das System-Management vereinfachen sollen. Mit Corba und DCOM stehen zwei Implementierungsmodelle für diese Middleware-Schicht zur Auswahl. Beide sind in ihren jeweiligen Definitionsgrenzen leistungsfähig, beide bilden jedoch nicht die universelle Lösung in Sachen Middleware.

DCOM wird bei der Entwicklung von Komponenten mit Microsoft-Produkten besser unterstützt, Corba bietet in heterogenen und stärker objektbasierten Umgebungen die geeignetere Basis. Beide Technologien stehen auf verschiedenen Plattformen zur Verfügung, seien es die verschiedenen Object Request Broker wie SOM von IBM oder Orbix von Iona auf der einen oder die DCOM-Implementierung für Unix von der Software AG auf der anderen Seite. Beiden Techniken ist zudem gemein, daß es ohne das aktive Zutun des Anwenders kaum möglich ist, sie in vorhandene Systeme zu integrieren. Auf Basis der vorhandenen Klassenbibliotheken ist es nötig, individuelle Schnittstellen und Objekte gemäß der jeweiligen Middleware unterschiedlich zu entwickeln und die Methoden zu implementieren. Dieser unvermeidliche Entwicklungsaufwand kann zu vertretbaren Kosten nur für eine Middleware-Welt geleistet werden. Erst dadurch entsteht der Zwang, sich zwischen Corba oder DCOM zu entscheiden. Einen goldenen Mittelweg scheint es nicht zu geben.

Ein Ausweg aus diesem Dilemma könnte die Entwicklung eigener Kommunikationskomponenten bedeuten, mit deren Hilfe sich verschiedene vorgefertigte Middleware-Produkte integrieren und Schnittstellen zu den bereits vorhandenen Applikationen bereitstellen lassen. Erreicht wird dies durch die Verwendung von plattformunabhängigen Entwicklungssystemen.

Wer jedoch seine Middleware-Anbindung in Cobol oder C selbst entwickelt, arbeitet ineffizient. Selbst viele der mittlerweile etwas in die Jahre gekommenen 4GL-Systeme helfen hier nicht weiter. Abgesehen davon, daß sie teilweise keine oder nur geringe Möglichkeiten der Entwicklung von Objekten und Komponenten bieten, führen sie zur Herstellerabhängigkeit. Kein Anwender will heute Zeit in die Entwicklung von IT-Komponenten stecken, die anschließend nur auf bestimmten Plattformen in einer Runtime-Umgebung eingesetzt werden können, für die er auch noch Lizenzen zahlen muß.

Eine zukunftssichere Lösung zeichnet sich dadurch aus, daß

?plattformunabhängiger Metacode erarbeitet wird,

ødieser Code für die Zielplattformen generiert wird,

die generierten Lösungen als eigenständige Programme, Komponenten oder Objekte laufen,

Portabilität der Komponenten gewährleistet ist.

Die Vorteile moderner komponentenbasierter Anwendungsentwicklung liegen auf der Hand, denn einzelne Komponenten sind schnell entwickelt, insbesondere wenn das Entwicklungssystem die Basisarbeiten automatisch erledigt. Dazu gehört die Generierung von Schnittstellen zu anderen Anwendungskomponenten und natürlich zu den Middleware-Komponenten ê la ORB.

Einbindung von klassischen Anwendungen

Als Ergänzung zu praktisch beliebigen ORBs braucht es Kommunikationskomponenten, die über entsprechende Schnittstellen auch die Einbindung klassischer OLTP-Systeme, etwa über TP-Monitore wie Tuxedo, CICS oder Open UTM, erlauben. Dabei ist wichtig, daß klassische OLTP-Anwendungen und moderne Komponenten parallel eingesetzt werden können, weil verteilte Systeme schnell an Leistungsgrenzen stoßen. ORB-zentrierte Middleware ist für großvolumige Transaktionsverarbeitung nicht ausgelegt.

Komponentenbasierte Eigenentwicklung eröffnet zudem die Perspektive, mit geringem Aufwand für die verschiedenen Server- und Client-Applikationen Proxis zu generieren, die als Kommunikationsvermittler zwischen Komponenten, Objekten, monolithischen Anwendungen und der Middleware fungieren. Zum anderen lassen sich die vorhandenen Anwendungen per Wrapping mit modernen Kommunikations-Schnittstellen versehen. Sie werden dann im Gesamtsystem wie jedes andere Objekt behandelt. Zudem können per Wrapping die Altanwendungen für Endbenutzer-Clients mit dem gewünschten GUI-Erscheinungsbild erhalten.

Der entscheidende Vorteil für viele Anwender mag aber die Überlegung sein, daß mit einem komponentenbasierten Entwicklungssystem, wie es etwa die Delta Software GmbH, München, anbietet, die Freiheit besteht, heute diesen ORB und morgen jenen einzusetzen, falls bei der Entwicklung Verarbeitungslogik und Kommunikationsmechanismen so weit entkoppelt wurden. Dann lassen sich letztere jederzeit um Schnittstellen zu anderen ORBs oder um ganz neue Middleware-Komponenten ergänzen, ohne die Kernfunktionalität anrühren zu müssen.

Als optimal erweist sich ferner ein Entwicklungssystem, das selbst den Ansprüchen an Interoperabilität genügt, weil es vorhandene und von Anwendungsentwicklern beherrschte Entwicklunsgkomponenten (bestimmte Sprachen oder auch Werkzeuge) ebenso einbindet wie modernste Einzel-Tools, sie sich für manche Aufgaben besonders eignen (etwa Visual BASIC, um GUIs zu entwerfen).

Angeklickt

Es gibt mehrere Möglichkeiten für Anwender, auf die verunsichernden Diskussionen um DCOM oder Corba zu reagieren. Am besten ist es, so der Autor, sich mit Hilfe selbstentwickelter Middleware-Layer von herstellerspezifischen Produkten frei zu machen. Damit der Programmieraufwand dafür nicht zu groß wird, schlägt er den Einsatz von Middleware-Generatoren vor.

*Ren'e Purwin ist freier Fachjournalist in Friedberg/Hessen.