Am Ende der proprietaeren DV-Aera sucht die IBM nach Techniken, die ihr ein Ueberleben in einer Welt der heterogenen Umgebungen sichern. Helfen soll dabei vor allem das als Distributed System Object Model (DSOM) bezeichnete hauseigene Konzept fuer verteilte Datenverarbeitung. Hier unternimmt IBM jedoch keineswegs einen seiner gefuerchteten Alleingaenge, sondern verwendet eine als offener Standard geltende Objekt-Technik, wie sie aehnlich auch von allen Konkurrenten eingesetzt wird.

Anliegen der objektorientier- ten Methode ist es - bei stets wachsenden Anspruechen an die Software - die Komplexitaet der Programme moeglichst gering zu halten. Es werden die als Objekte bezeichneten Einheiten von Daten und Programmen gebildet, die moeglichst unabhaengig voneinander sein sollen. Die Daten des Objekts stellen den Zustand des Objekts dar, die Programme, im Fachjargon: Methoden, bestimmen sein Verhalten. Weil Objekte die reale Welt nachbilden, ist der auf diese Weise erstellte Software- Code in der Regel leichter zu verstehen.

Auch die IBM arbeitet seit laengerer Zeit mit derartigen objekt- orientierten Techniken. So ist die Workplace Shell des Betriebssystems OS/2, 2.0 nach einem IBM-Konzept erstellt, das die Bezeichnung "System Object Model" (SOM) traegt. Dieses Modell ist aber auch allgemein fuer die Schaffung von Anwendungen vorgesehen.

Objektklassen in binaerer Form

Das Spezifische an SOM ist, dass die Methoden in unterschiedlichen Programmiersprachen kodiert werden koennen. Dabei kommen neben objektorien- tierten Sprachen auch die herkoemmlichen prozeduralen Programmierumgebungen in Frage. Durch diese Eigenschaft unterscheidet sich SOM von allen anderen kommerziell angebotenen Systemen.

Die Flexibilitaet von SOM ruehrt daher, dass die Objektklassen in binaerer Form realisiert sind. Dies bedeutet auch, dass sich aeltere Klassen durch neuere Versionen ersetzen lassen, ohne dass die anderen bestehenden Klassen davon beruehrt werden, solange das Interface der Klassen unveraendert bleibt. Wird dagegen die neue Version einer C++-Klassenbibliothek freigegeben, so sind alle vorhandenen Anwendungsprogramme neu zu kompilieren. SOM eignet sich daher besonders zur Integration von Klassenbibliotheken.

Die Programmierer koennen in der Sprache arbeiten, die ihnen vertraut ist. Allerdings muessen fuer SOM-Methoden einige spezielle Syntax-Regeln eingehalten werden. Beim urspruenglichen SOM ist die Moeglichkeit, unterschiedliche Programmiersprachen zu benutzen, aber noch nicht realisiert; als Programmiersprache wird vielmehr nur C unterstuetzt.

SOM enthaelt zur Erstellung grafischer Oberflaechen sogenannte WPS- Klassen. Ein Beispiel fuer die Anwendung dieser Klassen ist die Workplace Shell von OS/2 2.0. Alle Symbole, die auf dem Workplace von OS/2 angezeigt werden, sind mit SOM und den WPS-Klassen erzeugt.

Klassen werden in einer von der einzelnen Programmier- sprache unabhaengigen aber SOM-spezifischen Form definiert. Solche Festlegungen enthalten im Wesentlichen folgende Angaben:

- Klassenname,

- Unmittelbare Parent-Klasse, da in der naechsten Version von SOM mehrfache Vererbung unterstuetzt werden soll (Alle Klassen muessen eine uebergeordnete Parent-Klasse haben. Existiert keine Parent- Klasse mehr, so wird der Klasse ein SOM-Object als Parentklasse zugewiesen. Dabei handelt es sich um eine Klasse, die Teil des SOM-Systems ist.),

- Datenfelder, die in den Objekten der Klassen vorhanden sind, und

- Methoden, welche die Objekte der Klasse ausfuehren koennen (Es sind jeweils der Name der Methode und die Namen der Parameter anzugeben und deren Datentypen).

Die Objekte, die in unterschiedlichen Programmiersprachen geschrieben sind, koennen sich nicht nur gegenseitig Nachrichten senden, sondern auch in Vererbungs- und Teilebeziehungen zueinander stehen. Grundlage dafuer sind die im Vorigen beschriebenen von der Programmiersprache unabhaengigen Klassendefinitionen. Die Teilebeziehung wird dabei dadurch realisiert, dass auch SOM-Klassen als Datenfeldtypen in der Klassendefinition vorkommen koennen.

Die Systemklassen des SOM-Systems

Jede Klasse ist ein Objekt des SOM-Systems, die wiederum Methoden zur Erstellung von Objekten der jeweiligen Klasse enthalten. Ausserdem unterstuetzen sie Methoden, mit welchen Informationen ueber die Klasse eingeholt werden koennen. Dabei handelt es sich um Angaben wie zum Beispiel die Groesse des Speicherplatzes, die ein Objekt der Klasse belegt, die Parent-Klasse, und, ob die Klasse eine bestimmte Methode unterstuetzt.

Als Objekt gehoert jede Klasse einer anderen Klasse an und alle Klassen gehoeren standardmaessig zur sogenannten SOM-Class. Bezogen auf ein einfaches Objekt (kein Klassenobjekt) wird diese Klasse Metaklasse genannt. Fuer eine oder mehrere Klassenobjekte kann aber auch eine eigene Metaklasse definiert werden. Auf diese Weise lassen sich fuer diese Klassen zusaetzliche Klassenmethoden einfuehren beziehungsweise die vorhandenen Klassenmethoden modifizieren.

Wie schon bei der Beschreibung der Klassendefinition erwaehnt wurde, stellt SOM die Klasse SOM-Object als gemeinsame eventuell mittelbare Parent-Klasse zur Verfuegung. Darin sind Methoden enthalten, die alle Objekte verstehen. Die Klasse SOM-Object enthaelt aber keine Datenfelder.

Eine Methode der Klasse SOM-Object ermittelt zum Beispiel die Klasse eines vorgegebenen Objekts, eine andere Methode prueft, ob das Objekt einer bestimmten Klasse angehoert oder diese Klasse eine unmittelbare oder mittelbare Parent-Klasse des Objekts ist.

Die Version 2 von SOM soll neben C auch die Programmiersprache C++ verwenden. Fuer einen spaeteren Zeitpunkt sind Smalltalk und Cobol ebenso vorgesehen wie eine objektorien- tierte Erweiterung von Rexx. Versprochen ist auch Software, um C++-Klassenbibliotheken in SOM-Klassenbibliotheken umzusetzen.

Auch eine objektorientierte Datenbank will die IBM integrieren. Dabei arbeitet das Unternehmen mit Object Design, dem Hersteller von Objektstore, zusammen. Auch der Zugriff zu anderen Datenbanken wird durch Klassen unterschiedlicher Firmen unterstuetzt.

Auf Plattformebene soll OS/2 laut IBM noch in diesem Jahr durch das hauseigene AIX und bald auch durch die Unix-Version von Hewlett-Packard ergaenzt werden. Eine Windows-Version ist ebenfalls in Vorbereitung. Spaeter soll SOM auch auf IBM-Grossrechnern und auf den AS/400-Systemen laufen.

Die Erweiterung von SOM zu DSOM

Eine Erweiterung von SOM zum Distributed Object Modell (DSOM) soll es Objekten auf unterschiedlichen Anlagen ermoeglichen, sich mit Hilfe von Nachrichten gegenseitig aufzurufen. Fuer die einzelnen Objekte wird es transparent sein, ob sich das aufgerufene Objekt auf der gleichen oder einer anderen Anlage befindet.

Beim Aufruf eines Objektes auf einem Fremdsystem sieht DSOM vor, dass das Objekt im aufrufenden System als sogenanntes Proxy-Objekt repraesentiert wird. Dadurch erscheint es dem aufrufenden Objekt, als befaende sich das Objekt der Zielmaschine innerhalb des eigenen Systems. Die Aufrufe fuer interne und entfernte Objekte sind daher identisch. Proxy-Objekte werden bei Bedarf dynamisch vom SOM- System erzeugt. Diese Objekte gehoeren alle derselben Klasse an und sind somit unabhaengig vom Typ des aufgerufenen Objektes.

Beim Distributed Object Model (DSOM) handelt es sich um die IBM- Implementation des Object Request Brokers (ORB). Er erfuellt daher die Spezifikationen des "Common Object Request Broker Architecture"-(Corba-)-Standards, wie er von der Object Management Group (OMG) spezifiziert wurde.

Dazu gehoert auch, dass IBM die "Interface Definition Language" (IDL) verwendet, wie sie von der OMG fuer den ORB spezifiziert wurde. Diese Schnittstellen-Beschreibungssprache stellt das statische Interface des Corba-Standards dar.

Obwohl grundsaetzlich fuer die Zusammenarbeit von heterogenen Systemen konzipierte ist, wird bei der IBM in der Version 2 von SOM zunaechst nur die Kommunikation zwischen OS/2-Systemen realisiert. Es folgt die Einbindung von AIX/6000- und Windows- Systemen. Bei der geplanten Ausweitung der Umgebung legt die IBM das Distributed Computing Environment (DCE) der Open Software Foundation zugrunde. DSOM benutzt dann den dort enthaltenen Remote Procedure Call (RPC) sowie die "Location"- und "Security"- Services.

IBM und Hewlett-Packard werden ihre Software fuer die verteilte Verarbeitung auf der Basis der OO-Methode aufeinander abstimmen. Bei HP handelt es sich hierbei um die "Distributed Object Management Facility" (DOMF). Auch diese Software erfuellt den Corba-Standard. DOMF ist zur Zeit fuer Smalltalk realisiert, die Realisierung fuer C++ ist in der Entwicklung.

Zusaetzlich zum Begriff Klassenbibliothek ist der Begriff Framework ueblich. Bei einem Framework handelt es sich um eine Klassenbibliothek, in der Klassen zusammengestellt sind, welche eine bestimmte Aufgabe beziehungsweise Teilaufgabe erfuellen.

IBM hat die folgenden Frameworks angekuendigt:

- Replication Framework,

- Persistence Framework und

- Collection Classes Framework.

Diese Frameworks sollen noch in diesem Jahr zur Verfuegung stehen, zuerst fuer OS/2 und dann auch fuer AIX/6000.

Das Replication Framework macht Kopien desselben Objekts fuer mehrere Clients verfuegbar. Hier wird offenbar eine andere Form der verteilten Verarbeitung realisiert wie bei DSOM. Hier greifen mehrere Clients nicht auf das gleiche Objekt zu, aber die verschiedenen durch das Replication Framework erzeugten Kopien werden danach wieder konsolidiert. Diese Form der Verarbeitung ist sicherlich effizienter als die reine verteilte Verarbeitung.

Das Persistence Framework macht es moeglich, SOM-Objekte persistent auf Platte zu speichern und spaeter wieder verfuegbar zu machen. Dabei handelt es sich offenbar um eine Vorstufe fuer die Realisierung von persistenten Objekten. Das heisst, das Programm sollte die Objekte in gleicher Weise ansprechen koennen, ob sie auf der Platte gespeichert sind oder nur fuer den einzelnen Programmablauf im Hauptspeicher existieren.

Das Collection Classes Framework stellt den Programmierern fuer den Einsatz in Programmen Datenstrukturen wie "lists", "sets", "queues" und "dictionaries" zur Verfuegung.

Inzwischen haben auch andere Firmen begonnen, Klassenbibliotheken fuer SOM zu entwickeln beziehungsweise bestehende Software in Klassenbibliotheken dafuer umzubauen. Das Objektmodell der IBM bietet die Chance, dass an die Stelle grosser monolithischer Anwendungen kleinere auf bestimmte begrenzte Aufgaben ausgerichtete Komponenten treten, die zusammenwirken koennen, um groessere Anwendungen zu bilden.

So kann man sich zum Beispiel die Textverarbeitung als Zusammenspiel mehrerer Komponenten vorstellen. So koennte der Hersteller auf die Entwicklung eines eigenen Speicherungsmechanismus verzichten und statt dessen die Einbindung einer Datenbanksoftware zulassen, die dann die Speicherfunktion uebernimmt. Auch die Weiterentwicklung von Anwendungssystemen wuerde im Rahmen einer derartigen Komponenten-Bauweise einfacher.

Durch SOM erhalten prinzipiell auch kleine Firmen die Chance, bei der Software-Entwicklung mitzuwirken. Ein Hemmnis fuer diese Entwicklung liegt allerdings wohl in Problemen der Verguetung fuer die Erstellung von Komponenten, wenn diese in andere Produkte einbinden lassen. Ein Ausweg aus diesem Dilemma koennte darin bestehen, die Komponenten-Ersteller entsprechend der Benutzungshaeufigkeit ihrer Komponenten zu bezahlen. Unter dieser Vorraussetzung koennte es zu einem Boom fuer die Komponenten- Industrie kommen.

*Hermann Schmitt ist Leiter IS-Planung beim Landschaftsverband Rheinland.