Schon vor Jahren hat sich die damals noch boomende DV-Branche auf die Suche nach Märkten begeben. Nachdem sich KI und CIM als Flops erwiesen, richtet sich die Hoffnung der Anbieter jetzt auf die Objekttechnik. Die Möglichkeit, die damit erstellten Softwaremodule wiederzuverwenden, soll ihnen helfen, über niedrigere Entwicklungskosten bei den Innovationsschüben mitzuhalten, die sie in immer kürzeren Abständen bedrängen. Lassen sich die Kunden auf diesen Trend ein, dann könnte das die gesamte Datenverarbeitung revolutionieren - und den Herstellern aus der Absatzmisere heraushelfen. Aber auch die Anwender können profitieren. Sesha Pratap, als Chairman der Centerline Software Inc. und als Vorstandsmitglied der Object Management Group (OMG) ein intimer Kenner der Entwicklungen in diesem Bereich, stellt den Anwendern eine offene DV-Zukunft ohne Herstellerabhängigkeit in Aussicht. Um den Anschluß nicht zu verlieren, sind inzwischen, so Pratap im Gespräch mit den CW-Redakteuren Karin Quack und Hermann Gfaller, selbst Anbieter wie die IBM bereit, ihre Schnittstellen und Protokolle offenzulegen.
CW: Lange Zeit galt die Programmierung als die eigentliche Domäne der Objekttechniken. Wie geht es dort in den kommenden Jahren weiter?
Pratap: Ich sehe zwei Trends. Erstens: Immer mehr C-Programmierer wollen C + + benutzen. Das heißt nicht, daß sie objektorientiert entwickeln, denn Sie verwenden C + + wie ein besseres C. Diese Entwicklung ist insofern von großer Bedeutung, als diese Käuferschicht dafür sorgt, daß C + + gestärkt wird und nicht Smalltalk oder Eiffel die Programmiersprachen der Zukunft sind.
Zweitens: Vor allem im Umfeld von Sun steigt die Anzahl der Entwickler, die wirklich objektorientiert arbeiten wollen. Auch diese Gruppe verwendet eher C+ + als Smalltalk oder Eiffel. Obwohl diese Gruppe nicht viel mehr als etwa 15 bis 20 Prozent der Unix-SW-Entwickler ausmacht, interessieren sich diese Leute vor allem für komplette OO-Entwicklungsumgebüngen, für Class-Libraries und Tools für die Erstellung von grafischen Benutzeroberflächen. Hier entsteht ein umfangreicher Tool-Markt. Richtig lukrativ wird dieses Geschäft aber erst in ein bis zwei Jahren.
Selbst erfahrene Programmierer brauchen mindestens ein halbes Jahr, bis sie mit den objektorientierten Denkweisen vertraut sind. Danach müssen sie ihre neuen Kenntnisse an einem kleineren Projekt erproben. Erst dann sind Entwickler und Sprache für das Unternehmen eine wertvolle Hilfe.
CW: Es heißt, daß es bei der Software-Entwicklung nicht darauf ankommt, in welcher Sprache programmiert wird. Um den Methoden-Guru Larry Constantine sinngemäß zu zitieren: "Man kann auch in Cobol objektorientiert programmieren und umgekehrt mit Smalltalk konventionelle Software erstellen."
Pratap: Da hat er völlig recht. Das ist der Grund, warum die meisten Anwender heute mit C+ + konventionelle Programmentwicklung betreiben. Weil wir das wissen, empfehlen wir, über die konventionelle C + +-Entwicklung sukzessive auf OOP umzusteigen. Trotzdem muß Larry Constantines Statement insofern eingeschränkt werden, als es sehr schwierig ist, objektorientierte Cobol-Programme zu schreiben. Mit Smalltalk geht das weit einfacher.
CW: Streiten sich die Eiffel-, Smalltalk- und C + + -Freaks eigentlich immer noch um die reine objektorientierte Lehre?
Pratap: Diese Auseinandersetzung läuft noch, aber es gibt inzwischen einige Anzeichen, die darauf schließen lassen, daß C + + als Sieger hervorgehen wird. So dominierten vor drei Jahren Smalltalk und universitäres Publikum die Oopsla-Messe. Vor zwei Jahren nahm C + + bereits etwa 30 bis 40 Prozent der Präsentationen ein, im vergangenen Jahr zeigten mehr als die Hälfte der Aussteller C+ +, und in diesem Jahr hat der C-Nachfolger eindeutig dominiert. Das liegt nicht daran, daß C + + die beste objektorientierte Sprache ist. Object-C, das auf den Next-Rechnern eingesetzt wird, ist zum Beispiel viel besser, aber es wird weit weniger oft verwendet.
CW: Als das Kürzel "OO" vor zwei Jahren auftauchte, war damit vor allem die objektorientierte Programmierung gemeint. Heute dagegen spricht die Industrie ganz allgemein von objektorientierten Techniken. Wie ist dieser Umschwung zu deuten.
Pratap: Heute gibt es kein Gebiet mehr, auf dem sich der Trend zu Objekttechniken nicht bemerkbar macht. Vor zwei Jahren war Objektorientierung lediglich etwas für Programmierer. Diese Situation hat sich geändert, als die Hardware-Anbieter und Microsoft angekündigten, daß sie dabei seien, Betriebssysteme auf objektorientierter Basis zu entwickeln.
Inzwischen sind auch die Netzwerk- und Communications-Anbieter auf die OOP-Techniken eingestiegen. Kurz: In wenigen Jahren werden nicht nur die Betriebssysteme objektorientiert sein, sondern die gesamte DV-Umgebung, die gesamte Industrie. Die Anbieter haben durch den Erfolg der Programmiersprachen gemerkt, wie wichtig Objekt-Techniken sein können, und sind nach und nach auf diesen Zug aufgesprungen.
CW: Wo liegen denn diese sagenhaften Vorteile - abgesehen von der Wiederverwendbarkeit von Softwaremodulen?
Pratap: Ich glaube eher, daß es sich dabei um einen natürlichen Prozeß handelt. Vor 20 Jahren waren Funktionen und Daten noch vermischt, die Programme liefen völlig unstrukturiert ab - ganz einfach vom Anfang bis zum Ende.
Die große Wende kam, als einige Forscher der Industrie klarmachten, daß es sinnvoll ist, strukturiert vorzugehen und Daten, Funktionen sowie Text zu trennen. Die Folge waren Methoden wie Structured Analysis und Structured Design, aber auch das Relationenmodell.
Die nächste wichtige Veränderung findet derzeit durch die Objektorientierung statt. Dabei werden Funktionen und Daten, die zusammenarbeiten müssen, in Objekten verbunden. Das ist bereits Realität. Was jetzt ansteht, sind verteilte Objekte, man kann sagen Miniprogramme, die frei mit anderen Objekten in einem Netzwerk kommunizieren können. Aber bevor das Wirklichkeit wird, müssen Betriebssysteme, Netzwerksysteme und Objekt-Layers auf den Markt kommen, die diese Funktionalität unterstützen.
CW: Worin besteht denn aus der Sicht der Objekttechniker der Unterschied zwischen Datenbank- und Betriebssystem?
Pratap: Das ist gar nicht so einfach zu beantworten. Ich muß ausholen: Objektorientierte Datenbanksysteme haben zwei Anwendungen. Die eine besteht darin, datenbankbasierte Programme zu schreiben. Die andere ist die Anwendung als Betriebssystem-Komponente.
Heute verwenden die Benutzer strukturierte Programmiersprachen wie C, relationale Datenbanksysteme mit SQL und dateiorientierte beziehungsweise Netzwerk-Betriebssysteme. Programmiersprachen und Datenbanksysteme auf der Grundlage der Objekttechniken gibt es bereits.
In Kürze ist auch der Object Request Broker von der Object Management Group marktreif, der eine Reihe von Netzwerkaufgaben übernimmt. Und bis 1995 wird es objektorientierte Betriebssysteme geben, in denen Repository-änliche Funktionen genausogut für persistente Datenbestände sorgen wie spezialisierte Datenbanksysteme.
CW: Diese Beschreibung künftiger Betriebssysteme klingt sehr vage...
Pratap: Man muß sich Betriebssysteme vorstellen, die die bisherigen Dateisysteme durch eine Art objektorientiertes Datenbanksystem ersetzen. Insofern dürfte sich die Grenze zwischen Betriebssystem, Datenbank und Netzwerk immer mehr verwischen. Es wird dann weniger von Betriebssystemen als von DV-Umgebungen die Rede sein.
CW: Wie reagieren die Datenbankanbieter auf diese Entwicklung?
Pratap: Ein Datenbankprodukt besteht aus der Applikation und dem Management-System. Was jetzt zum Beispiel Oracle macht, ist, eine Objektschicht oder ein Objektprotokoll zwischen Anwendung und Datenbank einzusetzen, durch die es möglich wird, objektorientierte Anwendungen zu integrieren. Die Daten bleiben weiterhin relational gespeichert.
Diese Vorgehensweise verstößt allerdings sowohl gegen das reine Relationen-Modell als auch gegen die objektorientierte Lehre. Für den Anwender bedeutet sie Leistungsverlust. Deshalb wird die Entwicklung weitergehen: In etwa drei Jahren werden objektorientierte Anwendungen auf Objektdatenbanken zugreifen.
CW: Inwieweit sind die Anwender bei der Verwendung von Objekten auf objektorientierte Datenbanken und Betriebssysteme angewiesen?
Pratap: Das kommt darauf an. Es gibt schon heute eine ganze Reihe von Anwendungen, bei denen sich Objekttechniken problemlos einsetzen lassen. Denken Sie zum Beispiel an Benutzeroberflächen. Der Interface-Builder für die Next-Oberfläche arbeitet fast ausschließlich mit Objekttechniken.
Auf anderen Gebieten dagegen braucht man entweder ein objektorientiertes Betriebssystem oder muß eine Klassenbibliothek schreiben, die Objekte aufnehmen kann. Aber es ist sehr schwierig, solche Bibliotheken selbst zu erstellen. Außerdem gibt es hier das Standardisierungsproblem.
CW: Welchen Stellenwert haben hier die Bemühungen der Object Management Group?
Pratap: Die OMG spielt eine zentrale Rolle. Nach der Definition eines Object Request Broker für den netzweiten Datenverkehr zwischen heterogenen Systemen arbeitet das Gremium an einem allgemeinen Datenmodell, das sowohl vom Betriebssystem als auch von der Datenbank benutzt werden soll. Außerdem ist ein allgemeines Objektmodell in Arbeit, das definiert, auf welche Weise und über welche Schnittstellen Objekte miteinander kommunizieren.
CW: Entwickelt die OMG auch Standards für objektorientierte Betriebssysteme?
Pratap: Nein. Bisher arbeitet die OMG ausschließlich mit Modellen, die auf dem Betriebssystem aufsetzen. Object Request Broker und Objektmodell sind das, was heute Middleware heißt. Darüber liegt die Anwendung.
Um ein Beispiel zu nennen: Wenn ein Programm ein Datenobjekt braucht, dann wird der Request Broker davon unterrichtet. Anhand des Naming-Services findet er heraus, wo sich das Objekt im Netz befindet, und schickt eine Nachricht dorthin, um das Objekt aufzurufen. Das geschieht automatisch, so daß weder der Entwickler des Programms hier irgend etwas kodieren noch der Anwender aktiv werden muß.
CW: Das klingt nach einer ausgesprochen hohen Netzbelastung.
Pratap: Das ist in der Tat ein Problem, und es wird sich noch verschärfen, denn in wenigen Jahren wird es nicht nur verteilte Daten, sondern auch verteilte Anwendungen und verteilte Objekte geben.
CW: Dafür müßten aber die Anbieter ihre Schnittstellen und Protokolle offenlegen. Wie bringt man sie dazu?
Pratap: Das zu erreichen ist die Aufgabe der OMG. Wenn Sie sich die Mitgliederliste dieser Organisation anschauen, so gehören fast alle Hardwarehersteller dazu. Sie haben begriffen, daß sie den Einstieg in die objektorientierten Techniken nur dann schaffen, wenn sie sich über Schnittstellen und Protokolle einigen können. Und seit sich die OMG um Klassenbibliotheken kümmert, sind auch die Softwareanbieter mit von der Partie. Die Entwicklung eines objektorientierten Datenmodells hat die Datenbankanbieter in die Organisation gebracht.
CW: Das klingt so, als ob hier absolut offene Systeme entstünden. Demnach wird es den Herstellern künftig unmöglich sein, Kunden über proprietäre Features an ihre Produkte zu ketten.
Pratap: Richtig. Wenn die Anwendung den Objekt Request Broker unterstützt, dann ist es im Prinzip gleichgültig, welcher Rechner und welches Betriebssystem eingesetzt werden.
CW: Wenn das so ist, welches Interesse können dann Hersteller wie die IBM haben, in einer solchen Organisation mitzuarbeiten?
Pratap: Wenn sie es nicht tun, bleiben sie hinter der Entwicklung zurück. Erinnern Sie sich daran, was im Open-Systems-Bereich geschehen ist. Niemand hat sich dafür interessiert, bis Sun unter diesem Motto eine Drei-Milliarden-Dollar-Company geworden ist. Inzwischen agieren sämtliche Konkurrenten ebenfalls im Open-Systems-Markt und verursachen Sun einiges Kopfzerbrechen.
Was ich damit sagen will, ist, daß die Hersteller keine Wahl haben. Sie müssen bei den Objekttechniken mithalten, und sei es nur, damit die Kunden nicht zur Konkurrenz überlaufen.
CW: Hersteller wie Sun prophezeien, daß ein Software-Industriezweig entstehen wird, der ausschließlich von der Entwicklung neuer Objekte lebt. Stützen Sie diese Prognose?
Pratap: Eigentlich nicht. Natürlich wird es eine Reihe neuer Unternehmen geben, die eine Palette mit Objekten für verschiedene Funktionen herausgeben. Aber das bleibt eine Nische.
Vielmehr werden die Softwareanbieter ihre Produkte mit Objekteigenschaften ausstatten. So dürfte möglicherweise - um ein Beispiel zu nennen - Lotus 1-2-3 in fünf Jahren aus Objekten bestehen und verteilt auf heterogenen Systemen laufen.
Für die Anwender hat das den Vorteil, daß sie ihr System mit dem Zukauf von Modulen schrittweise erweitern können, während sie heute bei Komplettprodukten Funktionen mitbezahlen, die sie gar nicht brauchen.