Mit "SOM objects" ist die IBM angetreten, die Entwicklung objektorientierter Systeme zu vereinfachen. Doch eines der ersten in Deutschland durchgefuehrten SOM-Projekte wurde kuerzlich auf Eis gelegt. Martin Roesch* beleuchtet die Hintergruende dieser Entscheidung und zeigt, wie und warum die Anwender trotzdem bereits mit der Objektorientierung beginnen sollten.

Eigentlich sollte SOM objects mit den zahlreichen Einschraenkungen aufraeumen, die den Nutzen der Objektorientierung bislang vermindert hatten: Durch die konsequente Ausrichtung am Corba- Standard der OMG koennen SOM-Objekte, so die Absicht der IBM, unabhaengig von der verwendeten Programmiersprache miteinander in Verbindung treten, mit Hilfe von DSOM sogar ueber Maschinengrenzen hinweg. Die Unabhaengigkeit der Objekte wuerde dann das Entstehen einer Softwarekomponenten-Industrie ermoeglichen, wie sie in Anfaengen bereits erkennbar ist.

Oel ins Feuer giesst die Ankuendigung der IBM, SOM schon bald auch fuer MS-Windows zur Verfuegung zu stellen. Dadurch oeffnet sich fuer SOM-Entwickler der Zugang zum Windows-Massenmarkt, was noch in diesem Jahr zu einer Angebotsexplosion von Softwarekomponenten - und damit zum Zusammenbruch der Preise - fuehren koennte: Dann wird Software selbstverstaendlich zu grossen Teilen aus fertig eingekauften Komponenten zusammengesetzt.

Die Softwarespezialisten von Roesch Consulting hatten diese Entwicklung bereits bei der Vorstellung von SOM objects im Juni 1993 vermutet und starteten demzufolge ein Pilotprojekt, mit dem sie die Moeglichkeiten von SOM an einem kleinen, ueberschaubaren, aber nicht trivialen Beispiel demonstrieren und gleichzeitig den Umgang mit SOM trainieren wollten. Insbesondere sollten folgende Aspekte ueberprueft beziehungsweise geuebt werden: Bausteinbildung, Auswechseln von Bausteinen in fertigen Systemen, Bausteindokumentation und Bausteinverwaltung (was man nicht wiederfindet, kann man nicht wiederverwenden!).

Abbildung 1 zeigt eine objektorientierte Analyse (OOA) der Klassen und Objekte, wie sie im Beispielprojekt benutzt wurden: Kunden und Artikel. Wenn der Kunde sein Kreditlimit einhaelt und die bestellten Artikel vorraetig sind, wird geliefert und eine Rechnung gestellt. Reicht der Kredit nicht aus oder ist ein Artikel nicht vorraetig, muss die Zahlung des Kunden beziehungsweise das Eintreffen der fehlenden Artikel abgewartet werden.

Das Projekt folgte den Stufen:

1. OOA-Modelle nach Coad/ Yourdon, Rumbaugh und Booch;

2. funktionale Ueberpruefung des OOA-Modells;

3. Erstellen einer Einplatzversion mit Smalltalk;

4. Implementieren mit SOM und C++;

5. Einfrieren.

Nach dem SOM-Konzept liegen die Objekte nicht mehr im Verwaltungsbereich ihrer Sprache, sondern eine Ebene hoeher, also im System. Deshalb sind sie systemweit sicht- und ansprechbar. Die Objekte kennen sich gegenseitig (beispielsweise kennt eine Rechnung den Kunden, der sie bezahlen soll) und koennen andere Objekte durch Nachrichten zum Arbeiten veranlassen (zum Beispiel schickt eine Rechnung an ihren Kunden die Nachricht: Gib mir deine Adresse!)Wie wir im Verlauf unseres Projektes feststellen mussten, entspricht das heutige SOM-Produkt diesem Ziel noch nicht.

SOM-Objekte sind derzeit nicht in der Lage, sich langfristig zu kennen und auf einfache Weise jederzeit zur Mitarbeit aufzufordern. Die heutige Arbeitsweise von SOM/DSOM wird in Abbildung 3 wiedergegeben: Objekte kennen sich nur solange, wie sich alle beteiligten Objekte im Arbeitsspeicher befinden.

Wenn ein Objekt aus dem Arbeitsspeicher entfernt wird und nur noch seine Daten auf der Platte liegen, so ist es fuer die anderen Objekte im System nicht mehr vorhanden und folglich auch nicht mehr ansprechbar. Schlimmer noch: Ein Objekt, das aus dem Arbeitsspeicher entfernt wurde, ist unwiderruflich dahin. Wenn seine Daten von der Platte in den Arbeitsspeicher zurueckgeholt werden, entsteht nicht das alte Objekt neu, sondern ein neues Objekt, das keinem seiner alten "Objektkollegen" mehr bekannt ist.

Diese Arbeitsweise hat zwei Konsequenzen: Zum einen muss der Benutzer eines Objektes wissen, ob sich der gewuenschte Gespraechspartner, also das andere Objekt, im Arbeitsspeicher befindet. Falls nicht, muss der Benutzer sich im klaren sein, welches Programm er aufzurufen hat, um den Gespraechspartner in den Arbeitsspeicher zu laden, und welche Parameter dafuer erforderlich sind. Erst danach kann die Nachricht auf die Reise gehen.

Die Luecke wird bald geschlossen

Diese Vorgehensweise ist kompliziert, fehleranfaellig und weit davon entfernt, so einfach zu sein, wie es die Objektorientierung verspricht. Dass es auch anders geht, zeigt beispielsweise das Mainframe-Objekt-System der IBM mit der Bezeichnung Application Services Manager (ASM). Bei ASM wird ein Objekt - unsichtbar fuer den Benutzer - bei Bedarf von der Platte in den Speicher geholt ("automaterialize"). SOM und ASM sollen allerdings 1994 in einem Produkt zusammengefuehrt werden.

Zudem haben Hewlett-Packard und IBM vereinbart, die Objektrealisierungs-Techniken beider Firmen durch gegenseitige Lizenzen kompatibel zu gestalten. Mit der Distributed Object Management Facility (DOMF) stellt HP der IBM eine Technik zur Verfuegung, die dauerhafte Objektbeziehungen ermoeglicht. Im Gegenzug lizenziert IBM die gut gelungene Programmier- Schnittstelle von SOM an HP. Im Ergebnis entsteht eine gemeinsame Plattform fuer verteilte Objekte in heterogenen Netzen, wie sie weder IBM noch HP allein haetten angebieten koennen (vgl. Abbildung 4).

Die Kooperation von HP und IBM ist vor allem deshalb von Bedeutung, weil sie mit Blick auf die Version 2.0 des Corba- Standards der OMG vereinbart wurde. Es bestehen gute Chancen, dass die OMG die von IBM und HP entwickelte Technik zum Standard erklaert.

Was bedeutet die derzeitige Situation aber fuer Unternehmen, die heute konkrete Entscheidungen ueber Projekte faellen muessen? Am Anfang jeder Software-Entwicklung steht die Analyse. Fuer diese fruehe Stufe der Systementwicklung hat sich die OOA bewaehrt. Sie fuehrt schnell zu einem soliden Verstaendnis fuer das Anwendungsgebiet und die Aufgaben des neuen Systems. Doch nicht alle OOA-Methoden sind gleich leistungsfaehig. Hier lohnt sich ein Vergleich.

Die derzeitige Schwaeche von SOM wird fuer diejenigen Entwickler kaum eine Beeintraechtigung bedeuten, die noch damit beschaeftigt sind, ihre Kollegen und Chefs von den Vorteilen der OOA zu ueberzeugen.

Fuer die mittlerweile ueberwiegende Gruppe derer, die diesen ersten Schritt schon geschafft haben, gibt es hingegen einiges zu bedenken: Sollen sie heute schon bei SOM einsteigen? Gibt es Alternativen? Wie kann eine Strategie aussehen, die in der heutigen Situation den Nutzen und die Risiken gut gegeneinander abwaegt?

Die Antwort auf die Frage, ob man bereits bei SOM einsteigen sollte, ist ein klares "Jein": Ja, eine kleine Pioniergruppe sollte mit SOM spielen und so damit vertraut werden; nein, von einer Anwendungsentwicklung mit dem derzeitigen Versionsstand von SOM ist abzuraten.

Wer nach Alternativen sucht, sollte sich mit dem Corba-Standard der OMG beschaeftigen, dessen Vorgaben nicht nur auf Objekte anwendbar sind, sondern auch auf die herkoemmlichen Arten von Bausteinarchitekturen. SOM ist schliesslich auch nur eine Implementierung von Corba! Das Wichtigste fuer flexible Systeme und geringe IS-Kosten sind saubere Software-Architekturen und - Schnittstellen.

Eine Strategie, die Nutzen und Risiken gut gegeneinander abwaegt, koennte so aussehen:

1. Mit OOA beginnen;

2. das OOA-Modell testen;

3. hauseigene Software-Architekturen darauf ueberpruefen, wie sie an Corba angenaehert werden koennen;

4. neue Projekte nicht mehr ohne Corba beginnen (vgl. Abbildung 5).

Da die ersten Schritte auf dem Weg zu Corba-Bausteinen auch ohne SOM gemacht werden koennen, werden die Kinderkrankheiten des IBM- Produkts bei genauerem Hinsehen nur fuer wenige Firmen einen realen Rueckschlag bedeuten. Die meisten koennen nach der Formel "Objekte jetzt, doch SOM lieber spaeter" heute schon viel sinnvolle Vorarbeit leisten.

Erlaeuterung der Begriffe

und Abkuerzungen im Text

OMG: Object Management Group, Standardisierungsgruppe fuer Objekttechnik. Durch ihre hohe Dynamik und fachliche Kompetenz ist es der OMG gelungen, die gesamte Informationsbranche hinter sich zu versammeln und die Entstehung von Konkurrenzorganisationen zu verhindern.

Corba: Common Object Request Broker Architecture; beschreibt eine Objektarchitek-tur, auf die sich die in der OMG versammelten Firmen der Informationstechnik (etwa 360 an der Zahl) geeinigt haben. Die IBM-Implementierung des Corba-Standards ist SOM objects mit den Laufumgebungen SOM und DSOM.

Corba 1.1: Der Corba-Standard liegt zur Zeit in der Version 1.1 vor, die die Sprach- und Betriebssystem-unabhaengige Verbindung von Objekten innerhalb der Welt eines Herstellers ermoeglicht. Die Beschraenkungen, die beispielsweise C++ auferlegt, werden durch Corba aufgehoben. So koennen die "Gespraechspartner" eines C++- Objektes Objekte sein, die in anderen Programmiersprachen implementiert wurden.

Corba 2.0: Die Erweiterung der Objektarchitektur wird in diesem Jahr erfolgen - in der Version 2.0 des Corba-Standards sowie durch die Standardisierung von Object-Services. Die naechsten Ziele der Standardisierung sind die Zusammenarbeit von Object-Request- Brokern unterschiedlicher Hersteller sowie die Transaktionssicherung in dieser verteilten Welt. Hierfuer haben sich bereits drei Allianzen gebildet: IBM und HP, Microsoft und DEC sowie Sun und Next.

SOM: System Object Model, die Objektarchitektur der IBM; ist derzeit auf OS/2 und AIX verfuegbar. Implementierungen auf MS- Windows, AS/400 und verschiedenen MVS-Plattformen sollen folgen.

DSOM: Distributed System Object Model; ermoeglicht die Kommunikation von Objekten, die auch auf mehreren Maschinen liegen koennen. Die Verteilung der Objekte auf diese Geraete ist fuer Anwendungsentwickler unsichtbar, es werden also alle "Gespraechspartner" eines Objektes auf die gleiche Weise angesprochen - unabhaengig davon, ob sie auf der lokalen oder einer anderen Maschine "wohnen".

SOM objects: seit Juni 1993 die Bezeichnung fuer SOM/DSOM.