Verteilte Anwendungen mit einer Mehrschichtenarchitektur (n-Tier) gelten als State of the Art, bei der Erfüllung hoher Anforderungen an Skalierbarkeit, Verfügbarkeit und Wartbarkeit zu erfüllen. Hierbei läuft die Kommunikation zwischen den Systembestandteilen über Middleware-Technologien.

Entwickler sind dabei in ihren Vorhaben an die technischen und organisatorischen Rahmenbedingungen eines Unternehmens gebunden. Dazu zählen unter anderem verwendete Entwicklungsumgebungen und Betriebssysteme. Darüber hinaus liegt ein Augenmerk auf dem eigentlichen Kommunikationsparadigma, das die Basis für die Kommunikation bildet. Bekannte Techniken sind etwa Remote Procedure Calls (RPC), ORB-basierte Kommunikation mit Remote Objects und Message-orientierte Methoden (MOM) wie Message-Queing und Publish and Subscribe. Einige Stärken ausgewählter Techniken sind in der Tabelle "Middleware-Techniken" zusammengestellt. Vielfach greifen Entwickler auf die Implementierungen der Common Object Request Broker Architecture oder auf Microsofts Distributer Componenten Object Model (DCOM) zurück. Beide stellen als Kommunikationsparadigma Remote Objects bereit. das ist von Vorteil, wenn die Objekte häufige Zustandsänderungen aufweisen, Zugriffe aber eher selten sind.

Steigt die Zahl der Zugriffe und wächst die Menge von zusammenhängenden Objekten, kommt es rasch zu nicht tolerierbaren Leistungsabfällen. Ein bekannter Ausweg besteht darin, das Objekt auf Seiten des nutzenden Programms zu replizieren. Dafür hält zum Beispiel Corba das Typkonstrukt "Value" bereit.

Dieser Lösungsweg führt aber nicht weit, wenn zur Laufzeit kontextabhängige Sichten auf komplexe und versionierbare Objektstrukturen verarbeitet werden sollen. Vor genau diesem Problem stand man bei der Entwicklung eines mehrplatzfähigen, verteilten Auftrags- und Projekt-Management-Systems in einer homogenen NT-Infrastruktur. Die dabei gemachten Erfahrungen lassen sich auch auf andere Vorhaben übertragen.

Das objektorientierte Design der Anwendung erforderte die Kommunikation großer Objektmengen mit einer Vielzahl von Attributen, wobei zusammengesetzte Strukturen in Form von Listen, Grafen und Netzen verschiedenster Klassen verarbeitet werden sollten. Die Datenempfänger, typischerweise die Client-Anwendungen, sollten häufig wiederholt auf die Objekte zugreifen. Zusammengesetzte Objektstrukturen mussten zudem als Einheit persistent und im Rahmen einer asynchronen, über Queues koordinierten Verarbeitung als in sich integere Versionen ausgetauscht werden können.

Objekte und Attribute sollten darüber hinaus klassen- und instanzabhängig gefiltert werden, um das aus der Datenbankwelt bekannte Konzept der benutzerabhängigen Views abzubilden und ein erweitertes Autorisierungskonzept innerhalb der Anwendungslogik zu realisieren.

Eine weitere Anforderung waren Verwendungsmuster, die weitgehend Middleware-unabhängig sein sollten, um einen späteren Wechsel der Techniken oder eine gleichzeitige Unterstützung mehrerer Middleware-Protokolle in den Anwendungs-Servern zu ermöglichen.

Darüber hinaus sollten

- die Middleware-Anteile weitestgehend gegen die eigentliche Anwendungslogik gekapselt werden, um den Entwicklungsprozess hinsichtlich Aufwand und Geschwindigkeit zu optimieren,

- Änderungen von Klassen, die relevant für die Kommunikation sind, während der Entwicklung und Wartung schnell und einfach möglich sein und

- auch bei komplexen Anfragen an die Anwendungs-Server kurze Antwortzeiten erzielt werden.

Die geschilderten Anforderungen waren mit dem ORB-inhärenten Mechanismus der Remote Objects nicht zu erreichen. Für die im Projekt anzutreffenden komplexen, versionierten Objektstrukturen führte ihre Replikation über Prozessgrenzen hinweg zu einem optimierten Verfahren, nicht zuletzt aufgrund des erreichten Antwortzeitverhaltens.

Middleware-gestützte Replikationen von Objekten finden sich zum Beispiel in Corbas Value-Konstrukt ab der Version 2.3. Auch Java-RMI verwendet für die Kommunikationssteuerung Remote Objects. Objektstrukturen in Methodenparametern werden dabei aber als Einheit serialisiert und als entkoppelte Replikate in dem Empfängerprozess instanziiert. Beide Techniken liefern das Grundgerüst einer Lösung für die genannten Anforderungen.

Als Basis des Verfahrens wird ein Middleware-Produkt verwendet, das bidirektionale Kommunikationskanäle bereitstellt. Im Fall einer ORB-artigen Middleware sind dies aus der Ferne erreichbare Objekte mit einigen wenigen, eher allgemein gehaltenen Methoden. Ferner wird hiermit die Session- und Kontextverwaltung realisiert, beispielsweise die Verwaltung der Benutzeridentität.

Soll im Rahmen einer Anfrage eine komplexe Objektstruktur übertragen werden, so wird diese über ein geeignetes Containerobjekt (zum Beispiel eine Liste von Objekten oder das Root-Objekt eines Baumes) auf Seiten der Quelle an einen so genannten Objektstruktur-Marshaller (OSM) übergeben (siehe Abbildung "Objektreplikation"). Dieser serialisiert unter Berücksichtigung optional angegebener Filter die benötigten Objekte und transferiert sie über den Kommunikationskanal an den Empfänger, wo der Objektstruktur-Demarshaller (OSdM) die Objekte entsprechend entpackt. Einige Besonderheiten des Objektstruktur-(De-) Marshallers :

- Er erlaubt strukturspezifische Traversierungen, bei denen die Objektmenge so ergänzt wird, dass sie fachlichen und technischen Integritätsregeln entspricht.

- Filter unterdrücken Objekte bestimmter Klassen.

- Zur Designzeit einer Klasse findet eine klare Trennung von kommunikationsrelevanten und prozessprivaten Attributen statt

- Die je Klasse verarbeiteten Attribute können durch zur Laufzeit erstellte Filter weiter eingeschränkt werden; diese Filter werden direkt zwischen den kommunizierenden Programmen vereinbart.

- Neben der Erstellung eines Strukturreplikats auf Empfängerseite ("Copy") kann auch ein Verschmelzen ("Merge") mit einem bereits vorhandenen Replikat stattfinden, etwa bei Update-Anfragen.

- Die Klassen benötigen keine speziellen Methoden zur Übertragung.

Dieses Verfahren führt zu einer stabilen und performanten Kommunikation auch großer Mengen von Daten und Objekten. Das Hinzufügen und Ändern von Klassen geschieht wie gewohnt im Anwendungscode, ohne dass zusätzlich Schnittstellen-Dateien gewartet werden müssen. Dies führt zu kurzen Turnaround-Zeiten in der Entwicklung. Von der Middleware werden im Wesentlichen Basiseigenschaften verwendet, sodass ein relativ schneller Austausch, etwa aufgrund weiterer Anforderungen an Infrastrukturdienste, verhältnismäßig einfach möglich ist.

Im angeführten Projekt wurde das Verfahren mit Delphi für eine Windows-NT-Infrastruktur mit DCOM als Middleware realisiert. Hierbei wurden Laufzeit-Typinformationen zu den Objekten verwendet. Da diese nicht in jeder Programmiersprache zur Verfügung stehen, müssen sie dort geeignet ersetzt werden.

Die Schnittstellen verhalten sich hochgradig dynamisch und verwenden keine plattformneutrale Schnittstellen-Beschreibung wie die Interface Definition Language (IDL) von Corba. Sie sind damit nicht per se als "offene Schnittstellen" zu extern entwickelten Programmen verwendbar; dazu müssten Zusatzmaßnahmen getroffen werden. Bei mehreren getrennten oder unterschiedlichen Entwicklungsumgebungen sollte eine Synchronisation der unterschiedlichen Sichten auf Geschäftsobjektklassen und -strukturen über gemeinsam verwendete Repositories etabliert werden.

Das beschriebene Verfahren mit einem Ojectstruktur-Marshaller bietet sich vor allem dann an, wenn Server einer verteilten Anwendung häufig große Datenmengen liefern sollen und die Performance wichtig ist. Eine konsequent objektorientierte Sicht wird auch bei komplexen Anfragen bewahrt, da Anfrage- wie Antwortparameter aus Objekten oder Objektstrukturen bestehen.

Einen weiteren Nutzen liefert die Kapselung der Middleware gegenüber der Anwendungslogik, da einerseits der Aufbau von Middleware-Know-how auf wenige Entwickler beschränkt werden kann, andererseits die Schnittstellen in der verwendeten Programmiersprache entworfen werden. Zusammen mit dem dynamischen Charakter der Schnittstellen führt das zu einer stabilen Basis für Entwicklung und Wartung einer verteilten Anwendung, ohne dass sich das Projektrisiko oder der -aufwand erhöht.

*Dr.Thorsten Wenzel und Klaus Röder sind Berater und Projektleiter bei der Collogia Unternehmensberatung GmbH, Köln.

Abb: Update eines Replikats durch den Objektstruktur-(De)-Marshaller: Dabei identifiziert der Sender über die Quellspezifikation die betroffene Objektmenge. Unter Berücksichtigung anfragespezifischer Filter und der prozessübergreifenden Klassenvereinbarung (F) wird eine serialisierte Darstellung der Objekte erzeugt. Nach der Übergabe wird auf der Empfängerseite das Replikat der Objektstruktur aktualisiert. Dabei werden neu hinzugekommene Objekte instanziiert oder der Zustand bereits vorhandener Objektinstanzen abgeglichen. Quelle: Collogia