Von Thilo Schmid*

Wer OO-Konzepte mit Client-Server-Computing verbinden will, scheint seiner Zeit voraus zu sein. Es fehlen Standards, so dass der OO-Entwickler hinsichtlich der Interoperabilitaet immer wieder in alte Welten zurueckfaellt. Um so wichtiger ist es, sich mit den aktuellen Entwicklungen auseinanderzusetzen.

Objektorientierte Anwendungen gelten heute als modern und zukunftssicher. So lassen sich mit dieser Methode die Belange einer grafischen Benutzeroberflaeche gut meistern, auch die Realitaet im DV-System ist besser modellierbar und somit verstaendlicher abzubilden. Mit Techniken wie Vererbung, Polymorphismus und dynamischer Methodenanbindung kann man flexible und leicht anpassbare Anwendungen erstellen. Zusaetzliche Bestandteile sind dabei fuer neue Aufgaben wiederverwendbar. Doch ist Objektorientierte Programmierung (OOP) am Ende, wenn es um die Verbindung verschiedener Anwendungen ueber Systeme hinweg geht? Traditionell erfolgen solche Integrationen ja meist ueber den gemeinsamen Datenbestand. Bleibt als Ausweg also nur die Welt relationaler Datenbanken mit ISAM-Dateien (Index Sequential Access Method) und Flat-Files?

Im Grunde genommen lebt jeder OO-Entwickler in einer Client- Server-Welt. Wer ausschliesslich objektorientiert vorgeht, beschraenkt sich auf das Versenden von Nachrichten an Objekte, die darauf mit einer Antwort reagieren. Obwohl sich dies in der Regel innerhalb eines Programms auf einem einzigen System abspielt, besteht doch eine Client-Server-Beziehung zwischen dem Sender der Nachricht (Client) und dem Empfaenger, der die gewuenschte Antwort gibt (Server).

Aus der Sicht des Entwicklers spielt es deshalb keine Rolle, ob sich das angesprochene Objekt auch wirklich in seinem Programm befindet. Solange er das Objekt benennen kann, hat er die Moeglichkeit, ihm eine Nachricht zu senden. Leider sind die meisten Entwicklungssysteme zunaechst nicht so grosszuegig und erlauben dem Empfaenger einer Nachricht nicht, in einem anderen Programm auf einem anderen System zu sein. Mit entsprechenden Zusatzwerkzeugen laesst sich dies jedoch simulieren.

Als naechsten Schritt kann man sich vorstellen, dass das angesprochene Objekt komplexe Dienstleistungen verrichtet und eine Anwendung fuer sich darstellt. Innerhalb einer Entwicklungsumgebung ist dies mit entsprechenden Werkzeugen relativ problemlos zu realisieren. Doch was ist, wenn das Objekt nicht mit den gleichen Tools erstellt wurde? Was ist, wenn es von einem anderen Hersteller kommt?

Innerhalb wohldefinierter Entwicklungsumgebungen ist auch dieses Problem loesbar. So bietet MS-Windows Dienste wie Dynamic Data Exchange (DDE) und Object Linking and Embedding (OLE), die eine Integration verschiedener Anwendungen innerhalb von Windows erlauben. Diese Konzepte sind jedoch wenig objektorientiert, da sie die Kommunikation auf einem sehr niedrigen Level beschreiben. Hinzu kommt, dass sie schliesslich auch fuer nicht objektorientierte Anwendungen zugaenglich sein muessen. Entsprechende OO-Adapter sind jedoch einfach zu erstellen.

Das Problem ist damit aber nur oberflaechlich geloest. Standards wie DDE erlauben zwar, verschiedene Anwendungen miteinander zu verbinden, doch austauschbar sind sie damit noch nicht. Weil ein Protokoll wie DDE eben auf einem niedrigen Level definiert ist, sagen sie ueber Anwendungsfunktionen nichts aus. Eine Nachricht, die aus einem Budgetvergleich eine Grafik macht, sieht bei jeder Anwendung anders aus. Mitunter koennen sich nicht einmal deutsche und englische Versionen des gleichen Produktes unterhalten.

Wer heute objektorientiert entwickelt, wird es naturgemaess einfacher haben, Client-Server-Konzepte zu realisieren. Sollen Anwendungen in Client- und Server-Komponenten zerlegt werden, sind jedoch Sollbruchstellen zu modellieren.

In einer objektorientierten Anwendung tauschen sehr viele Objekte Informationen ueber sehr viele Nachrichten aus. In Smalltalk zum Beispiel sind selbst Schleifen und Interface-Bedingungen als Nachrichten implementiert. Man spricht bei solchen Nachrichten und denen, die Objekte in engen Schleifen versenden, von Heavy-load- Protokollen.

Solche Nachrichten eignen sich nicht fuer entfernte Objekte. Je nach Uebertragungsgeschwindigkeit und Protokoll-Overhead kann es Sekunden dauern, bis eine Nachricht bei einem entfernten Objekt ankommt.

Die Zeit zwischen dem Versenden der Nachricht und dem Empfangen der Antwort abzueglich der Verarbeitungszeit im entfernten Objekt bezeichnet man als Latenzzeit. Sie wird in der Regel mit Dummy- Nachrichten bestimmt, die durch eine leere Methode implementiert sind.

Die Latenzzeit fuer entfernte Objekte ist um Groessenordnungen laenger als fuer Objekte im gleichen Programm - einmal abgesehen von Auslagerungsoperationen durch zuwenig Hauptspeicher. Bei KHK wurden in einem 10Base-2-Ethernet-LAN auf einem Strang Latenzzeiten von zehn Millisekunden gemessen. Bei Hewlett-Packard in Cupertino, wo "Distributed Smalltalk" entwickelt wurde, hat man unter aehnlichen Bedingungen 100 Millisekunden ermittelt. Der Unterschied erklaert sich durch die verwendeten Protokolle. Distributed Smalltalk war die erste Corba-Implementation. Je groesser die Latenzzeit durch Protokoll-Overhead, desto groesser sollten die Nachrichten sein. Die Uebertragung groesserer Informationsmengen vermehrt die Latenzzeit nur unwesentlich (bis 2 KB kein Unterschied).

Der einfachste Schnitt durch eine Anwendung laesst sich zwischen der Praesentationsebene und der Semantik von Objekten ziehen. Die Begriffe Semantik- und Praesentationsebene wurden von Hewlett- Packard im Rahmen des Distributed-Smalltalk-Projektes eingefuehrt. In der Smalltalk-Muttersprache spricht man hingegen von Modellen, Views und Controllern (MVC). Andere Applikation-Frameworks haben aehnliche Architekturen. Die Praesentationsebene stellt dabei den klassischen Dialog dar, wobei die Semantikebene auch innerhalb dieses Levels ausgedehnt werden kann. Diese Erweiterungen sind jedoch lokal und gelten nur dort. Die Farbe eines geometrischen Objektes kann zum Beispiel Bestandteil der Praesentationsebene sein. Seine Form hingegen ist Semantik und gilt fuer alle Ansichten des Objektes.

Bei kaufmaennischen Anwendungen gibt es jedoch nur wenige Aspekte mit einer lokalen Bedeutung. Die moeglichen Ansichten auf ein Objekt liefern aber einen Anhalt fuer die Aufteilung komplexer Objekte, Rechnungen mit Stuecklisten zum Beispiel. In der Finanzbuchhaltung interessiert zum Beispiel nur die Ansicht des Buchungsstempels einer Rechnung. Der entsprechende Dialog (Client) tauscht mit der Rechnung (Server) also ganze Buchungsstempel aus. Der Zugriff auf die Bestandteile des Buchungsstempels ist unter Umstaenden schon ein Heavy-load-Protokoll, das jetzt nur innerhalb des Dialoges auftaucht.

Man kann versuchen, mit Hilfe von Caching-Mechanismen Heavy-load- Protokolle auch bei entfernten Objekten zu verwenden. Dies hilft jedoch nur, wenn sich der Informationsfluss primaer einseitig zum Client ausrichtet.

Bislang wurde wenig darueber gesagt, wie eine Nachricht ihren Empfaenger findet. Innerhalb eines Programms ist das auch trivial. Handelt es sich beim Empfaenger jedoch um ein entferntes Objekt, so muss man zur genauen Adressierung auch noch wissen, wo es sich befindet. Andererseits darf dies keine notwendige Voraussetzung sein - Systeme sind nur dann problemlos austausch- und skalierbar, wenn man Objekte und somit Dienste beliebig umdisponieren kann.

Benoetigt jedes System in einem Netz genaue Angaben, welche Dienste sich wo befinden, wuerde eine kleine Konfigurationsaenderung bei 100 Systemen schon aus praktischen Gruenden scheitern. Gefragt ist vielmehr ein Mechanismus, der Nachrichten zu namentlich bekannten Objekten fuehrt, egal wo diese sind. Solche Mechanismen werden Message-Broker genannt. Ihre Standardisierung ist zwingend.

Jedes Problem laesst sich meist in verschiedenen Programmiersprachen loesen. In der Praxis bieten ausgewaehlte Programmiersysteme den Vorteil, dass viel weniger Entwicklungsarbeit anfaellt. Dies trifft zum Beispiel fuer dynamische Systeme in Client-Server-Umgebungen zu. Jede objektorientierte Entwicklungsumgebung, die ein indirektes Versenden von Nachrichten ermoeglicht, etwa Smalltalk oder Objective C, hat einen entscheidenden Vorteil bei der Implementation von Zugriffen auf entfernte Objekte. So kann eine Nachricht von der Kommunikations-Schnittstelle abgelesen und indirekt an das Zielobjekt gesandt werden. Statische Entwicklungsumgebungen wie C++ muessen an den Schnittstellen von einem System zum anderen Nachrichten immer verschluesseln und wieder inter- pretieren. Dabei ist es erforderlich, dass diese Wandler fuer jede neue Nachricht aktualisiert werden.

Corba steht fuer Common Objekt Request Broker Architekture und ist ein Standardisierungsvorschlag der Object Management Group (OMG). Bei der OMG handelt es sich um einen losen Zusammenschluss mehrerer Systemhersteller, die die Notwendigkeit systemuebergreifender Standards erkannt haben. Das Ergebnis besteht bisher aus mehreren Versionen einer Spezifikation fuer einen Request Broker und fuer verschiedene Object-Services. Kernstueck der Corba-Spezifikation ist der Object Request Broker (ORB). Er ist ein Mechanismus, der die Grundlage fuer verschiedene Objekt-Dienstleistungen bildet und bietet dabei folgende Kerndienste an:

- Schnittstellen-Beschreibungen,

- statischer und dynamischer Schnittstellenaufruf sowie

- Schnittstellen-Repository.

Der Ausdruck "Schnittstelle" kann hier mit dem oben verwendeten Begriff "Nachrichtenprotokoll" gleichgesetzt werden. Eine neu entwickelte Schnittstellen-Beschreibungssprache IDL (Interface Definition Language) stellt Interfaces zur Verwaltung in einem Schnittstellen-Repository bereit.

Wer eine Nachricht an ein entferntes Objekt senden will, muss diese Nachricht gemaess der im Schnittstellen-Repository hinterlegten Beschreibung aufbauen. Dort sind Typen und Reihenfolge der Parameter hinterlegt. Eine passende Nachricht gelangt dann via Schnittstellen-Aufruf an ein entferntes Objekt. Der ORB lokalisiert das Zielobjekt und fuehrt eventuell notwendige Transformationen durch, wobei die Binaerdarstellung auf den Systemen unterschiedlich sein kann.

Bevor der Zugriff auf Objekte via ORB moeglich ist, muessen diese registriert werden. Die Anwendung erzeugt dazu einen Objektadapter, der die oeffentlichen Nachrichten an das betreffende Objekt weiterleitet. Oeffentliche Objekte muessen reentrant sein, wenn sie auch lokal genutzt werden. Der oeffentliche Zugriff kann im Objektadapter serialisiert werden. Greift jedoch das lokale Programm ebenfalls auf exportierte Objekte zu, kann es passieren, dass eine neue Nachricht begonnen wird, bevor die Bearbeitung der letzten abgeschlossen ist.

Verschiedene Dienstleistungen, die Object-Services beschreiben, bauen auf dem ORB auf. Es sind bislang jedoch nur die rudimentaeren Dienste standardisiert. Hier verbirgt sich die grosse Aufgabe fuer alle Softwarehersteller. Mit den Object-Services lassen sich naemlich auch anwendungsspezifische Dienste beschreiben und standardisieren. Bislang gibt es unter anderem Vorschlaege fuer folgende Dienstleistungen:

- Namensgebung fuer globale Objekte,

- gegenseitige Benachrichtigung ueber Ereignisse,

- Erzeugen, Veroeffentlichen, Privatisieren und Loeschen von Objekten,

- Persistenz von Objekten,

- Beziehungen zwischen Objekten,

- Zeit sowie

- Sicherheit und Zugriffsbeschraenkungen auf Objekte.

Mit den Lifecycle-Diensten (Erzeugen, Veroeffentlichen, Privatisieren, Loeschen und Persistenz) koennen Objekte ausserhalb des aktuellen Programms erzeugt und gehalten werden. In objektorientierten Datenbanken bietet sich die Moeglichkeit, diese Dienste zu implementieren und solche Objekte zu verwalten.

Wer sich als Software-Entwickler heute auf die zukuenftigen Standards in Sachen Interoperabilitaet vorbereiten will, sollte sich bei der Modellierung seiner Anwendung zunaechst grundsaetzlich am Client-Server-Prinzip orientieren.

Dienste werden in Zukunft nicht nur dem Anwender direkt, sondern auch anderen Anwendungen angeboten. Entsprechende Schnittstellen sind schon jetzt zu modellieren - unabhaengig davon, mit welchem Standard man sie verbindet.

Die Granularitaet der Dienste stellt dabei einen wichtige Gesichtspunkt dar. Low-level-Funktionen sind ebenso ungeeignet wie grosse Funktionen, die mit 100 Parametern versorgt werden muessen. Darueber hinaus ist die Persistenz von Massenobjekten ausserhalb der lokalen Systeme zu beruecksichtigen.

Wer sich heute naeher mit der Corba-Spezifikation auseinandersetzen moechte, der kann dies mit Distributed Smalltalk von Hewlett- Packard tun. Es basiert auf dem Produkt Visual Works von Parc Place Systems. Dem Entwickler zeigt es heute schon, wie sich Corba umsetzen laesst. Wie bei Hewlett-Packard in Cupertino zu erfahren war, arbeitet man zum Beispiel bereits an der Corba-Anbindung von Open-ODB, der objektorientierten Datenbank von HP.

Zum Thema

Die genaue Corba-Spezifikation kann beim OMG-Buero in Framingham, Massachusetts, USA, angefordert werden.

Telefon: 001/508/820-43 00, Fax: 001/508/820-43 03.