HUMBOLDT-UNIVERSITÄT ZU BERLIN I FÜR INFORMATIK · 2004-09-27 · KAPITEL 1. - EINLEITUNG 1.3...

HUMBOLDT-UNIVERSITÄT ZU BERLIN

INSTITUT FÜR INFORMATIKLEHRSTUHL FÜR SYSTEMANALYSE

DIPLOMARBEIT

Mobile Objekte in offenen Verteilten Systemen auf Grundlage des RM-ODP

JOACHIM DORN

Berlin, Juli 2004

INHALTSVERZEICHNIS1. Einleitung.......................................................................................................................................7

1.1 Einordnung der Arbeit...........................................................................................................71.2 Inhaltlicher Aufbau.................................................................................................................71.3 Form- und Schriftkonventionen........................................................................................... 8

2. Verteilte Systeme..........................................................................................................................92.1 Einleitung................................................................................................................................. 9

2.1.1 Überblick der Entwicklung von Verteilten Systemen............................................... 92.1.2 Vorteile von Verteilten Systemen für Anwendungen............................................. 102.1.3 Betrachtete Verteilte Systeme...................................................................................... 11

2.2 Das ODP-Referenzmodell für offene Verteilte Systeme................................................. 112.2.1 Einleitung....................................................................................................................... 112.2.2 Das objektorientierte Modellierungskonzept........................................................... 142.2.3 Sichtweisen auf ein ODP-System................................................................................162.2.4 Verteilungstransparenzen............................................................................................20

2.3 Objektorientierte Middleware............................................................................................ 222.3.1 Einleitung....................................................................................................................... 222.3.2 CORBA........................................................................................................................... 222.3.3 Java-Enterprise-Platform (J2EE)..................................................................................23

2.4 Spezifische Stärken und Schwächen des ODP-Referenzmodells...................................243. Steuerung der Verteilung durch Anwendungslogik...........................................................29

3.1 Vorüberlegungen.................................................................................................................. 293.1.1 Anwendungslogik als Koordinator............................................................................303.1.2 Neue mögliche Strategien der Middleware.............................................................. 303.1.3 Granularität der Verteilung.........................................................................................33

3.2 Erweiterung des ODP-Referenzmodells........................................................................... 333.2.1 Sichtweisen auf ein ODP-System................................................................................343.2.2 Verteilungstransparenzen............................................................................................343.2.3 Informations- oder Umgebungsmodell..................................................................... 343.2.4 Der Mobilitätsdienst..................................................................................................... 35

3.3 Genaue Definition der Erweiterung...................................................................................353.3.1 MOF-Überblick..............................................................................................................363.3.2 eODL-Überblick............................................................................................................ 373.3.3 Das Meta-Umgebungsmodell......................................................................................393.3.4 Der Mobilitätsdienst..................................................................................................... 423.3.5 Zusammenfassung........................................................................................................ 45

4. Existierende Verteilte Systeme mit mobilen Objekten ..................................................... 474.1 MobileRMI............................................................................................................................. 47

I

4.1.1 Bezug zur Erweiterung des RM-ODP........................................................................ 494.2 Mobile Agenten.....................................................................................................................50

4.2.1 Aglets.............................................................................................................................. 524.2.2 Nomads...........................................................................................................................534.2.3 Bezug zur Erweiterung des RM-ODP........................................................................ 53

4.3 Fazit.........................................................................................................................................555. Realisierung der vorgeschlagenen ODP-Erweiterung in Java...........................................57

5.1 Einleitung............................................................................................................................... 575.2 Flüchtige mobile Objekte als neuer Ansatz.......................................................................58

5.2.1 Spezialisierung des Anwendungsbereichs................................................................585.2.2 Flüchtige mobile Objekte............................................................................................. 59

5.3 Umsetzung.............................................................................................................................615.3.1 Einleitung....................................................................................................................... 615.3.2 Koordination der Verteilung von mobilen Objekten...............................................635.3.3 Das realisierte Umgebungsmodell............................................................................. 645.3.4 Serialisierung von Objekten in Java........................................................................... 665.3.5 Aufbau von mobilen Objekten.................................................................................... 675.3.6 Ablauf der Interaktion von mobilen Objekten..........................................................725.3.7 Weitere Implementierungsdetails.............................................................................. 755.3.8 Abschätzung des Leistungsverhaltens.......................................................................80

5.4 Bewertung.............................................................................................................................. 87

6. Zusammenfassung......................................................................................................................88

II

ABBILDUNGSVERZEICHNISKapitel 1. EinleitungKapitel 2. Verteilte Systeme

Abb. 1: ODP-Spezifikationskonzepte: Komposition/Dekomposition................................15Abb. 2: Sichtweisen auf ein System.......................................................................................... 16Abb. 3: Enterprise-Modellierungssichtweise.......................................................................... 17Abb. 4: Computational-Modellierungssichtweise..................................................................18Abb. 5: Engineering-Modellierungssichtweise.......................................................................19

Kapitel 3. Steuerung der Verteilung durch AnwendungslogikAbb. 6: Meta-UM als UML-Profil............................................................................................. 40Abb. 7: konkretes Umgebungsmodell Beispiel 1....................................................................41Abb. 8: konkretes Umgebungsmodell Beispiel 2....................................................................42

Kapitel 4. Existierende Verteilte Systeme mit mobilen Objekten Kapitel 5. Realisierung der vorgeschlagenen ODP-Erweiterung in Java

Abb. 9: Flüchtige mobile Objekte..............................................................................................60Abb. 10: Umgebungsmodell der Implementation................................................................. 64Abb. 11: Mobile Objekte durch Implementationsvererbung................................................68Abb. 12: Mobile Objekte durch Schnittstellenvererbung und dynamische Proxies......... 69Abb. 13: Mobile Objekte durch Proxy-Objekte und Delegation.......................................... 70Abb. 14: Mobile Objekte durch dynamische Subtypen......................................................... 71Abb. 15: Ablauf eines entfernten Aufrufs; Schritt 1............................................................... 73Abb. 16: Ablauf eines entfernten Aufrufs; Schritt 2............................................................... 73Abb. 17: Ablauf eines entfernten Aufrufs; Schritt 3............................................................... 74Abb. 18: Zusammenarbeit der Java-Threads.......................................................................... 79

Kapitel 6. Zusammenfassung

III

KAPITEL 1. - EINLEITUNG

1. EINLEITUNG

1.1 EINORDNUNG DER ARBEIT

Die vorliegende Diplomarbeit beschäftigt sich mit offenen verteilten Systemen und der Verteilung vonobjektorientierten Anwendungen in diesen Systemen. Unter näherem Bezug auf das ODP-Referenz-modell (RM-ODP), einem in diesem Umfeld etablierten Standard, werden verbreitete Konzepte zur Ver-teilung von Anwendungen analysiert. Dabei wird eine bestimmte Klasse von Anwendungen identifiziert, die von diesen Verteilten Systemennur unzureichend unterstützt wird, da den Anwendungen keine Möglichkeit geben wird, ihre eigeneVerteilung über die Knoten des Verteilten Systems aktiv zu beeinflussen. Für diese besonderen Fälle exis-tieren bereits spezialisierte Verteilte Systeme, die auch unter den Begriffen mobiler Code und mobileObjekte bekannt geworden sind und von denen im Laufe der Arbeit einige Beispiele vorgestellt werden.Das Anliegen der Arbeit ist es jedoch, das vorliegende RM-ODP dahingehend zu erweitern, dassAnwendungen auch in diesen Verteilten Systeme ihre Verteilung bei Bedarf manipulieren können unddamit die Notwendigkeit für spezialisierte Ansätze entfällt. Ergänzend zu den entwickelten Vorschlägenliegt eine prototypische Implementation für mobile Objekte in Java vor, die am Ende dieser Arbeit vorge-stellt und diskutiert wird.

1.2 INHALTLICHER AUFBAU

Die Arbeit ist in fünf große Abschnitte bzw. Kapitel gegliedert. Nach der Einleitung werden Verteilte Sys-teme allgemein eingeführt und anschließend das ODP-Referenzmodell als ein verbreiteter Standard füroffene Verteilte Systeme vorgestellt. Die Betrachtungen schließen mit einer Analyse über Schwachstellendieses Referenzmodells bei einer bestimmten Klasse von Anwendungen. Im dritten Kapitel wird eine Lö-sung für die gefundenen Unzulänglichkeiten entwickelt. Sie bestehen aus einer Einbeziehung derAnwendung selbst in die Koordinierung der Verteilung. Dazu wird eine Erweiterung des bestehendenRM-ODP vorgeschlagen. Der folgende Abschnitt gibt einen Einblick in existierende Entwicklungen aus anderen Bereichen ver-teilter und kooperierender Systeme und vergleicht diese Konzepte mit den oben entwickelten Lösungen.Im fünften Kapitel wird der entwickelte Prototyp vorgestellt. Dabei werden verschiedene mögliche Um-setzungen und auftretende Probleme diskutiert. Nach der inhaltlichen Zusammenfassung schließt dieArbeit mit einem Glossar der wichtigsten verwendeten Begriffe sowie einem Verzeichnis der verwende-ten Quellen und Ressourcen.

SEITE 7

KAPITEL 1. - EINLEITUNG

1.3 FORM- UND SCHRIFTKONVENTIONEN

Die Arbeit ist in Kapitel gegliedert, die jeweils numeriert sind. Die Kapitel können weiter in Subkapitelbis zur Tiefe zwei untergliedert sein (z.B. Kapitel 3.1.4). Einige Begriffe, die an der jeweiligen Stelle vonBedeutung sind und die gerade eingeführt werden, sind im fließenden Text speziell hervorgehoben. Zubesonders wichtigen Begriffen oder auch wiederholt verwendeten Abkürzungen existieren in der RegelEinträge im Glossar. Fußnoten1 sind innerhalb eines Kapitels fortlaufend nummeriert und werden jeweilsam Ende einer Seite erklärt. VerweiseIV auf Quellen oder andere wichtige Ressourcen werden am Endeder Arbeit erläutert. Im laufenden Text eingebetteter Quellcode ist durch eine Schriftart fixer Laufweiteoptisch hervorgehoben, längere Abschnitte oder Beispiele sind mit einem Rahmen eingefasst undmit einer Erklärung versehen:

Codebeispiel – Hallo Welt1. public class HalloWelt {2. public static void main(String[] args) {3. System.out.println(“Hallo Welt“);4. }5. }Hier befindet sich die Erklärung.

Abbildungen im Text haben einen Titel und tragen eine Nummer. Sie haben einen Eintrag im Abbil-dungsverzeichnis. Zitate sind in einem eigenen Absatz optisch abgesetzt und beinhalten einen Verweisauf ihren Eintrag im Quellenverzeichnis:

„Veni, vidi, vici“ [Julius Cäsar , 47 BC. IX]

Bei vielen verwendeten Fachbegriffen ist in Klammern das englische Pendant aufgeführt, vereinzeltwerden auch direkt englischsprachige Eigennamen verwendet (zum Beispiel Java-Enterprise-Platform).Der in dieser Arbeit zentrale Begriff des „Verteilten Systems“ wird als Eigenname aufgefasst und durch-gehend groß geschrieben. In Zusammenhang mit Details konkreter Technologie werden auch Akronymeverwendet (z.B. JVM, RPC) beziehungsweise Zusammensetzungen gebildet (z.B. Java-Thread). Bei Verweisen auf Ressourcen im Internet wird in der Regel auf die Angabe des Schemas http:// in derURL verzichtet (www.informatik.hu-berlin.de statt http://www.informatik.hu-berlin.de).

SEITE 8

KAPITEL 2. - VERTEILTE SYSTEME

2. VERTEILTE SYSTEME Dieses Kapitel beginnt mit einer kurzen Einführung Verteilter Systeme. Anschließend wird mit demODP-Referenzmodell ein grundlegender Standard für offene Verteilte Systeme vorgestellt, wobei der Fo-kus auf einigen ausgesuchten Aspekten und Konzepten liegt. Diese Spezialisierung lenkt die Aufmerk-samkeit auf bestimmte Fälle, bei denen einige Anwendungen unzureichend durch Verteilte Systemedieser Art unterstützt werden. Dies ist dann der Ausgangspunkt für die entwickelten Vorschläge imdritten Kapitel.

2.1 EINLEITUNG

2.1.1 ÜBERBLICK DER ENTWICKLUNG VON VERTEILTEN SYSTEMENDie Entwicklung von Verteilten Systemen ist eng gekoppelt mit der allgemeinen Entwicklung der Re-chen- und Computertechnik. Das Verständnis von Verteilten Systemen und ihre vorherrschenden Defini-tionen unterlagen während dieser Zeit bestimmten Wandlungen, die meist bedeutsame und neuartigeAspekte der jeweiligen Zeit in den Vordergrund stellten.Seit dem Aufkommen der Rechentechnik und ihrer gewachsenen Bedeutung im zweiten Weltkriegherrschte bis in die 60er Jahre des letzten Jahrhunderts die Nutzung im sogenannten Batch-Betrieb vor.Unabhängig von der stetig wachsenden Leistungsfähigkeit der damaligen Großrechner belegte eineeinzige Anwendung alle Ressourcen des Rechners. Verschiedene Aufgaben konnten nur sequentiell be-arbeitet werden.Weiterentwicklungen im Bereich der Betriebssteuerung dieser Großrechner ermöglichten dann schritt-weise Nebenläufigkeit von Anwendungen und damit den Mehrnutzerbetrieb. Damit wurden die Grund-lagen zu Betriebssystemen nach heutigem Verständnis gelegt, es konnten Rechenzeit, Speicherplatz undDaten nebenläufiger und konkurrierender Anwender verwaltet werden. Die Wurzeln der UNIX-Betriebs-systemfamilie stammen aus dieser Zeit. Anfang der 80er Jahre fanden Kleinrechner vermehrt Ver-breitung, da sie preiswert und zunehmend leistungsfähig wurden. Diese konnten relativ einfach zu loka-len Netzwerken mit fester Topologie verbunden werden. Dabei sollten gewohnte Merkmale des Mehr-nutzerbetriebs der Großrechner weiterhin erhalten bleiben. So musste eine übergreifende Verwaltung derRessourcen der Rechnernetze entwickelt werden sowie der Zugriff auf Daten unabhängig von ihrem tat-sächlichen physischen Aufenthaltsort in dem lokalen Netz ermöglicht werden.Aus dieser Zeit stammen verteilte Dateisysteme, erste verteilte Betriebssysteme und das Konzept entfern-ter Funktionsaufrufe (RPC1, Birell und Nelson, 1984 I). Die Definition von Tannenbaum und van Renessevon verteilten Betriebssystemen aus dem Jahre 1985 wird auch als eine ursprüngliche Definition von Ver-teilten Systemen allgemein betrachtet::

(1) RPC, Remote Procedure Call; siehe Glossar

SEITE 9


"A distributed operating system is one that looks to its users like an ordinary centralized operation system, butruns on multiple, independent CPUs. The key concept here is transparency, in other words, the use of multipleprocessors should be invisible (transparent) to the user. Another way of expressing the same idea is to say thatthe user views the system as a virtual uniprocessor, not as a collection of distinct machines.”[ TannenbaumA., van Renesse R., 1985 II]

Mit der weiteren Entwicklung und zunehmenden Vernetzung von Computern und dem Aufkommendes Internets änderte sich die Sichtweise auf Verteilte Systeme. Die Dimensionen wurden um ein Vielfa-ches größer, die Dynamik der Netztopologie nahm zu und die organisations- und staatenübergreifendeNatur des Internets förderte zunehmend dezentrale Sichtweisen und Organisationsformen. Gleichzeitigwurde die Objektorientierung zum beherrschenden Paradigma der Softwareentwicklung. Der ge-wandelte Blickwinkel auf Verteilte Systeme wird in der Definition von Coulouris aus dem Jahr 2000deutlich:

A distributed system is defined as one in which components at networked computers communicate and coordi-nate their actions only by passing messages. This definition allows for concurrent execution of programs, butprevents the possibility of a global clock and means that components can fail independently of one another.[Coulouris et al., 2000 III]

Durch die wachsende Bedeutung von Verteilten Systemen und das Vordringen in neue Anwendungsbe-reiche wie die Kommunikationstechnik wurden Bestrebungen verstärkt, durch StandardisierungRahmenbedingungen zu schaffen, die eine Interoperabilität der Produkte verschiedener Hersteller ge-währleisten sollte, um damit technische Innovation und wirtschaftliche Investitionssicherheit zu ver-binden. Einige der bekannten Referenzmodelle mit zum Teil unterschiedlichen Ausrichtungen bezüglichder Anwendungsdomänen sind z.B. TINA2 , RM-ODP3 oder MDA der OMG4. Auf Basis dieser Standardsgibt es verschiedene offene oder proprietäre Technologien wie CORBA, DCOM oder die J2EE-Plattform.

2.1.2 VORTEILE VON VERTEILTEN SYSTEMEN FÜR ANWENDUNGENUnabhängig von der inhaltlichen Ausrichtung bestimmter Anwendungen bieten Verteilte Systeme be-stimmte Vorteile gegenüber einzelnen, separaten Computern:

• Sie bieten im Allgemeinen bei vergleichbaren Kosten mehr Ressourcen (Rechenleistung, Spei-cher) als ein Einzelrechner. Die Grundlage dafür ist die Tatsache, dass die meisten Aufgabenstel-lungen von Anwendungen in separierbare Teile untergliedert werden können, die mit wenigenAbhängigkeiten parallel bearbeitet werden können. Eine Erhöhung der Leistungsfähigkeit bzw.Ressourcen von Rechensystemen ist wirtschaftlich viel günstiger durch nominale Vervielfälti-gung vorhandener physischer Bauteile möglich, als durch technologischen Fortschritt um einenentsprechenden Faktor. Selbst leistungsfähige Supercomputer erreichen ihre Leistungsdaten nurdurch interne Parallelisierung von Bauteilen.

• Sie bieten eine größere statistische Streuung des Ausfallrisikos bestimmter physischerKomponenten. Da es keine für den Gesamtbetrieb unersätzlichen Komponenten gibt, kann derAnwendungszweck auch bei einigen fehlerhaften Komponenten weiterhin verfolgt werden. Soist insgesamt eine höhere Verfügbarkeit und Zuverlässigkeit der Anwendungen realisierbar.

(2) TINA, Telecommunications Information Networking Architecture; siehe Glossar(3) RM-ODP, Reference Modell of Open Distributed Processing; siehe Kapitel 2.2(4) MDA & OGM, Model Driven Architecture ist ein Standard der Object Management Group; siehe Glossar

SEITE 10


• Durch den Aufbau aus räumlich verteilten, aber untereinander vernetzten Komponenten könnensie gleichzeitig zu verschiedenen externen Entitäten eine räumliche Nähe aufweisen. Dadurchsind Anwendungen relativ unabhängig von einem speziellen Ort einer Interaktion mit der Um-welt. Dies ermöglicht weitgehende Integration mit externen Systemen oder menschlichenBenutzern auch in Szenarien mit mobilen Akteuren.

2.1.3 BETRACHTETE VERTEILTE SYSTEMEIn dieser Arbeit werden nur Anwendungen und Verteilte Systeme betrachtet, die dem objekt-orientierten Paradigma folgen. Weiterhin werden eine Reihe von allgemeinen Charakteristika und Be-griffen für diese Verteilten Systeme angenommen:

• Verteilte Systeme bestehen aus räumlich verteilten Komponenten, die untereinander verbundensind. Die Komponenten werden als Knoten oder Host bezeichnet. Verbindungen werden imSinne von möglicher Signalübertragung bzw. Informationsaustausch betrachtet. Da Verteilte Sys-teme aus sehr vielen Knoten bestehen können und ebenso wie die Verbindungen dynamischenÄnderungen unterworfen sein können, sind Verteilte Systeme im Allgemeinen heterogen unddynamisch. Im Gegensatz zu verteilten Betriebssystemen gibt es keinen universellen Adressraumüber alle Knoten. In dieser Arbeit wird die Betrachtungsweise eingenommen, dass ein Knotengleichbedeutend mit einem abgeschlossenen Adressraum ist5.

• In einem Verteilten System kann es viele gleichzeitig aktive Anwendungen geben, die gege-benenfalls auf mehrere Knoten verteilt sind. Die Zuordnung der Objekte einer betrachtetenAnwendung zum Knoten des Verteilten Systems wird als eine gegebene Verteilung dieserAnwendung bezeichnet. Neben dieser statischen Verteilung oder Verteilungsstruktur kann derBegriff „Verteilung“ auch auf den Prozess der Zuweisung von Objekten auf Knoten bezogenwerden. Zur eindeutigen Trennung dieser beiden Bedeutungen wird die Änderung einer sta-tischen Verteilung in dieser Arbeit auch als Verteilungsänderung oder dynamische Verteilung be-zeichnet.

2.2 DAS ODP-REFERENZMODELL FÜR OFFENE VERTEILTE SYSTEME

2.2.1 EINLEITUNGIm Folgenden wird das ODP-Referenzmodell als repräsentativer Vertreter verschiedener Stan-dardisierungsbemühungen für Verteilte Systeme näher untersucht. Daneben existieren Standards andererGremien wie zum Beispiel TINA oder MDA. Obwohl das ODP-Referenzmodell schon einige Jahre exis-tiert und so nicht die neuesten Entwicklungen berücksichtigt, können viele aktuell verbreitete Technolo-gien wie CORBA oder die J2EE-Plattform im Wesentlichen als ODP-konform angesehen werden, so dasseine Betrachtung dennoch lohnend ist.Das Referenzmodell für offene Verteilte Systeme (Reference Model of Open Distributed Processing, RM-ODP) wurde entwickelt, um dem Fortschritt im Bereich des offenen verteilten Rechnens Rechnung zutragen und auf einer einheitlichen konzeptuellen Basis und Nomenklatur offene Verteilte Systeme zubeschreiben, zu entwerfen, zu entwickeln und zu integrieren. Dabei folgt es dem objektorientierten Pa-

(5) Ein Knoten kann aber eventuell mehrere Prozessoren unter einem Betriebssystem umfassen

SEITE 11


radigma. Das RM-ODP entstand in Kooperation der Internationalen Standardisierungsorganisation (ISO)und der Internationalen Telekommunikationsunion (ITU) Anfang der 90er Jahre. Die im RM-ODP de-finierten Begriffe und Strukturierungen werden darüber hinaus auch in neueren Standards anderer Gre-mien wieder aufgegriffen (z.B. bei MDA der OMG). Das RM-ODP kann als ein Metamodell angesehen werden, das die Konzeption und Entwicklung do-mänenspezifischer verteilter Anwendungen vereinfacht, die alle ähnlichen Ansprüchen an Offenheit, In-teroperabilität und Portabilität genügen müssen und aus Umgebungen stammen, die durch evolutionäreEntwicklung geprägt sind. Der Standard umfasst vier Teile und einen AnhangIV. Der erste Teil gibt einen Überblick und motiviertdie Schlüsselkonzepte. Der zweite Teil definiert in formalem Stil die Grundbegriffe, mit denen im drittenTeil die formalen Charakteristika bestimmt werden, nach denen die Konformität von konkreten Syste-men mit dem Referenzmodell nachgewiesen werden können. Der letzte Teil führt schließlich dieModellierungskonzepte aus Teil 2 auf bestehende formale Beschreibungstechniken wie LOTOS, SDL-92und ESTELLE zurück.

Als grundlegend für die Entwicklung des RM-ODP wurde die zunehmende Tendenz zur Offenheit vonVerteilten Systemen erkannt. Darunter versteht man den Trend, dass Informationssysteme zunehmendüber Unternehmens- und Organisationsgrenzen hinweg mit anderen Informationssystemen verbundenwerden und sich so Effizienz-, Kosten- und Flexibilitätsgewinne erzielen lassen. Für die Entwicklung undden Betrieb von Anwendungen bergen diese offenen Informationssysteme eine Reihe von neuen Heraus-forderungen und Möglichkeiten. Über folgende allgemeine Charakteristika definiert sich die Klasse derVerteilten Systeme6, die durch das RM-ODP adressiert werden soll:

1. Räumliche Verteilung: Die Knoten des Systems sind räumlich voneinander entfernt. Interak-tionen innerhalb des Systems können lokal (innerhalb eines Knotens) oder zwischen entferntenKnoten stattfinden.

2. Nebenläufigkeit: Komponenten oder Teile des Systems interagieren im Allgemeinen nebenläufig.

3. Kein Gesamtzustand: Der globale Zustand des Systems ist zu einem gegebenen Zeitpunkt nichterfassbar.

4. Ausfälle von Teilsystemen: Teilkomponenten des Systems können autonom ausfallen, d.h.einerseits ist ihr Ausfall nicht durch andere Komponenten des Verteilten Systems provoziert undandererseits hat ihr Ausfall nicht zwangsläufig den Ausfall weiterer Teilkomponenten zur Folge.

5. Asynchronität: Kommunikation und Verarbeitung haben Zeitverzögerungen. Eine genaue undglobal gültige Zeit gibt es jedoch nicht.

6. Heterogenität: Die Bestandteile des Verteilten Systems können verschiedenartig sein und mit derZeit wechseln. Dies betrifft verschiedene Ebenen wie Hardware, Betriebssysteme, Protokolle, Pro-grammiersprachen etc.

7. Autonomie: Es gibt keine zentrale Kontrolle und Administration im System. Vielmehr ist einNebeneinander und potentielle Überschneidungen von organisatorischen Verantwortungsbereichenmöglich.

8. Evolution: Der Lebenszyklus des Systems ist durch inkrementelle Veränderungen und Erweite-rungen der Aufgaben, der Infrastruktur und der Anwendungen gekennzeichnet.

(6) Siehe ISO/IEC 10746-1 Kap 6.1

SEITE 12


9. Mobilität: Physische Bestandteile wie Prozessoren, Datenträger, Interaktionsquellen und auch Pro-gramme können mobil sein.

Der Anspruch des RM-ODP ist es, Basis für flexible konkrete Architekturen zu sein, die Produkte unter-schiedlicher Hersteller integrieren können7. Durch Systematisierung des Entwicklungsprozesses vonAnwendungen und Trennung von anwendungsspezifischen und allgemeinen Anforderungen werdenTeilbereiche von geringerer Komplexität identifiziert die im modularen Zusammenspiel leistungsfähigeoffene Verteilte Systeme ergeben und gleichzeitig verbindlich vergleichbar sind. Zusammengefasstbesitzen ODP-konforme Systeme folgende Eigenschaften:

• offen – Sie sind portabel auf verschiedenen Arten von Knoten einsetzbar und können mitFremdsystemen interagieren.

• integriert – Sie integrieren ohne individuellen Entwicklungsaufwand unterschiedliche logischeKomponenten zu einem funktionierenden Ganzen.

• flexibel – Sie sind anpassungsfähig an Drittsysteme und deren Evolution. Sie sind fähig, Rekon-figurationen des Verteilten Systems zur Laufzeit zu überstehen.

• modular – Autonome, aber in loser Beziehung stehende Module bilden jeweils ein größeres Teil-system.

• können föderiert sein – Sie können aus mehreren technischen oder administrativen Domänenbestehen (z.B. unternehmens- oder staatsübergreifend).

• verwaltbar – Systemressourcen können überwacht und verwaltet werden. Damit sind Konfigu-ration, Dienstqualität und Zugriffsverwaltung realisierbar.

• bieten Dienstqualität – Reaktions- und Verarbeitungzeiten sind bestimmbar. Bei kontinuierli-chen Datenströmen werden Bandbreitengrenzen beachtet.

• sicher – Daten und Infrastruktur sind vor unberechtigtem Zugriff geschützt

• bieten Transparenzen – Anwendungen müssen keine Probleme lösen, die von der physischenVerteilung herrühren.

Inhaltlich besteht der Standard aus mehreren großen Kernbereichen, die in den Teildokumenten( ISO/IEC 10746-1 bis ISO/IEC 10746-4) wiederholt aufgegriffen werden:

Bereich 1Da Verteilte Systeme nach RM-ODP immer objektorientiert beschrieben und entwickelt werden, wird indiesem Abschnitt ein für die weiteren Ausführungen verbindliches Objektmodell entwickelt. Dabeiwerden Konzepte wie Objekt, Klasse etc. sowohl verbal als auch formal eingeführt.

Bereich 2Durch das Konzept von verschiedenen Sichtweisen auf ein System kann durch Weglassen von in der je-weiligen Sicht irrelevanten Details die Komplexität des zu betrachtenden Modells drastisch gesenktwerden. Es wird eine bestimmte Menge von Sichtweisen definiert, die über Verbindungen untereinanderdie notwendige Konsistenz wahren.

(7) Siehe ISO/IEC 10746-1, Seite 8

SEITE 13


Bereich 3Es wird eine Systeminfrastruktur definiert, die eine Reihe von Verteilungstransparenzen zu realisierenhat, auf die sich später Anwendungen in einem ODP-konformen Verteilten System verlassen können.

Bereich 4Dieser Bereich umfasst die Möglichkeiten der Validierung der Konformität von gegebenen VerteiltenSystemen mit dem RM-ODP.

Bereich 5Hier wird auf die Verwaltung von ODP-Systemen eingegangen. Es werden Verwaltungsmodelle,Verwaltungsdomänen und verschiedene Verwaltungsfunktionen betrachtet.

Für diese Arbeit sind besonders die Verteilungstransparenzen und die Einführung von Sichtweisen vonInteresse. Daher wird folgend nur selektiv auf die einzelnen Bereiche eingegangen.

2.2.2 DAS OBJEKTORIENTIERTE MODELLIERUNGSKONZEPTGrundlage der Spezifikation und Realisierung von Verteilten Systemen nach dem RM-ODP ist das objek-torientierte Paradigma. Objekte sind unterscheidbare Entitäten und kapseln Zustand und Verhalten.Alles, was sich nicht innerhalb eines Objektes befindet, wird als dessen Umgebung bezeichnet. Oft ent-sprechen Objekte auf abstrakte Weise realen Dingen oder Objekten der jeweiligen Anwendungsdomäne.Verhalten wird durch interne Aktionen eines Objektes oder durch Interaktionen zwischen Objektenermöglicht. Dabei kann sich der Zustand der beteiligten Objekte ändern. Eine Interaktion mit einem Objekt kann nur über definierte Schnittstellen (engl. interfaces) erfolgen, diedieses Objekt realisiert. Entgegen der öffentlich zugänglichen Schnittstelle ist das Innere des Objektes mitseiner konkreten Realisierung verborgen. Dies reduziert die direkten Abhängigkeiten im System undsteigert Flexibilität, Interoperabilität und Portabilität. Damit Objekte universell als Modelle beliebiger, evtl. realer Dinge verwendet werden können, ist dasKonzept der Objekte rekursiv anwendbar. Objekte können eine Komposition anderer Objekte sein, dieihrerseits in einer feineren Granularität wiederum Modell für weitere Substrukturen sind. Objekt-orientierung ist somit skaleninvariant, d.h. unabhängig den Dimensionen des modellierten Systems. ImRM-ODP kann ein Objekt gleichzeitig mehrere Schnittstellen realisieren.

SEITE 14


Als weitere Konzepte des Objektmodells im RM-ODP werden die Begriffe Typ und Klasse eingeführt, diesich aus mengentheoretischen Überlegungen zu Objekten mit gleichen Eigenschaften ableiten. Daraufaufbauend werden Typ- und Subtyphierarchien eingeführt. Während die Typ- und KlassendefinitionObjekte hinsichtlich ihrer Eigenschaften gruppiert, werden dabei keine Aussagen über die Entstehungvon Objekten gemacht. Objekterzeugung wird durch Schablonen (engl. templates) realisiert, die hinrei-chende Informationen besitzen, um Objekte mit einem initialen Zustand zu erzeugen. Schablonen werdenwiederum durch Schablonentypen beschrieben, die ihrerseits wieder zu Hierarchien organisiert werdenkönnen. Darüber hinaus gibt es weiteren Konzepte wie Verträge (engl. contracts) und Bindungen bzw.Verbindungen (engl. binding, liaison) zwischen kooperierenden Objekten8.

(8) Siehe ISO/IEC 10746-1; Kap. 7.3

SEITE 15

Abb. 1: ODP-Spezifikationskonzepte: Komposition/Dekomposition

übernommen aus ISO/IEC 10746-1 ; Kap. 7.2

C D

Figure 1 - Object composition


2.2.3 SICHTWEISEN AUF EIN ODP-SYSTEMDie Entwicklung von Anwendungen für Verteilte Systeme ist im Allgemeinen eine komplexe Aufgabe.Anforderungen müssen erkannt, strukturiert und umgesetzt werden. Dieser Entwicklungsprozess wirddurch mehrere, eventuell räumlich und zeitlich getrennte Personengruppen realisiert, die typischerweiseeinen jeweils eigenen Schwerpunkt des zu entwickelnden Modells betrachten. Um die Komplexität derEntwicklung zu senken, wird auch im RM-ODP das Konzept verschiedener Sichtweisen verfolgt. EineSichtweise (engl. viewpoint) auf ein System stellt eine bewusste Abstraktion dar, die nur Teile der ge-samten Anforderungen betrachtet und unter Auslassung von in diesem eingeschränkten Kontext irrele-vanten Teilen gewonnen wird.

Bei der Identifikation verschiedener Sichtweisen auf ein System können diese sich prinzipiell beliebigüberdecken oder orthogonale Aspekte betrachten. Es ist insgesamt jedoch von Interesse, mit den ge-fundenen Sichtweisen möglichst viele relevante Aspekte des Systems abzudecken und sinnvolle Bezie-hungen und Abhängigkeiten zwischen den Sichtweisen zu gewinnen. Obwohl keine Ordnung oderexplizite Anordnung in Schichtweisen definiert ist, wird es bei verbreiteten Entwurfsstrategien fürAnwendungen (z.b. Top-Down-Ansatz) wahrscheinlich eine bevorzugte Reihenfolge bei der Erstellungund Ausarbeitung der verschiedenen Sichtweisen geben.Das RM-ODP definiert fünf Sichtweisen auf ein Verteiltes System und stellt Abhängigkeiten zwischendiesen dar9. Für jede dieser Sichtweisen sind spezielle Ausdrucksformen wie etwa Spezifikations- oderModellierungssprachen vorgesehen. Die Ansichten werden im Folgenden vorgestellt:

(9) Siehe ISO/IEC 10746-1; Kap. 6.2.2

SEITE 16

Abb. 2: Sichtweisen auf ein System


1. Enterprise - ModellierungssichtweiseDas System als Ganzes und seine Umgebung werden aus der Sicht der allgemeinen Ziele des Unter-nehmens betrachtet. Es werden zum Beispiel die Rollen der Teilnehmer, vorhandene Besitzverhält-nisse und Autoritätsdomänen untersucht. Getroffene Anforderungen in dieser Sichtweise habenAuswirkungen auf die Umsetzungen der anderen Sichtweisen.

2. Informations - ModellierungssichtweiseDabei stehen die Informationen im Vordergrund, die vom System und seiner Umgebung ausge-tauscht und verarbeitet werden. Die beschreibende Sprache bedient sich dabei formaler Schemataüber Beziehungen von Informationen, die in die Kategorien invariant, statisch und dynamisch un-terteilt wird.

3. Computational – ModellierungssichtweiseHier erfolgt die funktionale Dekomposition in Schnittstellen und sie realisierenden Objekte. Eswerden also wesentliche Aspekte der Geschäftslogik in ein Objektmodell umgesetzt. Die Schnitt-stellen bzw. die sie realisierenden Objekte stellen prinzipiell die atomaren Einheiten einer späteren,möglichen Verteilung dar. Diese spätere Verteilung ist aber nur eine Option und ist an dieser Stellenicht relevant für die Abläufe der Geschäftslogik. Die Spezifikation stützt sich auf das bereits oben(Kap 2.2.2) erwähnte Objektmodell. In der Praxis kann diese Aufgabe durch Werkzeuge fürModellierungssprachen wie z.B. UML10 unterstützt werden.

(10) UML, Unified Modelling Language ; Weiter siehe Glossar

SEITE 17

Abb. 3: Enterprise-Modellierungssichtweise

Vereinfachtes Beispiel aus ISO/IEC 10746-1 S.47

ProviderUser Accessor

User

UserPolicy Domain A

Policy Domain B


4. Engineering – ModellierungssichtweiseHier wird auf die notwendigen Mechanismen für die Verteilung auf Knoten fokussiert. Sie sindüberwiegend unabhängig von der inhaltlichen Ausrichtung der Anwendung. So können sie voneiner separaten Infrastruktur realisiert werden. Es werden Konzepte wie Objekt, Channel, Cluster,Node, Capsule etc. verwendet. Es besteht ein enger Zusammenhang zwischen dieser und derComputational-Sichtweise. Während in der Computational-Sichtweise definiert wird, wann undwarum Objekte in einem Verteilten System interagieren, wird in dieser Sichtweise die Realisierungdieser Interaktionen in einem potentiell verteilten Umfeld spezifiziert.

SEITE 18

Abb. 4: Computational-Modellierungssichtweise

Grundlage ist wieder das Beispiel aus ISO/IEC 10746-1. Gegenüber Abbildung 3 sindsowohl Ähnlichkeiten, als auch eine feinere Strukturierung zu bemerken. Es sind diebeteiligten Objekte und ihre Bindung über Schnittstellen dargestellt.

CreatorDisplay Display

Repository

User User

User

Binding


5. Technology – ModellierungssichtweiseDies ist die Sichtweise auf das System und seine Umwelt mit Fokus auf die jeweils verwendetenTechnologien. Zur Entscheidung stehen hier nötige Hard- und Software unter Abwägung strate-gischer Gesichtspunkte (offene Standards, herstellerabhängige Lösungen) sowie Zuverlässigkeits-analysen und Kostenüberlegungen für die Phasen der Entwicklung und des Produktionseinsatzes.

Die Ausarbeitung der einzelnen Sichten bei der Entwicklung eines ODP-konformen Verteilten Systemskann zeitlich und vom Umfang her unterschiedlich sein. Die in einem konkreten Projekt gewählte Metho-de der Softwareerstellung, eventuelle rechtliche Bestimmungen oder auch Zertifizierungsauflagen habenzusätzlichen Einfluss auf den Umfang und die Ausprägung der Modellierung der jeweiligen Ansicht.

SEITE 19

Abb. 5: Engineering-Modellierungssichtweise

Der Ausschnitt bezieht sich wieder auf das gleiche Beispiel(ISO/IEC 10746-1). Gegenüber Abbildung 4 sind die neuenKonzepte (Node, Capsule, etc.) sowie eine Reihe vonHilfsobjekten zu sehen.

ComposerDisplay

Stub

User

Repository

CapsuleCluster

Binder Protocol

NodeProgrammatic reference points

Perceptualreference point

Interworkingreference point


2.2.4 VERTEILUNGSTRANSPARENZENDie Definition von Verteilungstransparenzen (engl. distribution transparencies) stellt den dritten Kernbe-reich des RM-ODP dar. Ein ODP-konformes Verteiltes System bietet seinen Anwendungen eine Reihevon Transparenzen, mit denen wesentliche Auswirkungen der physischen Verteilung verborgen werden.Durch sie werden Anwendungen von eigenem Aufwand zur Verwaltung der verteilten Ressourcen undObjekte befreit. Bei der Entwicklung von Anwendungen kann statt dessen auf die angebotenen Trans-parenzen zurückgegriffen werden und so dem eigentlichen Anwendungszweck volle Aufmerksamkeitgewidmet werden. Zur Laufzeit realisieren Dienste (engl. services) des Verteilten Systems die gewünsch-ten Transparenzen. Dieser Ansatz führt zur Entkoppelung der Anwendungslogik von dem ausführendenVerteilten System und fördert Modularisierung und Wiederverwertung bewährter Lösungen. Die Bereit-stellung dieser Verteilungstransparenzen erfordert jedoch zum Teil erheblichen Entwicklungsaufwandauf Seiten des Verteilten Systems und kann auch zur Laufzeit mit Leistungseinbußen der Anwendungenverbunden sein. So werden die folgenden, im RM-ODP definierten Verteilungstransparenzen nicht vonallen existierenden ODP-konformen Verteilten Systemen gleichermaßen unterstützt:

• Access-Transparenz Mögliche Unterschiede in der Datenrepräsentation (Zeichenkodierungen, Wortbreite, Byte-Rei-henfolge) oder bei Aufrufmechanismen (z.B. Parameterübergabe bei Methodenrufen) zwischenverschiedenen Hardwareplattformen oder Betriebssystemen werden durch einheitliche Me-chanismen ausgeräumt. Diese grundlegende Funktionalität wird von den meisten Realisierungenvon Verteilten Systemen geboten.

• Failure-Transparenz Damit kann jeweils eine bestimmte Klasse von Fehlern von Anwendungen ignoriert werden, dasie durch interne Fehlererholungsmechanismen nicht bis zur Anwendung durchdringen.

• Location-Transparenz Bei der Interaktion von Objekten wird von dem physischen Aufenthaltsort der beteiligten Objek-te abstrahiert. Allein die logischen Fähigkeiten und Beschränkungen der Anwendungsobjektebestimmen den Ablauf der Interaktionen.

• Migration-TransparenzAus der Sicht eines Objektes einer Anwendung werden eventuell vorgenommene Ortswechselauf andere Knoten des Verteilten Systems nicht wahrgenommen. Bindungen und Referenzen zuund von anderen Objekten bleiben gültig. Mit dieser Verteilungstransparenz kann in einem Ver-teilten System intern Effizienz optimiert werden (Lastausgleich etc.).

• Relocation-TransparenzSie verbirgt zu lösende Probleme, wenn gebundene und gerade in Interaktion stehende Objekteihren physischen Ausführungsort wechseln. Diese Verteilungstransparenz ermöglicht struk-turelle Änderungen der zu Grunde liegenden Hardware und ihrer Vernetzung ohne die Un-terbrechung von laufenden Anwendungen.

SEITE 20


• Replication-TransparenzDadurch wird ermöglicht, dass sich hinter einer einzigen Schnittstelle (Interface) intern eineGruppe von Objekten verbirgt, die abwechselnd Interaktionen über diese Schnittstelle mitanderen Objekten durchführen. Alle Objekte dieser internen Gruppe verhalten sich nach außenunter gegebenen Eingaben gleich. Mit dieser Verteilungstransparenz kann Leistung und Verfüg-barkeit eines Verteilten Systems erhöht werden.

• Persistence-TransparenzDurch Mechanismen wie Aktivierung und Deaktivierung von Objekten kann der logischeLebenszyklus der Objekte durch Serialisierung ihres Zustands eventuelle Neustarts des VerteiltenSystems (oder Teilen davon) bei Fehlern oder Änderungen der Hardware überdauern.

• Transaction-TransparenzDie Koordination der Konsistenz der Zustände der interagierenden Objekte wird auch bei zeitlichparallelen bzw. nebenläufigen Aktionssträngen gewahrt. Die Feinheiten wie z.B. der Grad derACID-Eigenschaften11 sind je nach Realisierung variabel.

Bei der Entwicklung einer konkreten Anwendung für ein ODP-konformes Verteiltes System werden ge-wünschte Verteilungstransparenzen als Anforderungen in die Spezifikation aufgenommen und spätervom Verteilten System eingefordert. Damit ist im Entwurfsprozess einer Anwendung der Aspekt einerspäteren Verteilung abschließend behandelt. Bei der Modellierung der Geschäftslogik und des Informa-tionsflusses in der Enterprise- und Informations-Sichtweise und auch bei der funktionalen Dekompositi-on in Schnittstellen und Objekte in der Computational-Modellierungssichtweise wird nur auf die reineAnwendungslogik fokussiert. Die Implikationen einer späteren konkreten physischen Verteilung werdenausgeblendet.Das Konzept der Verteilungstransparenzen unterstützt und rechtfertigt das gewählte Konzept der Sicht-weisen, bei dem in einigen Sichtweisen Aspekte der Verteilung ignoriert werden. Die Realisierung einigerVerteilungstransparenzen kann sich auf ausgewählte ODP-Funktionen abstützen. ODP-Funktionen sindbenannte und separat nutzbare, im RM-ODP nur informal eingeführte Funktionalitäten, die grund-legende oder häufig wiederkehrende Probleme oder Abläufe in Verteilten Systemen adressieren. Ihr Fo-kus ist weniger die direkte Unterstützung von Anwendungen, sondern die Administration und Wartungdes Verteilten Systems. Die definierten ODP-Funktionen gliedern sich in die Bereiche Management-, Ko-ordinierungs-, Repository und Sicherheits-Funktionen. Ausgewählte Beispiele im Zusammenhang mit Verteilungstransparenzen sind beispielsweise Knotenver-waltungs-, Replikations-, Migrations- und die Umverteilungs-Funktion. ODP-Funktionen können selbstauch wiederum bestimmte Anforderungen an Verteilungstransparenzen stellen, so können Funktionenrepliziert werden, um ihre Verfügbarkeit zu erhöhen oder sie können eine gewisse Fehlertoleranz auf-weisen12.

(11) ACID-Eigenschaften; verbreiteter Begriff aus dem Bereich der Datenbanksysteme; betrifft Eigenschaften von Transaktionen (ACID= Atomicity,Consistency, Isolation, Durability)

(12) ODP-Funktionen siehe ODP-Standard (ISO/IEC 1074-1 Kap. 8.8)

SEITE 21


2.3 OBJEKTORIENTIERTE MIDDLEWARE

2.3.1 EINLEITUNGWie sich aus den Betrachtungen des letzten Abschnitts am Beispiel des RM-ODP ergeben hat, gibt es inoffenen Verteilten Systemen eine Reihe von immer wiederkehrenden Problemstellungen, die nicht durchdie inhaltliche Ausrichtung der jeweiligen Anwendungen, sondern durch die offene und physisch ver-teilte Natur des Systems bedingt werden. Im ODP-Referenzmodell wurden diese Anforderungen zumeinen unter dem Begriff der Verteilungstransparenzen erkannt und zum anderen in verwaltungs-technische oder allgemeine Abläufe unterstützende ODP-Funktionen gruppiert. Damit sind diesewiederkehrenden Problemstellungen aus den Anwendungen ausgegliedert. Anwendungen können sounter Annahme einer effizienten Realisierung dieser Mechanismen konzipiert und entwickelt werden. Die programmatische Infrastruktur, die die Basis eines Verteilten System ist und die die Transparenzenrealisiert, wird allgemein Middleware oder auch Middleware-Plattform genannt. Die Klasse der Verteil-ten Systeme, die auf diese Art strukturiert ist, wird auch Middleware-Architektur genannt. Da sowohldas RM-ODP, als auch der überwiegende Teil moderner Middleware-Plattformen dem objektorientiertenParadigma folgen, kann in dieser Arbeit der ebenfalls verbreitete Begriff der objektorientierten Middle-ware (engl. object middleware) als Synonym gesehen werden.Die Middleware als Software-Infrastruktur bietet ihren Anwendungen auf jedem Knoten des VerteiltenSystems eine einheitliche Menge an Funktionalitäten, unter deren Nutzung Anwendungen die eingangserwähnten Abstraktionen nutzen können. Diese zur Verfügung gestellte Funktionalität ist in Dienste ge-gliedert. Dienste realisieren durch programmatische Schnittstellen (API13) die Verteilungstransparenzenund unterstützen Anwendungen in folgenden drei BereichenV:

1. Identifikation benötigter Schnittstellen

2. Bindung an gewünschte Schnittstellen und Interaktion mit den die Schnittstellen realisierendenObjekten

3. allgemeine Verwaltung der Objekte (engl. life cycle management)

Anwendungen können beispielsweise mit Hilfe eines Namensdienstes Referenzen auf Schnittstellen vonObjekten außerhalb ihres eigenen Adressraumes erlangen und über diese Referenzen eine Bindung mitanschließender Interaktionen herstellen. In anderen Fällen kann mittels eines Transaktionsdienstes eineReihe von Interaktionen verteilter Objekte transaktional abgesichert erfolgen.

2.3.2 CORBAEin prominenter Vertreter für eine objektorientierte, ODP-konforme Middleware-Plattform ist die Com-mon Object Request Broker Architecture (CORBA). CORBA ist ein durch viele Implementierungen ver-breiteter Standard der OMG (Object Management Group), der die Entwicklung von administrations-,programmiersprachen- und herstellerübergreifenden Verteilten Systemen ermöglicht.

(13) API; Application Programing Interface

SEITE 22


Struktureller Kern ist die deklarative Schnittstellendefinition der Funktionalität in einer CORBA-IDL ge-nannten Beschreibungssprache. Von dieser Sprache ausgehend existieren für viele Programmierspracheneineindeutige formale Abbildungen auf jeweilige Datentypen und Aufrufmechanismen. Es existieren un-ter anderem Abbildungen von CORBA-IDL zu C++, Pyton, C# und Java.Zur Laufzeit übernimmt eine Middleware, ORB (Object Request Broker) genannt, die Kommunikationund Interaktion von Objekten über diese Schnittstellen innerhalb des Verteilten Systems. Durch die ge-meinsame Schnittstellenbeschreibung können die beteiligten Objekte intern in unterschiedlicher Weiseimplementiert sein, die Interaktion findet aber immer wohl definiert statt.Die im RM-ODP definierten Verteilungstransparenzen sind in kommerziell verwendeten CORBA-Syste-men mehr oder weniger ausgeprägt wiederzufinden. Grundlegende Transparenzen wie Access- oderPersistence-Transparenz werden durchgehend realisiert, der Ansatz einer eigenen Schnittstellen-beschreibung via CORBA-IDL und definierte Abbildungen auf Programmiersprachen sind ideale Voraus-setzungen für eine transparente Integration verschiedener Datenformate und verschiedener Mechanis-men von Funktionsaufrufen.Komplexere Verteilungstransparenzen wie die Transaction-Transparenz fallen in den Bereich des Trans-aktionsdienstes und sind durch die speziellen Herausforderungen verteilter Transaktionen nicht allge-mein üblich und gegebenenfalls auf die Unterstützung durch Subsysteme wie z.B. Datenbankmanage-ment-Systeme angewiesen.

2.3.3 JAVA-ENTERPRISE-PLATFORM (J2EE)Im Gegensatz zu CORBBA besteht die Java-Enterprise-Platform aus einer größeren Menge von aufein-ander abgestimmten Standards. Die Kontrolle dieser Standards unterliegt der Firma Sun14, die auch maß-geblich die Basistechnologie Java entwickelt. Da es neben Sun weitere, auch nichtkommerzielle Anbieterfür J2EE-Produkte gibt (z.B. IBM, Oracle, BEA, HP, Apache Tomcat, JBoss), erfolgt die Ausarbeitung derStandards in kooperativer Abstimmung. Als Forum dieser Gestaltung hat sich der Java-Community-Pro-cess (JCP)15 etabliert, der neben Organisationen auch Privatpersonen offen steht.Den Ansprüchen an eine Middleware-Plattform wird J2EE auf verschiedenen Ebene gerecht. Schon dieBasistechnologie oder Programmiersprache Java verfolgt den Anspruch, Anwendungen übergreifend fürverschiedenste Hardware-Plattformen und Betriebssysteme zu entwickeln. Dies wird dadurch realisiert,dass die Programmiersprache Java und die Java-Virtual-Machine (JVM16) eng aufeinander abgestimmtsind. Statt in jeweils nativen Programmcode wird Java meist in portablen Bytecode übersetzt, der unver-ändert auf allen Hardware- und Betriebssystemplattformen lauffähig ist, für die eine standardkonformeJVM existiert. So wird Access-Transparenz also schon teilweise durch die Basistechnologie Java gewähr-leistet. Verteilten Anwendungen kann mit Hilfe von JavaRMI17 Location- und Access-Transparenz überalle Knoten des Verteilten Systems garantiert werden. Abhängig von der jeweiligen Implementation sindauch Migration- und Relocation-Transparenz umgesetzt. Ein wichtiger Baustein für JavaRMI, aber auchfür andere J2EE-Spezifikationen, ist JNDI, der zentrale Namens- und Verzeichnisdienst mit der Möglich-keit eines verteilten und fehlertoleranten Aufbaus. Die EJB18-Spezifikation realisiert auf Grundlage von Ja-vaRMI zusätzlich Persistence- und Replication-Transparenz. Dies kann mit einer Transaktionskontrollevia JTS19 gekoppelt werden, die auch verteilte Transaktionen koordinieren kann. An verschiedenen

(14) Sun Corporation, siehe www.sun.com oder www.java.sun.com(15) JCP siehe www.jcp.org(16) Spezifikationen siehe java.sun.com/docs/books/jls/ bzw. java.sun.com/docs/books/vmspec/(17) RMI = Remote Method Invocation (18) EJB = Enterprise Java Beans(19) JTS = Java Transaction Service

SEITE 23


Stellen wird Failure-Transparenz realisiert, beispielsweise beim Ausfall eines JNDI-Servers oder Ausfäl-len von Teilen des Persistenz-Subsystems (verteilte Datenbanken). Der hauptsächliche Fokus von J2EEliegt natürlich auf der Entwicklung von Anwendungen in Java, allerdings stellt die JavaRMI Spezifikati-on auch Möglichkeiten zur programmatischen Interaktion mit CORBA-Systemen zur Verfügung unddurch die umfassende Integration von WebService-Schnittstellen ist eine generische Offenheit gegenüberanderen Technologien und Programmiersprachen gegeben.Jede einzelne Spezifikation ist in der Regel in einem eigenen Dokument beschrieben und beinhaltet so-wohl einführende Motivation und Beispiele, als auch formalere Syntax- oder Grammatikdefinitionen.Ergänzt wird dies jeweils durch eine Reihe von Schnittstellendefinitionen, die in spezielle Java-Packagesstrukturiert sind. Verschiedene Anbieter von J2EE-Produkten differenzieren sich durch die Qualität ihrerImplementation, bzw. die Vollständigkeit der Implementation des vorgegebenen Standards.

2.4 SPEZIFISCHE STÄRKEN UND SCHWÄCHEN DES ODP-REFERENZMODELLS

Die Stärken und Schwächen des RM-ODP sollen nicht allgemein und erschöpfend, sondern nur auseinem ganz bestimmten Blickwinkel diskutiert werden. Dabei steht das RM-ODP als Stellvertreter fürvergleichbare andere Standards und soll im Sinne dieser Arbeit für alle „klassischen Verteilte Systeme“stehen, bei denen die Middleware-Plattform komplett die Verteilung aller Anwendungen organisiert.

Allgemeine StärkenVerteilte Anwendungen die gezielt für offene Verteilte Systeme entwickelt wurden, können aus derAnnahme von Verteilungstransparenzen zur Laufzeit in vielen Bereichen entscheidende Vorteile gegen-über herkömmlichen Anwendungen beziehen. Das rührt daher, dass nicht speziell für Verteilte Systemeentwickelte Anwendungen nur eingeschränkt von den Möglichkeiten profitieren können, die eine ver-teilte Infrastruktur bietet. Während eine normale Anwendung auch in einem Verteilten System immer nur auf einem Knoten ab-laufen kann, können RM-ODP-konforme Anwendungen durch Verteilungstransparenzen die möglicheParallelität vieler Knoten erschließen (siehe Kap 2.1.2 ). Dies alles wird durch Verteilungstransparenzenmöglich. Die Objekte einer gegebenen Anwendung werden durch Rückgriff auf Location-, Access-, Relo-cation- und Migration-Transparenz des Verteilten Systems mit geringem eigenen Aufwand in die Lageversetzt, über die Grenzen des eigenen Adressraumes und damit über die Grenzen eines Knotens zu in-teragieren. Genau wie bei einer herkömmlichen Anwendung hat die eigentliche Geschäftslogik der ver-teilten Anwendung aber kein echtes Konzept ihrer tatsächlichen Verteilung auf konkrete Knoten zueinem bestimmten Zeitpunkt. Die zur Laufzeit vorliegende Verteilungsstruktur wird durch Konfigurati-on beim Start der Anwendung oder durch Entscheidungen der Middleware zur Laufzeit bedingt. Vom Standpunkt der Middleware aus gesehen könnte man auch informaler formulieren, dass ODP-kon-forme Anwendungen viel „toleranter“ oder „robuster“ gegenüber einer Verteilung auf mehrere Knotenund ihrer dynamischen Änderung sind. Diese Robustheit wird auch durch die anderen Verteilungstrans-parenzen wie etwa Failure-, Persistence- und Transaction-Transparency deutlich. Eine Anwendung kanndamit bis zu einem gewissen Grad nicht durch fehlerhafte Teilsysteme in Mitleidenschaft gezogenwerden und ist in der Lage, den eigenen Lebenszyklus über den der Middleware-Plattform oder des un-terliegenden Betriebssystems auszudehnen. Für viele Anwendungsfälle ist dieser Ansatz vollkommenausreichend.

SEITE 24


Spezielle SchwächenOffene Verteilte Systeme nach RM-ODP realisieren über Verteilungstransparenzen zur Laufzeit eine Ent-kopplung der Anwendungen von dem realen, sich verändernden Verteilten System aus vielen hetero-genen Knoten. Auch in der Entwicklungsphase von Anwendungen für solche Systeme werden konkreteAspekte einer möglichen Verteilung zur Laufzeit in den Abläufen der Geschäftslogik ausgeblendet. Darinkann bei bestimmten Anforderungen von Anwendungen eine Schwäche liegen. Aus Sicht der Middleware besteht die Zielsetzung eines Verteilten Systems darin, den Anwendungen ma-ximale Effektivität bzw. Leistung zu sichern und dabei die vorhandenen Ressourcen effizient zu nutzen.Darüber hinaus spielen Aspekte wie Fairness zwischen vielen nebenläufigen Anwendungen und Zu-verlässigkeit eine große Rolle. Zur Steigerung von Anwendungseffektivität und Ressourceneffizienzwerden nach Möglichkeit verschiedene Anwendungen dynamisch auf unterschiedliche Knoten verteiltoder Objekte einer Anwendung auf mehrere Knoten verteilt. Die dabei von der Middleware angewand-ten Strategien zur Verteilung entscheiden über das Erreichen der Zielsetzung.Werden die Entscheidungen über Verteilungsänderungen allein von der Middleware getroffen, fehlt alsodas Wissen um die domänenspezifische Geschäftslogik der jeweiligen Anwendung, so können diese Ent-scheidungen nur auf der Basis von Beobachtungen der vorhandenen Ressourcen und des Verhaltens bzw.des Ressourcenverbrauchs der Anwendungen getroffen werden. Die Middleware kann in diesem Fallalso immer nur reaktiv die Verteilung ändern. Grundlage ist dabei die allgemeine Annahme, dass einequalitative Verbesserung der Ressourcen (Rechenleistung, Speicherausstattung, Bandbreite etc.) immervorteilhaft für eine Anwendung ist. Die Middleware-Plattform teilt also einer Anwendung immer diebestmöglichen Ressourcen zu, die sich durch den Kompromiss aus Fairness gegenüber anderenAnwendungen und Auslastung der vorhandenen Ressourcen ergeben.Ein Verteiltes System, dass zur Laufzeit nur Verteilungstransparenzen bieten kann, ist immer dann fürseine Anwendungen nicht die optimale Plattform, wenn domänenspezifische Geschäftslogik für Entschei-dungen zur Reorganisation der Verteilung notwendig ist.

Verteilte Anwendungen mit speziellen AnforderungenDie Schwächen des Konzeptes der Verteilungstransparenzen treten nur bei der eben charakterisiertenspezialisierten Klasse von Anwendungen auf – eben immer dann, wenn die Middleware im Sinne derAnwendung keine vorteilhafte Verteilung wählt. Diese Klasse von Anwendungen mit besonderen An-forderungen lässt sich in zwei Untergruppen aufteilen:

• Gruppe 1:

Hier kann man alle Fälle zusammenfassen, bei denen Entscheidungsfindung über Änderung derVerteilung für die Middleware erheblichen Aufwand darstellt oder erst als deutlich verzögerteReaktion stattfinden kann. Würde statt dessen die Anwendung selbst auf Basis ihr bekannter In-formationen die Verteilungsstruktur manipulieren, wäre eine schnellere Entscheidung möglichund allgemein ein Gewinn an Effizienz zu verzeichnen.

Damit sind also die Szenarien gemeint, die prinzipiell auch durch eine beobachtende, reaktiveMiddleware entschieden werden könnten. Es liegen aber schon früher in der Geschäftslogik In-formationen vor, die zu dieser Entscheidung führen könnten. Beispiele lassen sich überall dortfinden, wo durch die Anwendungslogik absehbar bestimmte Ressourcen (Rechenleistung, Band-breite zu entferntem Knoten) intensiv benutzt werden. Konkret könnten das etwa Datenbanksys-teme für Gensequenzen oder geographischen Informationen sein, bei denen Anwendungenmassiv auf den umfangreichen Rohdaten operieren müssen. Die Anwendungslogik könnte einenTransfer der jeweiligen Objekte auf diejenigen Knoten veranlassen, die im jeweiligen Fall vorteil-

SEITE 25


hafter sind, da sie z.B. eine höhere Rechenleistung oder eine bessere Kommunikationsanbindungzum Interaktionsziel aufweisen. Die Middleware-Plattform würde im Gegensatz dazu erst abdem Überschreiten gewisser Schwellenwerte eine Umverteilung vornehmen, da ihr nur die Be-obachtung bleibt. Sind die Schwellenwerte zu hoch oder zu niedrig, nimmt die allgemeine Effizi-enz ab. Dabei sind auch unerwünschte Schwingungen vorstellbar.

• Gruppe 2:

Hier kann man alle die Fälle zusammenfassen, bei denen die Entscheidungen der Middlewarenicht vorteilhaft oder sogar kontraproduktiv sind. Die Steuerung der eigenen Verteilung ist indiesem Fall integraler Bestandteil der Geschäftslogik.

Möglich ist dies beispielsweise in Situationen, in denen gesichert werden soll, dass bestimmteFunktionalität einer Anwendung nur auf bestimmten Knoten des Verteilten Systems ausgeführtwird, oder bestimmte Knoten explizit von einer Verarbeitung ausgeschlossen werden. Dabeikann jedoch weiterhin eine Interaktion mit diesen Objekten etwa durch entfernte Methodenrufeaus dem gesamten Verteilten System heraus möglich sein. Es gilt lediglich, die Ausführung vonsensiblen Anweisungen und den Speicherort von sensiblem Zustand genau zu kontrollieren.Diese Einschränkungen können sich etwa durch Sicherheitsüberlegungen ergeben oder im kom-merziellen Umfeld aus bestimmten Abrechnungsmodellen resultieren. Dabei wird angenommen,dass diese Sicherheits- oder Abrechnungsmodelle zu komplex, zu dynamisch oder auch zu ge-heim sind, als dass eine Middleware-Plattform dafür standardisierte Mechanismen anbietenkönnte.

Weiterhin gibt es Situationen, in denen die Verbesserung der Ressourcenlage (CPU, RAM, Kom-munikationsressourcen, etc.) nicht das primäre Ziel der Anwendungslogik ist. Eine Anwendungist üblicherweise auf eine kleine Teilmenge der Knoten des großen, offenen Verteilten Systemsaufgeteilt. Es kann sein, dass sie aber Daten oder Informationen benötigt, deren Existenz indiesem Teil des Verteilten Systems nicht genau bekannt ist. Das wird auch als begrenzter Hori-zont bezeichnet. Erhält eine Anwendung etwa über andere Anwendung quasi via „Hörensagen“Hinweise zu gesuchten Informationen oder Ressourcen, hat sie in einem Verteilten System nachRM-ODP keine Möglichkeit, diesen Hinweisen nachzugehen. Nur durch eine von derAnwendungslogik aktiv gesteuerte Änderung der eigenen Verteilung besteht die Möglichkeit, andiese Informationen zu gelangen. Beispiele für solche Anforderungen finden sich im Zusammen-hang mit Information Retrieval im Internet, konkret bei den weiter unten betrachteten Systemenvon mobilen Agenten aus einer Forschungsrichtung der künstlichen Intelligenz.

SEITE 26


Es gibt auch Situationen, in denen eine rein reaktive Änderung der Verteilung durch die Middle-ware zu spät wirksam werden würde. Offene Verteilte Systeme zeichnen sich wie eingangserwähnt (siehe Kap. 2.2.1) auch dadurch aus, dass bei ihnen der globale Zustand nicht feststellbarist, dass sie veränderlich sind und Teile autonom ausfallen können bzw. unerreichbar werden.Hat nun eine Anwendung Informationen darüber, dass Teile des Verteilten Systems die für ihreweitere Funktion wichtig sind für einen gewissen Zeitraum unerreichbar werden, so kann nureine vorzeitige Änderung der Verteilung den weiteren Zugriff auf diese wichtigen Teile sichern.Beispiele sind etwa Sonden oder Sensorsysteme, deren Verbindung wiederholt und absehbarzum Rest des Verteilten Systems zeitweilig abbricht oder mobile Kommunikationsgeräte, die ausKostengründen keine permanente Verbindungen zum Rest des Systems haben. Liegen diese In-formationen schon in der Geschäftslogik vor, könnte eine rechtzeitige Reorganisierung der aktu-ellen Verteilung spätere Probleme vermeiden.

Damit ist nun hinreichend motiviert, dass es Anwendungen mit speziellen Anforderungen gibt, die vonVerteilten Systemen nach RM-ODP ungenügend unterstützt werden. Grund dafür sind die im RM-ODPdefinierten Verteilungstransparenzen, die Anwendungen unumgänglich von Details der Verteilungabkoppeln.

SEITE 27

KAPITEL 3. - STEUERUNG DER VERTEILUNG DURCH ANWENDUNGSLOGIK

3. STEUERUNG DER VERTEILUNG DURCH ANWENDUNGSLOGIK

Wie sich in den vorangegangenen Betrachtungen gezeigt hat, erfordern bestimmte Anwendungen eineaktive Kontrolle der eigenen Verteilung über die Knoten des jeweiligen Verteilten Systems. In diesem Ka-pitel wird dazu eine mögliche Umsetzung in Form einer Erweiterung des RM-ODP entwickelt. Es sindnatürlich andere Ansätze denkbar, die auf anderen Standards beruhen oder auch völlig eigenständigentwickelt werden. Mit der Steuerung der Verteilung durch die Anwendungen wird auch eine neue Betrachtung der Objektenötig, aus denen die Anwendung besteht und die über mehrere Knoten des Verteilten Systems verteiltwerden. Trotz der von der Middleware garantierten Verteilungstransparenzen ist es üblich, Objekte aufeinem entfernten Knoten aus technischer Sicht als entfernte Objekte zu bezeichnen. Mit der möglichenManipulation der Verteilung dieser entfernten Objekte durch die Anwendungslogik wird eine neueQualität erreicht. Dass die jeweiligen entfernten Objekte wirklich entfernt sind, ist für die Anwendungnicht mehr transparent und nur technischer Natur, sondern drückt sich direkt als beobachtbarer Zustandaus. Darüber hinaus ist der Ort dieser Objekte nicht nur beobachtbar, sondern auch aktiv manipulierbar.Daher werden diese Objekte im weiteren als mobile Objekte bezeichnet. Vor der Erweiterung des RM-ODP um Mobilität werden zunächst noch einige allgemeinere Vorüberlegungen angestellt.

3.1 VORÜBERLEGUNGEN

In Zusammenhang mit der Steuerung der Verteilung durch die Anwendungslogik können verschiedeneAspekte untersucht werden. Zum einen ist die Arbeitsteilung von Anwendung und Middleware bei derOrganisation und Manipulation der Verteilung der Objekte von Interesse. Aus dieser gegenüber bisherbetrachteten Verteilten Systemen neuen Konstellation erwachsen potentiell auch neue und gegenüberODP-konformen Verteilten Systemen veränderte Verwaltungsmechanismen der Middleware-Plattform.Dazu soll auf einige Punkte näher eingegangen werden, die kurz erläutert werden:

• Es ist nur notwendig, dass die Anwendungslogik als Koordinator einer Verteilungsänderung auf-tritt. Andere Aufgabenbereiche können von der Middleware des Verteilten Systems übernommenwerden und so die Anwendungen entlasten.

• Eingriffe in die Verteilung durch die Anwendungslogik stellen eine Einschränkung des Konzep-tes der Verteilungstransparenzen des RM-ODP dar. Die Middleware kann so eventuell auf ande-re Strategien und Mechanismen für die Verwaltung der mobilen Objekte der Anwendungen zu-rückgreifen.

• Mobile Objekte sind nicht die einzigen denkbaren Einheiten einer Verteilung. Aus dem Bereichder Komponenten-orientierten Verteilten Systeme gibt es größere Strukturen, die jeweils alsGanzes einem Knoten zugeordnet werden.

SEITE 29


3.1.1 ANWENDUNGSLOGIK ALS KOORDINATORFür eine Erstellung oder Änderung einer Verteilung von mobilen Objekten auf verschiedene Knoteneines Verteilten Systems lassen sind allgemein gesehen drei Aufgabenbereiche identifizieren:

1. InformationserfassungEine Entscheidung über eine Verteilungsänderung wird im Allgemeinen auf Basis aktueller In-formationen über das Verteilte System getroffen werden. Daher müssen irgendwie permanent In-formationen erfasst und geeignet aufbereitet werden. Dies können beispielsweise Eigenschaftenvon Knoten oder Eigenschaften der Verbindungen zwischen Knoten sein.

2. EntscheidungsfindungAuf Grund der gewonnenen Informationen und gewisser Regeln werden Entscheidungen über eineVeränderung der derzeitigen Verteilung abgeleitet.

3. EntscheidungsumsetzungDie getroffenen Entscheidungen müssen durch Transfers von Objekten der Anwendung auf andereKnoten des Verteilten Systems umgesetzt werden. Dabei muss die Konsistenz von Daten und Ab-läufen gewährleistet werden.

In ODP-konformen Verteilten Systemen werden alle diese Bereiche komplett von der Middlewarerealisiert. Dies ändert sich natürlich bei den nun betrachteten Anwendungen, die ihre eigene Verteilunggezielt steuern. Statt einer kompletten Verlagerung dieser Aufgaben auf die Anwendung ist es jedochweiterhin möglich, dass die Middleware des Verteilten Systems die Erfassung und Aufbereitung der In-formationen und die Umsetzung der Entscheidungen übernimmt. Lediglich der domänenspezifische Be-reich der Entscheidungsfindung muss von jeder derartigen Anwendung selbst realisiert werden.Also muss die Middleware die Anwendungslogik mit gewissen aktuellen Informationen über das Ver-teilte System und über die derzeitige Verteilung der eigenen Objekte versorgen. Die Anwendungslogikmuss ihrerseits ein Konzept einer Verteilung besitzen, also die eigene momentane Verteilung als Teil deseigenen Zustands wahrnehmen. Die in der Geschäftslogik getroffenen Entscheidungen über Änderungder momentanen Verteilung der Objekte auf die Knoten des Verteilten Systems müssen von der Middle-ware umgesetzt werden.

3.1.2 NEUE MÖGLICHE STRATEGIEN DER MIDDLEWAREDie im RM-ODP definierten Verteilungstransparenzen garantieren Anwendungen in entsprechendenVerteilten Systemen, dass sie keine funktionalen Auswirkungen der momentanen Verteilung oder ihrerdynamischen Änderung zu spüren bekommen. Dies ist auch nötig, da diese Anwendungen keineMöglichkeiten zur Reaktion oder Vermeidung von negativen Konsequenzen einer Umverteilung haben.Dies ändert sich durch die direkte Steuerung der Verteilung durch Anwendungen. Die Middleware mussderart starke Garantien nicht mehr komplett aufrecht erhalten. Es kann vertretbar sein, dassAnwendungen bestimmten Einschränkungen unterliegen, die durch die momentane Verteilung bedingtsind. Diese Einschränkungen sind jedoch für die Anwendungen beherrschbar, da sie durch Ver-änderungen der Verteilung vermeidbar sind oder umgangen werden können. Im Gegenzug für dieseschwächeren Garantien der Middleware ist eine Entlastungen der koordinativen Aufgaben der Middle-ware-Plattform möglich.

SEITE 30


Beispiel: Referenzen zwischen ObjektenEin Beispiel für eine koordinative Aufgabe der Middleware stellt die Verwaltung von Referenzen zwi-schen Objekten dar. Die Verteilungstransparenzen des RM-ODP stellen sicher, dass Anwendungen ein-mal erlangte Referenzen unter allen Umständen und bei jeder Verteilungssituation nutzen können. Fürdie Middleware bedeutet diese Garantie erheblichen Aufwand. Normale direkte Referenzen basieren in-tern auf konkreten Speicheradressen und sind so auf den jeweiligen Adressraum der Objekte beschränkt.Sollen voneinander entfernte Objekte über Knotengrenzen miteinander interagieren, so ist das nur überHilfsmechanismen wie entfernte Referenzen zu realisieren. Bei einem Transfer dieser Objekte auf andereKnoten, etwa bei internen Lastausgleichen der Middleware-Plattform zwischen den einzelnen Knoten,müssen diese entfernten Referenzen konsistent und von den Anwendungen unbemerkt aktualisiertwerden.Mit einer Einschränkung der Verteilungstransparenzen kann ein Verteiltes System so konzipiert werden,dass die aufwendige Verwaltung der entfernten Referenzen eingeschränkt oder vermieden wird. DieseVereinfachung erfordert aber eine gewisse Spezialisierung auf bestimmte Anwendungen oder Situa-tionen. Folgende Strategien für die Verwaltung von Referenzen sind bei einem Transfer eines Objektesauf einen neuen Knoten aus der Sicht der Middleware denkbar:

1. Strategie:

Das betreffende Objekt wird normal zu dem neuen spezifizierten Knoten transferiert. Die Middlewa-re muss entfernte Referenzen verwalten.

2. Strategie:

Das betreffende Objekt und alle durch Referenzen verbundenen Objekte werden auf den spezifi-zierten Knoten transferiert. Es müssen keine entfernten Referenzen verwaltet werden.

3. Strategie:

Es werden von dem betroffenen Objekt und allen durch Referenzen verbundenen Objekten Kopienangelegt und diese auf den neuen Knoten transferiert. Es müssen ebenfalls keine entfernten Referen-zen verwaltet werden.

Eine konkrete Middleware-Plattform kann dabei auf eine bestimmte Strategie oder eine bestimmte Misch-form ausgelegt sein. Es ist aber nicht vorgesehen, dass die Middleware bei jedem Transfer eines Objekteseine andere Strategie wählt. Einige dieser Strategien scheinen zunächst unpraktikabel. Wie in der nach-folgenden Erläuterung jedoch deutlich wird, ermöglichen sie unter bestimmten Randbedingungenwesentliche Vereinfachungen seitens der Middleware.

1. Strategie - ein Objekt wird transferiert, entfernte Referenzen werden verwaltetDiese Strategie ist universell anwendbar. Mit ihr können auch Verteilte Systeme nach dem ODP-Referenz-modell realisiert werden. Nachteil dieser Variante ist der Aufwand für die Middleware. Im allgemeinenFall müssen bestehende direkte Referenzen in entfernte Referenzen umgewandelt werden oder be-stehende entfernte Referenzen aktualisiert werden. Darüber hinaus sind Referenzen meist gerichtet, sodass zu einem gegebenen Zielobjekt nicht alle auf dieses Objekt verweisenden Referenzen effizient er-mittelt werden können.

SEITE 31


Entfernte Referenzen werden oft mit Hilfe von lokalen Proxy-Objekten1 realisiert, in dieser Rolle werdensie auch als Stub-Objekte bezeichnet. Beim Transfer eines Objektes müssen alle entfernten Referenzenkonsistent aktualisiert werden. Dabei muss sichergestellt werden, dass andere Objekte auch über unter-schiedliche Ketten von Referenzen das gerade im Transfer befindliche Objekte immer eindeutig identifi-zieren und nicht etwa eine alte „Version“ auf einem nicht mehr aktuellen Knoten treffen. Da es wieerwähnt praktisch unmöglich ist, zu einem gegebenen Objekt alle darauf verweisenden Referenzen zu er-mitteln, müssen spezielle Mechanismen wie etwa Verweisobjekte eingesetzt werden, die veraltete Refe-renzen auf den neuen Knoten umleiten. Alternativ könnten auch ungültige Referenzen zugelassenwerden und für diesen Fall eine Fehlererholung angeboten werden, etwa über einen globalen Namens-dienst, der immer eine aktuell gültige Referenz auf ein gesuchtes Objekt liefern kann.

2. Strategie - das Objekt und alle referenzierte Objekte werden transferiertBei dieser Strategie wird das eigentlich zu übermittelnde Objekt und die transitive Hülle aller durchReferenzen verbundener Objekte transferiert. Dadurch sind nach dem Transfer auf einen entferntenKnoten alle späteren potentiellen Interaktionspartner des gegebenen Objekts auch ohne entfernte Refe-renzen wieder garantiert im selben Adressraum erreichbar. In der Praxis ist es wieder problematisch, alleüber Referenzen verbundene Objekte zu bestimmen, da nicht alle auf ein gegebenes Objekt verweisendenReferenzen ermittelt werden können. Die Middleware ist jedoch davon entlastet, entfernte Referenzen zupflegen. Die weiter unten aufgeführten Projekte aus dem Bereich der mobilen Agenten verfolgen zumTeil sehr konsequent diese Strategie (siehe Kap. 4.2). Problematisch ist die nebenläufige Interaktion vonObjekten, da ein Transfer eines beteiligten Objekts zu einem anderen Knoten immer eine Fehlersituationfür die anderen Abläufe (Prozesse, Threads etc.) provoziert. Es ist sinnvoll, diese Strategie bei der Interaktion mit Objekten anderer Anwendungen mit der obigen zukombinieren und entfernte Referenzen zwischen Objekten unterschiedlicher Anwendungen zulassen.

3. Strategie - Transfer von KopienHierbei werden neben dem betrachteten Objekt alle über Referenzen erreichbaren Objekte kopiert undanschließend zum neuen Knoten transferiert. Alle bestehenden Referenzen auf dem alten Knoten bleibengültig, es gibt keine entfernten Referenzen.Der offensichtliche Nachteil besteht darin, dass nach einem Transfer ein betrachtetes Objekt in mehreren„Inkarnationen“ auf verschiedenen Knoten vorliegt und damit der Zustand inkonsistent werden kann.Das Anwendungsfeld dieser Strategie besteht damit eher in einer Kombination mit anderen Strategien.Ein solcher Transfer von Kopien von Objekten kann aber immer dort angewendet werden, wo die ge-naue Identität der Objekte unwichtig ist und sie zustandslos sind bzw. einen konstanten Zustand haben.Ist dies gegeben, erfordert diese replizierende Strategie minimale Anstrengungen der Middleware undkommt ohne zentrale Komponenten wie etwa einen globalen Namensdienst aus.

ZusammenfassungAm Beispiel von Referenzen zwischen Objekten ist deutlich geworden, dass eine Abkehr von der unbe-dingten Einhaltung der Verteilungstransparenzen des RM-ODP neue Freiheitsgrade für die Middlewareund ihre Verwaltungsmechanismen bringen kann. Ähnliche Problemfelder lassen sich auch beim syn-chronisierten Zugriff mehrerer Kontrollflüsse auf Objekte finden, die während des synchronisierten Zu-griffs durch Transfers auf andere Knoten gelangen.

(1) Proxy-Pattern siehe Glossar

SEITE 32


3.1.3 GRANULARITÄT DER VERTEILUNGDie feinste mögliche Verteilung einer Anwendung über die Knoten eines Verteilten Systems ist durch denobjektorientierten Ansatz gegeben (siehe Kap. 2.1.3) und definiert Objekte als atomare Einheiten einerVerteilung von Anwendungen auf Knoten. Es sind aber auch größere Einheiten denkbar.In Komponenten-orientierten Verteilten Systemen gibt es zusätzlich zum Programmcode Metadaten, diedie initiale Verteilung und Konfiguration dieser Anwendungen definieren (CORBA-CCM, EJB). Darüberhinaus gibt es auch Technologie-unabhängige Beschreibungssprachen, mit denen durch allgemeinereKonzepte Metainformationen zur Verteilung und Konfiguration erstellt werden können. Ein Beispiel da-für ist die unten (Kap. 3.3.2) näher vorgestellte Extended Object Definition Language (eODL). Da diesedurch Metainformationen definierten Komponenten schon bei der Konfiguration und initialen Verteilungbei Anwendungsstart verwendet werden, liegt die Idee nahe, statt einzelner Objekte ganze Komponentenzur Laufzeit durch die Anwendungslogik umverteilen zu lassen.Diese Möglichkeit ist jedoch nicht allgemein praktikabel. Meist sind diese Metainformationen zur Struk-turierung in Komponenten oder Assemblies zur Laufzeit der Anwendung nicht selbst zugänglich.Außerdem beschreiben die Metadaten aktueller Technologien üblicherweise nur statisch einen initialenZustand und treffen keine erschöpfenden Aussagen über erlaubte Reorganisationen zur Laufzeit. Dennoch sind die dort verwendeten Konzepte und Begriffe eine wertvolle Grundlage für die notwendigeModellierung dynamischer Informationen über das Verteilte System, so wie sie für die Steuerung derVerteilung durch die Anwendungslogik nötig sind. Sobald es möglich ist, dass reale Verteilte Systemediese eigenen Metainformationen zur Laufzeit nutzen können und diese Metadaten auch dynamischeAspekte berücksichtigen, eröffnet sich eine interessante Alternative zur Verteilung einzelner Objekte.

3.2 ERWEITERUNG DES ODP-REFERENZMODELLS

Nun soll das in Kapitel 2.2 eingeführte RM-ODP dahingehend erweitert werden, dass auchAnwendungen unterstützt werden, die ihre eigene Verteilung steuern wollen. Aus Vereinfachungs-gründen sei an dieser Stelle angenommen, dass Anwendungen in solchen Verteilten Systemen entwederselbst exklusiv ihre Verteilung bestimmen oder dass, solange keine Eingriffe erfolgten, die Middlewarewie in bisher betrachteten Fällen die Organisation der Verteilung einer Anwendung übernimmt, die keinInteresse an einem Eingreifen hat. Damit sind konkurrierende Entscheidungen über die Verteilung vonObjekten ausgeschlossen.Durch diese Erweiterung erfahren einige bestehende Konzepte des RM-ODP eine Überarbeitung oderwerden durch Neues ergänzt. Diese Ergänzung besteht im Wesentlichen aus einer Definition eines gene-rischen Modells der momentanen Situation des Verteilten Systems, das die Middleware denAnwendungen anbietet. Der Zugriff auf dieses Informationsmodell wird durch einen ebenfalls neuen Mo-bilitätsdienst der Middleware möglich. Dieser setzt auch die Entscheidungen der Anwendungslogikdurch Transfers von Objekten zu anderen Knoten um. Leichte Änderungen ergeben sich bei den Sicht-weisen und den Verteilungstransparenzen während das dem RM-ODP zu Grunde liegende Objektmodellunverändert Bestand hat.

SEITE 33


3.2.1 SICHTWEISEN AUF EIN ODP-SYSTEMBei der Erweiterung des RM-ODP bleiben die vorhandenen Sichtweisen größtenteils unverändert. Es gibtjedoch eine entscheidende Veränderung in der Computational-Modellierungssichtweise. EineAnwendung die zur Laufzeit ihre eigene Verteilung manipulieren möchte, muss dazu in den Geschäfts-abläufen in bestimmter Weise die aktuelle Verteilungssituation berücksichtigen. In dieser Sichtweisemuss also schon ein Konzept einer späteren aktuellen Verteilung vorliegen und es müssen Abläufe zurManipulation existieren.In der Engineering-Modellierungssichtweise kann nun durch die Möglichkeit, einzelne Objekte auf ent-fernte Knoten zu transferieren, nicht mehr statisch von einer vorbestimmten Gruppierung der Geschäfts-objekte ausgegangen werden. Die Strukturierung in Konzepte wie node, cluster und capsule muss dyna-misch angepasst werden können.

3.2.2 VERTEILUNGSTRANSPARENZENAuch in einem Verteilten System in dem Anwendungen selbst ihre dynamische Verteilung steuern, sindeinige Verteilungstransparenzen (vgl. Kap. 2.2.4) notwendige Grundlage. Ohne Access-Transparenz isteine Interaktion zwischen entfernten Objekten wie auch mobilen Objekten nicht möglich. Auch dieanderen Verteilungstransparenzen wie Failure- oder Persistence-Transparenz haben im Falle einer durchAnwendungslogik gesteuerten Änderung von Verteilungsstrukturen weiterhin ihre Berechtigung. Alleindie Location-, Migration- und Relocation-Transparenz wandelt ihre Bedeutung. Es ist zwar weiterhinerwünscht, dass der physische Aufenthaltsort kein Hindernis für eine Interaktion von Objekten darstellt,er wird jedoch nicht vor der Anwendung verborgen, sondern wird als Teil des Informationsmodells überdas Verteilte System zum beobachtbaren Zustand.

3.2.3 INFORMATIONS- ODER UMGEBUNGSMODELLDas schon in den Vorüberlegungen dieses Kapitels erwähnte Informationsmodell ist die Basis auf der dieAnwendungslogik die eigene momentane Verteilung der Objekte über die Knoten des Verteilten Systemsüberwachen und beeinflussen kann. Im Kern ist es ein sich zur Laufzeit veränderndes abstraktes Abbildder Knoten und Verbindungen des betrachteten Verteilten Systems und der Verteilung der Objekte derAnwendungen auf diese Knoten. In einem allgemeinen, offenen Verteilten System kann dieses Modell aber kein zentrales Modell uni-verseller Gültigkeit sein, da der Gesamtzustand dieser Systeme nach Definition (siehe Kap. 2.2.1) nichtzu bestimmen ist. So sind, von einem bestimmten Knoten des Verteilten Systems aus betrachtet, nicht alleanderen Knoten hinreichen aktuell erfasst oder sogar unbekannt. Deshalb ist dieses Modell ein verteiltesModell und unterliegt zwangsläufig auf jedem Knoten einer eigenen Sichtweise, die den lokalen In-formationsstand dieses Knotens widerspiegelt. Da Anwendungen in einem Verteilten System im Allge-meinen über mehrere Knoten verteilt sind, können verschiedene mobile Objekte der gleichenAnwendung durchaus voneinander abweichende Informationen über das Verteilte System haben. Wenneine verteilte Anwendung Informationen über das Verteilte System zusammenführt, die von mehreren,räumlich getrennten Objekten stammen oder die sie durch Kommunikation mit anderen Anwendungengewonnen hat, muss neben dieser potentiellen Widersprüchlichkeit ebenfalls beachtet werden, dass auchnicht immer eine echte Vergleichbarkeit dieser Fragmente möglich ist. Zum Beispiel kann der selbephysische Knoten unter unterschiedlichen Bezeichnungen auftauchen. Zusätzlich zu diesen Abbildungs-

SEITE 34


problemen fehlt auch prinzipiell ein exakter gemeinsamer Zeitbezug, da es in offenen Verteilten Syste-men keine global gültige Zeitmessung gibt. Diese Charakteristika stellen gewissermaßen den schwierigs-ten Fall eines offenen Verteilten Systems dar, in vielen Verteilten Systemen sind „verlässlichere“ Be-dingungen und eindeutige Bezeichner vorhanden.Um den verteilten, lokal geprägten und unvollständigen Charakter dieses Informationsmodells zu be-tonen, wird dieses Modell im folgenden Umgebungsmodell (UM) genannt, auch wenn der Bezug aufden Begriff der Umgebung eines Systems in diesem Fall für sich alleine aus systemtheoretischer Sichtmissverständlich wäre.

3.2.4 DER MOBILITÄTSDIENSTDer Mobilitätsdienst ist ebenfalls eine Neuerung gegenüber dem RM-ODP. In ihm werden alle Aufgabengebündelt, die für eine Manipulation der Verteilung notwendig sind und die von der Middleware-Platt-form den Anwendungen zur Verfügung gestellt werden. Die Kernaufgaben des Mobilitätsdienstes sinddaher die folgenden:

1. Der Mobilitätsdienst muss den Anwendungen ein aktuelles und möglichst korrektes Umgebungs-modell über eine definierte Schnittstelle anbieten. Dieses Modell liefert möglichst viele Informa-tionen über das Verteilte System, die für die Entscheidung der Geschäftslogik ausschlaggebend seinkönnten. Die Korrektheit des Modells bezieht sich auf die Konsistenz zur Realität. Ein inkorrektesModell kann zu Fehlentscheidungen führen, die real messbare Nachteile bringen. Grob falscheModelle können sogar physikalische oder logische Grundannahmen einer jeden Anwendungslogikunterlaufen und so zu schweren Fehlern der Anwendung führen (z.B. Umgebungsmodell meldetnegative Latenzzeiten zwischen Knoten).

2. Der Mobilitätsdienst muss eine Schnittstelle anbieten, mit deren Hilfe eine Anwendung die Vertei-lung von eigenen Objekten verändern kann. Jede Veränderung muss zu einer Rückkopplung führenund von der Anwendung am Umgebungsmodell zu beobachten sein.

Für einen solchen Mobilitätsdienst sind viele Varianten denkbar und auch das den Anwendungen zurVerfügung gestellte Umgebungsmodell kann viele Ausprägungen haben. Damit verschiedene Variantenvergleichbar sind, ist es jedoch von Vorteil, einen gemeinsamen Bezug zu haben. Dieser übergreifende Be-zug wird in dieser Arbeit durch eine abstrakte Beschreibung des Mobilitätsdienstes sowie durch ein gene-risches Metamodell für Umgebungsmodelle hergestellt. Dieses Metamodell definiert technologieneutraleine Klasse von verschiedenen konkreten Umgebungsmodellen, die von den Mobilitätsdiensten verschie-dener, konkreter Verteilter Systeme realisiert werden könnten. Je nach Fähigkeiten der jeweiligen Middle-ware-Plattform werden konkrete Umgebungsmodelle mehr oder weniger komplex.

3.3 GENAUE DEFINITION DER ERWEITERUNG

Die Definition der vorgeschlagenen Erweiterungen des RM-ODP besteht aus zwei Teilen, der formalenCharakterisierung des Umgebungsmodells und der programmatischen Schnittstellen des Mobilitätsdiens-tes. Das Umgebungsmodell wird durch ein Metamodell definiert, während die notwendigen Schnitt-stellen des Mobilitätsdienstes nur vereinfacht in Pseudocode und erläuterndem Text ausgeführt werden,da eine reale Umsetzung wieder abhängig von der verwendeten Technologie ist.

SEITE 35


Durch die Festlegung eines geeigneten Metamodells für Umgebungsmodelle (Meta-UM) wird eineKlasse von konformen Umgebungsmodellen definiert, die durchaus einen untereinander unterschiedli-chen Informationsgehalt bezüglich der Struktur des Verteilten Systems aufweisen können. Die Definitiondes Metamodells erfolgt mit Hilfe der Meta Object Facility (MOF), die Notation erfolgt graphisch durchUML-Diagramme2 nach dem UML-Profil für MOF.Inhaltlich entspricht ein Umgebungsmodell einem Graphen, der Ähnlichkeiten zur Topologie derKnoten, Verbindungen und Objektverteilung des Verteilten Systems aufweist. Da es wie erwähnt bereitsaus dem Umfeld komponentenorientierter Verteilter Systeme Technologie-unabhängige Ansätze gibt, diefür die abstrakte Darstellung der Struktur von Verteilten Systemen geeignet sind, wird folgend nebenMOF in einem kurzen Überblick auch die Extended Object Definition Language (eODL) vorgestellt.

3.3.1 MOF-ÜBERBLICKMOF ist ein Standard der OMG (Object Management Group) und dient der Technologie-neutralen Spezi-fikation von Modellen beliebiger Domänen durch Metamodelle. Mit MOF können flexibel underweiterbar beliebige Modelle nach objektorientiertem Paradigma definiert werden. Die Spezifikationvon Modellen durch Metamodelle ist eine Alternative zur traditionellen Definition auf Basis vonGrammatiken. Der Vorteil von Modelldefinitionen über Metamodelle liegt in der Geschlossenheit desKonzeptes. Da sowohl die Spezifikation (Metamodell), als auch der Gegenstand der Definition letztend-lich wieder ein Modell ist, können sie durch gleiche Werkzeuge verwaltet und erstellt werden und not-wendige Transformationen zwischen Modellen können formal über Transformationen der Metamodelledefiniert und automatisiert werden. Es existieren beispielsweise Metamodelle für UML, eODL und MOF selbst. Die Notation für die Meta-modellierung mit MOF ist offen, üblich ist eine grafische Repräsentation durch UML-Klassendiagrammeoder das XML-basierende Austauschformat XMI3 in Zusammenhang mit einer Abbildung auf IDL-Schnittstellen. Als Standard der OMG ist MOF eng mit CORBA verzahnt.Grundlegend für das Verständnis der Metamodellierung ist die Unterscheidung der Begriffe Instanz undTyp. Beliebige konkrete Entitäten, die eine gewisse strukturelle Gleichheit haben, bilden einen Typ.Dieser Typ wird auch als Modell bezeichnet und die konkreten Entitäten sind die Instanzen dieses Typs.Dieses Konzept manifestiert sich direkt im Paradigma der objektorientierten Programmierung etwadurch Klassen und Instanzen. Die Metamodellierung wendet dieses Prinzip nun rekursiv an. Die erste Modellebene (M0 genannt) be-zeichnet konkrete Instanzen. Die einfache Modellebene M1 definiert Typen dieser Instanzen. Beispiels-weise könnte in einem UML-Klassendiagramm eine Klasse „Person“ existieren, von denen viele konkreteM0 Instanzen, also Personenobjekte, vorstellbar sind. Will man nun Aussagen über das spezielle Modelltreffen, in dem die Klasse „Person“ definiert wurde, gelangt man zur nächsten Stufe M2, dem UML-Me-tamodell. Mit Hilfe des UML-Metamodells ist die Menge aller gültigen Klassendiagramme definiert, alsoquasi der Typ von M1-Modellen gegeben. Das Modell M1 mit der gedachten Klasse „Person“ ist in dieserSicht nur noch irgendein beliebiges mögliches UML-Klassendiagramm, also eine konkrete Instanz vonM2. Mit der nächsten Stufe M3 ist universelle Abstraktionsfähigkeit erreicht. Auf dieser auch MOF-Meta-Me-tamodell (kurz MOF-Modell) genannten Stufe existieren die MOF-Konzepte, mit denen sich beliebige In-stanzen, also konkrete Metamodelle (M2), für jede domänenspezifische Modellierung definieren lassen.Weitere Abstraktionsstufen über M3 hinaus bringen keinen Zuwachs an Abstraktionsfähigkeit. Die

(2) UML, Unified Modelling Language ; siehe auch Glossar(3) XMI, XML Metadata Interchange; ein XML-basiertes Austauschformat für Metamodelle nach MOF; OMG-Standard

SEITE 36


wesentlichen Bestandteile im MOF-Modell sind MOF-Klassen, MOF-Assoziationen, MOF-Packages undMOF-Datentypen.

• MOF-Klassen - Sie modellieren Metaobjekte, sind also der Typ von Objekten in M2-Modellen.Sie können Attribute, Operationen, Referenzen etc. besitzen.

• MOF-Assoziationen - Sie drücken Beziehungen zwischen Metaobjekten von M2-Modellenaus. Sie besitzen Namen und drücken Kardinalitäten der Beziehung aus. Assoziationen sindimmer binär.

• MOF-Datentypen - Sie schränken die Belegungen von Attributen und Operationsparameternmit Werten ein, wobei der konkreten Belegung keine Identität im Sinne von echter Objektidenti-tät zugemessen wird. Es gibt einfache Datentypen (Integer, Boolean, String ...) und komplexe Da-tentypen (Aufzählungstyp, Containertyp, Strukturtyp und Aliastyp).

• MOF-Pakete - Sie gruppieren Modellelemente und modularisieren sie. Pakete können wiederModellelemente wie Klassen, Assoziationen, Datentypen und weitere Pakete enthalten.

Darüber hinaus gibt es viele weitere Konzepte wie z.B. Generalisierung/Verfeinerung auf die jedoch imRahmen dieser kurzen Übersicht nicht weiter eingegangen wird.

3.3.2 EODL-ÜBERBLICKDie Extended Object Definition Language (eODL) ist eine Empfehlung (Z.130VI) der International Tele-communication Union (ITU) und eine Erweiterung des ITU-Standards ODL. eODL ist eine Technologie-unabhängige Beschreibungssprache und dient der Entwicklung komponentenorientierter Verteilter Syste-me. Der Zuschnitt der Sprache auf CORBA-CCM4 ist jedoch unverkennbar. eODL ist selbst durch ein Me-tamodell mit Hilfe von MOF definiert. Ein zentrales Konzept von eODL ist die Betrachtung durch vierunterschiedliche Sichtweisen:

• Computational-SichtweiseBeschreibt die strukturellen Aspekte des Systems in Form von Objekten (computational objects,COs), deren funktionale Schnittstellen (Operation, Stream, Signal) sowie deren Ports. Mit demKonzept der Ports kann ausgedrückt werden, wie Objekte zu benötigten Schnittstellenreferenzengelangen, bzw. welche sie zur Verfügung stellen. Ports werden zum Teil auch auch unter eineruntergeordneten eigenen Sichtweise, der Konfigurations-Sicht betrachtet5.

• Implementations-SichtweiseArtefakte schaffen hier die Verbindung der Schnittstellendefinitionen der Computational-Sicht-weise und konkreten Implementationen, die diese Schnittstellen realisieren. In objektorientiertenSprachen entsprechen Artefakte Klassen.

(4) CORBA-CCM; CORBA-Component-Model ; eine komponentenorientierte Erweiterung von CORBA(5) Siehe ITU-T Recommendation Z.130, Annex A.4

SEITE 37


• Verteilungs-SichtweiseBeschreibt Systemaspekte, die bei der Verteilung zum Anwendungsstart und beim Betrieb un-abhängig von einer konkreten Zielumgebung von Interesse sind. Dabei werden CO-Typen undderen initiale Konfiguration in Form einer Assembly zusammengefasst. Zusätzlich werden Soft-ware-Komponenten spezifiziert, die diese COs realisieren.

• Zielumgebungs-SichtweiseDefiniert ein Modell eines Netzwerkes von Knoten (nodes) und deren Verbindungen (links),wobei die Identität der Knoten und Verbindungen irrelevant ist. Im Zuge der Integration derAnwendung in ein konkretes Verteiltes System kann mit Hilfe dieser Beschreibung eine automa-tisierte, topologisch äquivalente Verteilung der Assemblies auf konkrete Knoten erfolgen.

• Verteilungsplan (deployment plan): besteht aus Zielumgebung, Installations-Abbildungen,Assemblies und Instantiierungs-Abbildungen

• Installations-Abbildungen (installation map): definiert Zuweisung der Software-komponenten auf Knoten

• Instantiierungs-Abbildungen (instantiation map): definiert konkrete Instantiierungen vonCO-Typen und Zuweisungen initialer Referenzen.

Diese Übersicht ist stark vereinfacht, insbesondere sind die vielfältigen Zwischenbeziehungen der Sich-ten und die zu Grunde liegende Typhierarchie ausgelassen worden. Für den Fokus dieser Arbeit ist aberauch nur ein vergleichender Blick auf die Zielumgebungs-Sichtweise interessant, so wie sie in der eODL-Spezifikation unter Kapitel 5.6 „Target Environment Concepts“ beschrieben ist. Dort sind Knoten (nodes) und Knotenverbindungen (nodeLinks) definiert. Beliebig viele Knoten könnenverbunden sein und die Verbindungen sind wahlweise bidirektional. Auf einem Knoten sind beliebigviele Komponenten installiert. Eine Komponente kann auf beliebig vielen Knoten vorhanden (installiert)sein. Es gibt eine Reihe von vordefinierten Eigenschaften von Knoten und Verbindungen, die in eODL-Modellen ausgedrückt werden und die Informationen über das Verteilte System bereitstellen:

• Eigenschaften von Knoten:

• Prozessor (Typ, Frequenz)

• Hauptspeicher in kB

• Betriebssystem (Name, Version)

• Eigenschaften von Verbindungen:

• Bandbreite in kB/s

Für diese Eigenschaften existieren definierte Schnittstellenbeschreibungen in ITU-IDL. Erweiterungenum zusätzliche Eigenschaften sind nicht ohne eine Veränderung des Standards möglich.

Bewertung der Konzepte der Zielumgebungs-SichtweiseMit Modellen der Zielumgebungs-Sichtweise von eODL ließe sich auch zur Laufzeit die aktuelle Strukturdes jeweiligen Verteilten Systems abbilden. Einen Nachteil stellt jedoch der gewählte Ansatz dar, den In-formationsgehalt dieser Sichtweise bezüglich der Eigenschaften des Verteilten Systems statisch konkretzu definieren. Die per Standard festgelegten Eigenschaften sind zwar verlässliche Basis fürAnwendungen, darüber hinausgehende Merkmale von Verteilten Systemen wie etwa Latenzzeiten oder

SEITE 38


eventuelle Energievorräte drahtloser, mobiler Knoten können nur durch Erweiterungen des Standardsund damit des Metamodells realisiert werden.

3.3.3 DAS META-UMGEBUNGSMODELLNun wird das Meta-Umgebungsmodell vorgestellt. Zum klaren Verständnis der Zielsetzung dieses Ab-schnitts soll noch einmal kurz die Modellierung von verschiedenen möglichen Umgebungsmodellen mo-tiviert werden: Die tatsächliche physische Struktur des Verteilten Systems und die Verteilung der Objekte auf die Knotenist die Basis für Entscheidungen der Anwendung über Änderung dieser Verteilung. Die Geschäftslogikeiner Anwendung hat darauf aber nur indirekten Zugang über das ständig aktualisierte Umgebungs-modell, das durch den Mobilitätsdienst der Middleware bereitgestellt wird. Der konkrete Zustand desUmgebungsmodells zu einem Zeitpunkt ist daher der Bezugspunkt für Entscheidungen der Geschäfslo-gik und stellt eine Instanz des Umgebungsmodells dar (M0 nach MOF).Der Begriff Umgebungsmodell bezeichnet die einfache Modellebene M1 nach MOF, in der für eine kon-krete Middleware-Plattform festgelegt ist, welche Informationen ihr Mobilitätsdienst den Anwendungenzur Verfügung stellt. Das Umgebungsmodell ist für ein gegebenes Verteiltes System fix, es kannhöchstens über längere Zeiträume im Zuge evolutionärer Erweiterungen der Middleware veränderlichsein. Die Zielumgebungs-Sichtweise von eODL ist hiermit vergleichbar. Dort ist schon im Standard festgelegt,welche Information über die Struktur des Verteilten Systems abgebildet wird (Knoten und Verbindungensowie eine feste Menge an definierten Eigenschaften). Das hier vorgestellte Meta-Umgebungsmodell (Meta-UM) ist eine weitere Abstraktionsstufe und ent-spricht dem M2 Level von MOF. Auf dieser Stufe wird festgelegt, wie gültige Umgebungsmodelle allge-mein strukturiert sein können und welche Art Informationen sie generell über das Verteilte System ab-bilden können. Das Meta-UM wird durch ein MOF-Modell spezifiziert. Da viele der verwendeten Konzepte (Klassen, Re-lationen) des MetaUM bereits aus existierenden Sprachen bekannt sind, wird das MetaUM, statt als völligeigenständiges Metamodell, durch ein Profil des UML-Metamodells definiert. Damit werden bereits exis-tierende Konzepte wiederverwendet und die Definition auf die wesentlichen neuen Aspekte reduziert.

SEITE 39


Das MetaUM wird als M2-Modell durch folgendes UML-Profil definiert:

Betrachten wir eine mögliche Instanz des MetaUM – also ein spezielles Umgebungsmodell, welches voneinem konkreten Verteilten System realisiert sein könnte:Mit einer binären Relation können alle direkten bidirektionalen Verbindungen zwischen den Knotendargestellt werden. Das Umgebungsmodell würde damit jedoch den Anwendungen des Verteilten Sys-tems weniger Informationen liefern als etwa die statische Zielumgebungssicht von eODL, da keinerleiEigenschaften über die Knoten oder die Verbindungen abgebildet werden.

SEITE 40

Abb. 6: Meta-UM als UML-Profil

Alle durch das Meta-UM definierten konkreten Umgebungsmodelle bestehen aus einerMenge von Knoten, einer Menge von Relationen und einer Menge von mobilen Objekten.Die Relationen können n-stellig sein und haben Knoten als Bestandteile. Relationenkönnen optional auch Attribute haben. Attribute bilden beliebige Eigenschaften ab undkönnen mit Werten belegt werden (mehrwertige Attribute bzw. strukturierte Belegungensind zulässig). Mobile Objekte befinden sich auf Knoten, wobei sich ein gegebenesmobiles Objekt aus Sicht der Anwendungslogik zu jedem Zeitpunkt immer komplett aufgenau einem Knoten befindet.

Mit diesen wenigen Konzepten können alle Informationen über die Struktur einesVerteilten Systems und der Verteilung von Objekten ausgedrückt werden.

MetaUM <<profile>>

«meta»Association

«stereotype»hat Elemente

«meta»Class

«stereotype»Relation

«stereotype»Knoten

«stereotype»Mobiles Objekt

«stereotype»befindet sich

«meta»Attribute

«stereotype»Eigenschaft

1 1

1..*

0..*

10..*1

1

1..*0..*


Der Nutzen für Anwendungen wird durch Attribute der Relationen erheblich gesteigert. Die Beispielre-lation LinkInfo könnte mit Attributen wie „Bandbreite“ oder „Latenzzeit“ inhaltlich erweitert werden.Eine zusätzliche unäre Relation kann über Attribute wie „CPU-Typ(en)“ , „Hauptspeicher“ , „CPU-Leis-tung“ usw. alle knotenspezifischen Eigenschaften ausdrücken. Mehrstellige Relationen können z.B. administrative Verantwortungsbereiche, gegenseitige direkte Er-reichbarkeit von Knoten in drahtlosen Netzen und weitere beliebige Merkmale von Gruppen von Knotenabbilden. Ein derartiges Umgebungsmodell übertrifft den Informationsgehalt der Zielumgebungs-Sicht-weise von eODL um ein Vielfaches.

SEITE 41

Abb. 7: konkretes Umgebungsmodell Beispiel 1

Dies ist ein sehr einfaches Umgebungsmodell. Es existiert nureine Relation (LinkInfo) und es werden keine weiterenEigenschaften abgebildet.

Zur besseren Trennung der Modellebenen sind englischeBezeichner für die Elemente des Modells gewählt worden.

Beispiel1 <<MetaUM>>

«Knoten»Node

«Relation»LinkInfo

«Mobiles Objekt»ApplicationObjectX

2

-<<hat Elemente>>

0..*

-<<befindet sich>> 1

0..*


ZusammenfassungDurch das vorgeschlagene Meta-UM lässt sich für eine gegebene Middleware-Plattform ein konkretesUmgebungsmodell als Instanz des MetaUM definieren. Je nach Fähigkeit der Middleware wird ein einfa-cheres oder komplexeres Umgebungsmodell realisiert werden können. Damit Anwendungen diesesModell sinnvoll für Transferentscheidungen verwenden können, sollte jedoch in jedem Umgebungs-modell immer eine Relation gegeben sein, die die Verbindung der Knoten ausdrückt. Anderenfallswerden eventuell durch die Geschäfslogik Transferentscheidungen getroffen, die nicht umsetzbar sind.Eine implizite Annahme, dass alle bekannten Knoten verbunden sind, ist vor dem Hintergrund vontemporären Unerreichbarkeiten von einzelnen Knoten nicht allgemein zulässig (z.B. Handys, autonomeSonden etc.).

3.3.4 DER MOBILITÄTSDIENSTDer Mobilitätsdienst ist eine weitere Neuerung. Durch diesen neuen Dienst haben Anwendungen zurLaufzeit die Möglichkeit, das von der Middleware-Plattform bereitgestellte Umgebungsmodell sowieweitere unterstützende Mechanismen für die Änderung der Verteilung zu nutzen. Die entsprechendenprogrammatischen Schnittstellen sind einfach aufgebaut und reflektieren die beiden Aufgabenbereichedes Mobilitätsdienstes, die Bereitstellung eines Umgebungsmodells und die Umsetzung von Transferent-scheidungen. Da es sich bei den Schnittstellen immer um Technologie-abhängige Beschreibungen handelt, wird hiernur beispielhaft eine Variante in Java-ähnlichem Pseudocode gegeben. Dies gilt ebenso für das Umge-bungsmodell, das durch den Mobilitätsdienst bereitgestellt wird. In weiterführenden Arbeiten könntedafür auf standardisierte Abbildungen von MOF in die jeweilige Sprache zurückgegriffen werden, inJava steht dafür mit dem Java-Metadata-Interface (JMI) eine umfassende Spezifikation zur VerfügungVII.

SEITE 42

Abb. 8: konkretes Umgebungsmodell Beispiel 2

Das Umgebungsmodell ist gegenüber Beispiel 1 umfangreicher und für Anwendungen informativer.Es existiert eine unäre (NodeInfo) und eine binäre Relation (LinkInfo). Beide bilden mehrereEigenschaften über das Verteilte System ab.

Zur besseren Trennung der Modellebenen sind englische Bezeichner für die Elemente des Modellsgewählt worden.

Beispiel2 <<MetaUM>>

«Knoten»Node -CPU : Eigenschaft

-RAM : Eigenschaft-OS : Eigenschaft

«Relation»NodeInfo

-Latency : Eigenschaft-Bandwidth : Eigenschaft


«Mobiles Objekt»ApplicationObjectX

-<<hat Elemente>>

1 0..*

2

-<<hat Elemente>>

0..*


0..*


Alternativ ist auch der Weg über eine Abbildung via XMI in IDL denkbar, für das auch in viele Program-miersprachen Abbildungen bestehen.

Bereitstellung des UmgebungsmodellsDie Schnittstelle des Mobilitätsdienstes zur Erlangung des Umgebunsgmodells sieht nun beispielhaft wiefolgt aus:

EnvironmentModel model = mobilityService.getEnvironmentModel();

Der Typ EnvironmentModel entspricht dabei dem konkreten Umgebungsmodell des betrachteten Mo-bilitätsdienstes der Middleware. Es ist sinnvoll, für diesen Typ eine sehr generische Struktur festzulegen,da das Meta-Umgebungsmodell ebenfalls sehr generisch ist. Im Folgenden soll nur eine unvollständigeVariante angegeben werden, die aber die Absicht hinreichend verdeutlicht. Neben einigen Typdefini-tionen (z.B. für Identifier) fehlen dabei für reale Anwendungen nützliche Funktionalitäten, wie etwaMöglichkeiten zur Beobachtung von Elementen oder Werten des Modells (Observer/Listener-Entwurfs-muster). Da hier die Elemente einer Relation als Menge und nicht als geordnetes Tupel modelliertwurden, sind zusätzlich benannte Rollen für die Knoten zum Zwecke der Unterscheidbarkeit eingeführtworden. Dies ist aber nur der Einschätzung geschuldet, dass im praktischen Umgang eine Unterschei-dung der Knoten einer Relation über Namen verständlicher und weniger fehlerträchtig ist, als über eineIndizierung ihrer Position im Tupel (siehe RelationEntry).

interface EnvironmentModel {Set<Node> getNodes();Set<Relation> getRelations();Node getLocalNode();

}

interface Relation {EnvironmentModel getEnvironmentModel()Set<RelationEntry> getRelationEntries();String[] getRoles();Set<Property> getProperties();

}

interface RelationEntry {Relation getRelation();Set<Node> getParticipatingNodes();Node getNodeInRole(String role);Object getPropertyValue(Property property);

}

interface Property { String getName(); Type getValueType(); Relation getRelation();

}

interface Node {Identifier getIdentifier();

}

SEITE 43


In einem gedachten konkreten Fall könnte eine Anwendung über die Schnittstelle des Mobilitätsdienstesan ein Objekt des Typs EnvironmentModel und darüber an eine bestimmte Relation gelangen. DiesesRelationsobjekt besitzt eine Menge von Einträgen, mit denen nun Tupel von Knoten und Belegungen derEigenschaften der Relation abgebildet sind. Im Falle der gegebenen binären Beispielrelation LinkInfo(das wäre ein Relation-Objekt) würden die Einträge alle Zweierpaare von direkt verbundenen Knotenenthalten (Menge von RelationEntry-Objekten). Jedes Paar (ein RelationEntry-Objekt) bestehtaus den teilnehmenden Knoten in eventuell ausgezeichneten Rollen, sowie aus konkreten Werten derdurch die Relation definierten Eigenschaften. Aus dem Unterschreiten eines gewissen Wertes (z.B. freierHauptspeicher) könnte die Geschäftslogik dann eine Transferentscheidung für bestimmte Objekte ablei-ten.Obige Schnittstellenbeschreibung orientiert sich am Meta-Umgebungsmodell und ist generisch angelegt.Sowohl die Menge der Beziehungen der Knoten untereinander (Relationen), als auch die dabei erfasstenEigenschaften sind variabel. Dies hat den Vorteil, dass diese Schnittstellenbeschreibung unabhängig voneinem konkreten Umgebungsmodell einer konkreten Middleware ist. Alle Relationen und Attributekönnen von einer Anwendung zur Laufzeit über Reflektions- bzw. Inrospektionsmechanismen ermitteltwerden. Damit ist dieser Ansatz in Flexibilität und Erweiterbarkeit der Zielumgebungs-Sichtweise voneODL überlegen. Ein Nachteil dieser Flexibilität ist jedoch die Abwesenheit bekannter und garantierter Informationen.Anwendungen die ihre Verteilungsstruktur in Abhängigkeit von bestimmten Eigenschaften dynamischanpassen wollen (z.B. freier Hauptspeicher, Latenzzeiten zwischen Knoten), müssen dazu die passendeRelation „kennen“ und das konkrete Verteilte System muss diese Informationen auch anbieten. Es ist da-her zweckmäßig, jedoch weiterführenden Arbeiten überlassen, einem minimalen Informationsumfangder Umgebungsmodelle schon durch das MetaUM zu vereinbaren. Die öffentliche Verbreitung von zu-sätzlichen Relationen und ihren möglichen Attributen ist voraussichtlich am Besten durch zentraleVerzeichnisse zu erreichen. Die grundlegende Problematik ist hierbei ähnlich der Verwaltung von öffent-lich zugänglichen WebServices in UDDI-Verzeichnissen. In beiden Fällen steht der technisch einfachenVerwendung von fremder Funktionalität das schwierige, da semantisch begründete automatische Auf-finden der gewünschten Funktionen entgegen.

Umsetzung von VerteilungsentscheidungenDer zweite große Aufgabenbereich des Mobilitätsdienstes besteht aus der Umsetzung von Entschei-dungen der Geschäftslogik zu Verteilungsänderungen durch Transfers von mobilen Objekten auf ent-fernte Knoten. Konkret wird dabei ein Objekt der Anwendung durch den Aufruf einer speziellen Opera-tion des Mobilitätsdienstes zu einem anderen Knoten des Verteilten Systems transferiert. Auf die dabeimöglichen Auswirkungen auf die Referenzen des Objektes zu anderen Objekten ist bereits oben (vgl. Kap3.1.2) eingegangen worden. Die Repräsentation bzw. Identifikation des gewählten Zielknotens ist starkabhängig von dem konkreten Verteilten System und ist nicht allgemeingültig festzulegen. In offen Ver-teilten System mit universell eindeutigen Bezeichnern (z.B. IP-Adressen, URIs, etc.) ist dieses Problemleicht zu lösen, es gibt jedoch auch offene Verteilte Systeme ohne diese Ordnung. Deshalb ist in der ge-wählten Schnittstellenbeschreibung des Umgebungsmodells für den Typ Node auch der nicht näher spe-zifizierter Typ Identifier gewählt worden, der sich je nach konkreten Verhältnissen in dem jewei-ligen Verteilten System auf mögliche vorhandene Ordnungen abstützen kann. Es ist nur erforderlich,dass die Middleware zu einem Identifier eindeutig einen Knoten zuordnen kann. Ob zwei gegebeneIdentifier den selben Knoten bezeichnen, kann in sehr dezentral organisierten, offenen VerteiltenSystemen nicht allgemein entschieden werden. Die entsprechende Schnittstelle des Mobilitätsdiensteskönnte wie folgt aussehen:

SEITE 44


mobilityService.move(MobileObject object, Node target);

Eine alternative Möglichkeit besteht darin, dass Anwendungen nicht unmittelbar Objekttransfers initi-ieren, sondern statt dessen nur deklarativ die Zuordnung von mobilen Objekten auf Knoten entscheiden.Die Transfers würden also nicht direkt durch den Aufruf des Services stattfinden, sondern nur in den Fäl-len stattfinden, wo die bezeichneten mobilen Objekte später interagieren. Dies ließe der MiddlewareSpielraum bei der Durchführung der Transfers und vermeidet unter Umständen Transfers von Objekten,die nie aufgerufen werden. Die entsprechende alternative Signatur des Mobilitätsdienstes könnte dannwie folgt aussehen:

mobilityService.mapObjectToNode(MobileObject object, Node target);

Nach einer solchen Verknüpfung muss die Middleware dann sicherstellen, dass das mobile Objekt jedochauf jeden Fall vor einer Interaktion auf den zugewiesenen Knoten transferiert wird. Auch muss jederTransfer aus Sicht der Anwendung atomar erfolgen, d.h. auch parallele Interaktionen anderer Objekte mitdem spezifizierten Objekte müssen das Objekt zu jedem Zeitpunkt immer komplett auf genau einemKnoten antreffen.

3.3.5 ZUSAMMENFASSUNGIn diesem Kapitel wurde eine Erweiterung des RM-ODP vorgeschlagen, die neben neuen Konzepten aucheine Änderung bestehender ODP-Konzepte wie der Verteilungstransparenzen beinhaltet. Die Neue-rungen bestehen in einer durch ein MOF-Metamodell beschriebenen Klasse von Umgebungsmodellen,die alle möglichen Informationen über die momentane Struktur und Eigenschaften eines Verteilten Sys-tems abbilden kann und aus einem neuen Dienst der Middleware, mit dessen Hilfe Anwendungen dasUmgebungsmodell nutzen und daraus abgeleitete Entscheidungen über eine Änderung ihrer Verteilungumsetzen können. Über die Realisierbarkeit der Vorschläge lässt sich an dieser Stelle nur spekulieren. Un-ter Vorgriff auf spätere Kapitel dieser Arbeit kann man jedoch von einer möglichen Umsetzung ausgehen.Im folgenden Kapitel werden spezialisierte Varianten von offenen Verteilten Systemen vorgestellt, diesich von ODP-konformen Verteilten Systemen unterscheiden. Diese andersartigen Verteilten Systemensind zum Teil sehr speziell auf eine Anwendungsdomäne fokussiert. Bei ihnen ist jedoch die Kontrolleder eigenen Verteilungen durch die jeweiligen Anwendungen eine Schlüsselfähigkeit.

SEITE 45

KAPITEL 4. - EXISTIERENDE VERTEILTE SYSTEME MIT MOBILEN OBJEKTEN

4. EXISTIERENDE VERTEILTE SYSTEME MIT MOBILEN OBJEKTEN

Im Zusammenhang mit Programmen, die in einem Umfeld aus vernetzten und verteilten Rechnern einge-setzt werden, ist der Begriff mobiler Code bekannt. Damit wird die Fähigkeit umschrieben, dass in einemNetz von verschiedenen Einzelknoten Programme verteilt ausgeführt werden können, ohne dass der da-zugehörige Programmcode im Vorfeld auf den jeweiligen Knoten installiert wurde. Statt dessen wird derProgrammcode zur Laufzeit je nach Bedarf auf die Knoten verteilt. Mobiler Code findet auch schon teilweise in etablierten Technologien wie etwa der ODP-konformenJ2EEPlattform Verwendung1. Die hauptsächlich mit mobilem Code in Verbindung gebrachten Systemesind jedoch verschieden von den bisher betrachteten Verteilten Systemen. Aus diesem Bereich sollen imRahmen dieser Arbeit einige Vertreter der Gruppe der mobilen Agenten und das Forschungsprojekt Mo-bileRMI vorgestellt werden. Bei ihnen handelt es sich im Prinzip um Middleware-Plattformen für offeneVerteilte Systeme. Diese Verteilten Systeme weisen ebenfalls die im RM-ODP aufgeführten Charakteris-tika wie räumliche Verteilung, Nebenläufigkeit und Autonomie der Knoten auf (vgl. Kap. 2.2.1). DieMöglichkeiten von mobilem Code nutzen sie aber dazu, ihren Anwendungen die Kontrolle über die Ver-teilung ihrer Objekte auf die Knoten des Verteilten Systems zu ermöglichen. Diese Systeme sind jedochmeist auf bestimmte Anwendungsdomänen spezialisiert und nicht durch allgemeine Referenzmodellestandardisiert. Bei der Vorstellung der Beispiele wird daher jeweils ein Vergleich mit der vorge-schlagenen ODP-Erweiterung durchgeführt, untersucht werden die Möglichkeiten der Anwendungenzur Manipulation ihrer Verteilung und die Unterstützung dabei durch die jeweilige Middleware.

4.1 MOBILERMIMobileRMI ist eine Erweiterung von JavaRMI um mobilen Code und ist als Forschungsprojekt an derUniversität Pisa entwickelt wordenVIII. JavaRMI ist ein zentraler Bestandteil der Java-Enterprise-Platform2.Es definiert Mechanismen zum Aufruf von Methoden an entfernten Objekten in Java und kann als ODP-konform angesehen werden. In JavaRMI werden entfernte Objekte nur über ihre Schnittstellentyp refe-renziert. Die anwendungsspezifischen Schnittstelle muss eine vorgegebene Schnittstelle erweitern (ja-va.rmi.Remote). Statt über normale Referenzen wird mit diesen entfernten Objekte über entfernteReferenzen interagiert. Das Auffinden von entfernten Objekten wird mit Hilfe symbolischer Namen übereinen zentralen Namensdienst organisiert. Dann realisiert ein durch die Middleware zur Verfügung ge-stelltes Proxy-Objekt im Adressraum des Aufrufers die entfernte Referenz und leitet die Aufrufe über dieGrenzen der lokalen JVM an das echte entfernte Objekt auf einer anderen JVM weiter3. MobileRMI erweitert dieses Konzept nun dahingehend, dass nicht nur entfernte Objekte erzeugt werdenkönnen, sondern entfernte Objekte mittels einer speziellen Methode ( move(...) ) zur Laufzeit denKnoten wechseln können. Mobile Objekte sind also in diesem Fall entfernte Objekte, die durch dieAnwendung von einem entfernten Knoten auf einen anderen entfernten Knoten transferiert werdenkönnen. Damit ist MobileRMI eine Middleware-Plattform für Verteilte Systeme, in denen Anwendungen

(1) Zum Beispiel werden in JavaRMI bei entfernten Methodenrufen Typdefinitionen von Parametern unbekannten Typs dynamisch nachgeladen.(2) Siehe auch Kapitel 2.3.3 zu JavaRMI oder Glossar(3) dabei ist neben dem nativen RMI Protokoll auch eine Kooperation mit CORBA-Systemen via Internet Inter-Orb Protocol (RMI-IIOP) möglich.

SEITE 47


explizit die Verteilung ihrer Objekte steuern können. Allerdings sind nicht implizit alle Objekte vonAnwendungen mobil, sondern nur speziell als mobile Objekte angelegte Instanzen. Folgendes Beispieldemonstriert die Funktionsweise:

Codebeispiel - MobileRMI1. public interface Foo extends Mobile {2. public methodA(…) throws RemoteException;3. public methodB(…) throws RemoteException;4. }5.6. .....7.8. Foo foo;9. try {10. foo=(Foo)MURO.11. create(“FooImpl“,remoteHost,Mobile.DEFAULT_PORT,codebase);12. 13. result=foo.methodA(..);14. foo.move(<another host>);15. result=foo.methodB(..);16.17. }catch(ObjectMovedException e1) {…}18. catch(RemoteException e2) {…}19. .....In diesem Fragment wird in den Zeilen 1 bis 4 zunächst ein Interface Foo definiert, welches das InterfaceMobile erweitert. In einem anderen Zusammenhang wird später eine Variable dieses Typs deklariert (Zeile8). Ihr wird in Zeile 10 beginnend ein mobiles Objekt zugewiesen, das mit Hilfe einer nicht näherspezifizierten Implementation erzeugt wurde (Klassenname FooImpl) und sich auf einem bestimmtenKnoten befindet (remoteHost). In den Zeilen 13 bis 15 wird nun mit diesen Objekt interagiert. Dabei erfolgen Methodenrufe völlig analogzu normalen lokalen Objekten. Die Methode methodA(..) wird auf dem ursprünglichen entfernten Host(remoteHost) ausgeführt. Mit move(..) in Zeile 14 wird das Mobile Objekt vom alten entfernten Knotenzu einem neuen entfernten Knoten transferiert (<another host>). Der nächste Methodenruf methodB(..) am mobilen Objekt foo kommt nun dort zur Ausführung.

Unabhängig von der vom Autor nicht geprüften Funktionstüchtigkeit von MobileRMI birgt der gewählteAnsatz rein konzeptionell sowohl Vor- als auch Nachteile. Als Vorteil kann bewertet werden, dass sichMobileRMI auf die etablierte JavaRMI-Technologie abstützt und so eine getestete und einschätzbare Basisvorweisen kann. Auch wird sich die Entwicklung von Anwendungen mit mobilen Objekten durch dieÄhnlichkeit zu JavaRMI an vorhandenen Strukturierungen, Entwurfsmustern und Erfahrungenorientieren können. Es gibt jedoch auch eine Reihe von Kritikpunkten, die im folgenden aufgezähltwerden:

• Bei Transfers der mobilen Objekte auf neue Knoten werden Verweisobjekte auf den alten Knotenzurückgelassen, da nicht festgestellt werden kann, welche anderen Objekte noch Referenzen aufden alten Knoten besitzen. Die so bei mehrfachen Transfers entstehenden Ketten von Verweis-objekten müssen zusätzlichen verwaltet werden4.

• Wie bei JavaRMI ist eine verteilte Speicherbereinigung über die Knoten des Verteilten Systemserforderlich5. Dadurch, dass die entfernten Objekte nun als mobile Objekte ihren Knotenwechseln können, werden entsprechende Algorithmen aufwendiger.

(4) Die Verwaltung geschieht durch einen eigenen Hintergrunddienst, den MobilityDaemon.(5) Siehe JavaRMI Specification Kap3.3

SEITE 48


• Es ist weiterhin ein zentraler Namensdienst zur Verwaltung der mobilen Objekte nötig.

• Die mobilen Objekte müssen Thread-sicher und serialisierbar sein6.

• Bei der initialen Verteilung von Anwendungen in einem Verteilten System mit MobileRMI alsMiddleware-Plattform müssen mit zusätzlichen Werkzeugen Stub- und Skeletonklassen generiertwerden.

• Die Aufrufsemantik von Parametern bei Methodenrufen verhält sich bei MobileRMI wie bei Ja-vaRMI: Nur entfernte (JavaRMI) oder mobile Objekte (MobileRMI) werden per call-by-referenceübergeben, call-by-value wird für alle anderen Objekte angewandt.

• Es ist ungeklärt, was im Falle von Synchronisation von mobilen Objekten im Anwendungscodebei Transfers von beteiligten mobilen Objekten geschieht.

• Schon JavaRMI ermöglicht es, auf einem Knoten fehlende Typdefinitionen dynamisch und trans-parent für Anwendungen bei Bedarf nachzuladen. Zum einen ist die dabei gewählte Vorgehens-weise nicht sehr effizient (jede Klassendefinition in einer einzelnen Nachfrage), zum anderen istbei MobileRMI nicht klar, wie von einem mobilen Objekt der eigentliche Ursprungsknoten ge-funden werden kann, um dort eventuell fehlende Typdefinitionen nachzufragen. Dies hat in Javadurchaus Relevanz, da jedes Objekt potentiell unvollständig gebunden (engl. linked) sein kann.Wird bei einer Interaktion ein bisher nie aufgetretener Ausführungspfad ausgewählt, kann un-abhängig von der bisherigen Dauer der Existenz des Objektes die Notwendigkeit entstehen, bis-her unbekannte Typen von lokalen Variablen nachzuladen.

4.1.1 BEZUG ZUR ERWEITERUNG DES RM-ODPNun soll ein Vergleich zwischen MobileRMI und der in dieser Arbeit vorgeschlagenen Erweiterung desRM-ODP stattfinden. Dabei sollen die Fähigkeiten in Bezug auf Mobilität von Objekten und die Möglich-keiten der Anwendungslogik zur Einflussnahme darauf untersucht werden. Da schon absehbar ist, dassMobileRMI äquivalent durch Mittel der Erweiterung des RM-ODP beschrieben werden kann, erfolgt derVergleich aus der Sicht der ODP-Erweiterung aus Kapitel 3.

Informationen über das Verteilte System

• Modellierung von KnotenDie Zusammensetzung des Verteilten Systems aus einer Menge von Knoten und Verbindungenwird bei MobileRMI nicht explizit durch ein Modell ausgedrückt. Knoten werden nur implizit inForm von Hostnamen dargestellt, die aus protokollspezifischen Strings (z.B. URLs) bestehen. Da-mit fehlt eine explizite Typisierung und eine Vergleichbarkeit von Knoten kann nur durch Parsenvon Zeichenketten und nötiges Wissen über Darstellungsformen der spezifischen Protokolle er-reicht werden.

• Modellierung von Eigenschaften Bei MobileRMI werden keine Informationen über das Verteilte System aufbereitet.Anwendungen können keine Rückschlüsse auf Verbindungstopologien der Knoten oder Ver-bindungs- oder Knotenmerkmale wie etwa Bandbreite oder verfügbarer Hauptspeicher ziehen.Nach Verständnis des Autors wird aber bei MobileRMI implizit angenommen, dass alle Knotendirekt oder indirekt miteinander verbunden sind.

(6) Thread-Safety siehe JavaRMI Specification Kap. 3.2: Serialisierung siehe Kap. 5.3.4

SEITE 49


• Zuordnung von Objekten auf KnotenIn den vorliegenden Unterlagen über MobileRMI finden sich keine Hinweise auf Schnittstellen,mit denen der aktuelle Knoten eines mobilen Objektes ermittelt werden kann. Dieser Mangel istjedoch, sollte er wirklich vorhanden sein, aus technischer Sicht behebbar.

• Äquivalentes Umgebungsmodell Ein gegenüber MobileRMI im Informationsgehalt für Anwendungen äquivalentes Umgebungs-modell nach der vorgeschlagenen Erweiterung des RM-ODP dieser Arbeit könnte wie folgt aus-sehen: Es gibt nur die Menge der Knoten und eine einzige Relation ohne weitere Attribute. DieRelation drückt lediglich aus, dass alle Knoten untereinander verbunden sind.

Programmatische Schnittstellen der Middleware• Da es bei MobileRMI seitens der Middleware keine modellierten Informationen über das Ver-

teilte System gibt, gibt es auch keine Schnittstellen, um dieses Modell zu erlangen.

• Der Transfer von mobilen Objekten wird bei MobileRMI komplett von der Middleware unter-stützt. Anwendungen lösen einen Transfer, wie im Beispiel oben zu sehen, durch einen Metho-denruf ( obj.move(..) ) aus. Dabei sorgt die Middleware für die Aktualisierung aller betrof-fenen entfernten Referenzen.

• Es gibt keinen ausgezeichneten Mobilitätsdienst. Im Vergleich mit dem Vorschlag dieser Arbeitist anzumerken, dass bei MobileRMI die Fähigkeit zu einer Migration dem Anwendungsobjektselbst zugeschrieben wird, was sich durch die Erweiterung der Schnittstelle des Anwendungs-objektes ausdrückt ( obj.move(..) ). Nach Meinung des Autors ist die in dieser Arbeit vorge-schlagene Variante eines speziellen Mobilitätsdienstes konzeptionell besser, schließlich sollte dieSchnittstelle eines Anwendungssobjektes nur domänenspezifische Anwendungslogik beinhalten.

Strategien bei Objekttransfers• Bei einem Objekttransfer migriert im Wesentlichen nur das mobile Objekt selbst. Es werden zu-

sätzlich auf dem alten Knoten sogenannte Verweisobjekte hinterlassen, um die entfernten Refe-renzen anderer Objekte nicht ungültig werden zu lassen. Objekte die das transferierte mobileObjekt selbst referenziert, fallen in zwei Gruppen: Handelt es sich um mobile Objekte, so wird le-diglich die Referenz kopiert und übertragen. Alle anderen, normalen Java-Objekte werden je-doch bei einem solchen Transfer komplett kopiert7.

4.2 MOBILE AGENTEN

Das zweite Beispiel sind mobile Agenten. Sie werden sehr häufig im Zusammenhang mit dem Begriff„mobiler Code“ genannt. Für den Fokus dieser Arbeit ist jedoch entscheidender, dass es sich um mobileObjekte handelt. Mobile Agenten stammen aus einer Forschungsrichtung der Künstlichen Intelligenz(KI), neben vielen Implementierungen wissenschaftlicher Forschungsgruppen gibt es auch kommerzielleLösungen. Plattformen für mobile Agenten sind Middleware-Plattformen für offene Verteilte Systeme,bei denen die Anwendungen (die Agenten) aktiv ihren eigenen Ausführungsort wechseln. Vereinfacht

(7) tiefe Kopie mittels Serialisierung

SEITE 50


ausgedrückt versuchen mobile Agenten, durch die Migration von Knoten zu Knoten in ihrem Sinne „ab-sichtlich und bewusst“ ihre Ziele zu erreichen. In diesem Überblick über mobile Agenten wird vereinfachend angenommen, dass ein Agent eine eigen-ständige Anwendung darstellt. Dies trifft für Anwendungsfelder wie etwa Reservierungen von Hotelsoder Flügen zu, bei denen eine Instanz eines Agenten im Auftrag seines Nutzers unter verschiedenenRandbedingungen allein die gewünschten Aktionen durchführt. Es kann jedoch auch Anwendungen ge-ben, die erst durch das Zusammenwirken vieler Agenten ihren Zweck erfüllen, ein Beispiel könnten Si-mulationen von Populationsdynamiken durch sehr viele Agenteninstanzen sein.Die mobilen Agenten dabei zu Grunde liegenden offenen Verteilten Systeme sind überwiegend dezentralorganisiert. So haben Agenten in diesen Systemen nur einen begrenzten Horizont und können nur in un-mittelbarer Nachbarschaft Ressourcen nutzen oder mit anderen Agenten oder Anwendungen intera-gieren. Die Migration zu einem anderen Knoten ist so der Weg, um an neue Ressourcen zu gelangen, In-formationen über andere Knoten zu erhalten und andere Agenten zu treffen. Die Beispiele für mobile Agenten aus den untersuchten ProjektenIX sind vom Umfang her eher kleineAnwendungen und bestehen normalerweise aus einem einzigen Kontrollfluss. Typisch für mobileAgenten ist, dass sie immer als Ganzes migrieren. Sie sind also keine über viele Knoten des VerteiltenSystems verteilten Anwendungen, sondern eher „räumlich kompakte Nomaden“. Ein Transfer eines Agenten wird innerhalb seines eigenen Programmcodes durch Aufruf einer Methodewie etwa migrate(newHost)ausgelöst. Alle untersuchten Varianten von Agenten transferieren sichimmer nur selbst und werden nie von anderen Agenten transferiert. Mobile Agenten sind konzeptuellnicht nur einfache mobile Objekte sondern haben je nach Betrachtung auch den aktiven Charakter einesselbstständigen Kontrollflusses (Prozess, Thread).Bei Arbeiten und Veröffentlichungen über mobile Agenten wird viel Wert auf die Unterscheidung derArt der Migration gelegt. Es gibt starke und schwache Migration (engl. weak/strong migration). Die Un-terschiede liegen darin, dass nur Agenten mit starker Migration in der Lage sind, nach einem Transfer mitihrem Kontrollfluss ungestört fortzufahren, während Agenten mit schwacher Migration eine Art Neustarthinnehmen müssen. Bei ihnen bleibt bei Transfers zwar der Zustand der Variablen erhalten, die Pro-grammausführung wird aber immer bei einer bestimmten Methode neu angefangen. Diese Unterschiedehaben technische Ursachen, so ist es in vielen Programmiersprachen nicht möglich, portabel den kom-pletten Zustand einer Anwendung, also auch den momentanen Stand des Instruktionszählers zu erfassenund nach erfolgtem Transfer wieder zu etablieren. Für die Betrachtung von mobilen Agenten als mobileObjekte in offenen Verteilten Systemen die ihre eigene Verteilung bestimmen können, ist diese Unter-scheidung jedoch von untergeordneter Relevanz. Im Vergleich mit Verteilten Systemen nach RM-ODP realisiert eine Agenten-Plattform für ihreAnwendungen einige Verteilungstransparenzen wie Access-, und Persistence-Transparenz. Dadurch,dass der Ansatz von mobilen Agenten aber auf sehr große und dezentral organisierte Verteilte Systemeabzielt, kann aber nicht uneingeschränkt von Location-, Migration- und Relocation-Transparenz die Redesein. Mobile Agenten werden durch Transfers nicht behindert, aber ihre wahrnehmbare Umwelt ändertsich, was ja auch Ziel der Migration ist. Daher kann in diesen Fällen nicht von einer echten Verteilungs-transparenz gesprochen werden. Die Problematik von existierenden Referenzen zu Objekten andererAnwendungen wird von verschiedenen Agentenplattformen unterschiedlich gehandhabt, deshalb ist dieFrage der Relocation- und teilweise auch der Migration-Transparenz nicht pauschal zu beantworten.Folgend sollen nun einige Arbeiten und Projekte aus dem Bereich der mobilen Agenten vorgestelltwerden. Die dabei ausgewählten Projekte sind in Java realisiert. Allgemein gesehen sind derzeitigeAgentenplattformen meist auf Basis relativ hardwareunabhängiger Programmiersprachen realisiert. DiePalette umfasst Scriptsprachen, interpretierte Sprachen oder Sprachen mit spezieller Laufzeitumgebung,Beispiele sind Tcl, Scheme, Java oder Python, wobei Java am häufigsten vertreten ist. Der Grund liegt

SEITE 51


darin, dass derzeitige Prozessorarchitekturen und Betriebssysteme nativen Anwendungen keine ausrei-chenden Möglichkeiten geben, den Zustand laufender Programminstanzen so zu externalisieren, dass sieüber Grenzen von Adressraum und spezifischer Prozessorarchitektur transferierbar und auf einem ent-fernten Knoten fortsetzbar sind. Dagegen lassen die oben genannten Sprachen sich durch Eingriffe in diezu Grunde liegenden Interpreter oder Laufzeitumgebungen besser manipulieren.

4.2.1 AGLETSDas Aglets-System ist eine Java-basierte Middleware-Plattform für mobile Agenten mit schwacher Migra-tion und wurde als ein Projekt der IBM-Forschung entwickelt. Konkrete eigene Agenten erweitern dievorgegebene Klasse com.ibm.aglet.Aglet. Dort sind eine Reihe von Callback-Methoden definiert,die im Falle unterschiedlicher Ereignisse durch die Agentenplattform am Agenten aufgerufen werden.Neben den Bereichen Persistenz, Lebenszyklus und dem Kopieren von Agenten ist Mobilität eines dieserEreignisse (onCreation(..), onDisposing(), run() ). Die Migration zu einem anderen Host wirddurch den Aufruf der Methode dispatch(URL destination) ausgelöst. Der Agent wird per Java-Serialisierung in Binärform gespeichert und mit benötigten Klassendefinitionen zum Ziel übertragen.Dort wird der übertragene Agent wieder deserialisiert und erneut die Hauptmethode run() aufge-rufen. Die aktive Entwicklung des Projektes scheint im Jahre 2001 zum Stillstand gekommen zu sein, eswird aber immer noch als eine Referenz für mobile Agenten aufgeführtX.Das folgende Beispiel ist der Dokumentation entnommen und illustriert die Funktionsweise von Aglets-Agenten:

Codebeispiel - Aglets1. public class MyAglet extends Aglet {2. static int class_variable = 0;3.4. public void onCreation(Object init) {5. class_variable = 10;6. dispatch("atp://next.place");7. }8.9. public void run() {10. if (class_variable != 10) {11. System.out.println("Class variable never get transferred!");12. }13. }14.15.}Das gewählte Beispiel soll im originalen Kontext das Verhalten von statischen Feldern bei Transfersverdeutlichen. Als erstes wird die Klasse MyAglet geladen und die Klassenvariable class_variable mit0 initialisiert. Sobald der Aglet-Agent erzeugt wird, wird diese statische Variable geändert und ein Transfermittels dispatch(..) eingeleitet. Nach dem Transfer wird am Zielhost die Klassendefinition geladen,damit die Abarbeitung mit run() fortgesetzt werden kann. Das statische Feld erhält im Zuge derKlasseninitialisierung wieder den Standardwert 0. Da die Methode onCreation(..) aber nur einmal imLebenszyklus eines Aglet-Agenten gerufen wird, wird die entsprechende Ausgabe aus Zeile 11 auf derKonsole ausgegeben.

SEITE 52


4.2.2 NOMADSEin weiteres Beispiel für Agenten-Plattformen ist das ebenfalls Java-basierte Projekt NomadsXI. Agentenauf Basis von Nomads erreichen starke Migration. Dies ist durch eine eigene Implementation einer JVMmöglich, die erweiterte Fähigkeiten für Mobilität bietet und beispielsweise die Ein- und Auslagerung desProgrammzählers erlaubt.

Codebeispiel - Nomads 1.public class Example extends Agent {2.3. public static void main (String[] args) {4. System.out.println ("On source");5. go (destination);6. System.out.println ("On destination");7. }8.}Wie in Zeile 1 zu sehen ist, erweitert die Anwendung die vorgegebene Klasse Agent. Die Konsolenausgabein Zeile 4 wird auf dem Host ausgegeben, auf dem das Beispiel gestartet wurde. In Zeile 5 wird ein Transferinitiiert. Die genaue Definition der Variable destination ist für das Verständnis nicht weiter entscheidend.Die Ausgabe der Zeile 6 wird nach dem Transfer nun auf dem mit destination bezeichneten Hostausgegeben.

Bei Nomads, wie bei allen anderen untersuchten Agentenplattformen, ist die Frage des Umgangs mitReferenzen bei Transfers nicht befriedigend geklärt. Es wird häufig angeführt, dass der Agent als Ganzesmigriert, wie aber in der Umsetzung eigene referenzierte Objekte von fremden referenzierten Objektenanderer Anwendungen unterschieden werden, wird nicht ausgeführt. Offen sind auch Fragen in Bezugauf Referenzen anderer Objekte, die das jeweilige mobile Objekt als Ziel haben. Einige Agentenplatt-formen bieten eine Möglichkeit zur Fehlererholung durch einen Namensdienst an, durch den immer dermomentane Ort von Agenten aufgefunden werden kann. Diese Möglichkeit verträgt sich aber nicht sehrgut mit dem Anspruch eines dezentral organisierten Verteilten Systems. Bei mobilen Agenten auf Basisvon Java sind weiterhin Mobilität und Synchronisation überwiegend unverträgliche Bereiche.

4.2.3 BEZUG ZUR ERWEITERUNG DES RM-ODPDie Eigenschaften von mobilen Agenten sollen wieder im Vergleich zur Erweiterung des RM-ODP be-trachtet werden. Allgemeine Aussagen über mobile Agenten stützen sich dabei auf die näher untersuch-ten Varianten8. Bei der großen Anzahl verschiedener Projekte und Prototypen sind einzelne Abwei-chungen von den pauschalen Urteilen nicht ausgeschlossen.

Informationen über das Verteilte System

• Modellierung von KnotenDie Zusammensetzung des Verteilten Systems aus einer Menge von vernetzten Knoten wird auchbei mobilen Agenten nicht explizit modelliert. Wie bei MobileRMI werden Knoten nur implizit inForm von Zeichenketten oder URLs dargestellt. Plattformen für mobile Agenten die strenger denPrinzipien der Künstlichen Intelligenz folgen, haben laut allgemeiner Darstellung in Veröffentli-chungen und Dokumentationen nur ein begrenzten Horizont. Ob damit aber nur die Interaktion

(8) Siehe Quellenverzeichnis

SEITE 53


mit anderen Anwendungen oder Agenten auf weit entfernten Knoten eingeschränkt ist, oderauch prinzipiell kein Transfer auf „weit entfernte“ Knoten möglich ist, ist nicht genau klar.

• Modellierung von EigenschaftenBei mobilen Agenten gibt es, wie schon bei MobileRMI, keine expliziten Informationen überEigenschaften des Verteilten Systems wie etwa Rechenleistung von Knoten oder Kennzahlen vonVerbindungen wie etwa Bandbreite etc. Da der Anspruch von mobilen Agenten aber darin be-steht, auf der Suche nach Informationen oder mit der Absicht von bestimmten Handlungen „in-telligente“ Transferentscheidungen zu treffen, ist die Abwesenheit von relativ technischen In-formationen eventuell von untergeordneter Bedeutung.

• Zuordnung von Objekten auf KnotenEin mobiler Agent hat im Allgemeinen auch keinen erschöpfenden Überblick über denmomentanen Ort anderer entfernter Objekte oder Agenten. Dies steht im Einklang mit demerwähnten begrenzten Horizont der Agenten. Bei einigen Varianten von mobilen Agenten gibt esglobal gültige Verzeichnisse aller Agenten mit jeweils aktuellem Aufenthaltsort. Dies sollte abernach Meinung des Autors als Ausnahme angesehen werden, da es von der Grundidee eines de-zentral organisierten Verteilten Systems abweicht.

• Äquivalentes Umgebungsmodell Ein vom Informationsgehalt für Anwendungen äquivalentes Umgebungsmodell nach dem Vor-schlag dieser Arbeit könnte wie folgt aussehen: Es existiert nur die Menge aller Knoten und eineeinzige Relation ohne weitere Attribute. Diese Relation würde wie im Falle von MobileRMI le-diglich ausdrücken, dass die jeweiligen Knoten als erreichbar angesehen werden.

Programmatische Schnittstellen der Middleware• Da es keine explizite Modellierung des Verteilten Systems gibt, existieren auch keine Schnitt-

stellen, um dieses Modell zu erlangen.

• Der Transfer von mobilen Objekten wird bei mobilen Agenten von der jeweiligen Plattform un-terstützt. Je nach Fähigkeit und verwendeter Technologie wird nach einem Transfer dieAnwendung (der Agent) fortgesetzt (strong migration) oder eine Ausführung an definiertenSchnittstellen wiederholt (weak migration). Im Unterschied zu anderen mobilen Objektenwerden mobile Agenten nicht durch Aufrufe anderer Objekte transferiert, sondern initiierenimmer selbst einen Transfer. Dies geschieht durch Methodenrufe wie transfer(target).

• Wie schon bei MobileRMI existiert kein separater Dienst, der die Funktionalität bezüglich Mo-bilität von Objekten kapselt. Statt dessen wird wieder die Fähigkeit zu Transfers in die Schnitt-stelle der Agenten, also der Anwendungsobjekte integriert. Allerdings ist das Paradigma vonautonomen, mobilen Agenten an diesem Punkt sehr schwer einzuordnen, da man Mobilität auchals ureigene Funktionalität aller Agenten ansehen könnte. Hier kommt es wieder auf die einge-nommene Sichtweise an, die eher den Charakter als mobiles Objekt oder den Charakter als ak-tiven Kontrollfluss (Prozess, Thread) im Vordergrund sieht.

SEITE 54


Strategien bei Objekttransfers• Beim Transfer eines mobilen Agenten wird der Agent immer komplett bewegt. Auf Ebene der

Objekte bedeutet dies den Transfer der transitiven Hülle aller referenzierten Objekte. Die auf demalten Knoten zurückbleibende Version des Agenten gilt ab dann als ungültig. In Programmier-sprachen mit automatischer Speicherbereinigung kann die Beseitigung dieser invaliden „Über-bleibsel“ aber unterlaufen werden und zu subtilen Fehlern führen. Durch den kompletten Trans-fer gibt es keine entfernten Referenzen. Dadurch, dass sich ein mobiler Agent zu einem Zeitpunktimmer auf einem Knoten befindet, also alle Objekte innerhalb eines Adressraums versammeltsind, gilt bei mobilen Agenten immer die normale Aufrufsemantik für Methodenparameter. InJava ist dies call-by-reference für alle Referenztypen und call-by-value für alle primitiven Typen.Allerdings ändert sich bei jedem Transfer die numerische bzw. binäre Repräsentation einer Refe-renz9.

4.3 FAZIT

Die vorgestellten Beispiele verdeutlichen, dass es bereits einige spezialisierte offene Verteilte Systemegibt, in denen Anwendungen ihre eigene Verteilung bestimmen. Systeme wie MobileRMI oder die meis-ten Agentenplattformen haben allerdings derzeit noch überwiegend experimentellen Charakter. Es istaber auch klar, dass klassische Verteilte Systeme nach RM-ODP oder ähnlichen Standards in vergleichba-ren Einsatzszenarien unterlegen oder untauglich sind.Im Vergleich von MobileRMI und den verschiedenen Varianten mobiler Agenten mit der Erweiterungdes RM-ODP dieser Arbeit wird deutlich, dass sich derzeitige Systeme für mobile Objekte vorwiegendmit der technischen Umsetzung von Objekttransfers beschäftigen. Die Unterstützung und Fundierung derTransferentscheidungen der Anwendungen durch aufbereitete Informationen über das Verteilte Systemund seine Ressourcen ist bestenfalls rudimentär entwickelt. Die vorgeschlagene Erweiterung des RM-ODP kann zumindestens konzeptionell diese spezialisierten Lösungen ersetzen und gerade im Bereichder Bereitstellung von Informationen übertreffen. Wenn es gelingt, taugliche Middleware-Plattformen zuentwickeln, die konform zu dem erweiterten ODP-Referenzmodell sind, könnten auch alle diese spezi-ellen Anwendungen in den großen Rahmen des RM-ODP integriert werden.

(9) In Sprachen die nativen Code erzeugen entspricht das meist Speicheradressen, in Java ist das beobachtbar durch den Hashcode (Object.hashCode()oder auch System.identityHashCode(..) )

SEITE 55

KAPITEL 5. - REALISIERUNG DER VORGESCHLAGENEN ODP-ERWEITERUNG IN JAVA

5. REALISIERUNG DER VORGESCHLAGENEN ODP- ERWEITERUNG IN JAVA

5.1 EINLEITUNG

Parallel zum schriftlichen Teil dieser Arbeit wurde eine prototypische Implementation entwickelt. Zielwar es, die praktische Bedeutung und Vorteile der vorgeschlagenen Neuerungen zu demonstrieren undgleichzeitig die technische Machbarkeit nachzuweisen. Die aus der Untersuchung bereits existierenderVarianten von Verteilten Systemen mit mobilen Objekten gewonnenen Einsichten halfen dabei, die Vor-teile der verschiedenen Ansätze zu kombinieren und neuartig umzusetzen.Es wurde eine Middleware-Plattform mit einem Mobilitätsdienst entwickelt, mit dessen Hilfe esAnwendungen möglich ist, ihre Objekte gezielt über die Knoten des jeweiligen Verteilten Systems zu ver-teilen und diese Verteilung zur Laufzeit der Anwendung zu verändern. Darüber hinaus bietet der Mobili-tätsdienst den Anwendungen ein Umgebungsmodell an, das eine Instanz des vorgestellten Meta-Umge-bungsmodells ist. Die Implementation wurde in der Programmiersprache Java umgesetzt. Eine ersteAnalyse zu Beginn der Arbeit führte zu einer umfassenden Menge von Anforderungen an die zurealisierende Middleware:

• Das Verteilte System soll geeignet sein, unterschiedlich komplexe Anwendungen aus unter-schiedlichen Domänen zu unterstützen.

• Die Implementation soll konform zum Java-Standard sein und keine spezialisierte JVM voraus-setzen. Alle Aufrufe an mobilen Objekten sollen synchron sein (wie alle üblichen Methodenrufein Java).

• Für die Entwicklung von Anwendungen darf es möglichst wenig Vorgaben oder Ein-schränkungen geben. Darunter fallen beispielsweise vorgegebene Klassenhierarchien für mobileObjekte, Abweichungen von der normalen Aufrufsemantik oder ein Versagen von Synchronisa-tionsmechanismen bei der Interaktion mobiler Objekte.

• Der Start einer Anwendung in dem Verteilten System soll aus der Sicht eines menschlichen Ad-ministrators oder Anwenders möglichst einfach sein.

• Die Middleware soll zur Laufzeit wenig Aufwand bzw. Systemlast verursachen. Die verwal-tenden Mechanismen der Middleware-Plattform sollen also möglichst einfach und ressourcen-sparend sein.

Im weiteren Verlaufe wurde jedoch klar, dass diese Anforderungen nicht alle gleichzeitig zufrieden-stellend zu erfüllen sind. Neben Technologie-bedingten Mängeln durch die gewählte Programmierspra-che gibt es grundlegende Widersprüche zwischen der Offenheit für beliebige Anwendungen und einemgarantiert geringen Verwaltungsaufwand der Verteilung seitens der Middleware-Plattform zur Laufzeit. Für die im Rahmen dieser Arbeit entwickelte Middleware-Plattform wurde daher ein Kompromiss ge-funden, der eine ausgewogene Einschränkung der Anforderungen beinhaltet. Die daraus gefundene Im-plementierung ist aber nur eine mögliche Realisierung der theoretischen Vorgaben. Eine andere Wich-tung der obigen Anforderungen hätte auch zu einer anderen Implementation führen können, die etwadem in Kapitel 4.1 vorgestellten MobileRMI näher gekommen wäre.

SEITE 57


5.2 FLÜCHTIGE MOBILE OBJEKTE ALS NEUER ANSATZ

5.2.1 SPEZIALISIERUNG DES ANWENDUNGSBEREICHSWie im Kapitel 4 beschrieben, gibt es verschiedene existierende Ansätze von Verteilten Systemen, beidenen Anwendungen aktiv die Umverteilung ihrer mobilen Objekte beeinflussen (MobileRMI, mobileAgenten). Ein Vergleich beider Ansätze bezüglich der Mechanismen der Middleware offenbart Stärkenund Schwächen:

Vergleich von MobileRMI und mobilen AgentenDie von MobileRMI realisierte Variante mobiler Objekte schränkt die möglichen Domänen vonAnwendungen kaum ein. Eine Anwendung kann über viele Knoten verteilt werden und die mobilenObjekte können nahezu beliebig, auch nebenläufig, miteinander interagieren. Der Preis dafür besteht je-doch in der aufwendigen Verwaltung der mobilen Objekte durch entfernte Referenzen und in verteiltenAlgorithmen für die Speicherbereinigung. Ähnliche spezielle Konstrukte zur verteilten Synchronisationkönnten die derzeitigen Unverträglichkeiten von mobilen Objekten und Thread-Synchronisation be-heben.Einen gegensätzlichen Platz nehmen die Plattformen für mobile Agenten ein. Sie kommen ohne entfernteReferenzen und andere verteilte Algorithmen aus und vereinfachen so wesentlich die Verwaltung derAnwendung zur Laufzeit. Dadurch ist es einfacher, sehr große Verteilte Systeme zu realisieren. Auf deranderen Seite sind bei mobilen Agenten die möglichen Anwendungsdomänen eingeschränkt. So vertei-len sich mobile Agenten nicht auf mehrere Knoten, sondern bestehen meist nur aus einem Kontrollflussund migrieren als Ganzes von Knoten zu Knoten. Ein solcher Wechsel stellt jedoch einen massiven Ein-schnitt in die Kooperationsfähigkeit mit anderen Anwendungen dar, da dabei alle bestehenden Referen-zen zwischen Objekten der beteiligten Anwendungen ungültig werden. Dies kann aus der Sicht einer miteinem Agenten kooperierenden Anwendung unvermittelt zu jedem Zeitpunkt passieren und ist vor derNutzung einer Referenz auch kaum zu testen.

Idee: Kombination beider AnsätzeAus dem Vergleich ergab sich eine Idee, die zwar eine moderate Spezialisierung des Anwendungsbe-reichs voraussetzt, innerhalb dessen aber die Vorteile der beiden genannten Ansätze kombinieren kann.Die Idee fordert zunächst für die Anwendungslogik folgende Einschränkungen hinsichtlich des Einsatzesvon mobilen Objekten:

1. Mobile Objekte interagieren nie gleichzeitig bzw. nebenläufig mit anderen Objekten.

2. Sie werden im Idealfall nur von Objekten innerhalb eines Kontrollflusses referenziert1. Interagierensie dennoch mit Objekten aus anderen Kontrollflüssen, so müssen sich diese anderen Objekte zuBeginn der Interaktion innerhalb des selben Adressraumes wie das betrachtete mobile Objekt be-finden2.

(1) Damit ist gemeint, dass alle anderen mit diesem Objekt interagierenden Objekte innerhalb des selben Java-Threads interagieren und die Referenzkeinen Objekten aus anderen Java-Threads oder gar Prozessen bekannt ist.

(2) Nicht aus verschiedenen Prozessen bzw. keine 2 Threads aus verschiedenen JVMs

SEITE 58


3. Die Anwendungslogik kommt idealerweise ohne eigene Synchronisation von mobilen Objekten aus.Wird in der Anwendungslogik doch die Interaktion mobiler Objekte durch Synchronisationsme-chanismen (z.B. Schlüsselwort synchronized oder Rufe wie wait(), notify() etc.)koordiniert, so tritt dies möglichst selten auf und hat keinen entscheidenden Einfluss auf die Leis-tung der Anwendung.

Durch diese Einschränkungen ist sichergestellt, dass ein mobiles Objekt durch lokale, also auf deneigenen Adressraum beschränkte Mechanismen kontrollierbar ist. Gleichzeitige Interaktionen sind unter-sagt und sequentielle Interaktionen mit Objekten aus unterschiedlichen Kontrollflüssen können mit einfa-chen lokalen Synchronisationsmechanismen geregelt werden.

5.2.2 FLÜCHTIGE MOBILE OBJEKTEDurch diese strikte Kontrolle der Interaktion der mobilen Objekte besteht die Möglichkeit, Anwendungeneine dauerhafte Verteilung ihrer Objekte nur „vorzutäuschen“. Statt einem längeren Verweilen auf einementfernten Knoten wird ein mobiles Objekt bei jedem Methodenruf zu dem entsprechenden Knoten hin-und anschließend zurücktransferiert. Während eines Methodenrufes befindet sich das mobile Objekt aufdem entfernten Knoten, es finden parallel aber keine weiteren Interaktionen statt. Außerhalb von Interak-tionen mit diesem mobilen Objekt muss das Objekt nicht auf dem entfernten Knoten bleiben, da es drittenObjekten aus anderen Adressräumen nicht bekannt ist und so die Abwesenheit nicht zu Fehlern führenkann.Unter den oben getroffenen Annahmen ist das Verhalten dieser mobilen Objekte aus der Sicht derAnwendung äquivalent zu mobilen Objekten, die permanent auf dem von der Anwendung bestimmtenentfernten Knoten residieren. Im Folgenden wird dieser Ansatz auch flüchtige Verteilung genannt unddie Objekte als flüchtige mobile Objekte bezeichnet. Im Gegensatz zu entfernten Objekten wie etwa beiTechnologien wie CORBA sind diese flüchtigen mobilen Objekte aber nicht allgemein bekannt oder überNamensdienste beliebig öffentlich zugänglich, sondern haben eher „privaten“ Charakter und werden nurvon einer Anwendung benutzt.

SEITE 59


Die Verwendung dieser flüchtigen mobilen Objekte vereint folgende Vorteile:

• Da die Objekte pro Methodenruf hin- und zurück transferiert werden, ist eine Verteilung vonFunktionalität auf viele Knoten des Verteilten Systems möglich, ohne entfernte Referenzenverwenden zu müssen. Dies vermeidet zum einen Verwaltungsaufwand und senkt zum anderendie Anfälligkeit der Anwendung für Kommunikationsstörungen. Anwendungen sind Unterbre-chungen der Verbindungen zwischen den Knoten nur noch für den Zeitraum der Interaktion un-ausweichlich ausgesetzt. Wird eine Störung zu Beginn des Transfers eines flüchtigen mobilenObjektes bemerkt, kann darauf reagiert werden und ein Ausweichziel gewählt werden. Her-kömmliche Ansätze bei denen die mobilen Objekte permanent verteilt sind, sind unvorhergese-henen Verbindungsabbrüchen über die gesamte Laufzeit ausgeliefert.

• Im Gegensatz zu mobilen Agenten kehrt ein mobiles Objekt nach einem Aufruf und der aufeinem entfernten Knoten durchgeführten Ausführung wieder in den ursprünglichen Adress-raum zurück. Damit sind nachfolgende Interaktionen mit anderen Objekten auf dem ursprüngli-chen Knoten problemlos möglich. Anders als bei mobilen Agenten führen Transfers nicht zu un-gültigen Referenzen dritter Objekte.

SEITE 60

Abb. 9: Flüchtige mobile Objekte

Phase 1: Ein mobiles Objekt befindet sich zu Beginn eines Aufrufs auf dem Ausgangsknoten A.

Phase 2: Das mobile Objekt wird zum Knoten B transferiert, auf dem es sich laut Entscheidung derAnwendungslogik befinden soll. Dort findet dann der Aufruf statt.

Phase 3: Nach erfolgtem Aufruf wird das mobile Objekt vom Knoten B wieder zum Ausgangsknoten A zurücktransferiert.

Phase 4: Das Ergebnis wird an den Aufrufer auf Knoten A zurückgegeben.

Knoten A

Knoten A

Phase 1

Phase 2

Phase 3

Phase 4

Knoten B

Knoten B Knoten BKnoten A

Knoten A Knoten B


• Da mobile Objekte sowieso pro Aufruf transferiert werden, kann die Verteilung von Funktionali-tät im praktischen Umgang noch feingranularer als etwa bei MobileRMI genutzt werden. Es kannnicht nur ein mobiles Objekt genau einem Knoten zugeordnet werden, sondern pro Methode desflüchtigen mobilen Objektes ein anderer Knoten als Ausführungsziel ausgewählt werden.

Die Nachteile dieser Idee bestehen neben der möglichen Einschränkung des Anwendungsbereichs vorallem in möglichen Ineffizienzen aus dem wiederholten Transfer des Objektes zu immer gleichen Knotenbei jeder Interaktion. Der Umfang eines einzelnen Transfers pro Aufruf ist auch größer als ein Aufrufeines herkömmlichen, dauerhafter auf entfernten Knoten residieren mobilen Objektes, bei dem pro Auf-ruf nur die jeweiligen aktuellen Parameter übertragen werden müssen.

5.3 UMSETZUNG

5.3.1 EINLEITUNGEntsprechend der dargelegten Idee wurde eine Middleware-Plattform für verteilte Anwendungen mitflüchtigen mobilen Objekten entwickelt. Da die dafür notwendige Spezialisierung des Anwendungsbe-reichs (vgl. Kap. 5.2.1) in der Realisierung in Java nicht statisch sichergestellt werden kann, wurden zu-sätzliche Mechanismen verwendet, um die geforderten Annahmen zur Laufzeit garantieren zu können.Damit kann die Integrität der mobilen Objekte immer gewährleistet werden. Sollten die getroffenenAnnahmen dennoch verletzt werden, etwa durch häufige Verwendung von Synchronisationsmechanis-men durch die Anwendung selbst, kann es zu wesentlichen Leistungseinbußen oder sogar Verklem-mungssituationen (engl. deadlock/livelock) von Kontrollflüssen kommen.In der vorliegenden Realisierung können Anwendungen nicht beliebige normale Java-Objekte verteilen.Die betreffenden Objekte müssen explizit als mobile Objekte angelegt werden. Diese Einschränkung isterforderlich, da im Gegensatz zu normalen Objekten die Methodenaufrufe von mobilen Objekten geson-dert behandelt werden, da ein Aufruf ja jeweils einen Transfer erfordern kann. Darüber hinaus gibt esweitere Forderungen an die mobilen Objekte, wie etwa ihre Serialisierbarkeit. Diese Einschränkungengegenüber normalen Java-Objekten haben aber eher den Charakter eines Aspektes, die mobilen Objekteder vorliegenden Implementation können inhaltlich jede Funktionalität der Geschäftslogik erfüllen undsind an keine vorgegebenen Vererbungshierarchien gebunden.Die Anwendungslogik kann über den Mobilitätsdienst ein Umgebungsmodell mit einfachen Informa-tionen über die Knoten des Verteilten Systems und ihre Leistungsparameter erhalten. Das Umgebungs-modell ist eine gültige Instanz des Meta-Umgebungsmodells aus Kapitel 3.3.3. Es werden beispielsweiseaktuelle Informationen über den verfügbaren Hauptspeicher und das Betriebssystem eines Knotens sowieLatenzzeiten zwischen jeweils zwei Knoten des Verteilten Systems abgebildet. Die Schnittstellen des Mo-bilitätsdienstes orientieren sich eng an den Vorgaben aus Kapitel 3.3.4. Entscheidet sich die Geschäftslogik einer Anwendung auf Grund dieser Informationen zu einerÄnderung der Verteilung, so kann sie mit Hilfe des Mobilitätsdienstes ein mobiles Objekt komplett oderauch nur ausgewählte Methoden mit einem Knoten aus dem Umgebungsmodell assoziieren. Jederfolgende Methodenruf an diesem mobilen Objekt wird dann entsprechend der Konfiguration auf dementfernten Knoten ausgeführt.

SEITE 61


Die Aufrufsemantik der Parameterübergabe bei Methodenrufen weicht vom normalen Verhalten in Javaab. Primitive Typen (z.B. char, long ...) und normale Referenztypen (Interface-, Array- und Klassenty-pen) haben call-by-value Semantik und werden daher bei einer Parameterübergabe kopiert. Nur mobileObjekte werden per call-by-reference übergeben und können so als Seiteneffekt einer Operation ihrenZustand ändern. Diese Besonderheit ist analog zum Verhalten von entfernten Objekten bei JavaRMI bzw.mobilen Objekten bei MobileRMI (vgl. Kap. 4).

Zum leichteren Verständnis wird nun ein einfaches „Hallo Welt“-Programm präsentiert, dass einenersten Einblick in die Möglichkeiten der entwickelten Middleware gibt. Dabei und bei allen anderenfolgenden Progammbeispielen wird immer implizit angenommen, dass auf den beteiligten Knoten be-reits die Middleware gestartet wurde. Die Beispiele selbst haben wie die gesamte Implementation durch-gehend englische Bezeichner und Kommentare.

Codebeispiel : Hallo Welt

1. public class HalloWorld { 2. ...3. 4. public static void main(String[] args) throws Exception{5. ...6.7. MobileA mobileObject = (MobileA) factory.8. createMobileObject(MobileA.class);9.10. EnvironmentModel model = service.getEnvironmentModel();11.12. Method method = MobileA.class.getMethod("helloWorld", 13. new Class[]{String.class});14. 15. Iterator it = model.getNodes().iterator();16. for (Object current=it.next(); current!=null; current = it.next() )17. { 18. service.setInvocationTarget(mobileObject, method, (Node) current);19.20. String result = mobileObject.helloWorld(" from "+ 21. InetAddress.getLocalHost().getHostName());22.23. System.out.println("Result: "+result);24. }25. ...26. }27.}28.29....30.31.public class MobileA implements Serializable { 32. 33. public String helloWorld(String msg) throws Exception {34. System.out.println("Hello world,"+msg);35. return "Greetings from "+ InetAddress.getLocalHost().getHostName();36. }37.}In diesem Beispiel sind Details ausgelassen, die die Initialisierung des Mobilitätsdienstes und die Erstellungder mobilen Objekte (factory) betreffen. In Zeile 7 wird ein mobiles Objekt angelegt. Die Geschäftslogikdieses Typs ist in der Klasse MobileA ab Zeile 31 definiert.

SEITE 62


Dann werden in Zeile 15 alle bekannten Knoten des Verteilten Systems erfragt und in der Schleife beginnendin Zeile 16 verarbeitet. Diese Verarbeitung besteht darin, dass das mobile Objekt mit dem jeweils aktuellenKnoten derart verknüpft wird (Zeile 18), dass die Methode helloWorld(..) auf diesem Knoten ausgeführtwird. Abweichend vom Vorschlag in Kapitel 3.3.4 besitzt die Methode setInvocationTarget einenzusätzlichen Parameter. Dies liegt in der Entscheidung für flüchtige mobile Objekte begründet und erlaubteine sehr feine Steuerung der Mobilität pro Methode des mobilen Objektes. Danach wird die MethodehelloWorld(..) in Zeile 20 aufgerufen und der Rückgabewert in Zeile 23 ausgegeben. Auf jedem dieserKnoten wird die Methode helloWorld(..) ausgeführt und führt zur Ausgabe von „Hello world,from NodeA“ und auf Knoten A zu vielen Ausgaben der Art „Greetings from NodeX“. [Annahme:„NodeA“ ist der Hostname des Ausgangsknotens , „NodeX“ steht für einen beliebigen Hostnamen einesKnotens der Knotenmenge aus Zeile 15.] Die ungewohnte Benutzung des Iterators (Zeile 16) istImplementierungsdetails geschuldet.

5.3.2 KOORDINATION DER VERTEILUNG VON MOBILEN OBJEKTENWie im obigen Programmbeispiel zu sehen ist, erfolgt die Zuordnung der mobilen Objekte zu Knoten desVerteilten Systems in der Anwendungslogik mit Unterstützung des Mobilitätsdienstes der Middleware-Plattform. Ein Aufruf von service.setInvocationTarget(..) verknüpft die durch ein Objekt darge-stellte Methode (Zeile 12 im Beispiel) dieses mobilen Objektes mit einem bestimmten Knoten. DieserVorgang kann zur Laufzeit beliebig oft wiederholt werden. Der Knoten wird durch ein Objekt vom TypNode repräsentiert. Die spezifischen Informationen zur Identifikation des entsprechenden entferntenKnotens sind in diesem Node-Objekt gekapselt und vor der Anwendung verborgen. Lediglich die Middleware, die die Transfers durchführen muss, hat Zugang zu der konkreten Protokoll-spezifischen Repräsentationsform des entfernten Knotens. Dadurch könnten sogar bei entsprechendenFähigkeiten der Middleware transparent von der Anwendung gleichzeitig verschiedene Kommunika-tionsarten verwendet werden. Derzeit ist nur die Kommunikation über Sockets3 implementiert, eineErweiterung ist jedoch durch entsprechende Strukturierung der Implementation schon vorgesehen undleicht möglich.Die Koordination der Verteilung der Objekte auf die Knoten des Verteilten Systems ist von der eigentli-chen Interaktion der beteiligten Objekte entkoppelt. Wird eine derart verknüpfte Methode niemals andem speziellen Objekt gerufen, so wird diese Funktionalität niemals entfernt oder lokal ausgeführt unddas mobile Objekt nie zu dem Knoten transferiert. Insofern ähnelt diese Umsetzung eher MobileRMI (vgl.Kap. 4.1) und weniger mobilen Agenten, bei denen eine Entscheidung zum Transfer immer unmittelbarumgesetzt wird (vgl. Kap. 4.2).Methoden die nicht explizit mit einem bestimmten Knoten verknüpft wurden, werden immer auf demgleichen Knoten ausgeführt, auf dem sich das aufrufende Objekt befindet. Entspricht der einer Methodezugeordnete Knoten gerade dem jeweils lokalen Knoten, so wird die Interaktion natürlich ebenfalls lokalausgeführt. Für alle diese lokalen Aufrufe gilt abweichend von Aufrufen auf entfernten Knoten, dassdoch die in Java definierte Aufrufsemantik bei Parameterübergabe gilt. So werden also auch alle norma-len, nicht explizit mobilen Objekte per call-by-reference übergeben und können so im Laufe des Metho-denrufes ihren Zustand ändern.

(3) Socket, übersetzt etwa „Verbindung“ oder „Sockel“; Sockets sind logische Endpunkte eines verbreiteten Kommunikationsmechanismus für Binärdaten.Heute auf sehr vielen Betriebssystemen verbreitet, wurden Sockets erstmals in BSD-Unix Varianten eingeführt. Siehe auch RFC147 von 1971 (www.rfc-archive.org)

SEITE 63


Für umfangreichere Anwendungen sind eventuell noch andere Formen der Koordination der Verteilungwünschenswert. Neben der beschriebenen feingranularen Zuordnung pro Methode eines individuellenObjektes ist derzeit ebenfalls die Zuordnung ganzer individueller Objekte zu Knoten möglich. Nichtrealisiert, aber technisch einfach umzusetzen wären beispielsweise die Verwaltung von Objekten undKnoten über benannte Gruppen oder die Zuordnung auf Basis des Typs statt pro Instanz.

5.3.3 DAS REALISIERTE UMGEBUNGSMODELLDie entwickelte Middleware-Plattform stellt über den Mobilitätsdienst den Anwendungen ein Umge-bungsmodell zur Verfügung. Dieses Umgebungsmodell orientiert sich an den theoretischen Überle-gungen aus Kapitel 3 und ist eine Instanz des Meta-Umgebungsmodells (vgl. Kap. 3.3.3). Dieses Umge-bungsmodell wird von der Middleware regelmäßig aktualisiert und spiegelt den Informationsstand desjeweiligen Knotens wieder. Es werden folgende Informationen über das Verteilte System dargestellt:

• alle bekannten Knoten

• Eigenschaften der Knoten: Hauptspeicher (maximal/frei), Anzahl der Prozessoren, Betriebssys-tem, Java-Version

• Eigenschaften der Verbindungen jeweils zweier Knoten: die Dauer einer Informationsüber-tragung zum entfernten Knoten hin und wieder zurück (engl roundtrip).

Die formale Beschreibung des Umgebungsmodells nach dem in Kapitel 3.3 eingeführten Meta-Umge-bungsmodell ist die folgende:

Auf Basis dieser Informationen kann eine Anwendung in dem Verteilten System ihre Entscheidung zurVerteilung von mobilen Objekten treffen. Da die konkreten Werte des Umgebungsmodells veränderlichsind, ist es aus Sicht der Anwendung unpraktisch, jede Veränderung aktiv zu überwachen. In der vor-liegenden Implementation wurde daher umfangreiche Funktionalität zur Benachrichtigung vonAnwendungen nach dem Beobachter-Entwurfsmuster (engl. observer/listener pattern) integriert. Neben

SEITE 64

Abb. 10: Umgebungsmodell der Implementation

Das von der vorliegenden Implementation angebotene Umgebungsmodell bildet mehrere Eigenschaften derKnoten und eine Eigenschaft der Verbindung zwischen jeweils zwei Knoten ab.

Umgebungsmodell <<MetaUM>>

«Knoten»Node

-Number of CPUs : Eigenschaft-CPU Architecture : Eigenschaft-OS : Eigenschaft-Java-Version : Eigenschaft-Total Memory : Eigenschaft-Free Memory : Eigenschaft

«Relation»NodeInfo

-RoundtripTime : Eigenschaft


«Mobiles Objekt»ApplicationObject

-<<hat Elemente>>

1 0..*

2

-<<hat Elemente>>

0..*


0..*


der Beobachtung des Umgebungsmodells können auch mobile Objekte selbst überwacht werden. Es kanndie Erstellung eines mobilen Objektes und der Beginn und Abschluss von Methodenaufrufen mobilerObjekte verfolgt werden. Im folgenden Programmfragment werden Änderungen des Umgebungsmodells von der Anwendungüberwacht. Sobald im Verteilten System ein neuer Knoten bekannt wird oder der Wert des freien Haupt-speichers gewählte Schranken bricht, werden bestimmte Aktionen ausgelöst.

Codebeispiel : Listener-Funktionalität1.2. public class ListenerDemo { 3. ... 4. public static void main(String[] args) throws Exception {5. ...6. EnvironmentModel model = service.getEnvironmentModel();7. MyEnvironmentModelListener listener = new MyListener(..);8. model.addEnvironmentModelListener( listener, listener );9. ...10. } 11.12. private static class MyListener implements EnvironmentModelListener {13.14. public void newNodeDiscovered(NodeDiscoveryEvent event) {15. try {16. Node newNode = event.getDiscoveredNode();17. mobilityService.setInvocationTarget(mobileObject,null,newNode);18.19. String msg = mobileObject.helloNode( InetAddress.20. getLocalHost().21. getHostName() );22. 23. System.out.println("New node "+msg+" joins our distributed24. system.");25. } catch (Exception e) { e.printStackTrace(); }; 26. } 27.28. public void propertyValueChanged(PropertyValueChangedEvent event) {29. Property prop = event.getProperty();30. if (! prop.getName().equals(Constants.PROPERTY_FREE_MEMORY))31. return;32.33. RelationEntry entry = event.getRelationEntry(); 34. Node node=(Node) entry.getParticipatingNodes().iterator().next();35. Long value=(Long) entry.getPropertyValue(prop);36. 37. if (value.longValue() < 1024*1024) // 1MB should be free38. System.out.println("low on free memory: "+value+" bytes free");39. }40. }41.42.}43.44.public class MobileB implements Serializable { 45. ... 46. public String helloNode(String msg) throws Exception {47. System.out.println("Welcome new node! Greetings from "+msg);48. return InetAddress.getLocalHost().getHostName();49. }50.}

SEITE 65


In diesem Beispiel sind aus Gründen der Übersichtlichkeit einige Details ausgelassen worden (Initialisierungdes Mobilitätsdienstes, Erzeugung der verwendeten mobile Objekte, etc. ). In der stark verkürzten main-Methode wird in Zeile 7 ein Listener angelegt und am Umgebungsmodell registriert. Alle weiterenAktionen finden nun nur statt, wenn das Umgebungsmodell bestimmten Änderungen unterliegt. Tritt ein neuer Knoten dem Verteilten System bei, so wird dies über das Umgebungsmodell reflektiert (Zeile14) und führt zu einer Benachrichtigung über dieses Ereignis. Daraufhin wird ab Zeile 16 der neue Knotenmit einem mobilen Objekt (dessen Erstellung ausgelassen wurde) verknüpft (Verknüpfung für ganzesObjekt – siehe null-Argument für Methode). Der anschließende Aufruf führt zu einer Ausgabe auf demneuen entfernten Knoten (Zeile 47) und einer Ausgabe auf dem originalen Knoten (Zeile 23).Bei jeder Änderung von Werten von Eigenschaften des Umgebungsmodells können ebenfallsBenachrichtigungen empfangen werden. Dies ist ab Zeile 28 demonstriert. In diesem Beispiel ist nur eineÄnderung des freien Hauptspeichers von Interesse (Zeile 30). Unterschreitet dieser eine gewisse Grenze(Zeile 37), wird eine Warnung ausgegeben.

Die nachfolgenden Abschnitte befassen sich nun näher mit den konkreten technischen Abläufen undUmsetzungen. Am Ende des Kapitels befindet sich eine abschließende Bewertung, die die Vor- undNachteile der entwickelten Middleware-Plattform noch einmal kurz diskutiert.

5.3.4 SERIALISIERUNG VON OBJEKTEN IN JAVAWichtig für das weitere Verständnis ist die Kenntnis der Mechanismen der Serialisierung undDeserialisierung in Java. Die ausführliche und maßgebliche Spezifikation wird durch die Firma Sun ge-stellt (siehe Glossar und QuellenverzeichnisXII).Generell ist Serialisierung ein fest in die bestehende Klassenbibliothek von Java eingebundener Me-chanismus, mit dem Objekte bzw. deren Zustand in eine Folge von Bytes transformiert werden kann.Dies kann beispielsweise dem Export des Zustandes über Knotengrenzen oder der Persistierung derObjekte dienen. Objekte sind serialisierbar, wenn ihre Klasse die Schnittstelle java.io.Serializablerealisiert, Arrays sind serialisierbar, wenn alle ihre Elemente serialisierbar sind. Die Schnittstelle java.io.Serializable dient aber nur der Markierung der Objekte und definiertkeine Methodensignaturen. Vielmehr stellt sie eine strukturelle Erlaubnis dar, den Zustand von Objektendieses Typs zu externalisieren. Objekte werden serialisiert, indem sie speziellen Stream-Objekten über-geben werden (java.io.ObjectOutputStream). Diese Stream-Objekte lesen den kompletten Zu-stand ungeachtet vorhandener Zustandskapselung (private etc.) aus und überführen ihn in ein de-finiertes binäres Format. Durch die Verkettung von Stream-Objekten können diese Binärdaten beliebigweiterverwendet werden (Dateien, Netzwerke, etc. ). Der Zustand eines Objektes ist im Allgemeinen einbeliebiger Objektgraph, da Referenzen auf andere Objekte bestehen. Im Zuge der Serialisierung wirddieser Objektgraph (transitive Hülle der erreichbaren Referenzen) komplett in binärer Form abgebildet.Dabei müssen alle Objekte dieser Hülle ebenfalls serialisierbar sein.Beim inversen Prozess der Deserialisierung wird aus einer binären Darstellung durch ein speziellesStream-Objekt (java.io.ObjectInputStream) wieder ein Objekt erstellt, das den entsprechendenZustand besitzt. Dadurch ist gewissermaßen ein zusätzlicher Konstruktor gegeben, denn jederDeserialisierungsvorgang erstellt immer ein neues Java-Objekt mit eigener Identität. Enthält die binäreDarstellung Objekte unbekannten Typs, so müssen bei der Deserialisierung die entsprechendenKlassendefinitionen bereitgestellt werden. In auftretenden Fehlerfällen brechen Serialisierung sowieDeserialisierung komplett ab.

SEITE 66


Dieser grobe Überblick soll an dieser Stelle genügen. Viele weitere Möglichkeiten sowohl seitens der zuserialisierenden Klassen als auch seitens der Stream-Objekte lassen eine genaue Kontrolle dieses Pro-zesses und sogar der binären Repräsentation zu.Serialisierung ist in den den meisten Java-basierten Verteilten Systemen oder Middleware-Plattformender verwendete Mechanismus, um Objekte über die Grenzen des Adressraums zu übertragen. Beispielefinden sich in Technologien und Standards wie JavaRMI, EJB, verteilten Web- und Application-Servernetc. Die oft als Nachteil dargestellte Anforderung, dass die beteiligten Objekte die Schnittstelle Seriali-zable implementieren müssen, sieht der Autor eher als saubere und klare Designentscheidung. Esließen sich eigene Mechanismen realisieren, die die gleiche Mächtigkeit ohne jede Anforderungen an diebetroffenen Objekte erreichen würden. Damit wären jedoch prinzipiell alle Objekte dem Auslesen undder Weitergabe ihres internen Zustandes durch Dritte ohne Einflussnahme ausgeliefert. Jeder eigene Me-chanismus zur Externalisierung des Zustandes von Objekten unterliegt aber ebenfalls der grundlegendenEinschränkung, dass in Java aus einer gegebenen externen Zustandsdefinition eines Objektes immer nurein neues Objekt konstruiert und nie das Ursprungsobjekt verändert werden kann.

5.3.5 AUFBAU VON MOBILEN OBJEKTENBevor das Verhalten der mobilen Objekte näher untersucht wird, soll zunächst die besondere Strukturvon mobilen Objekten geklärt werden. Wie unterscheiden sich in Java mobile Objekte von normalenObjekten und welche grundsätzlichen Varianten gibt es zur technischen Umsetzung der besonderen Be-dürfnisse mobiler Objekte?

1. Kategorie – Objekttransfer durch eine spezielle MethodeAlle bisher betrachteten Verteilten Systeme mit mobilen Objekten, die durch Anwendungslogik zu be-stimmten Knoten transferiert werden können, fallen in diese Kategorie (mobile Agenten, MobileRMI). Einmobiles Objekt migriert bei Aufruf einer ausgezeichneten Methode wie etwa move(..) oder go(..) zueinem definierten Zielknoten. Die Middleware muss also dafür Sorge tragen, dass bei Aufruf dieser spezi-ellen Methode ein mobiles Objekt transferiert wird, während sämtliche sonstige Funktionalität des mobi-len Objekts ohne Wechsel des Knotens ausgeführt werden soll. Bei den in Kapitel 4 betrachteten Syste-men gibt es zwei verschiedene Ansätze zur Realisierung:

• Ansatz A – Ableitung vorgegebener Klassen

Diese Realisierung ist relativ einfach, schränkt aber Anwendungen in ihrer Typhierarchie ein, dain Java keine Mehrfachvererbung möglich ist. Es gibt für alle mobilen Objekte einen bestimmtenvon der Middleware-Plattform vorgegebenen Supertyp, der durch seine Implementation dafürsorgt, dass beim Aufruf einer speziellen Methode der Transfer des jeweiligen Objektes initiiertwird. Für Anwendungen bedeutet das, vorgegebene Klassen zu erweitern, damit ihre mobilenObjekte über die Vererbung der Implementation die Fähigkeit zur Migration auf entfernteKnoten erhalten. Ein Vertreter dieser Variante sind die mobilen Agenten des Projektes Aglets,welches in Kapitel 4 vorgestellt wurde. Dort heißt die spezielle Methode dispatch(..) undtransferiert den Agenten unmittelbar bei Aufruf zum angegebenen Zielknoten.

SEITE 67


• Ansatz B – Realisierung vorgegebener Schnittstellen

Auf den ersten Blick ähnelt die Verwendung der mobilen Objekte bei MobileRMI ebenfalls demeinfachen Schema aus Ansatz A. Bei MobileRMI wird ein mobiles Objekt mittels Aufruf vonmove(...) auf einen spezifizierten Knoten transferiert. Als Erweiterung des ODP-konformenJavaRMI und damit Vertreter von Verteilten Systemen mit entfernten Referenzen ist dieFunktionsweise jedoch grundlegend anders.

Eine Anwendung hat keine Vorgaben bezüglich einer vorgegebenen Klassenhierarchie für ihremobilen Objekte zu beachten. Statt Implementationsvererbung findet nur Schnittstellenverer-bung statt. Die Klassen der mobilen Objekte der Anwendung müssen eine spezielle Schnittstelleimplementieren. Da es in Java zulässig ist, mehrere Schnittstellen zu realisieren, sindAnwendungen wesentlich freier in ihrer Typhierarchie als im ersten Ansatz.

Da bei MobileRMI das mobile Objekt im Allgemeinen permanent auf einem entfernten Knoten ineinem anderen Adressraum residiert, muss die Middleware jedoch nicht nur bei Aufruf der aus-gezeichneten Methode move(..) zum Transfer eines mobilen Objektes tätig werden, sondernjede Interaktion mit diesem mobilen Objekt unterstützend begleiten. Diese Unterstützung wirddurch entfernte Referenzen in Form von Proxy-Objekten realisiert. Aus der Sicht des Aufruferseiner Methode eines sich auf einem entfernten Knoten befindlichen mobilen Objektes ist der Ab-lauf der folgende: Er erhält durch die Middleware (durch den Namensdienst) eine Referenz aufein im gleichen Adressraum befindliches Objekt. Dieses Objekt ist ein durch die Middleware dy-namisch generiertes Proxy-Objekt, das die gleiche Schnittstelle wie das originale, entfernte mobi-le Objekt realisiert. Alle Aufrufe die logisch gesehen an das entfernte mobile Objekt gestelltwerden, werden tatsächlich an das lokale Proxy-Objekt gestellt, welches sie über Hilfsmechanis-men der Middleware an das entfernte mobile Objekt weiterleitet.

SEITE 68

Abb. 11: Mobile Objekte durchImplementationsvererbung. Subtypenstützen sich auf die Fähigkeiten desSupertyps.

+gotoNode(in node)

MobilesObjekt

+businessLogic()

AnwendungsTyp


Durch die Verwendung von Proxy-Objekten wird ein aus Anwendungssicht atomares mobilesObjekt durch mehrere verschiedene Java-Objekte in verschiedenen Adressräumen realisiert.Diese Indirektion erlaubt der Middleware, jede Interaktion mit einem mobilen Objekt abzufangenund zu manipulieren. Die Manipulation besteht normalerweise in der Erfassung des Zustandesder Parameter des Methodenaufrufs und im Austausch dieses Zustandes zwischen den entfern-ten Knoten. Im Falle der speziellen Methode move(..) organisiert die Middleware denphysischen Transfer des entfernten mobilen Objektes zu einem neuen Knoten.

2. Kategorie – Objekttransfer bei jedem MethodenrufFür den in dieser Arbeit gewählten Ansatz der flüchtigen mobilen Objekte ist eine andere Umsetzung er-forderlich. Abhängig von der Entscheidung der Anwendungslogik ist ein Transfer eines mobilen Objektespotentiell bei jedem Methodenruf möglich. Damit ist es nicht möglich, dass eine Klassenhierarchie mitfester Implementation bestimmter Methoden oder eine feste Schnittstelle vorgegeben werden kann. DieMiddleware-Plattform muss dennoch bei jedem Ruf einer beliebigen Methode einer Anwendungsklasseintervenieren können und gegebenenfalls einen Transfer des mobilen Objektes initiieren. Diese Anforderungen berühren aber nicht die eigentliche Funktionalität des mobilen Objektes. Es mussnur vor und nach der eigentlichen Geschäftslogik etwas Zusätzliches geleistet werden. Dies ist ein ty-pisches Szenario eines Aspektes4. Java ist aber keine aspektorientierte Programmiersprache und exis-tierende Java-Objekte sind nicht dynamisch in ihrem Typ erweiterbar. Daher kann ein normales Java-Objekt nicht zur Laufzeit mit dieser neuen Funktionalität erweitert werden. Will eine Anwendung mobileObjekte verwenden, so müssen diese explizit neu angelegt werden. Zwei verschiedene Realisierungensind in der objektorientierten Programmiersprache Java denkbarXIII:

(4) siehe Quellenverzeichnis: Aspektorientierte Programmierung (AOP)

SEITE 69

Abb. 12: Mobile Objekte durch Schnittstellenvererbung unddynamische Proxies. Zu jedem Anwendungstyp kann sodynamisch eine Proxyklasse generiert werden, deren Objekteüberall stellvertretend für Anwendungsobjekte eingesetztwerden können, da sie die identischen Schnittstellenrealisieren. Im konkreten Fall MobileRMI muss dieSchnittstelle der Geschäftslogik die vorgegebene SchnittstelleMobile erweitern.

AnwendungsTyp

+businessLogic()

«interface»Geschäftslogik

+gotoNode(in node)

«interface»MobilesObjekt

DynamicProxy


• Ansatz C – Delegation mit Proxy-Objekten

Hierbei wird ein logisch atomares mobiles Objekt durch mehrere Java-Objekte realisiert. DieStrategie setzt auf Delegation und folgt wieder dem Proxy-Entwurfsmuster als einem Spezialfalldes Adapter-Entwufsmusters5. Im Gegensatz zu Ansatz B befinden sich Proxy-Objekt und dastatsächliche mobile Objekt aber im selben Adressraum.

Zu einem gegebenen Objekt der Anwendung kann die Middleware zur Laufzeit Proxy-Objektegenerieren, die die gleiche Schnittstelle besitzen. Soll nun in der Anwendung ein mobiles Objekteines bestimmten Anwendungstyps erstellt werden, wird dem Aufrufer ein entsprechendesProxy-Objekt zurückgegeben. Dieses referenziert zusätzlich exklusiv eine Instanz des eigentli-chen Anwendungstyps und hat alleinigen Zugang dazu. Alle anderen Objekte referenzieren dasProxy-Objekt, welches Aufrufe vor der Weiterleitung an das funktional „echte“ Anwendungs-objekt mit der Middleware koordinieren kann. Bei entsprechender Verknüpfung der jeweiligenMethode mit einem entfernten Knoten wird dann ein Transfer des mobilen Objektes eingeleitet.

In einer früheren Version der entwickelten Middleware-Plattform wurden flüchtige mobileObjekte nach diesem Ansatz realisiert.

• Ansatz D – Dynamische Bildung von Subtypen

Obwohl es für eine Realisierung von flüchtigen mobilen Objekten nicht praktikabel ist, dassAnwendungsklassen vorgegebene Klassen der Middleware-Plattform erweitern, ist die Umkeh-rung aber möglich: Durch die Middleware werden dynamisch Subklassen von Anwendungs-klassen generiert. Dabei werden alle vorhandenen Methoden überschrieben. Eine Instanz dieserSubklasse realisiert dann weiterhin die selben Schnittstellen wie ein originales Anwendungs-objekt. Durch das Überschreiben der Methoden wird jedoch zunächst die Implementation in derSubklasse aufgerufen, die dort wieder zu koordinativen Eingriffen der Middleware-Plattformführt. Nachdem der Aspekt der Mobilität dort geregelt wurde, kann die eigentliche Funktionali-tät durch einen Aufruf der Implementation der Superklasse durchgeführt werden.

(5) siehe Glossar Adapter / Proxy-Pattern

SEITE 70

Abb. 13: Mobile Objekte durch Proxy-Objekte und Delegation.

DynamicProxy

+businessLogic()

«interface»Geschäftslogik

AnwendungsTyp 11


Die aktuelle vorliegende Implementation folgt diesem Ansatz zur technischen Realisierung dermobilen Objekte6.

Vergleich der Ansätze C und DIm Vergleich haben sowohl Ansatz C wie auch Ansatz D Vor- und Nachteile. Die Wahl auf letzteren fielaber vor allem wegen folgender Problematik: Wenn ein mobiles Objekt durch die Kombination mehrererJava-Objekte realisiert wird, gibt es eine Anomalität bei Selbstrufen des mobilen Objekts (engl. this-calls).Zwar folgen alle Interaktionen anderer Objekte der gewünschten Delegation über das Proxy-Objekt, Me-thodenrufe des „echten“ Objektes der Anwendungsklasse an sich selbst referenzieren sich selbst (engl.this) jedoch im Sinne von normalen Java-Objekten und entgehen damit der Indirektion und Kontrolledurch das Proxy-Objekt. Weitere bedeutende Vor- und Nachteile sind die folgenden:

Ansatz C - Delegation

• Mit einfachen Mitteln der Java-Standardbibliothek sind dynamische Proxy-Klassen für Schnitt-stellentypen (Interface) erzeugbar7. Sollen dagegen für beliebige Klassen dynamisch Proxy-Klassen generiert werden, ist die Middleware auf die Verwendung spezieller externer Bibliothe-ken angewiesenXIV.

• Da flüchtige mobile Objekte nach einem Methodenruf wieder in den jeweils lokalen Adressraumdes Aufrufers zurückkehren, muss sich für alle anderen Objekte sichtbar auch der Zustand derbeteiligten mobilen Objekte ändern können (call-by-reference Semantik). Dies ist bei derVerwendung von Delegation einfach, da das von allen referenzierte, zustandslose Proxy-Objektnicht transferiert werden muss, sondern nur das eigentliche Anwendungsobjekt. Nach dem Me-thodenruf gelangt eine eventuell zustandsveränderte Kopie zurück. Es handelt sich um einanderes Java-Objekt. Dies ist aber unerheblich, da keine externen Objekte das alte Original direktreferenzieren. Das Proxy-Objekt kann jedoch ganz einfach die veraltete Version desAnwendungsobjektes durch die neue ersetzen. Dieser Austausch von Java-Objekten ist nach aus-sen transparent.

(6) Die dynamische Erweiterung von Anwendungsklassen wird dabei mit Hilfe der CGLib-Bibliothek realisiert (siehe Quellenverzeichnis).(7) Siehe JDK-Klassenbibliothek java.lang.reflect.Proxy

SEITE 71

Abb. 14: Mobile Objekte durchdynamische Subtypen.

MobilesObjekt

+businessLogic()

AnwendungsTyp


Ansatz D – dynamische Subklassen

• Ein mobiles Objekt ist auch immer genau ein Java-Objekt. Selbstrufe unterscheiden sich nichtgrundlegend von externen Aufrufen durch andere Objekte.

• Die Generierung dynamischer Subklassen erfordert externe Bibliotheken. Die Ableitung einerbeliebigen Anwendungsklasse stellt folgende Anforderungen: Die Anwendungsklasse musserweiterbar (public und nicht final) sein. Die Methoden müssen überschreibbar (nichtprivate und nicht final) sein.

• Es ist schwieriger als beim Ansatz der Delegation, nach einem erfolgten Methodenaufruf den po-tentiell veränderten Zustand der beteiligten mobilen Objekte im ursprünglichen Adressraumwiederherzustellen. Dies liegt daran, dass durch die Deserialisierung jeweils ein neues, eigenesJava-Objekt erzeugt wird. Eine Anpassung des Zustandes erfordert daher eine explizite An-passung aller Felder (Member) des jeweiligen mobilen Objektes nach einem entfernten Aufruf.Daher dürfen mobile Objekte keine konstanten, also als final deklarierten Felder besitzen.

Abschließend bleibt festzustellen, dass mobile Objekte auf verschiedene Weise realisiert werden können.Die jeweils geeigneten Ansätze sind dabei abhängig von der Ausrichtung des Verteilten Systems. Mitderzeit verbreiteten Programmiersprachen ist aber oft nur ein Kompromiss erreichbar, da der Austauschvon Objekten über die Grenzen des aktuellen Adressraums nicht umfassend unterstützt wird.

5.3.6 ABLAUF DER INTERAKTION VON MOBILEN OBJEKTENNun werden die dynamischen Aspekte von mobilen Objekten betrachtet. Es wird ein Aufruf einer Me-thode betrachtet und es wird angenommen, dass er entfernt stattfinden soll. Als Ausgangspunkt seifolgender Auszug aus dem Progammbeispiel (vgl. Kap. 5.3.1) gegeben:

service.setInvocationTarget(mobileObject, method, node); mobileObject.helloWorld(...);

Die Methode helloWorld(...) wird aufgerufen. Das mobile Objekt ist eine Instanz einer dynamischgenerierten Subklasse der eigentlichen Anwendungsklasse. Daher wird die überschriebene Methode auf-gerufen und so der eigentliche Aufruf der Funktionalität der Geschäftslogik zunächst abgefangen. Nachobiger Annahme erkennt das mobile Objekt, dass diese Methode auf einem entfernten Knoten ausgeführtwerden soll. Nun wird das gerufene Objekt sowie alle Parameter der Methode serialisiert. Damit sindalle Objekte zusammengefasst, die potentiell an der Interaktion irgendwie beteiligt sein könnten. EinenSpezialfall stellen globale Variablen in Form der statischen Felder von Klassen dar. Auf sie wird imnächsten Unterkapitel gesondert eingegangen.

SEITE 72


Die Middleware des lokalen Knotens A nimmt Kontakt zum entfernten Knoten B auf und übermittelt dieserialisierten Objekte sowie Informationen über die auszuführende Methode. Der Kontrollfluss derAnwendung auf Knoten A stoppt hier bis auf Weiteres. Auf dem entfernten Knoten werden aus den übermittelten binären Daten mittels Deserialisierung Java-Objekte erzeugt. Dabei werden eventuell auf Knoten B unbekannte Klassendefinitionen erkannt und ge-bündelt von Knoten A nachgeladen. Dann wird auf Knoten B die Methode in einem eigenen Java-Threadan dem mobilen Objekt mit den aktuellen Parametern aufgerufen.

SEITE 73

Abb. 15: Ablauf eines entfernten Aufrufs; Schritt 1

Das Sequenzdiagramm ist stark vereinfacht und zeigt neben dem beteiligten mobilen Objekt die Middleware alseine Einheit. Nach dem Aufruf von halloWelt wird die reguläre Aktion unterbrochen und statt dessen dieMiddleware-Plattform eingeschaltet (intercept).

halloWelt()

mobileObject

intercept(..)

serialize(..)

Middleware-Plattform

Node A


Node B


Der Austausch von Typdefinitionen ist optional. Nachdem das mobile Objekt übertragen und deserialisiert wurde,wird die eigentliche Funktionalität durch Aufruf der Implementation der Superklasse aufgerufen(super.halloWelt).

halloWelt()

mobileObject

intercept(..)

serialize(..)


Node A


Node B

transfer(..)

requestTypeDefinition(..)

providetTypeDefinition(..)

deserialize(..)

mobileObject

halloWelt(..)super.halloWelt(..)


Im Laufe dieser Ausführung kann es zu weiteren Methodenrufen an mobilen Objekten kommen, die aufeinem weiteren Knoten ausgeführt werden sollen. Der hier beschriebene Vorgang setzt sich dann einfachrekursiv fort, wieder werden Objekte übertragen und der Kontrollfluss bis zum Abschluss der entferntenInteraktion angehalten.Nach Abschluss des Methodenrufs wird schließlich das Ergebnis (oder die aufgetretene Ausnahme)wieder serialisiert und zurück übertragen. Damit endet der jeweilige Java-Thread auf dem entferntenKnoten. Da alle an dieser Interaktion beteiligten mobilen Objekte der call-by-reference Sematik unter-liegen, müssen ebenfalls alle im Verlauf dieses Aufrufs zu Knoten B übertragenen mobilen Objekteserialisiert und rückübertragen werden.Dort auf Knoten A ist nun folgendes Problem zu lösen: Ist der Rückgabewert ein normales Java-Objekt,so kann einfach das neue, durch die Deserialisierung gewonnene Objekt als Rückgabewert der Methodezurückgeliefert werden, schließlich gilt dann call-by-value. Für alle beteiligten mobilen Objekte muss derdurch die Interaktion potentiell veränderte Zustand jedoch auf die originalen Java-Objekte auf Knoten Azurück übertragen werden. Da in Java ein Objekt nicht die Identität bzw. Adresse eines anderen Objektesübernehmen kann, ist eine Übertragung des Zustandes nur dadurch möglich, dass alle Felder (Member)des alten originalen Objektes durch die neuen Belegungen aus der rückübertragenen Kopie über-schrieben werden. Dazu dürfen wie erwähnt die Referenzen nicht als konstant (final) deklariert sein.Dieser ganze Vorgang ist in der vorliegenden Implementation eng in den Prozess der Deserialisierung in-tegriert, damit die Aktualisierung des Zustandes von mobilen Objekten auch unter beliebig vernetztenObjektstrukturen möglich ist. Nach erfolgreichem Abschluss des Methodenrufs kann der ursprünglicheAufrufer schließlich fortfahren.

SEITE 74


halloWelt()

mobileObject

intercept(..)

serialize(..)


Node AMiddleware-Plattform

Node B

transfer(..)

requestTypeDefinition(..)provide TypeDefinition(..)

deserialize(..)

mobileObject

halloWelt(..)super.halloWelt(..)

provide TypeDefinition(..)

requestTypeDefinition(..)

serialize(..)transfer result & mobile objects

deserialize(..)& update state

return result


Nach dem Rücktransfer von Knoten B auf den Ursprungsknoten Knoten A dürften die auf B verbliebenenObjekte, insbesondere die mobilen Objekte, eigentlich nicht mehr existieren. In der Regel werden sie auchdurch die Speicherbereinigung der JVM beseitigt, da sie eigentlich nicht außerhalb des bereitsterminierten Java-Threads bekannt sein sollten. Da ein Verstoß dagegen durch die Anwendung aber nichtdurch statische Maßnahmen verhindert werden kann, werden alle mobilen Objekte invalidiert. Jeder Ver-such einer Interaktion mit diesen invaliden mobilen Objekten erzeugt dann eine Ausnahme. So könnenmobile Objekte nicht gleichzeitig in verschiedenen „Inkarnationen“ unkontrollierbar auf verschiedenenKnoten existieren.

5.3.7 WEITERE IMPLEMENTIERUNGSDETAILSIn diesem Unterkapitel werden weitere Details betrachtet, die bei der vorliegenden Umsetzung von Inter-esse sind, oder die aus den bisherigen Ausführungen als Fragen übrig geblieben sind.

Synchronisationsmaßnahmen der Middleware-PlattformIm oben beschriebenen Ablauf eines entfernt ausgeführten Methodenaufrufs wurde erwähnt, dass derZustand der beteiligten mobilen Objekte nach Abschluss der entfernten Operation aktualisiert wird. Es istauch klar, dass diese mobilen Objekte in der Zwischenzeit vor anderen, potentiell den Zustandverändernden Interaktionen bewahrt werden müssen. Dieser Forderung ist für das aufgerufene Objektselbst leicht nachzukommen, schließlich wurden bei der Einführung der flüchtigen mobilen Objekte (vgl.Kap. 5.2.2) parallele Interaktionen am selben Objekt verboten. Schwieriger ist die Lage jedoch für mobileObjekte, die als Teil der transitiven Hülle der Aufrufparameter ebenfalls zum entfernten Knoten transfe-riert werden. Wann und ob mit ihnen interagiert wird, ist zu Beginn des Methodenrufs nicht abzusehen. In der vorliegenden Implementation wird daher präventiv und sehr umfassend der Zugriff auf diese mo-bilen Objekte eingeschränkt. Bereits während der Serialisierung der transitiven Hülle aller am Methoden-ruf beteiligten Objekte werden dabei betroffene mobile Objekte durch lokale Synchronisationsmechanis-men exklusiv gesperrt. Diese Sperrung erstreckt sich über die gesamte entfernte Ausführung und wirderst nach Abschluss des Methodenrufs, also nach erfolgtem Rücktransfer und der Aktualisierung des Zu-standes gelöst. Die Sperrung verhindert, dass die betroffenen mobilen Objekte mit anderen Objekten dergleichen JVM interagieren können, indem entsprechende Aufrufe blockieren.Wie leicht zu sehen ist, entstehen bei diesem Verfahren Risiken für Verklemmungssituationen. Stößt dieSerialisierung während der versuchten Errichtung der Sperren auf ein schon gesperrtes mobiles Objekt,kollidieren offensichtlich gerade zwei verschiedene entfernte Ausführungen. Interne Maßnahmen stellendann sicher, dass die Situation mindestens für eine der konkurrierenden entfernten Ausführungen erfolg-reich ist und keine Verklemmung auftritt.Die Situation kann jedoch unlösbar werden, wenn die Anwendungslogik zusätzlich durch eigene Syn-chronisation in diese Abläufe eingreift. Dabei auftretende Verklemmungen sind dann nicht automatischerkennbar und behebbar, sondern führen im Allgemeinen zum Stillstand der Anwendung (Deadlock oderLivelock möglich).

Organisation des Verteilten Systems als einfaches Peer-to-Peer Netzwerk Damit der Mobilitätsdienst den Anwendungen ein Umgebungsmodell zur Verfügung stellen kann, mussdie Middleware-Plattform selbst diese Daten von allen beteiligten Knoten aggregieren. Die vorliegendeImplementation ist dazu nach sehr einfachen Prinzipien als Peer-to-Peer-Netzwerk organisiert.

SEITE 75


Jeder Knoten führt dazu eine Liste von bekannten Knoten, an die er wiederholt (im Sekundenabstand)Anfragen über die aktuellen Daten dieses Knotens stellt. Aus diesen Antworten werden die Informa-tionen des Umgebungsmodells aufbereitet. Neue Knoten können auf zwei Arten bekannt werden: Mit jeder Antwort eines entfernten bekanntenKnotens auf eine Anfrage nach dessen aktuellen Daten schickt dieser entfernte Knoten zusätzlich eineListe aller ihm bekannter Knoten mit. So wird das Wissen um neue Knoten im Verteilten System an alleKnoten propagiert. Die zweite Variante ergibt sich dadurch, dass ein Knoten eine Anfrage von einem bis-her unbekannten Knoten erhält. Diesen Knoten nimmt er nun in seine Liste der bekannten Knoten aufund verbreitet diese Informationen an andere Knoten weiter. In der Praxis ist damit ein einfaches Zu-sammenfügen einer Gruppe von Knoten zu einem Verteilten System möglich: Die Middleware wird aufeinem Knoten gestartet und hat zunächst kein Wissen über andere Knoten. Auf allen nachfolgendenKnoten wird dann ebenfalls die Middleware gestartet und der jeweilige Vorgängerknoten als bekannterKnoten des Verteilten Systems angegeben. Nach einigen Zyklen der internen Kommunikation haben allebeteiligten Knoten Kenntnis voneinander und tauschen direkt Informationen aus, aus denen sich die je-weiligen Umgebungsmodelle ergeben.Dieser Teil der vorliegenden Implementation ist bewusst einfach und rudimentär gehalten. Die Art derPropagation von Informationen auf andere Knoten ist in größeren Verteilten Systemen mit vielen Knotenkaum praktikabel. Auch ist nicht vorgesehen, dass einmal am Verteilten System beteiligte Knoten wiederherausgelöst werden können, die Anzahl der Knoten des Verteilten Systems darf also nie kleiner werden.Der Schwerpunkt der Arbeit liegt jedoch auf den Mechanismen für mobile Objekte und ihren Transferund nicht auf einer möglichst umfassenden und effizienten Entwicklung von Peer-to-Peer Netzwerken. In weiterführenden Entwicklungen müssten an dieser Stelle bessere Verfahren gefunden werden. Dabeikönnen bestehende Entwicklungen wie beispielsweise das generische Peer-to-Peer-Framework JXTA8

oder auch andere Modelle wie Client-Server-Architekturen in Betracht gezogen werden.

Objektorientierte und Nachrichten-basierte KommunikationDie entwickelte Middleware-Plattform verwendet intern mehrere Abstraktionsschichten bezüglich derKommunikation unter den Knoten des Verteilten Systems. Der zentrale Teil der Middleware, der die mo-bilen Objekte verwaltet, ihre Serialisierung und Deserialisierung sowie den Transfer bei einem Metho-denruf organisiert, ist rein objektorientiert und unabhängig von der derzeit realisierten Kommunikationüber Sockets konzipiert. Alle Aktionen mit anderen Knoten werden durch Objekte des Typs Messageabgewickelt. Eine spezielle Aktion wird von einem Objekt des Typs Request beim entfernten Knotenangefragt und mit einem Objekt des Typs Response beantwortet (beides Subtypen von Message). Vondiesen Aktionen und damit Paaren von Typen gibt es folgende:

• ExecutionRequest / ExecutionResponse Damit wird die Ausführung einer Methode eines mobilen Objektes auf dem Ziel dieser Nach-richt nachgefragt. Es ist die direkte Folge eines durch die Anwendung getätigten Aufrufs einerMethode an einem mobilen Objekt. Diese Objekte beinhalten Informationen über den Aufruf,den serialisierten Zustand der nötigen Objekte bzw. die Ergebnisse des Aufrufs. Die Antwort(ExecutionResponse) wird erst nach Abschluss des erfolgten Aufrufs auf dem entferntenKnoten versandt und enthält den Rückgabewert sowie den aktuellen Zustand der am Aufruf be-teiligten mobilen Objekte.

(8) JXTA ist eine generische Technologie für Peer-to-Peer Netzwerke; http://www.jxta.org

SEITE 76


• ClassRequest / ClassResponseDamit werden fehlende Typdefinitionen nachgefragt. Nachdem die Antwort mit den benötigtenDefinitionen empfangen wurde, kann der jeweilige Knoten die Typen dynamisch nachladen undInstanzen anlegen. Dies ist oft während einer entfernten Ausführung nötig, da im Allgemeinenauf dem entfernten Knoten nicht alle benötigten Typen bekannt sind. Für die Versionierung vonTypen wird sich auf die in Java vorgesehenen Mechanismen verlassen9.

• EnvironmentRequest / EnvironmentResponseDies sind interne Nachrichten, die ohne Veranlassung durch eine Anwendung regelmäßig zwi-schen den Knoten ausgetauscht werden. Wie oben erwähnt, werden dadurch von einem KnotenInformationen über die anderen Knoten gesammelt und damit das Umgebungsmodell ak-tualisiert.

Diese Nachrichtenobjekte werden der Transportschicht der Middleware-Plattform übergeben, die im vor-liegenden Fall der Kommunikation über Sockets diese Nachrichten wiederum serialisiert und binär über-trägt. Ein serialisiertes mobiles Objekt einer Anwendungsklasse liegt also als Byte-Array den Nachrich-ten-Objekten bei. Diese werden durch die Socket-Kommunikation wieder serialisiert und übertragen.Diese zum Teil doppelte Serialisierung hat folgenden Grund:Eine erfolgreiche Deserialisierung erfordert alle Typdefinitionen der betreffenden Objekte. Soll eine be-stimmte Funktionalität eines mobilen Objektes auf einem entfernten Knoten ausgeführt werden, so fehlendazu sehr wahrscheinlich einige Typdefinitionen. Auf dem entfernten Knoten können die Nachrichten-Objekte aber als Teil der Middleware garantiert deserialisiert und in Objekte decodiert werden. NachAuswertung des Message-Objektes kann dann das eigentliche mobile Objekt der Anwendungslogikdeserialisiert werden, wobei gegebenenfalls zuvor noch mit einer Nachfrage alle fehlenden Klassendefini-tionen gebündelt nachgeladen werden.

Realisierung der Middleware-Plattform durch kooperierende, nebenläufige KontrollflüsseGrob gesehen sind bei der entfernten Ausführung einer Methode eines mobilen Objektes zwei unabhän-gige JVMs auf zwei verschiedenen Knoten involviert. Allerdings sollte diese Aufgabe nicht allein voneinem einzigen Java-Thread pro Knoten abgewickelt werden, da die Middleware eines Knotens potentiellviele mobile Objekte gleichzeitig koordiniert.Während des Transfers von Objektzustand und Typdefinitionen sowie während der Ausführung der Me-thode des mobilen Objektes gibt es einige riskante Abschnitte und einige blockierende Stellen wie etwaden Serialisierungsprozess und die Kommunikation mit entfernten Knoten. Aus Sicht der Middleware-Plattform besteht dort ein Risiko, da mit der Ausführung der Methode des fremden mobilen Objektesauch beliebige Fehlersituationen auftreten können. Die Fehlerbehandlung in Java führt dann zum Ab-bruch der Aktion und kann damit potentiell die Middleware-Plattform als Ganzes beeinträchtigen.Daher ist die Middleware auf jedem Knoten für sich schon durch mehrere kooperierende Java-Threads in-nerhalb einer JVM realisiert, die über spezielle Mechanismen miteinander kooperieren. Fehler in einemJava-Thread beeinflussen nicht automatisch die anderen Java-Threads. So ist die Middleware-Plattforminsgesamt robust und bleibt auch bei vereinzelten Verzögerungen insgesamt responsiv. Für die Imple-mentation dieser Abläufe wurde auf eine externe Bibliothek für entsprechende Konzepte von DoughLeaXV zurückgegriffen. Eine nächste Version dieser als util.concurrent bekannten Bibliothek wirdTeil der Java-Klassenbibliothek Version 1.5.

(9) Siehe Java Object Serialization Specification Kapitel 5

SEITE 77


Folgende Aufgabenbereiche der Middleware-Plattform werden durch separate Java-Threads realisiert:

• Die konkrete Kommunikation über Sockets wird durch zwei Java-Threads realisiert. Der eineüberwacht eingehende Nachrichten auf einem konfigurierbaren Port, deserialisiert die Nachrich-tenobjekte und reiht sie in eine Nachrichtenschlange ein. Der zweite Java-Thread überwacht aus-gehende Nachrichten an einer weiteren Nachrichtenschlange, serialisiert dort ankommendeNachrichtenobjekte und überträgt diese binär an den in der Nachricht bestimmten Zielknoten.

• Ein zentraler Java-Thread überwacht die Nachrichtenschlange der von entfernten Knoten ein-treffenden Nachrichtenobjekte und ordnet sie je nach Typ in andere Nachrichtenschlagen fürandere Verwaltungsthreads ein oder bearbeitet sie selbst. Diese erneute Aufteilung ist wichtig,weil einige der Aufgaben wie Ausführung der Methode eines mobilen Objektes oder dasVersenden von Typdefinitionen fehlerträchtige bzw. durch IO-Zugriffe lange blockierende Vor-gänge sind.

• Jedes Nachrichtenobjekt vom Typ ExecutionRequest wird in einem eigenen, neuen Java-Thread weiter bearbeitet. Es wird das mobile Objekt der Anwendung deserialisiert und die spe-zifizierte Methode aufgerufen. Eventuell auftretende Ausnahmen behindern keine anderen Ab-läufe der Middleware-Plattform und auftretende Pausen durch nötiges Nachladen von Klassenverzögern lediglich die eigene Ausführung.

• Das Bereitstellen von Typdefinitionen (classfiles) als Folge von externen Nachfragen wird auchwieder von einem eigenen Java-Thread organisiert. Einmal gefundene binäre Repräsentationenwerden komprimiert zwischengespeichert, um bei einer wiederholten Anfrage Wartezeitendurch den Zugriff auf langsamen IO-Subsysteme zu vermeiden. Derzeit wächst dieser Zwischen-speicher stetig an und ist nicht echt als Cache beschränkter Größe realisiert10.

• Letztlich organisieren noch ein zusätzlicher Java-Thread und der oben genannte zentrale Java-Thread den internen Informationsaustausch der Knoten untereinander und aktualisieren dasUmgebungsmodell.

Ein Diagramm des Ablaufs eines entfernt ausgeführten Methodenrufs eines mobilen Objektes illustriertTeile der Kooperation der Java-Threads der Plattform und der Anwendung noch einmal anschaulich:

(10) Es ließen sich auch externe Caching-Bibliotheken integrieren, beispielsweise JCS, EHCache oder OSCache.

SEITE 78


Behandlung von globalen Variablen beim Transfer der mobilen Objekte Globale Variablen stellen bei der Interaktion mobiler Objekte eine Ausnahme dar. In Java sind sie durchstatische Felder realisiert (Schlüsselwort static) und können Referenztypen oder primitive Typenhaben. Der sprachlichen Einfachheit halber ist im Folgenden immer von statischen Objekten die Rede, fürprimitive Typen (int, boolean etc.) gelten die Aussagen analog.Wie ihr Name impliziert, sind globale Objekte an keine anderen Objekte gebunden oder von derenLebenszyklus abhängig, sondern sind „immer da“ und global sichtbar. Bei genauerer Betrachtung sind siejedoch einer Klasse oder einer Schnittstelle zugeordnet und haben durch deren qualifizierten Namen qua-si einen Namensraumpräfix zugeordnet (Beispiel: System.out ; out ist statisches Objekt der KlasseSystem). Ganz exakt gesehen besteht diese Zuordnung zu einer Klasse darin, dass die globalen Objektedem jeweiligen Klassenobjekt zugeordnet sind. Das Klassenobjekt (selber vom Typ java.lang.Class)

SEITE 79

Abb. 18: Zusammenarbeit der Java-Threads.

Das Diagramm ist an ein UML-Aktivitätsdiagramm angelehnt, vermischt aber synchrone und asynchroneAbläufe. Jede Einfärbung verdeutlicht, dass die betreffende Aktion in einem eigenen Java-Thread abläuft.Die vier Threads im linken Teil der Legende laufen in der JVM des betrachteten Ausgangsknotens, dieverbleibenden drei Java-Threads laufen auf dem jeweiligen entfernten Knoten ab. Die Entscheidung über einNachladen von Klassendefinitionen ist hier nur einmalig während der Deserialisierung des Objektes und derParameter dargestellt. Prinzipiell kann es dazu aber noch während der gesamten Ausführung der Methodeauf dem entfernten Knoten und auch noch während der Deserialisierung des Ergebnisses auf demAusgangsknoten kommen.

invoke method

serialize object & parameters

send Message receive message

create ExecutionRequest

start execution thread

deserialize object & parameters

create ClassRequest

send Message

receive message

findClasses

create ClassResponsesend Message

receive message

deserialization done execute method

serialize result & mobile objectscreate ExecutionResponsesend Messagereceive message

deserialize result & mobile objects update state of mobile objects return result

User Application Thread

Platform Thread 3

Platform Thread 2

Platform Thread 1

Execution Thread

Platform Thread 4 Platform Thread 5


existiert genau einmal pro Typ und ermöglicht es, die objektorientierte Sichtweise auch auf Typen auszu-dehnen und über Introspektion Informationen über den Typ (Name, Felder, Methoden, etc.) zur Laufzeitzu gewinnen. Das Klassenobjekt wird von der JVM beim Laden der Klasse angelegt. Statische Objekte werden auch während des Ladens der Klasse, sozusagen im Konstruktor des Klassen-objektes11 angelegt. Ein Typ wird in einer JVM genau einmal geladen und initialisiert, nämlich dann,wenn er vorher unbekannt war und erstmals benötigt wird (z.B. zur Konstruktion von Objekten). Dar-über hinaus gibt es weitere Details, auf die an dieser Stelle nicht weiter eingegangen wird (ClassLoader,Runtime-Type etc.).Bei der Ausführung einer Methode eines mobilen Objektes auf einem entfernten Knoten werden alleüber das gerufene Objekt oder die Aufrufparameter transitiv erreichbaren Objekte zum entferntenKnoten transferiert. Dies ist zwar aufwendig, aber vertretbar, da diese Objekte Teile des Zustandes derAnwendung darstellen. Eigentlich müssten zusätzlich alle globalen Objekte übertragen werden, damitsich die entfernte Ausführung wie eine entsprechende lokale Ausführung verhalten kann. Rein konzep-tionell gehören viele der globalen Objekte jedoch nicht zu der Anwendung, sondern sind Teil andererAnwendungen (statische Objekte fremder Klassen) oder sind gar der Umgebung (Ein-/Ausgabe z.B.System.out) zuzurechnen. Eine Übertragung des Zustandes dieser Objekte auf einen anderen Knotenist eigentlich schon konzeptionell fragwürdig. Auch aus technischer Sicht gibt es viele Schwierigkeiten,da zum einen sehr viele globale Objekte existieren können und zum anderen das Manipulieren dieserObjekte Auswirkungen auf alle Anwendungen der jeweiligen JVM hätte. So ist bei der vorliegenden Implementation die Verwendung von statischen Variablen im Zusammen-hang mit mobilen Objekten nicht immer definiert und damit zu vermeiden. Unabhängig vommomentanen Zustand eines globalen Objekts auf einem gegeben Knoten wird bei der Ausführung einerMethode eines mobilen Objektes auf einem entfernten Knoten wahrscheinlich ein anderer Zustand desglobalen Objektes vorgefunden werden. War der Typ zu dem das globale Objekt gehört dem entferntenKnoten bisher unbekannt, so wird das globale Objekt den initialen Zustand besitzen, ist der Typ auf dementfernten Knoten bereits bekannt, kann der Zustand beliebig sein.Diese Einschränkung stellt nicht unbedingt einen grundlegenden Nachteil dar. Die entwickelte Middle-ware-Plattform ist für Anwendungen entworfen worden, die ein Konzept ihrer physischen Verteilungüber die Knoten des Verteilten Systems haben und die Verteilung aktiv manipulieren wollen. Da dabeidie uneingeschränkte Erfüllung von Verteilungstransparenzen überwunden wurde, ist es auch zulässig,dass ein mobiles Objekte nach einem Transfer eine Veränderung seines Umgebungszustands wahr-nehmen kann, zumal globale Objekte meist nicht zum unmittelbaren Zustand der Anwendung selbst ge-hören.

5.3.8 ABSCHÄTZUNG DES LEISTUNGSVERHALTENSZum Abschluss wird an einem einfachen Beispiel das Leistungsverhalten der entwickelten Implementati-on untersucht. Es geht dabei um einen groben quantitativen Vergleich der Laufzeiten von gewöhnlichenMethodenrufen und von Methodenrufen an mobilen Objekten. An dieser Stelle ist nur das Laufzeitver-halten von Interesse, Aspekte des Speicherverbrauchs werden nicht explizit betrachtet. Das kompletteBeispielprogramm (ExampleBenchmark.java) befindet sich im Java-Package der Beispiele (dorn.-joachim.diplom.examples).

(11) static initializer, siehe Java Language Specification Kap. 8

SEITE 80


Allgemeine ErwartungenBeim Aufruf von Methoden an mobilen Objekten muss auf jeden Fall mit einem wesentlich erhöhten Zeit-verbrauch gerechnet werden. Dabei gibt es verschiedene Ursachen, die dazu beitragen können. Einigesind für diese Implementation spezifisch, andere Effekte sind allgemein der Interaktion mit entferntenKnoten geschuldet. Die erwarteten maßgeblichen Ursachen sind:

• Aufrufe von Methoden via Java-Reflection12

In modernen JVM-Implementationen ist der ursprünglich extreme Laufzeitnachteil bei dem Auf-ruf von Methoden über Mechanismen der Java-Reflection deutlich ausgebessert worden undliegt bei den derzeitigen Versionen unter einem Faktor von zehn (Sun JRE 1.4.2).

• Marshalling von Objekten bei entfernten Aufrufen

Bei der vorliegenden Implementation wird dies per Java-Serialisierung realisiert (siehe Kap. 5.3.4)

• Interaktion über die Grenzen der jeweiligen JVM (Inter-Prozess-Kommunikation)

Die Interaktion mit anderen Prozessen hat schon im selben Betriebssystem einen signifikantenZeitverlust zur Folge.

• Netzwerkkommunikation

Um zu einer Einschätzung des Einflusses von Latenzzeiten und Bandbreite zu gelangen, solltenAufrufe mit unterschiedlichen Datenvolumina untersucht werden. Die Kommunikation überSockets kann als relativ performant eingeschätzt werden.

• Laden und Initialisieren von Klassen durch die JVM

Die dafür benötigte Zeit ist von der konkreten JVM abhängig, generell kann dies jedoch ein be-stimmender Faktor sein. Selbst wenn die binäre Klassendefinition (classfile) schon vorliegt, er-fordert das Laden13 in die JVM einige Zeit (grobe Schritte: Laden, Bytecode verifizieren, In-itialisieren von statischen Variablen).

Es wurden keine Vergleiche mit JavaRMI oder MobileRMI durchgeführt. Auf Grund der Besonderheitender gewählten Implementation (flüchtige mobile Objekte, siehe Kapitel 5.2.2) sind jedoch folgende Ge-meinsamkeiten und Unterschiede anzunehmen:

• Die Netzwerkkommunikation wird immer einen entscheidenden Einfluss auf die Ausführungs-zeit haben. Die hier vorgestellte Implementation ist aber im Zusammenhang mit dem Nachladenvon Klassen effizienter, da sie fehlende Klassen gezielt gebündelt nachlädt.

• Die vorliegende Implementation überträgt pro Aufruf nicht nur die jeweiligen Methodenparame-ter, sondern auch das gerufene Objekt selbst. Daher wird pro Aufruf der Umfang der Netzwerk-kommunikation und entsprechend auch der Aufwand beim Marshalling gößer sein.

• Ebenfalls durch die Besonderheiten der gewählten Implementation ist bei jedem Aufruf erneutein Laden und Initialisieren der beteiligten Klassen nötig, da derzeit jede entfernte Ausführungeiner Methode eines mobilen Objektes durch ein eigenes ClassLoader-Objekt koordiniert wird.

• In der derzeitigen Implementation werden alle von entfernten Knoten jemals nachgeladenenKlassendefinitionen in binärer Form gespeichert14. An dieser Stelle könnte die Verwendung einesechten Caches einen Kompromiss aus Speicherverbrauch und wiederholtem Nachladen bringen.

(12) Siehe Package java.lang.reflect der Klassenbibliothek(13) Das Laden von Klassendefinitionen in die JVM ist etwas anderes als das Nachladen der Klassendefinitionen von einem entfernten Knoten über ein

Netzwerk.(14) Sie werden als gzip-komprimierte Bytes gespeichert

SEITE 81


• Es werden in der vorliegenden Implementation verstärkt Mechanismen der Java-Reflectionverwendet, insbesondere auch, um nach einem Methodenaufruf den Zustand der beteiligten mo-bilen Objekte auf dem Ausgangsknoten zu aktualisieren.

TestszenarioEs wurde die Laufzeit von einfachen Methoden gemessen, die in Schleifen mehrfach aufgerufen wurden.Die Methoden selbst haben eine kleine Laufzeit, um die Zeitmessung für die Aufrufe nicht signifikant zubeeinflussen. Dabei wurden folgende Arten von Aufrufen gegenübergestellt:

1. Direkter Aufruf:

Normaler Aufruf einer Methode eines normalen Java-Objektes. Diese Methode ist dabei publicund non-final, damit möglichst nicht der eigentlich virtuelle Aufruf durch die JVM optimiertwird15.

2. Lokaler mobiler Aufruf:

Aufruf einer Methode eines mobilen Objektes. Die Konfiguration des mobilen Objektes sieht abervor, dass die Methode auf dem derzeitigen Knoten ausgeführt wird. Der Aufruf erfolgt also imselben Java-Thread. Neben interner Verwaltung zum Erkennen der lokalen Ausführung sind dabeiMechanismen der Java-Reflection die wesentlichen Aktionen.

3. Entfernter mobiler Aufruf:

Aufruf einer Methode eines mobilen Objektes, welche auf einem entfernten Knoten ausgeführtwerden soll. Um dabei den Einfluss der Kommunikation über das Netzwerk zu bestimmen, werdenhier zwei Varianten betrachtet:

1. Es sind nicht wirklich zwei physisch verschiedene Knoten beteiligt. Statt dessen werden zweiInstanzen der Plattform in zwei JVM-Instanzen innerhalb eines Betriebssystems gestartet. DieKommunikation findet über das Netzwerk-Loopback-Interface statt (localhost / 127.0.0.1).

2. Es werden zwei Instanzen der Plattform auf echt physisch entfernten Knoten verwendet. DieKommunikation findet über ein lokales Netzwerk statt.

Verwendete InfrastrukturAlle Messungen bei denen nur ein physischer Computer verwendet wurde, wurden auf einem MobilePentium III von Intel mit 700Mhz und 392MB Ram durchgeführt. Als Betriebssystem diente MicrosoftWindows 2000 Professional SP3. Als zweiter Rechner diente ebenfalls ein Intel Pentium III, in diesemFall in der nicht-mobilen Ausführung mit ebenfalls 700Mhz und 448MB Ram und dem gleichen Betriebs-system. Das Netzwerk bestand aus einem durch einen Switch verwaltetes 100MBit Ethernet LAN. AlsJVM kam jeweils das JRE 1.4.2_03 von Sun zum Einsatz.

TestprogrammIn dem Testprogramm wurde von der Klasse MobileBenchmark je ein normales Java-Objekt und mobilesPendant angelegt:

MobileBenchmark mobileObject = (MobileBenchmark) factory.createMobileObject(MobileBenchmark.class);

MobileBenchmark normalObject = new MobileBenchmark();

(15) die HotSpot-JVM Versionen von SUN optimieren adaptiv zur Laufzeit und können insbesonders Methodenrufe in Schleifen optimieren (inline einbindenetc. )

SEITE 82


Dann wurde folgende Methode an beiden Objekten aufgerufen. Die auf den ersten Blick unnötig er-scheinende Arithmetik wurde in der Hoffnung verwendet, dass dadurch die dynamisch optimierendeJVM daran gehindert würde, die Aufrufe von doSomething so zu optimieren, dass sie gänzlichverschwinden.

private static int doInLoop(MobileBenchmark obj, int loopCount) { int c = 0; while( (loopCount--) > 0) { c += obj.doSomething(loopCount % (loopCount -(loopCount-8))); } return c;}

... // in Klasse MobileBenchmark:

public int doSomething(int a) { return a+a+3; }

Für die lokalen und entfernten mobilen Aufrufe wurde dann vor dem Aufruf von doInLoop(..) je-weils ein Node-Objekt zugewiesen, das den eigenen bzw. einen entfernten Knoten bezeichnet:

service.setInvocationTarget(mobileObject, MobileBenchmark.class.getMethod("doSomething", new Class[]{int.class}), someNode);

Messung A

Testlauf Testeinstellungen Zeit in Millisekunden Normalisierter Faktor

#1 normales Objekt; direkter AufrufloopCount: 1.000.000 130 1

#2 mobiles Objekt; lokaler mobiler AufrufloopCount: 10.000 450 346

#3 mobiles Objekt; entfernter mobiler Aufruf; Kommunikation über localhost/127.0.0.1loopCount: 100

6180 ca. 475.000

#4 mobiles Objekt; entfernter mobiler Aufruf; Kommunikation zu Rechner 2 im LANloopCount: 100

4960 ca. 380.000

Anmerkungen/Ergänzungen:

• Die Messwerte stellen konkrete gerundete Ergebnisse eines Testlaufs dar. Sie sind jedoch re-präsentativ und gründen sich auf mindestens vier Wiederholungen eines jeden Testlaufs.

• Variante von Testlauf 1:

Ein Aufruf der Methode des normalen Objektes via Java-Reflection an Stelle des obigen direktenAufrufs führte allein zu einem gestiegenen Zeitverbrauch um den Faktor 9.

SEITE 83


• Überraschend ist der Vergleich der Testläufe 3 und 4. Anscheinend ist bei den Testläufen 1 bis 3die Rechengeschwindigkeit ein limitierender Faktor (CPU-Auslastung immer 100%). Bei Testlauf4 war auf beiden beteiligten Rechnern die CPU-Auslastung unter 100%.

• Alle Tests wurden mit den Standardeinstellungen für den Aufruf der JVM durchgeführt. DieVerwendung anderer Einstellungen führte in folgenden Fällen zu signifikanten Unterschieden:

• Starten der JVM im Server-Modus (-server Option). Dadurch wird eine stärkere dyna-mische Optimierung zugelassen. Die zusätzlichen Optimierungsversuche wirkten sich je-doch nur im Testlauf 1 mit einer Laufzeit von 50-80ms positiv aus. Bei allen anderenverschlechterten sich die Laufzeiten geringfügig, bei Testlauf 2 aber sogar auf knapp dasFünffache.

• Starten der JVM mit inkrementeller Speicherbereinigung (-Xincgc Option). Damit wurdendurchgehend schlechtere Ergebnisse erreicht (zwischen 120% und 200%).

• Die Zuteilung von mehr Hauptspeicher für die JVM (-Xms128M -Xmx256M Optionen fürgrößeren Heap) führte in dieser Messung zu keinem signifikant unterschiedlichen Ergebnis.

Messung BUm den Einfluss des Datenvolumens bei entfernten Aufrufen zu bestimmen, wurde obige Messung miteiner anderen Methode wiederholt, bei der ein Byte-Array als Parameter übergeben wurde. Währendnormale Aufrufe und lokale mobile Aufrufe durch die Aufrufsemantik in Java (call-by-reference) von derGröße der Arrays unbeeinflusst bleiben sollten, müssen bei entfernten mobilen Aufrufen alle Parameterecht übertragen werden (call-by-value). Die geänderten Methoden sind:

private static int doInLoop2(MobileBenchmark obj,int loopCount,byte[] buffer) { int c = 0; while( (loopCount--) > 0) { c += obj.doSomethingWithLargeData(buffer); } return c;}

... // in Klasse MobileBenchmark:

public int doSomethingWithLargeData(byte[] b) { return b.length; }


#1 normales Objekt; direkter Aufrufbuffer: 8 Byte; loopCount: 1.000.000 40 1

#2 mobiles Objekt; lokaler mobiler Aufrufbuffer: 8 Byte; loopCount: 10.000 240 600

#3 mobiles Objekt; entfernter mobiler Aufruf; Kommunikation über localhost/127.0.0.1buffer: 8 Byte; loopCount: 100

4330 ca. 1.000.000

SEITE 84



#4 mobiles Objekt; entfernter mobiler Aufruf; Kommunikation zu Rechner 2 im LANbuffer: 8 Byte; loopCount: 100

2800 ca. 700.000




4130 ca. 1.000.000


3060 ca 765.000




71.700 ca. 18.000.000


65.100 ca 16.300.000

Anmerkungen/Ergänzungen:

• Die Messwerte sind ebenfalls konkrete aber repräsentative Messwerte und sind durch je mindes-tens vier Wiederholungen gesichert.

• Die Übertragung von kleineren Datenmengen führt bei entfernten mobilen Aufrufen (Testlauf 3mit 8 Byte und Testlauf 7 mit 16384 Byte) zu keinen signifikanten Unterschieden. Erst die Über-tragung eines 1MB-Arrays als Parameter wirkt sich auf die Laufzeit merklich aus (#11 und #12).

• Die Zuteilung von mehr Hauptspeicher für die JVM Instanzen (-Xms128M -Xmx256M Optionen)hatte lediglich in folgenden Fällen signifikante Verbesserungen zur Folge:

- Testlauf 4 (8 Byte Daten als Parameter) : statt vorher 4330 ms nun 3850ms

- Testlauf 11 (1MB Daten als Parameter) : statt vorher 71.700ms nun ca. 21.500ms

Da Testlauf 7 (16KB Daten als Parameter) nicht von der Vergrößerung des Heap-Speichers profi-tieren konnte, ist das Bild uneinheitlich.

• Der Server-Modus (-server Option) führte überwiegend zu einer erhöhten Laufzeit. Lediglichin den Testläufen 11 und 12 wurden jeweils rund 10 Sekunden eingespart (ca 60.000ms statt vor-her 71.700ms bei #11 und ca 54.500ms statt vorher 65.100ms bei #12).

SEITE 85


Abschließende Anmerkungen für beide Messungen• Die Bedingungen für den normalen Aufruf waren im gewählten Beispiel relativ gut. Während

der Zeitmessung waren alle notwendigen Typen bekannt, so dass es zu keinem Laden vonKlassen in die JVM kam.

• Bei den entfernten mobilen Aufrufen kam es jeweils nur beim ersten Schleifendurchlauf indoInLoop bzw. doInLoop2 zu einem Nachladen von Klassendefinitionen vom anderenKnoten (2 Klassen, zusammen 4KB groß) und damit zu vier Interaktionen zwischen den Knoten(einmal ExecutionRequest/ExecutionResponse und einmal ClassRequest/ClassResponse; sieheKap. 5.3.7). In allen folgenden Schleifendurchgängen wurden jeweils nur zwei Interaktionen(ExecutionRequest/ ExecutionResponse) benötigt, da die bereits binär vorliegenden Klassende-finitionen auf dem entfernten Knoten zwischengespeichert wurden.

• In der derzeitigen Implementation ist jedoch bei jedem einzelnen entfernten mobilen Aufruf einLaden der binären Repräsentation in die JVM und eine Initialisierung der Klassen der Objektenotwendig. Dies scheint einen wesentlichen Teil der Verarbeitungszeit pro Aufruf einzunehmen.

Interpretation der ErgebnisseWie erwartet, erfordern Aufrufe an mobilen Objekten wesentlich mehr Zeit als direkte Methodenrufe,selbst wenn die Ausführung lokal im selben Java-Thread geschieht. Schon ohne mobile Objekte ist imBeispiel ein Aufruf via Java-Reflection ungefähr zehnmal so langsam wie ein direkter Aufruf. Die mobi-len Objekte dieser Implementation sind Instanzen von dynamisch generierten Subklassen (Kap. 5.3.5). Sieverwenden pro Aufruf mehrfach Java-Reflection und haben zusätzliche interne Verwaltungsmechanis-men. Gegenüber direkten Methodenrufen sind sie um einen dreistelligen Faktor langsamer (im Beispiel300- 600). Diese Verzögerung ist also nur den Punkten Java-Reflection und interner Verwaltung ge-schuldet.Bei der Ausführung von Methoden mobiler Objekte auf anderen Knoten wird diese Differenz noch umGrößenordnungen gesteigert. Der Faktor, um den Aufrufe mobiler Objekte langsamer sind, erreichtHunderttausende bis mehrere Millionen. Um hier zu einer genauen Analyse zu gelangen, wären verglei-chende Messungen mit anderen verteilten Technologien wie JavaRMI oder auch CORBA oder .Net hilf-reich. Entgegen den anfänglichen Erwartungen stellt jedoch die eigentliche Kommunikation zwischen den ent-fernten Knoten nicht den limitierenden Faktor dar. Dies zeigt sich dadurch, dass das Szenario zweierJVM Instanzen auf einem physischen Rechner langsamer ist, als die Variante zweier JVM Instanzen aufzwei echt entfernten Computern.So ist anzunehmen, dass andere Technologien eventuell erheblich weniger Zeit beim entfernten Aufrufvon Operationen benötigen könnten, sogar wenn sie ebenfalls auf Java basieren.So sieht der Autor das Marshalling der Objekte, die Inter-Prozess-Kommunikation und auch das intensi-ve dynamische Laden von Klassen als Hauptursache für die auftretenden Verzögerungen an. Diese Ein-schätzung wird auch durch die beobachtete maximale CPU-Auslastung gestützt. Während andere Java-basierende Technologien beim Marshalling der Objekte und der Interaktion mit anderen Prozessen unge-fähr dem selben Aufwand gegenüberstehen, sind nur Technologien für mobile Objekte auf ein häufigesdynamisches Laden von Klassendefinitionen angewiesen16. Es ist aber nicht abzusehen, dass mit dem indieser Arbeit verfolgten Ansatz eine Implementation erreichbar ist, die um einige Zehnerpotenzenschneller ist.

(16) Der Ansatz der flüchtigen mobilen Objekte ist besonders stark betroffen, da Laden und Initialisieren von Klassen bei jedem Aufruf stattfinden muss.

SEITE 86


5.4 BEWERTUNG

Die parallel zur Arbeit entwickelte prototypische Realisierung der vorgeschlagenen ODP-Erweiterungkann im Wesentlichen die in sie gesteckten Erwartungen erfüllen. Die Umsetzung des in dieser Arbeitvorgeschlagenen Mobilitätsdienstes wurde erreicht und bietet die erwartete Unterstützung zur aktivenManipulation der Verteilungsstruktur für Anwendungen auf jeder Rechenplattform mit normaler Java-Umgebung.Wie im Laufe des Kapitels aufgezeigt und diskutiert wurde, gibt es für die Realisierung des Mobilitäts-dienstes und der mobilen Objekte auf mehreren Ebenen verschiedene mögliche Ansätze. Aus der Kennt-nis bereits existierender Umsetzungen wie MobileRMI oder verschiedenen Agentensystemen herauswurde für die Middleware ein neuartiges Konzept zum Transfer und zur allgemeinen Verwaltung vonmobilen Objekten entwickelt. Mit diesen flüchtigen mobilen Objekten wird ein akzeptabler Kompromissaus Einschränkungen der Anwendungsdomänen, dem nötigen Verwaltungsaufwand und der Anfällig-keit gegenüber Verbindungsabbrüchen zwischen den Knoten gefunden. Entsprechend dem prototypischen Charakter der Implementation wurde nur auf thematisch grund-legende Funktionalität geachtet. Es wurde weder auf eine effiziente Kommunikations- und Organisa-tionsform der Knoten untereinander geachtet, noch auf Sicherheitsmechanismen während der Über-tragung oder Beschränkung der Aktionsmöglichkeiten der mobilen Objekte auf den entfernten Knoten.

Insgesamt ist mit der vorliegenden Implementation eine mögliche Umsetzung des in dieser Arbeit vorge-stellten Konzepts eines Mobilitätsdienstes und eines Umgebungsmodells entstanden, die ihre Vor- undNachteile klar herausstellt und so anderen Alternativen konkrete Vergleichsmöglichkeiten bietet. Einengroßen Einfluss auf die entstandene Strukturierung und Umsetzung der Middleware-Plattform hatte dieWahl der Programmiersprache Java. Die damit vorhandenen Möglichkeiten gehen im Kontext dieserArbeit über die Fähigkeiten anderer verbreiteter Programmiersprachen wie C++ hinaus17 und werdennach erster Einschätzung des Autors lediglich von C# oder untypisierten Scriptsprachen erreicht.

(17) Gemeint sind die Möglichkeiten der jeweiligen Standardbibliotheken oder existierender anderer Bibliotheken. Natürlich ist es möglich, in C++Interpreter für Java oder Scriptsprachen zu entwickeln.

SEITE 87

KAPITEL 6. - ZUSAMMENFASSUNG

6. ZUSAMMENFASSUNG Die vorliegende Diplomarbeit befasst sich mit dem Thema der Verteilung von objektorientiertenAnwendungen auf die Knoten eines offenen Verteilten Systems. Der ISO/ITU-Standard RM-ODP dientdazu als Grundlage für die Charakterisierung von offenen Verteilten Systemen und ist zugleich Aus-gangspunkt für eine kritische Diskussion der Grenzen von entsprechenden Verteilten Systemen. Bei-spiele für ODP-konforme Technologien sind z.B. CORBA oder die Java-Enterprise-Platform (RMI, EJBetc.). Während viele Anwendungsbereiche mit den im RM-ODP oder ähnlichen Standards definiertenKonzepten zufriedenstellend erschlossen werden können, sind andere Anwendungen denkbar, die zwarebenfalls für offene Verteilte Systeme konzipiert wurden, die jedoch durch ODP-konforme Verteilte Sys-teme unzureichend unterstützt werden.Zentraler Teil der Kritik am RM-ODP sind die dort definierten Verteilungstransparenzen, die als Garanti-en seitens der Middleware-Plattform gegenüber den Anwendungen alle beobachtbaren funktionalenAuswirkungen der physischen Verteilung über die räumlich getrennten Knoten verbergen. Währendviele Anwendungen indifferent gegenüber ihrer tatsächlichen momentanen Verteilung über die Knoteneines Verteilten Systems zu einem bestimmten Zeitpunkt sind, gibt es Anwendungen, bei denen die Kon-trolle der eigenen Verteilungsstruktur integraler Bestandteil der Geschäftslogik ist.Für diese Anwendungen gibt es bereits existierende Middleware-Plattformen, die aber bisher keinen Be-zug zum RM-ODP oder anderen Referenzmodellen oder Architekturen haben und deren Vergleich-barkeit untereinander auch nicht immer nach einheitlichen Kriterien möglich ist. Die in dieser Arbeit un-tersuchten Beispiele umfassen ausgewählte Projekte aus dem Gebiet der mobilen Agentensysteme sowieMobileRMI als eine Erweiterung der JavaRMI-Technologie.Als Ergebnis der identifizierten Mängel des RM-ODP und der anderen, unterschiedlichen und zum Teilrecht spezialisierten existierenden Middleware-Plattformen wurde in dieser Arbeit eine Erweiterung desRM-ODP vorgeschlagen. Diese Erweiterung beschreibt einen neuen Mobilitätsdienst der Middleware,spezifiziert seine grundlegenden Funktionalitäten und trifft Einschränkungen bisheriger ODP-Konzepte.Der Mobilitätsdienst sorgt zum einen für den Transfer von Objekten und setzt so die Entscheidungen derAnwendungslogik über Verteilungsänderungen um. Zum anderen stellt er den Anwendungen ein ab-straktes Modell der momentanen Struktur des Verteilten Systems zur Verfügung, auf dessen Basis dieAnwendungslogik ihre Entscheidungen treffen kann. Das vorgeschlagene abstrakte Modell ist als gene-risches Meta-Modell durch ein UML-Profil definiert, die programmatischen Schnittstellen zum Umgangmit diesem Modell sind informal beschrieben.Mit dieser Erweiterung werden die eingangs identifizierten Kritikpunkte beseitigt und die bisher mögli-chen Anwendungsbereiche von ODP-konformen Verteilten Systemen ausgedehnt. Die Fähigkeiten derspezialisierten Middleware-Plattformen wie z.B. der mobilen Agenten werden erreicht und zum Teilübertroffen.Die entwickelten Vorschläge werden durch eine ebenfalls im Rahmen dieser Diplomarbeit entwickelteprototypische Implementierung in der Programmiersprache Java ergänzt. Dabei werden an verschie-denen Stellen unterschiedliche Möglichkeiten zur Realisierung diskutiert und die getroffenen Entschei-dungen motiviert. Die entwickelte Umsetzung verwendet sogenannte flüchtige mobile Objekte an Stellevon entfernten Referenzen. Eine Reihe von Beispielen demonstriert die Möglichkeiten der aktiven Steue-rung der mobilen Objekte.

SEITE 88

GLOSSAR

AAdapter-Entwurfsmuster Klassisches Entwurfsmuster (siehe Gamma et. al, siehe Quellenverzeichnis) das beschreibt,wie mit Hilfe von Adapter-Objekten eine Interaktion zwischen semantisch mehr oder wenigerkompatiblen Objekten stattfinden kann, deren Schnittstellen jedoch syntaktisch inkompatibelsind.

AnsichtSiehe Sichtweisen

AnwendungslogikSiehe Geschäftslogik

Aspektorientierte Programmierung (AOP)Der Ansatz der aspektorientierten Programmierung geht über das Paradigma der objekt-orientierten Programmierung hinaus und nimmt sich der Kapselung von „cross cutting con-cerns“ an, die in bisherigen objektorientierten oder prozeduralen Programmen über vieleStellen im Quellcode verteilt sind und die mit den bisherigen Strukturierungsformen wieKlassen nicht zentralisiert und leicht erweiterbar gehandhabt werden können. Klassische Bei-spiele für Aspekte sind Sicherheitsmechanismen und Logging. Zwei bekannte und auf Java aufsetzende aspektorientierte Frameworks sind AspectJ (www.aspectj.org) und HyperJ (http://www.alphaworks.ibm.com/tech/hyperj).

DDienstIn einem Umfeld in dem verschiedene Soft- und Hardwarekomponenten aufeinander aufbau-en, ist der Begriff „Dienst“ gebräuchlich. Er bezeichnet eine beliebige Fähigkeit, die eineKomponente besitzt und die es anderen, übergeordneten Schichten anbietet. Diese Fähigkeitwird von diesen ohne Wissen um die interne Realisierung benutzt (Black-Box-Prinzip).

EEntfernte ObjekteEin Objekt ist aus Sicht eines anderen Objektes entfernt, wenn es sich auf einem anderenKnoten befindet. Da es sich damit ausserhalb des eigenen Adressraumes befindet, muss eineInteraktion über spezielle entfernte Referenzen erfolgen. Da im Grunde das Kriterium desAdressraumes ausschlaggebend ist, müssten eigentlich auch Objekte aus anderen Prozessendes gleichen Knotens als entfernte Objekte angesehen werden. In dieser Arbeit wird jedochdie übliche Sichtweise eingenommen und entfernte Objekte mit entfernten Knoten verbunden.

GLOSSAR

GGeschäftslogikDarunter versteht man diejenigen Abläufe der Anwendung, die den eigentlichen domänen-spezifischen Zweck der Anwendung verkörpern. In gewisser Weise könnte man sie auch alsAlgorithmus bezeichnen. Geschäftslogik ist unabhängig von einer konkreten Programmier-sprache und könnte etwa durch UML-Diagramme definiert sein.

HHostSiehe Knoten

JJavaJava ist eine objektorientierte Programmiersprache. Siehe auch http://www.java.sun.com

Java Remote Method Invocation (JavaRMI)Standardmechanismus in Java, der durch entfernte Methodenrufe verteilte Anwendungenermöglicht (RPC in Java). Siehe auch QuellenverzeichnisXVI.

Java Virtual Machine (JVM)Als JVM wird die Laufzeitumgebung von Programmen bezeichnet, die in Java-Bytecode vor-liegen. Der Name erklärt sich dadurch, dass Java-Bytecode den Befehlssatz für einen einfachenaber virtuellen Prozessor verwendet. Dieser Prozessor ist nicht physisch vorhanden und derBytecode kann daher nicht nativ ausgeführt werden. Eine JVM ist ein Programm, das auf einergegebenen Betriebssystem- und Hardwareplattform diesen virtuellen Prozessor simuliert undden Java-Bytecode ausführt. Dies kann in Form eines Interpreters oder durch Transforma-tionen in nativen Code der jeweiligen Plattform erfolgen. Damit sind Anwendungen unabhän-gig von einer konkreten Plattform, die jeweilige JVM sorgt für die nötige Umsetzung.Siehe auch JVM-Spezifikation: http://www.java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html

KKnotenEin Knoten ist ein autonom funktionsfähiger Rechner und eine physische Komponente einesVerteilten Systems. Ein Knoten kann selbst intern mehrere parallele Prozessoren beinhalten,relevant ist in diesem Zusammenhang nur, dass er gegenüber anderen Knoten als eine atoma-re Einheit auftritt. Aus der äußeren Sicht hat ein Knoten also einen einheitlichen Adressraum,ist entweder fehlerfrei oder befindet sich in einem Fehlerzustand und dient als Endpunkt fürKommunikationsverbindungen.

GLOSSAR

KomponenteDer Begriff der Komponente wird in dieser Arbeit in mehrfacher Bedeutung verwendet. Zumeinen ist damit die Bedeutung als Teil von etwas Größerem gemeint. Diese Bedeutung ist bei-spielsweise im Zusammenhang von Knoten als Teilen (Komponenten) von Verteilten Syste-men anzutreffen.Eine speziellere Bedeutung hat der Begriff der „komponentenorientierten Software“.Komponenten stellen hier eine spezielle Einheit der Strukturierung der Anwendung dar undenthalten im Allgemeinen neben Schnittstellendefinitionen auch Implementationscode sowiezusätzliche Metainformationen. Der Gedanke ist der, dass mit Hilfe dieser Metainformationenneue Anwendungen leicht und automatisiert aus vorhandenen Komponenten zusammenge-fügt oder zur Laufzeit reorganisiert werden können. Die Metainformationen liefern dabei dieGrundlage für eine automatisierte Verwaltung von gegenseitigen Abhängigkeiten, Kontrolleetwaiger Versionsabhängigkeiten sowie die Generierung von eventuell notwendigem Ver-bindungscode (engl. glue-code).

MMarshallingMarshalling bezeichnet den Prozess der Transformation von Daten oder auch Objekten in einegeeignete Repräsentation, um das Ergebnis als Teil einer gültigen Nachricht an entfernte Emp-fänger zu senden. Als allgemeiner Begriff umfasst Marshalling auch den inversen Prozess desDemarshalling oder Un-Marshalling.

Model Driven Architecture (MDA)Standard der OMG. MDA adressiert Technologie-neutral Konzepte zur Entwicklung, Vertei-lung und Verwaltung von Anwendungen und propagiert Portabilität, Sicherheit, Produktivi-tät und Wiederverwertbarkeit von Lösungen. MDA stützt sich dabei auf die modellbasiertenEntwurfsstrategien der OMG wie UML und MOF. Siehe http://www.omg.org/mda/.

Middleware, Middleware-PlattformDie Systemsoftware, die ein Verteiltes System realisiert. Sie verwaltet die Anwendungen unddie Ressourcen, um die die verschiedenen Anwendungen konkurrieren. Die Middleware setztdazu im Allgemeinen ihrerseits auf unterschiedliche Betriebssysteme der einzelnen Knotenauf und schafft darauf eine einheitliche Basis (daher Plattform). Diese Basis definiert gewisseKonventionen und beinhaltet gewisse Zusicherungen an Anwendungen (zum Beispiel Vertei-lungstransparenzen), so dass trotz der heterogenen Zusammensetzung des Verteilten Sys-tems die Anwendungen auf die Knoten verteilt werden können und die Verteilung je nach Be-darf oder Notwendigkeit angepasst werden kann.

Mobile AgentenEin Klasse von Anwendungen für spezielle Verteilte Systeme. Sie realisieren bestimmte Pa-radigmen aus dem Forschungsgebiet der Künstlichen Intelligenz und beeinflussen ihre Vertei-lung auf die Knoten des jeweiligen Verteilten Systems sehr gezielt, um trotz ihres einge-schränkten Informationshorizontes in einem üblicherweise dezentral organisieren VerteiltenSystem ihre Ziele zu erreichen. Siehe auch Kapitel 4.2.

GLOSSAR

Mobiler CodeOberbegriff für eine Klasse von Software, bei der dynamisch Code und manchmal auch Objek-te bzw. Programmzustand zwischen physisch entfernten Knoten ausgetauscht wird. Beispielesind mobile Agenten, das dynamische Nachladen von Klassendefinitionen über das Netzwerkbei JavaRMI oder auch aktive Netzwerke, bei denen zur Laufzeit die Algorithmen der Netz-werkinfrastruktur (Router etc.) abhängig von aktuellen Anforderungen modifiziert werdenkönnen (z.B. verteilte adaptive Caches).

Mobile ObjekteMobile Objekte sind im Allgemeinen entfernte Objekte, die ihren Aufenthaltsort, also denKnoten auf dem sie residieren, ändern können. Entscheidend für die Einstufung als mobilesObjekt ist, dass diese Migration des Objektes von der Anwendung beobachtet und gesteuertwerden kann. Wird dagegen ein Transfer von Objekten von der Middleware so vorgenom-men, dass dies von den Anwendungen nicht festgestellt und beeinflusst werden kann, sokönnen sie nicht als mobile Objekte angesehen werden. Vergleiche dazu „Verteilungstrans-parenzen“ Kapitel 2.2.4.

MobileRMIEine Erweiterung von JavaRMI um mobile Objekte. Siehe auch Quellenverzeichnis

MOFMeta Object Facility, siehe auch Kapitel 3.3.1 und QuellverzeichnisXVII

OODPSiehe RM-ODP

Object Management Group (OMG)Ein 1989 gegründetes Standardisierungsgremium, welches seine Bedeutung aus der Expertiseund Marktposition der Mitglieder bezieht, die überwiegend aus Unternehmen bestehen. Sieheauch http://www.omg.org

PProxy-Objekte / Proxy-EntwurfsmusterKlassisches Entwurfsmuster (siehe Gamma et. al, QuellenverzeichnisXVIII) und Spezialfall desAdapter-Entwurfsmusters. Proxys dienen als Stellvertreter für andere Objekte. Die Schnitt-stelle von Proxy-Objekten ist daher eine Teilmenge der Schnittstelle ihres jeweiligen eigentli-chen Anwendungsobjekts. Diese Funktion als Platzhalter entkoppelt vorher direkt durch Refe-renzen verbundene Objekte und ermöglicht eine feine Kontrolle dieser Bindung.

RReference Model of Open Distributed Processing (RM-ODP)Gemeinsamer Standard der ITU und ISO für offene Verteilte Systeme. Ausführlichere Erklä-rung in Kapitel 2.2.

GLOSSAR

Remote Method Invocation (RMI)Siehe JavaRMI

Remote Procedure Call (RPC)Wichtiges Konzept in der Sichtweise auf Interaktionen zwischen verteilten Computern.Anders als beim Austausch von Nachrichten bei dem die Verteilung offensichtlich wird, dehntdas Konzept der RPCs die von rein lokalen Programmen gewohnte Vorgehensweise des Auf-rufs von in Prozeduren gekapselter Funktionalität auf entfernte Rechner aus. Siehe auchQuellenverzeichnis (Birell & Nelson [I])

SSichtweisenDas Konzept von verschiedenen Sichtweisen auf ein System dient der Bewältigung der Kom-plexität. Oft sind Systeme zu komplex, um alle Aspekte gleichzeitig erfassen und sinnvoll in-terpretieren zu können. Eine Sichtweise betrachtet daher nur einen für den speziellen Anlasswichtigen Teil des Systems und läßt alles andere aus.

SerialisierungIn dieser Arbeit ist damit die Serialisierung von Objekten gemäß der Java Object Serializati-on Specification gemeint. Siehe auch Eintrag im Quellenverzeichnis [XI].

TTelecom Information Networking Architecture (TINA). Referenzarearchitektur für Entwicklung und Verwaltung von Kommunikationsnetzwerkenmit erweiterten Diensten. Siehe auch www.tinac.com

UUmgebungsmodellModell der momentanen Struktur des Verteilten Systems und der Verteilung der Objekte derAnwendung. Siehe Kapitel 3.2.3.

Unified Modelling Language (UML)UML ist eine objektorientierte Modellierungssprache und wird von der OMG standardisiert.Mit Hilfe von 12 standardisierten Diagrammtypen können statische und dynamische Aspektevon beliebigen Systemen detailliert modelliert werden. Im informationstechnischen Umfeldkönnen die modellierten Diagramme oft als weitgehende Spezifikation für eine Implementati-on dienen. Es können auch Teile der Implementation automatisch aus einer UML Spezifikati-on generiert werden.UML beruht als Sprache auf einem Metamodell nach MOF. Im Rahmen der Metamodellierunggibt es die Möglichkeit, bestimmte Anpassungen bzw. Einschränkungen der Sprache UMLüber das UML-Metamodell zu definieren. Dieser Mechanismus ist unter dem Begriff UML-Profil bekannt.

GLOSSAR

VVerteilungstransparenzenVerteilungstransparenzen sind ein Kernkonzept des RM-ODP. Sie umfassen verschiedene Zu-sagen bzw. Garantien eines Verteilten Systems an seine Anwendungen. Im wesentlichen wirdauf logischer Ebene die Zusammensetzung aus heterogenen Rechenknoten vor denAnwendungen verborgen. Dadurch werden Anwendungen bei einer Verteilung auf verschie-dene Knoten des Verteilten Systems nicht in ihrem Ablauf beeinträchtigt. Ausführlichere Er-klärung in Kapitel 2.2.4.

VERZEICHNIS VERWENDETER QUELLEN UND EXTERNER RESSOURCEN

[I] Birrell, A. , Nelson, B. 1984 'Implementing Remote Procedure Calls', in Proceedings of the ACM Symposium onOperating System Principles

[II] Tanenbaum, A.S., Van Renesse, R. 1985 'Distributed Operating Systems', Computing Surveys vol. 17, pp. 419 -470

[III] Coulouris, G. 2000 'Distributed Systems: Concepts and Design', Addison-Wesley

Nach Hinweis aus Entwurf der Habilitation von Dr. Eckhardt Holz (www.informatik.hu-berlin.de/~holz/)

[IV] RM-ODP, 1995

• Teil 1 (Overview): ITU-T Rec. X.901 | ISO/IEC 10746-1

• Teil 2 (Foundations): ITU-T Rec. X.902 | ISO/IEC 10746-2

• Teil 3 (Architecture): ITU-T Rec. X.903 | ISO/IEC 10746-3

• Teil 4 (Architectural semantics): ITU-T Rec. X.904 | ISO/IEC 10746-4

[V] Van Halteren, A. 2003 'Towards an adaptable QoS aware middleware for distributed objects', Universal Press,Veenendaal, p. 61

[VI] Extended Object Definition Language (eODL), ITU-T Recommendation Z.130

[VII] JMI , Java-Metadata-Interface, siehe JSR 40 , http://jcp.org/aboutJava/communityprocess/final/jsr040/index.html

[VIII] MobileRMI, eine auf JavaRMI aufsetzende Technologie für mobile Objekte von Avvenuti M. und Vecchio A. ,Universität Pisa.

einige Veröffentlichungen bezüglich MobileRMI:

• Avvenuti M., Vecchio A. 2000 'MobileRMI: a toolkit for enhancing Java Remote Method Invocation withmobility ', 6th ECOOP Workshop on Mobile Object Systems

• Avvenuti M., Vecchio A. 2001 'Embedding Remote Object Mobility in Java RMI ', 8th IEEE Workshop onFuture Trends of Distributed Computing Systems

• Avvenuti M., Vecchio A. 2002 'Upgrading Java Remote Method towards mobility'

[IX] Folgende Plattformen für mobile Agenten wurden näher betrachtet: Aglets, D'Agents und Nomads. Dabei wurdenjeweils möglichst umfassend die erreichbare Dokumentation und entsprechende wissenschaftlicheVeröffentlichungen untersucht. Die jeweiligen Programmpakete wurden nicht getestet.

Einstiegsseiten der Projektgruppen:

• Aglets: www.trl.ibm.com/aglets/

• D'Agents: http://agent.cs.dartmouth.edu/

• Nomads: http://nomads.coginst.uwf.edu/

Von Interesse sind weiterhin::

• Fünfrocken, S. 1998 'Transparent Migration of Java-based Mobile Agents (Capturing and Reestablishing theState of Java Programs)', Proceedings of the Second International Workshop on Mobile Agents (MA'98),Stuttgart, Germany, September 9 - 11 ; (http://www.informatik.tu-darmstadt.de/VS/Mitarbeiter/Fuenfrocken/)

• 'The Java Language Specification', http://java.sun.com/docs/books/jls/index.html

• 'The Java Virtual Machine Specification', http://java.sun.com/docs/books/vmspec

[X] Eine umfassende Übersicht über Plattformen für mobile Agenten ist als „The Mobile Agent List“ bekannt undunter http://reinsburgstrasse.dyndns.org/mal/mal.html zu finden

[XI] Homepage der Nomads-Projektgruppe : http://nomads.coginst.uwf.edu/

[XII] 'Java Object Serialization Specification', siehejava.sun.com/j2se/1.4/docs/guide/serialization/spec/serialTOC.doc.html

VERZEICHNIS VERWENDETER QUELLEN UND EXTERNER RESSOURCEN

[XIII] Siehe dazu auch Lea, D. 1999 'Concurrent Programming in Java, Second Edition', Addison Wesley Kapitel 1.4'Before/After Patterns'

[XIV] Die in dieser Arbeit verwendete externe Bibliothek zur dynamischen Modifikation von Klassendefinitionen ist dieCode Generation Library (CGLib). Siehe auch http://cglib.sourceforge.net/

[XV] Lea, D. 1999 'Concurrent Programming in Java, Second Edition', Addison Wesley

Siehe auch das java.util.concurrent Package in Java 1.5.0 (http://gee.cs.oswego.edu/dl/ bzw.http://www.jcp.org/en/jsr/detail?id=166)

[XVI] 'JavaRMI Specifikation', 2003, http://java.sun.com/products/jdk/rmi/reference/docs/index.html

[XVII] 'Meta Object Facility (MOF) Specification', 2002 Version 1.4,http://www.omg.org/technology/documents/formal/mof.htm

[XVIII] Gamma, E., Helm, R., Johnson, R, Vlissides, J 1994, 'Design Patterns: Elements of Reusable Object-OrientedSoftware', Addison Wesley

Dieser Arbeit liegt eine CD bei, auf der sich der praktische Teil der Arbeit befindet. Er umfasst dieImplementation einer Plattform für flüchtige mobile Objekte als Quelltext und als lauffähiges Java-Programm. Ergänzend liegen eine Reihe von Beispielen und eine Dokumentation (JavaDoc) bei.

Date post:	16-Aug-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

HUMBOLDT-UNIVERSITÄT ZU BERLIN I FÜR INFORMATIK · 2004-09-27 · KAPITEL 1. - EINLEITUNG 1.3...

Documents