Entwurf und Implementierung einer CORBA-Schnittstelle für eine Mobile-Agenten-Infrastruktur

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungen

1 Einleitung
1.1 Motivation und Aufgabenstellung
1.2 Gliederung der Arbeit

2 Agententechnologie
2.1 Agenten
2.1.1 Charakteristika von Agenten
2.1.1.1 Autonomie
2.1.1.2 Reaktivität
2.1.1.3 Kommunikation / Kooperation
2.1.1.4 Schlussfolgerungs- / Lernfähigkeit
2.1.1.5 Persönlichkeit / Charakter
2.1.1.6 Mobilität
2.1.2 Taxonomie
2.2 Mobile Agenten
2.2.1 Die Arbeitsweise mobiler Agenten
2.2.2 Vor- und Nachteile mobiler Agenten
2.2.2.1 Vorteile bei dem Einsatz mobiler Agenten
2.2.2.2 Nachteile bei dem Einsatz mobiler Agenten
2.3 Mobile Agenten als Basistechnologie für den Zugriff auf CORBA Services
2.4 Zusammenfassung

3 CORBA
3.1 Einführung
3.1.1 Die OMG und ihre Object Management Architecture
3.2 Die Common Object Request Broker Architecture im Überblick
3.2.1 Das OMG Objektmodell
3.2.2 Der Objekt Request Broker
3.2.3 Interface Definition Language
3.2.4 Stubs und Skeletons
3.2.5 Dynamic Invocation Interface
3.2.6 Dynamic Skeleton Interface
3.2.7 Interface Repository
3.2.8 Object Adapter
3.3 CORBA Services
3.3.1 Der Concurrency-Control Service
3.3.2 Der Event Service
3.3.3 Der Externalisation Service
3.3.4 Der Licensing Service
3.3.5 Der Lifecycle Service
3.3.6 Der Name Service
3.3.7 Der Trader Service
3.3.8 Der Objektpersistenzdienst
3.3.9 Der Property Service
3.3.10 Der Query Service
3.3.11 Der Relationship Service
3.3.12 Der Security Service
3.3.13 Der Timer Event Service
3.3.14 Der Transaction Service
3.4 Zusammenfassung

4 Implementierungsaspekte
4.1 Tcl
4.1.1 Tk
4.1.2 Safe-Tcl
4.2 ffMAIN
4.3 Web Server
4.4 MICO
4.5 TclMico
4.6 Anmerkung
4.7 Zusammenfassung

5 Eine CORBA-Schnittstelle für mobile Agenten
5.1 Start der Komponenten
5.1.1 Agentenserver
5.1.2 CORBA @ccesspoint Server
5.1.3 Browser
5.2 CORBA @ccesspoint
5.2.1 Implementation Repository Tools
5.2.1.1 Das Implementation Repository
5.2.2 CORBA Name Service Tools
5.2.2.1 Der CORBA Name Service
5.2.2.2 Der Name Service Setup Agent
5.2.3 Agenten Tools
5.2.4 Bereitstellung der Infrastruktur für den Zugriff mobiler Agenten auf den CORBA-Name Service
5.3 Die Arbeitsweise der CORBA-Schnittstelle für mobile Agenten
5.3.1 Die Name Service-Schnittstelle
5.4 Die Bank-Konto-Anwendung
5.4.1 Die Arbeitsweise des mobilen Kontoführungs-Agenten
5.4.2 Die Arbeitsweise des stationären Konto Server Agenten
5.5 Zusammenfassung

6 Mobile Agent Facility
6.1 Die MAF-Spezifikation
6.2 Die MAF-Schnittstellen
6.2.1 Die MAFAgentSystem-Schnittstelle
6.2.2 Die MAFFinder-Schnittstelle
6.3 Zusammenfassung

7 Zusammenfassung
7.1 Schlussbetrachtung

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

2.1 Eine Agenten-Klassifikation

2.2 Vergleich des Applet-, Servlet- und Remote Procedure Call-Prinzips mit mobilen Agenten

2.3 Die Arbeitsweise eines mobilen Agenten

3.1 Das OMA Referenz-Modell

3.2 Common Object Request Broker Architecture

3.3 Die IDL-Typhierachie

3.4 Funktion des Objekt Adapters

3.5 Objekterzeugung mittels einer Objektfabrik

4.1 Benutzerschnittstelle für den Start des Account-Agenten

4.2 Der Safe-Tcl Mechanismus

4.3 Der Kommunikationsmechanismus von ffMAIN

4.4 Anwendung mit integriertem TclHttpd-Web Server

4.5 dezentrale und zentrale ORB-Realisierung

5.1 Homepage des CORBA @ccesspoint Servers

5.2 Registrierung des Name Service im Implementation Repository

5.3 Start des Name Service Client Agenten

5.4 Interaktion der CORBA Name Service - Schnittstenkomponenten

5.5 Bereitstellung der CORBA-Schnittstelle für die Bank-Konto-Anwendung und Bearbeitung eines Auftrages durch den mobile Konto-Agenten

Tabellenverzeichnis

Verborgene Kommandos in Safe-Tcl Interpretern

Eigenschaften der dezentralen und zentralen ORB-Realisierung

Abkürzungen

Abbildung in dieser Leseprobe nicht enthalten

"Durch Stolpern kommt man bisweilen weiter, man muss nur nicht fallen und liegen bleiben."

Kapitel 1

Einleitung

1.1 Motivation und Aufgabenstellung

Die zukünfig verstärkte Nutzung von Anwendungen über das Internet im Mobilfunkbereich sowie das stetig steigende Interesse an Mobile Computing-Technologien lassen die Verknüpfung zweier Teilaspekte verteilter Systeme sinnvoll erscheinen, nämlich mobile Agenten und CORBA Dienste.

Die Wachstumsmärkte Mobilkommunikation und Mobile Commerce können von dieser Verbindung profitieren, da mittels mobiler Agenten, weniger leistungsstarken Geräten, wie z.B. www-fähige Mobiltelefone und PDAs, die Nutzung von Middleware-Funktionalität zugänglich gemacht wird. Die Agententechnologie erspart die Installation umfangreicher und komplexer Middleware und verlagert die Resourcennutzung auf spezialisierte Server.

Mobile Agenten können von Dienstanbietern zur Verfügung gestellt oder nach Bedarf vom Dienstnutzer erzeugt werden.

Als weitere Einsatzmöglichkeit in Verbindung mit CORBA Diensten wäre denkbar mobile Agenten mit einer Überwachungstätigkeit zu beauftragen.

Ein mobiler Agent kann z.B. die Kurse bestimmter Aktien beobachten und den Benutzer bei über- oder unterschreiten eines festgelegten Wertes informieren. Der Agent kann sogar selbst tätig werden und je nach Auftrag die entsprechende Aktie kaufen oder verkaufen. Die Aktien würden bei diesem Szenario als CORBA-Objekte vorliegen und von der verantwortlichen Institution, also der die Aktien handelnden Börse, verwaltet.

Denkbar ist auch eine Überwachung der medizinischen Daten von Intensivpatienten. Der behandelnde Arzt kann einen mobilen Agenten beauftragen ihn zu benachrichtigen, falls Vitalfunktionen von ihrem Normalbereich abweichen. Die Benachrichtigung kann z.B. mit Hilfe der SMS-Technik auf das mobile Telefon des Arztes erfolgen. Die Patientendaten würden als CORBA-Objekte verwaltet und könnten in ein Gesamtkonzept zur Realisierung der digitalen Patientenakte (CORBAMed [33]) eingebunden werden.

Die Kombination mobiler Agenten mit CORBA Diensten bewahrt den Benutzer vor der zeitintensiven Einarbeitung in komplexe Middleware-Anwendungen. Der mobile Agent erhält einen Auftrag und erledigt diesen autonom für seinen Auftraggeber. Für den Benutzer können durch mobile Agenten lange Wartezeiten vermieden werden, die auf vielbesuchten Servern oder durch geringe Übertragungsraten entstehen. Hierdurch wird die Arbeitseffizienz erhöht, da sich der Anwender bis zum Eintreffen des Ergebnisses anderen Aufgaben widmen kann.

Für die Kombination der beiden Technologien spricht auch, dass bei der Realisierung mobiler Enterprise Strukturen und Applikationen die Unterstützung verschiedener mobiler Endgeräte mit verschiedenen Betriebssystemen und Anwendungen möglich ist.

Die im Rahmen dieser Arbeit implementierte und im weiteren Verlauf vorgestellte CORBA-Schnittstelle für mobile Agenten kann aufgrund ihrer Einsetzbarkeit auf allen wichtigen Betriebssystemen in bestehende IT-Infrastrukturen eingebettet werden, wobei umfassende Sicherheitsaspekte systemimanent sind.

Mit der vorliegenden Arbeit soll gezeigt werden, wie die Nutzung von CORBA Diensten durch mobile Agenten ermöglicht werden kann. Hierzu werden die grundlegenden Konzepte der beiden verknüpften Technologien – mobile Agenten und CORBA – dargestellt, Implementierungsdetails besprochen sowie die Funktionsweise der CORBA-Schnittstelle für mobile Agenten erläutert. Anhand einer für diese Arbeit entwickelte Beispielanwendung wird die Einsatzmöglichkeit nachgewiesen.

1.2 Gliederung der Arbeit

Die Arbeit ist in sieben Kapitel unterteilt.

In Kapitel 2 erfolgt eine Einführung in das Thema Agententechnologie im Allgemeinen und in die, für diese Arbeit verwendeten, mobilen Agenten. Ebenfalls enthalten ist eine Begründung für die Wahl mobiler Agenten als Basistechnologie für CORBA Services.

Eine Vorstellung grundlegender Begriffe und Modelle der Middleware-Architektur CORBA wird in Kapitel 3 vorgenommen. Es enthält darüber hinaus eine Beschreibung der wichtigsten CORBA Services.

Kapitel 4 schließt mit der Darstellung der Komponenten, welche für diese Arbeit benötigt werden, den Grundlagenteil ab.

In Kapitel 5 wird die implementierte CORBA-Schnittstelle für mobile Agenten ausführlich beschrieben. Außerdem wird eine Beispielanwendung vorgestellt, welche die Einsatzmöglichkeiten der implementierten Schnittstelle demonstriert.

Das 6. Kapitel beschäftigt sich mit der Mobile Agent Facility-Spezifikation der OMG. Neben einem Überblick über die Spezifikation wird gezeigt, inwieweit das für diese Arbeit verwendete Agentensystem die Spezifikation erfüllt und mit welchen Mitteln eine Anpassung erreicht werden kann.

Kapitel 7 fasst die gesamte Arbeit zusammen.

Im Anhang findet sich der Quelltext der implementierten Schnittstelle, der realisierten Beispielanwendung einer erstellten CORBA-Managementkomponente als Web-Servererweiterung sowie die Name Service-IDL Datei.

Kapitel 2

2. Agententechnologie

In diesem Kapitel wird eine Einführung in das Konzept der Agenten gegeben. Hierzu wird zunächst konkretisiert, wie Agenten definiert sind und welche Eigenschaften sie haben können. Im weiteren Verlauf wird ein spezieller Agententyp, die mobilen Agenten, beschrieben. Diese bilden die Grundlage für die vorliegende Arbeit. Im dritten Abschnitt dieses Kapitels erfolgt eine Einordnung des Themas mobile Agenten im Bezug auf diese Diplomarbeit.

2.1 Agenten

Die Menge der weltweit zur Verfügung stehenden digitalen Informationen und deren mögliche Nutzung ist bereits heute unüberschaubar groß und nimmt täglich zu. Diese Tatsache ermöglicht intelligenten Software­agenten nach Brenner et al. [5] sich zu einem zentralen Werkzeug der Informationsgesellschaft zu entwickeln. Sie stellen eine neue Kategorie von Instrumenten dar, die den Umgang mit der digitalen vernetzten Welt erleichtern.

Durch die fortschreitende Entwicklung der informationstechnischen Infrastruktur können Benutzer, im geschäftlichen und privaten Bereich, Informationen in digitaler Form aus den Netzen beziehen und für andere bereitstellen. Agenten ersparen hierbei den Benutzern z.B. repetitive und zeitaufwendige Tätigkeiten.

Es ist schwierig eine einheitliche Definition für Agenten zu finden, welche alle Eigenschaften beinhaltet, die diesen Begriff umfassend beschreibt. Jeder Forschungszweig der sich mit Agenten befasst erstellt eine auf seine Bedürfnisse zugeschnittene Definition. Wie Nwana [27] anmerkt, handelt es sich um einen Überbegriff, der einen heterogenen Forschungs- und Entwicklungsbereich beschreibt.

Wooldridge und Jennings [16] definieren den Begriff Agent folgendermaßen:

Ein Agent ist ein Computersystem in einer bestimmten Umgebung, das in der Lage ist, autonome Aktionen in dieser Umgebung zum Erreichen der ihm gegebenen Aufgaben auszuführen.

Mit Autonomie beschreiben die Autoren die Fähigkeit des Agenten selbständig, ohne die Intervention eines Benutzers oder anderer Agenten, zu handeln. Er soll stets selbst die Kontrolle über seine Aktionen und seinen internen Zustand besitzen.

Für die Forschungstätigkeit der Professur Architektur und Betrieb Verteilter Systeme (ABVS) wurden Agenten folgendermaßen definiert [21]:

Ein Agent ist ein Computerprogramm, das den Benutzer bei der Ausführung einer Aufgabe unterstützt. Um dies zu ermöglichen, besitzt es einen persistenten Zustand und kann mit seinem Eigentümer, anderen Agenten und der Systemumgebung kommunizieren.

2.1.1 Charakteristika von Agenten

Es gibt zahlreiche Attribute welche je nach Einsatzgebiet und Fachrichtung den Agenten zugeschrieben werden. Die nach [5] wichtigsten Merkmale werden im Folgenden kurz beschrieben.

2.1.1.1 Autonomie

Einer der wesentlichen Unterschiede zwischen Agenten und herkömmlichen Softwareprogrammen besteht in der Fähigkeit eines Agenten seine Ziele zu großen Teilen autonom, das heißt ohne Eingriffe oder Anweisungen der Umwelt, zu verfolgen.

2.1.1.2 Reaktivität

Sie beschreibt die Fähigkeit eines Agenten in angemessener Art und Weise auf Einflüsse und Informationen aus seiner Umgebung zu reagieren. Hierzu benötigt er einen Sensor-Mechanismus. Die für den praktischen Teil der vorliegenden Arbeit verwendeten Agenten der Agenteninfrastruktur ffMAIN (siehe Kapitel 4.2) besitzen die Möglichkeit, sich über Veränderungen eines von ihnen festgelegten Bereiches asynchron informieren zu lassen:

2.1.1.3 Kommunikation / Kooperation

Die Erfüllung seiner Aufgaben erfordert von einem Agenten oft die Interaktion mit seiner Umwelt. Hierzu zählen vor allem Benutzer und andere Agenten. Die Interaktion lässt sich in zwei aufeinander aufbauende Stufen unterscheiden, nämlich die Kommunikation und die Kooperation. Erstere ermöglicht dem Agenten die Kontaktaufnahme mit seiner Umwelt über fest vorgegebene Mechanismen zum Austausch von Informationen. Für einen Dialog zwischen mehreren Agenten, mit dem Ziel gemeinsam eine Aufgabe zu lösen, reicht dies aber nicht aus. In diesem Fall muss die Kommunikationsfähigkeit um eine darüber hinausgehende Eigenschaft, die Kooperation, ergänzt werden. Komplexe Aufgaben, die einen einzelnen Agenten überfordern, lassen sich durch Kooperation mehrerer Agenten schneller und besser lösen. Jeder Agent profitiert von der Kooperation, da er seine eigenen Ziele in kürzerer Zeit erreicht oder sogar komplett von anderen Agenten lösen lassen kann. Miteinander kooperierende Agenten müssen über eine erweiterte Agenten-Kommunikations-Sprache verfügen, da sie nicht nur reine Kommunikationsprotokolle benötigen, sondern darüber hinaus auch ihre Zielvorstellungen, Absichten und bisherigen Wissensstände untereinander austauschen müssen.

2.1.1.4 Schlussfolgerungs- / Lernfähigkeit

Jeder Agent muß einen bestimmten Mindestgrad an Intelligenz besitzen, um überhaupt als Agent bezeichnet werden zu können. Allerdings ist, insbesondere im Bereich der Intelligenz, eine sehr breite Spanne zwischen einfachen, nur wenig intelligenten Agenten und komplexen, hochintelligenten Systemen denkbar. Die Intelligenz eines Agenten setzt sich aus drei Hauptkomponenten zusammen:

(1) seiner internen Wissensbasis

der Fähigkeit Schlussfolgerungen, basierend auf den Inhalten der Wissensbasis zu ziehen

die Fähigkeit zu lernen, bzw. sich Änderungen der Umwelt anzupassen

Die Fähigkeit zur Schlussfolgerung versetzt einen Agenten in die Lage, seine Umwelt zu beobachten und bei Änderungen innerhalb dieser Umwelt bestimmte Schlussfolgerungen zu ziehen. Mindestens ebenso wichtig für das intelligente Verhalten eines Agenten ist jedoch die Fähigkeit, aus den bisherigen Erfahrungen zu lernen und die eigenen Verhaltensweisen Schritt für Schritt besser an die Umwelt anzupassen. Dies gilt sowohl in Bezug auf die Kommunikation mit Nutzern und anderen Agenten, als auch für die zur Verfügung stehenden Resourcen.

Der Lernprozess eines Agenten sollte, ähnlich wie der Schlussfolgerungsprozess, rationale Züge besitzen, das heißt er sollte den Agenten stets der Erfüllung eines seiner Ziele näher bringen.

2.1.1.5 Persönlichkeit / Charakter

In vielen Fällen ist es wünschenswert, dass ein Agent nach außen ein möglichst menschenähnliches Verhalten demonstriert. Tritt ein Agent beispielsweise gegenüber seinen Benutzern als virtuelle Person auf, als sogenannter Avatar, so muß er, um diese Rolle sinnvoll ausfüllen zu können, bestimmte menschliche Charaktereigenschaften besitzen. Für einen Agenten wichtige Eigenschaften sind vor allem:

Ehrlichkeit

Vertrauenswürdigkeit

Zuverlässigkeit

Kein Benutzer würde einem Agenten wichtige Aufgaben anvertrauen, wenn er die Befürchtung hätte, dass dieser nicht vertrauenswürdig wäre und mit Absicht ein nicht abgesprochenes Ziel verfolgt oder vertrauliche Informationen an andere Agenten oder Personen verraten würde.

Für solche Agenten, die viel mit menschlichen Personen interagieren, ist es von großer Bedeutung, emotionale Zustände, z. B. Freude, Trauer oder Ärger in ihren Verhaltensweisen widerspiegeln zu können. Ohne Emotionen lassen sich viele Situationen und Resultate dieser Agenten nicht vernünftig nach außen kommunizieren, da es leicht zu Mißverständnissen kommen kann.

2.1.1.6 Mobilität

Mobilität beschreibt die Fähigkeit eines Agenten zur Migration zwischen verschiedenen Rechnern, um die ihm gegebene Aufgabe zu erfüllen. Mobile Agenten sind in der Lage, von einem Rechner eines Netzwerkes zu einem anderen zu wandern. Stationäre Agenten sind dagegen an ihren Standort gebunden. Das Kapitel 2.2 beschäftigt sich mit dem Thema mobile Agenten ausführlich.

2.1.2 Taxonomie

Einen weiteren Überblick über Agententypen erhält man durch die in Abbildung 2.1 gezeigte Klassifikation.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Eine Agenten-Klassifikation

Bei biologischen Agenten kann man zwei Teilbereiche unterscheiden. Makro-Agenten sind z.B. Reisebüros, Versicherungsagenturen, Künstlervermittlungen – also "menschliche" Agenturen. Diese sollen ihr Fachwissen einsetzen, um im Auftrag des Kunden etwa einen Reise zu buchen, die günstigste Versicherung zu ermitteln oder einen Vertrag für ein Engagement abzuschließen. Dem Mikro-Bereich kann man die Symbiose, also das Zusammenleben verschiedener Arten zuordnen. Hierbei profitiert in der Regel jeder Partner von dieser symbiotischen Gemeinschaft. So gibt es z.B. Pflanzen, die durch die Ansiedlung von Pilzen an ihren Wurzeln für ihre Versorgung mit Nährstoffen, Wasser und Ionen sorgen [18]. Es ist allerdings fraglich, ob diese Einordnung unter dem Hauptbegriff Intelligente Agenten ihre Berechtigung hat. Dieser Sachverhalt kann durchaus kontrovers diskutiert werden. Da er aber für diese Arbeit im Speziellen und für den Bereich der Software Agenten im Allgemeinen keinen Einfluss hat, soll hier nicht weiter darauf eingegangen werden. Hardware-Agenten stammen aus einem Fachgebiet, das sich mit Robotik beschäftigt. Für diese Arbeit ist der Bereich der Software Agenten und hier speziell das Teilgebiet der mobilen Agenten relevant. Der Einsatz mobiler Agenten ist in allen drei Kategorien von Software Agenten denkbar.

2.2 Mobile Agenten

Mobile Agenten sind Programme, welche eigenständig von einem Client-Computer zu verschiedenen Servern migrieren können, um dort ausgeführt zu werden [55].

Die Idee der Client/Server-Kommunikation durch Übertragung ausführbarer Programme existiert schon sehr lange. In den letzten Jahren wurde das Interesse an diesem Gebiet durch Forscher und Entwickler verstärkt, die sich mit Themen wie z.B. Electronic Commerce, Software Distribution, Information Retrieval, System­administration, Netzwerk Management und Mobile Computing beschäftigen.

Verglichen mit anderen, "verwandten" Technologien unterscheiden sich mobile Agenten von Applets (heruntergeladener Programmcode vom Server zum Client), Abbildung 2.2.a, und Servlets (heraufgeladener Programmcode vom Client zum Server), Abbildung 2.2.b, derart, dass sie vom Client entkoppelt sind und zur Erledigung ihrer Aufgabe eigenständig mehrere Hosts aufsuchen können [25]. Im Vergleich zu Remote Procedure Calls (RPCs), Abbildung 2.2.c, welche auf den Transport von Daten zu entfernten Prozeduren beschränkt sind, transportieren mobile Agenten, Abbildung 2.2.d, beides, die Daten und das Programm welches die Daten verarbeitet [6].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Vergleich des Applet- (a.), Servlet- (b.) und Remote Procedure Call-Prinzips (c.) mit mobilen Agenten (d.).

2.2.1 Die Arbeitsweise mobiler Agenten

Mobile Agenten sind in der Lage sich innerhalb eines elektronischen Netzwerkes und den darin befindlichen Rechnern frei zu bewegen und dabei mit den Objekten ihrer Umgebung, wie z.B. Informationsquellen oder anderen Agenten, zu kommunizieren. Die Art des Netzwerkes spielt nur eine untergeordnete Rolle. Es kann sich beispielsweise um ein firmeninternes LAN, ein nationales WAN oder um ein weltumspannendes Netzwerk, wie das Internet, handeln. Entscheidend ist die Tatsache, dass ein mobiler Agent sich von einem Rechner des Netzwerkes zu einem anderen bewegen kann und dabei in seiner Arbeitsweise nicht beeinträchtigt wird. Man spricht in diesem Zusammenhang auch von der Fähigkeit zur Migration. Stationäre Agenten sind im Gegensatz dazu nicht in der Lage, ihre Ursprungsumgebung, das Rechnersystem auf dem sie erzeugt wurden, zu verlassen [5].

Der mobile Agent kapselt die Prozedur, welche auf einem entfernten Host ausgeführt werden soll, die Daten als Argumente für die Prozedur und den Zustand des Agenten. Anschließend migriert der mobile Agent auf einen Server, auf dem er die ihm gestellte Aufgabe, z.B. durch Kommunikation mit einem stationären Service-Agenten, ausführt. Für die Erledigung seiner Aufgabe sind evtl. weitere Migrationen erforderlich. Diese initiiert der mobile Agent dann in Abhängigkeit seines internen Zustandes. Nach Beendigung seiner Arbeit kehrt der mobile Agent an seinen Ursprungsort zurück, sofern er Ergebnisse abzuliefern hat. Diese allgemeine Vorgehensweise ist in Abbildung 2.3 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Die Arbeitsweise eines mobilen Agenten

Mobile Agenten vereinen also Programmcode und Zustand. Wenn sie auf einen neuen Host migrieren wird beides dorthin transportiert. Das hat den Vorteil das der Agent nicht nur weiß was er zu tun hat, sondern sich auch daran "erinnert" was er bereits getan hat.

2.2.2 Vor- und Nachteile mobiler Agenten

Den offensichtlichen Vorteilen mobiler Agenten stehen einige gewichtige Nachteile gegenüber. Hier lassen sich vor allem die hohen Anforderungen an die technische Infrastrukur und Sicherheitsprobleme nennen, welche mit dieser Technologie verbunden sind. Dieser Abschnitt stellt die Argumente für als auch gegen den Einsatz mobiler Agenten gegenüber.

2.2.2.1 Vorteile bei dem Einsatz mobiler Agenten

Brenner [5] beschreibt die folgenden Vorteile:

Reduzierte Netzwerkbelastung

Die Verringerung des Netzwerkverkehrs stellt einen der wesentlichen Vorteile mobiler Agenten dar. Da mobile Agenten die meisten Aufgaben auf entfernten Servern erledigen, wird die Menge der über das Netz zu übertragenden Daten auf ein Minimum reduziert. Außer dem eigentlichen Agenten müssen nur die Informationen transportiert werden, die der Agent für die Erledigung seiner Aufgabe benötigt oder die dem Benutzer als Ergebnis präsentiert werden sollen. Insbesondere bei großen Datenmengen, wie z.B. bei Datenbankabfragen, Video-, Audio- und Bilddaten, ist es von entscheidender Bedeutung, dass nicht alle "Rohdaten" zum Benutzer übertragen werden müssen, damit dieser anschließend entscheidet, welche Informationen für ihn interessant sind und welche nicht. Der mobile Agent kann durch die Formulierung seines Auftrages die relevanten Daten eigenständig ermitteln und diese zum Benutzer übertragen. Die Kommunikationskosten verringern sich, da das Volumen der zu transportierenden Daten sinkt und die Berechnung nach der Dauer der Verbindungszeit oder der Menge der übertragenen Daten erfolgt.

Reduzierte Resourcenbelastung des Client

Mobile Agenten nutzen zur Bearbeitung ihrer Aufgaben die Kapazitäten und Resourcen der entfernten Server. Hierdurch ergibt sich für den Rechner auf dem der mobile Agent gestartet wurde, also den Client, eine deutliche Entlastung. Diese Tatsache ermöglicht die Benutzung "leichtgewichtiger" Endgeräte wie PDAs und WWW-fähige Mobiltelefone als Startpunkt für mobile Agenten. Auf der Server-seite kommt es durch den Betrieb der mobilen Agenten zu einer höheren Belastung einiger Resourcen, wie z.B. CPU und Arbeitsspeicher.

Asynchrone Arbeitsweise

Im Gegensatz zu stationären Agenten, die nicht zwangsläufig asynchron arbeiten, verwenden mobile Agenten prinzipiell eine asynchrone Vorgehensweise. Sie werden von ihren Benutzern mit bestimmten Aufgaben betraut, begeben sich zur Lösung dieser Aufgaben zu einer Anzahl verschiedener Server und kommen zu einem späteren Zeitpunkt mit den ermittelten Ergebnissen zurück. Der Benutzer muss den Agenten, aufgrund seiner Autonomie, während seiner Arbeit nicht beaufsichtigen. Er kann seine Verbindung zum Netzwerk trennen. Wenn der Agent seine Arbeit beendet hat wird er bei einer erneuten Netzverbindung des Auftraggebers auf dessen Rechner zurückmigrieren.

Rekonfigurierbare Dienste

Herkömmliche Softwareprogramme, bei denen die Kommunikation via RPC stattfindet, bieten nur sehr eingeschränkte Möglichkeiten sich auf individuelle Bedürfnisse der Nutzer einzustellen, da die aufrufbaren Prozeduren des entfernten Servers sowie die Art und Anzahl der Parameter fest vorgegeben sind. Durch den Einsatz mobiler Agenten wird diese Problematik umgangen. Ein mobiler Agent enthält die speziell auf seinen Benutzer abgestimmten Prozeduren und kann diese selbständig zu einem entfernten Server transportieren. Spezielle Prozeduren müssen also nicht durch den Server-Betreiber entwickelt und bereitgestellt werden, sondern werden durch den Agenten selbst angeboten. Dieser Vorgang geschieht vollständig dynamisch, da der Agent automatisch auf dem entfernten Server installiert und ausgeführt werden kann. Bietet beispielsweise ein Datenbankserver Prozeduren zur Durchsuchung seines Datenbestandes nur nach einzelnen Schlüsselfeldern an, kann kein komplexer Suchvorgang durch Kombination mehrerer Schlüsselfelder genutzt werden. Ein mobiler Agent kann jedoch Prozeduren für komplexere Suchtransaktionen enthalten, die auf den angebotenen einfachen Prozeduren des Servers basieren. Da der mobile Agent auf dem Datenbankserver ausgeführt wird, erscheint es seinem Benutzer, als ob ihm die vom Agenten angebotene komplexe Suche durch den Server zur Verfügung gestellt wird. Für den Benutzer ist nicht die Tatsache relevant wer letztendlich die erweiterte Funktionalität anbietet, sondern ausschließlich, dass diese ihm zur Verfügung steht. Mobile Agenten ermöglichen somit rekonfigurierbare, individuell gestaltete Dienstleistungen, die mit herkömmlichen RPCs nicht realisierbar wären.

Aktives Handeln

Die Fähigkeit mobiler Agenten, sich selbständig zu entfernten Rechnersystemen zu bewegen, macht aktive Handelsszenarien denkbar. Ein Händler kann durch den Einsatz mobiler Agenten potentiellen Kunden direkt neue Dienstleistungen anbieten, indem er entsprechende Agenten entwickelt und diese zu den Rechnern der Kunden schickt [23]. Beispielsweise kann Softwareverteilung und die automatische Installation neuer Softwareversionen, durch dafür entwickelte mobile Agenten, für den Nutzer auf transparente Art vorgenommen werden. Kunden erhalten so durch mobile Agenten nicht nur spontanen Zugriff auf neue Dienste, sondern müssen nicht einmal selber aktiv werden. Auch für die beteiligten Händler ergeben sich Vorteile. Dazu gehören u.a. die aktive Ansprache der Kunden und die flexibleren und dynamischeren Distributionsmöglichkeiten neuer Dienstleistungen und Angebote.

2.2.2.2 Nachteile bei dem Einsatz mobiler Agenten

Der Einsatz mobiler Agenten birgt allerdings auch einige Hürden die prinzipiell bei der Mobilität von Programmobjekten auftreten:

Sicherheit

Der Erfolg mobiler Agenten wird im wesentlichen Maße von der Lösung der mit dem Einsatz von Agenten verbundenen Sicherheitsprobleme abhängig sein.

Die folgenden Teilprobleme lassen sich bestimmen: eindeutige Identifizierung und Authentifizierung der beteiligten Komponenten Schutz vor virusähnlichen mobilen Agenten mit böswilliger und zerstörerischer Programmfunktion Schutz des Agenten vor Modifikation durch fremde Server Absicherung der Zahlungsfähigkeit und Zahlungswilligkeit der Agenten Ein Benutzer wird einem Agenten nur dann wichtige Aufgaben erteilen oder ihm vertrauliche Daten anvertrauen wenn er der Überzeugung ist, dass der Agent seine Daten vertraulich behandelt und keine Möglichkeiten für andere Personen oder Objekte bestehen, die Arbeit des Agenten zu beeinträchtigen, indem sie beispielsweise illegal an vertrauliche Daten des Agenten gelangen.

Effizienz

Es ist möglich das der Besuch vieler mobiler Agenten auf einem Server zu großen Belastungen führen kann. Derzeit liegen noch keine Erfahrungen vor wie ein Server sich verhält auf dem hunderte oder gar tausende von Agenten gleichzeitig aktiv sind und welche Netzwerkbelastung eine große Anzahl mobiler Agenten erzeugen können.

Standardisierung / Interoperabilität

Die Technologie der mobilen Agenten kann sich nur dann etablieren, wenn genügend Anlaufpunkte im Netzwerk angeboten werden. Jeder beteiligte Server muss ein Agentensystem zur Verfügung stellen, das den unterschiedlichen Agententypen eine auf sie abgestimmte Laufzeitumgebung bietet. Dies lässt sich durch die Definition und Verabschiedung von Standards bewirken. In Kapitel 6 wird gezeigt, wie sich die in dieser Arbeit genutzte Agenteninfrastruktur in einen bereits existierenden Standard einfügt.

Transport / Migration

Die Anforderungen an die bei der Migration von Agenten beteiligten Softwareumgebungen auf der Client- und Serverseite sind hoch. Es sind eine Reihe komplexer Softwaremodule und –schichten notwendig, um Agenten überhaupt transportieren zu können. Derartige Komponenten sind zur Zeit meist erst als Prototypen verfügbar, was die praktische Einsatzfähigkeit mobiler Agenten einschränkt.

Abrechnungssysteme

Ohne detaillierte Möglichkeiten zur Ermittlung und Abrechnung von Resourcenverbräuchen, lassen sich die durch mobile Agenten erzeugten Kosten nicht erfassen. Hierzu müssen zum einen Standards für die Erfassungssysteme innerhalb des Servers geschaffen werden und zum anderen finanzielle Abrechnungssysteme, mit deren Hilfe die entstandenen Kosten auf effiziente Weise abgerechnet werden können.

2.3 Mobile Agenten als Basistechnologie für den Zugriff auf CORBA Services

Die Verwendung mobiler Agenten für den Zugriff auf CORBA Services ermöglicht es, auf Arbeitsplatz- oder Mobilrechnern sowie auf PDAs oder WWW-fähigen Mobiltelefonen, die CORBA-Funktionalität zu nutzen. Hierfür müssen auf diesen Geräten keine umfangreichen CORBA-Produkte installiert werden. Die CORBA-Funktionalität kommt von Servern, die für mobile Agenten zugänglich sind. Die mobile Agenteninfrastrukur ist sehr kompakt im Gegensatz zu den großen CORBA-Produkten.

Die Verbindung dieser Technologien bietet so eine leistungsfähige und flexible Möglichkeit auf CORBA-Funktionen zugreifen zu können. Mobile Agenten können, bei Kenntnis beider Technologien (CORBA und mobile Agenten), ohne großen programmiertechnischen Aufwand erstellt werden und lassen sich zu leistungsfähigen CORBA-Anwendungen ausbauen.

Als Einsatzgebiet ist beispielsweise ebenfalls denkbar, mobile Agenten als Brücke zwischen verschiedenen CORBA-Produkten einzusetzen, welche aufgrund proprietärer Teillösungen nicht direkt miteinander kommunizieren können. Mobile Agenten würden dann Verbindungen zu mehreren CORBA-Plattformen aufbauen.

Die Funktionalität der CORBA Services wird im nächsten Kapitel ausführlich erläutert.

2.4 Zusammenfassung

Bei Agenten handelt es sich um Computerprogramme, welche ihre Benutzer bei der Ausführung von Aufgaben unterstützen und dabei mit ihren Eigentümern, anderen Agenten und der Systemumgebung kommunizieren können.

Den Verwendungsmöglichkeiten von Agenten sind in der digitalisierten und vernetzten Welt eigentlich keine Grenzen gesetzt. Je mehr Inhalte zur Verfügung stehen, z.B. im Internet, und je leistungsfähiger die verwendete Netzwerk-Infrastruktur ist, um so größer werden die Einsatzmöglichkeiten für Agenten sein.

Es existieren Agenten mit verschieden starken Ausprägungen der beschriebenen Charakteristika. Autonomie ist wohl die von den meisten Forschungsbereichen gleichermaßen geforderte Haupteigenschaft. Die Fähigkeit der Agentenmobilität ist für diese Arbeit das wichtigste Merkmal.

Mobile Agenten können von einem Ursprungsort zu anderen Servern migrieren, um so die vom Benutzer vorgegeben Aufgaben zu erfüllen.

Agententechnik spart Zeit und Rechnerkapazität. Ist die Netzverbindung über ein Notebook begrenzt, die Bandbreite über ein Modem eingeschränkt oder der Anschluss teuer, weil er über ein Mobiltelefon läuft, dann übernimmt der Agent die Aufgabe und führt sie losgelöst fort. Die Verbindung mit dem Netz kann nach Vergabe des Auftrages sofort unterbrochen werden. Der Agent führt seine Aufgabe aus und wartet auf einem Knotenrechner auf eine erneute Verbindung zur Kommunikation mit dem Auftraggeber.

Mobile Agenten haben einige unbestreitbare Vorteile, denen zur Zeit noch eine Reihe technischer Hürden gegenüberstehen. So vermeidet das Remote-Programming-Prinzip den Austausch großer Datenmengen im Netz, wie es bei der herkömmlichen Client-/Server-Umgebung nötig wäre. Ein weiterer Vorteil ist, dass sich verteilte Softwareinfrastrukturen durch Agenten dynamisch konfigurieren lassen. Außerdem bieten sie z.B. Verminderung der Resourcenbelastung auf der Client-Seite, asynchrone Arbeitsweise und aktives Handeln. Damit sich mobile Agenten als Instrumente der Informationsgesellschaft etablieren können, müssen allerdings noch Punkte wie Interoperabilität, Fragen der Effizienz sowie Abrechnung erbrachter Leistungen und der Sicherheitsproblematik geklärt werden.

Als Basistechnologie für den Zugriff auf CORBA-Funktionen erschließen mobile Agenten leistungsschwächere und mobile Endgeräte. Diese könnten ansonsten aufgrund der hohen Anforderungen an die Infrastruktur die CORBA-Funktionalität nicht nutzen.

Kapitel 3

3. CORBA

Dieses Kapitel beschreibt eine Kommunikations-Middleware für verteilte Objekte [50] und ihre Entstehung. Der erste Teil gibt eine Motivation für die Entwicklung einer solchen Plattform und zeigt die Object Management Architecture, die ihr zugrunde liegt. Im zweiten Abschnitt wird die Common Object Request Broker Architecture mit ihren wichtigsten Bestandteilen vorgestellt. Der dritte Teil führt die bedeutendsten CORBA Services und deren Funktionen ein.

3.1 Einführung

Die zentrale Motivation für die Entwicklung von Rechnernetzen und Informationssystemen ist der Wunsch nach Kommunikation und Kooperation. Wie die Entwicklung des Internet in den letzten Jahren und die stets wachsende Zahl derer die diese Technologie nutzen zeigt, existiert ein großes Bestreben durch ein verteiltes System alle nur denkbaren Informationen und Funktionalitäten jederzeit abrufen zu können.

Das Internet ermöglicht den Zugriff auf Daten die weltweit verteilt verfügbar sind. Diese Informationen lassen sich mit Browsern auf den eigenen Rechner holen. Mit Mailprogrammen kann Informationsaustausch und Kommunikation schnell und einfach stattfinden.

Ein Vorteil des Internet, nämlich die Möglichkeit mit einer Vielzahl von Produkten – sowohl Software als auch Hardware – an dieser Technologie teilzunehmen, erweist sich gleichermaßen als Nachteil. In diesem hochgradig heterogenen Umfeld ist es trotz der verfügbaren Daten noch nicht möglich, entfernte Dienste zu nutzen. Die Rahmenbedingungen, um in einem verteilten System von jedem Rechner auf die komplette Funktionalität jedes anderen zugreifen zu können, scheinen hierfür zu eng gefasst: hier bedarf es eines "universellen Mittels" zur Beseitigung der Schwierigkeiten.

Es existiert ein Schlagwort, welches die Lösung der genannten Probleme verspricht – die Objekttechnologie. Objektmodelle werden erstellt, um die Kommunikation zwischen heterogenen Softwarekomponenten zu ermöglichen, fehlertolerante Systeme mit optimalem Laufzeitverhalten sowie Leistungsfähigkeit zu gewährleisten.

Das Objektmodell ist also die Grundlage für die gewünschte universelle Rechnerkommunikation. Ein Objekt kann als Black Box angesehen werden, welches eine öffentliche Schnittstelle besitzt. Mittels dieser Schnittstelle kann ein Programmierer das Objekt im eigenen Programm referenzieren, ohne Kenntnisse über dessen Implementierung zu haben. Die Grundidee ist, Programmiersprachenunabhängigkeit dadurch zu erreichen, dass man die Schnittstellendefinition von der Implementierung trennt. Ein so definiertes Objektmodell soll garantieren, dass Objekte unterschiedlicher Herkunft, d.h. von verschiedenen Entwicklern in unterschiedlichen Programmiersprachen entwickelt, zusammenarbeiten können.

Ein Objektmodell für ein verteiltes System stellt weitergehende Anforderungen. Da Produkte verschiedener Hersteller kooperieren sollen, ist hier sowohl Software- als auch Hardwareheterogenität zu berücksichtigen. Objekte sollen über Prozess- und Rechnergrenzen hinweg genutzt werden können. Das erweiterte verteilte Objektmodell gewährleistet, über eine Referenz entfernte Objekte zu lokalisieren und Methodenaufrufe an entfernten Objekte auszuführen. Damit ist das verteilte Objektmodell die Grundlage für Kommunikation in verteilten Systemen, in denen die Funktionalität der Rechner auch von anderen Rechnern genutzt werden kann.

Ein solches verteiltes Objektmodell liefert die Objekt Management Group mit der von ihr spezifizierten und im folgenden beschriebenen Object Management Architecture. Die hieraus resultierende Common Object Request Broker Architecture (CORBA) stellt einen Softwarebus zur Verfügung, der die Verwaltung von Objekten und Methodenaufrufen regelt, wobei die Spezifikation sowohl Programmiersprachen- als auch Plattformunabhänigkeit fordert. Hierdurch ist es möglich, den o.g. Anforderungen gerecht zu werden, nämlich Objekte in einer beliebigen objektorientierten Programmiersprache zu implementieren und auf beliebigen Rechnern auszuführen. Ein im verteilten System existierender Client kann dann über den auf einem Netzwerk basierenden Softwarebus eine Objektreferenz auf dieses Objekt erhalten, Methodenaufrufe übermitteln und das entsprechende Ergebnis zurückgeliefert bekommen [22].

3.1.1 Die OMG und ihre Object Management Architecture

Die Object Management Group wurde 1989 aus einem Konsortium mehrerer Firmen gegründet und besteht mittlerweile aus über 800 Mitgliedsfirmen. Die Aufgabe der OMG ist die Förderung und Entwicklung objektorientierter Technologie. Sie beschäftigt sich nach eigenen Angaben mit der Erstellung von Industrienormen und Spezifikationen zur Unterstützung einer allgemeinen Plattform zur Anwendungsentwicklung. Das Ergebnis dieser Arbeit soll die Entwicklung heterogener Rechnerumgebungen ermöglichen [47].

Die Grundlage aller Aktivitäten der Gruppe ist die abstrakte Beschreibung der Objektwelt aus Sicht der OMG, welche sie in der Object Management Architecture (OMA) [31] zusammengefasst hat. Bei der in Abbildung 3.1 gezeigten Referenzarchitektur handelt es sich um eine Plattform zur Entwicklung verteilter, objektorientierter Anwendungen. Die Object Management Architecture ist aber keine konkrete Implementierung oder gar ein Produkt, sondern eher eine Richtlinie, die keine Vorschriften über die bei der Implementierung zu verwendenden Technologien macht. Vergleichbar mit dem ISO/OSI-Referenzmodell, das die Architektur aller möglichen Netze grundsätzlich beschreibt, unabhänig von der Art der Endgeräte und Anwendungen, aber auch unabhänig von der Art der technischen Vernetzung [17].

Ein zentraler Punkt der OMA ist die Beschreibung von Schnittstellen. Hierfür wird von der OMG eine Sprache definiert, die sogenannte Interface Definition Language (IDL) (Kapitel 3.2.3). Sie dient der Spezifikation "sichtbarer" Eigenschaften von Objekten, dazu gehören Attribute, Operationen, Exceptions und Datentypen für die Kommunikation mit den Objekten. Die Schnittstellendefinition legt die Verwendungsmöglichkeiten des beschriebenen Objektes fest. Hiermit wird sichergestellt, dass die von verschiedenen Programmierern entwickelten Teile einer komplexen Anwendung korrekt zusammenarbeiten.

Die Bestandteile einer verteilten Anwendung sind in Komponenten unterteilt, welche aus einer Menge von Objekten gebildet werden, die eine bestimmte Aufgabe erfüllen sollen. In der Terminologie der OMG wird die von den Komponenten ausgeführte Aufgabe als Dienst oder Service bezeichnet. Die Dienst-spezifikation erfolgt in separaten Standards, in denen die geforderte Funktionalität sowie die Interfaces der Objekte in IDL festgelegt werden. Eine Implementierung der Services wird von der OMG nicht bereitgestellt, dies ist Aufgabe der Hersteller, die ein CORBA-konformes Produkt anbieten oder der Anwendungsprogrammierer, welche eine verteilte Applikation auf CORBA-Basis erstellen.

Die OMA klassifiziert die Dienste in 5 Gruppen:

- Object Request Brocker
- Object Services
- Common Facilities
- Domain Services
- Application Objects

Diese Gruppen lassen sich wie folgt beschreiben:

Der Kern der CORBA-Kommunikation ist der Object Request Broker (ORB). Der ORB [30] stellt die Infrastruktur zur Verfügung, welche einen transparenten Informationsaustausch zwischen Clients und Serverobjekten ermöglicht, unabhänig von spezifischen Plattformen und Techniken der Objektimplementierung.

Der ORB kann von Objekten zur Kommunikation mit anderen Objekten im selben Programm, wie auch in anderen Programmen benutzt werden. Das aufrufende Objekt muss also nicht wissen auf welchem Rechner sich das referenzierte Objekt physikalisch befindet. Der ORB ermöglicht die transparente Weiterleitung der Objektaufrufe über einen Zielrechner zu dem adressierten Objekt, unabhängig vom Betriebssystem des Rechners oder der Programmiersprache des Zielobjektes.

Die Object Services beschreiben die fundamentalen Schnittstellen zur Realisierung von CORBA-Anwendungen [29]. Diese sogenannten CORBA Services können flexibel miteinander kombiniert werden, sie erleichtern und vereinheitlichen die Anwendungsentwicklung. Kapitel 3.3 enthält die Beschreibung einiger CORBA Services.

Ziel der Common Facilities [32] sind Schnittstellendefinitionen auf höherer Anwendungsebene als die Object Services. Die OMG umschreibt sie als "End-nutzerorientiert". Diese stark spezialisierten, funktionalen Einheiten machen den wesentlichen Teil einer Anwendung aus. Die sogenannten horizontalen^[1] Systemdienste können durch Konfigurationsmechanismen an verschiedene Aufgabenstellungen angepasst und somit in mehreren Anwendungen eingesetzt werden. Beispiele für Common Facilities sind graphische Benutzeroberflächen (GUI), Dienste zur Druckersteuerung, zur Dokumentenverwaltung, Datenbanken und E-Mail. Ihre Standardisierung führt zu einer konzeptionellen Integrität verschiedener Anwendungen, so dass sich ein Benutzer beispielsweise nicht für jede Anwendung auf einen neuen Mechanismus zum Ausdrucken von Dokumenten umstellen muss [43].

Domain Services stehen auf gleichhoher Ebene wie die Common Facilities. Sie enthalten branchenspezifische Schnittstellen wie zum Beispiel für Finanz- (CORBAfinancials), Gesundheits- (CORBAmed) [33][52] und Telekommuni­ka­ti­ons­we­sen (CORBAtel). Aufgrund der Spezialisierung werden sie auch als vertikale^[2] Dienste bezeichnet.

Application Objects sind konkrete produktive Systeme, wie sie vom Anwender gesehen werden. Traditionell kann man ein Application Object auch als Anwendung bezeichnen. Da es eine individuelle Lösung für ein spezielles Problem darstellt, ist es für ein bestimmtes Anwendungsgebiet optimiert. Im Gegensatz zu den anderen Kategorien werden Application Objects nicht durch die OMG spezifiziert.

3.2 Die Common Object Request Broker Architecture im Überblick

Die CORBA-Spezifikation der OMG beschreibt ein System zur Realisierung der Interoperabilität zwischen Objekten in heterogenen, verteilten Umgebungen. Ihr Design basiert auf dem Objektmodell der OMG. Abbildung 3.2 zeigt die Struktur der Architektur. Die zentrale Komponente von CORBA ist der Object Request Broker. Objektmodell und ORB werden in den folgenden zwei Abschnitten vorgestellt. Anschließend erfolgt die Beschreibung der Interface Definition Language, Stubs und Skeletons sowie des Dynamic Invocation Interface und des Dynamic Skeleton Interface. Am Ende werden die beiden wichtigen Aspekte Interface Repository und Object Adapter betrachtet [51].

3.2.1 Das OMG Objektmodell

Grundlegender Baustein für verteilte Anwendungen in der OMA ist das Objektmodell. Ein Objekt ist nach [22] definiert als eine Modellierung jeder möglichen Komponente der realen Welt. Um ein Objekt zu bestimmten Aktionen zu veranlassen, werden Operationen definiert. Weiterhin besitzt ein Objekt mindestens eine Schnittstelle an der die Operationen aufgerufen werden können.

Das Grundprinzip des Objektmodells – die Trennung von Schnittstellenbeschreibung und ihrer Implementierung – wird dadurch ermöglicht, dass nicht das Objekt als Instanz einer Klasse, sondern die Klasse selbst in einer sprachunabhängigen Form beschrieben wird. Ein Mechanismus erzeugt dann Instanzen von Klassen und Methodenaufrufe, die innerhalb der Schnittstellendefinition einer Klasse beschrieben werden. Durch dieses Prinzip des Objektmodells, Schnittstellen und Implementierung zu trennen, wird der Zustand eines Objektes gekapselt. Auf Objekte kann somit nur durch ihre Methoden zugegriffen werden, welche in der Schnittstellendefinition spezifiziert sind. Nur über diese Methoden lässt sich der Zustand eines Objektes verändern.

Das OMG Objektmodell definiert implementierungsunabhängig allgemeine Objektsemantiken für die Spezifikation der extern sichtbaren Eigenschaften der Objekte [42]. Weiterhin beschreibt es Konzepte zur Objekterzeugung, zu Anfragen, Typen und Signaturen sowie Konzepte zur Objektimplementierung.

Vorteil des objektorientierten Ansatzes ist die Modularität. Objekte können leichter in Anwendungen integriert werden, mehrere Objekte können kombiniert oder existierende Anwendungen entsprechend erweitert werden. Daraus ergeben sich für eine CORBA-Anwendung kurze Entwicklungszeiten und eine flexible Struktur der Software.

3.2.2 Der Objekt Request Broker

Der ORB stellt die Basismechanismen für die transparente Anfrage und den Empfang von Antworten von lokalen oder entfernten Objekten zur Verfügung, ohne das der Client die Mechanismen für die Kommunikation, die Aktivierung oder Speicherung von Objekten kennen muss. Dieses Ziel wird nach [42] erreicht durch

Zugriffstransparenz

Hierbei hat der Quellcode zur Durchführung von Aufrufen die gleiche Syntax, egal ob Client und Server im gleichen Adressraum liegen oder auf verschiedenen Rechnern in einem Netzwerk.

Ortstransparenz

Interaktionen mit entfernten Objekten zeigen ein identisches Verhalten, unabhänig von ihrem Ort.

Implementierungstransparenz

Interaktionen sind unabhänig von programmiersprachlichen Einzelheiten der beteiligten Objekte.

Insofern bildet der ORB die Grundlage für die Konstruktion von Anwendungen aus verteilten Objekten und für die Interoperabilität zwischen Anwendungen in homogenen und heterogenen Umgebungen.

3.2.3 Interface Definition Language

Die Interface Definition Language (IDL) ist eine abstrakte, programmiersprachenunabhängige Beschreibungssprache, welche die an der Schnittstelle von Objekten sichtbare Funktionalität beschreibt und dabei Implementierungsdetails der eigentlichen Objekte verbirgt [22]. Mit IDL wird also festgelegt, welche Operationen auf dem beschriebenen Objekt ausführbar sind, welche Parameter diese Operation benötigt, welche Attribute das Objekt besitzt und welche Ausnahmebehandlungen für das Objekt definiert sind.

IDL bildet die Grundlage für die Trennung von Schnittstelle und Implementierung der Objekte und ermöglicht es somit Objekten, die mit verschiedenen Programmiersprachen erstellt wurden, miteinander zu kommunizieren. Eine Eigenschaft die in heterogenen Systemen besonders wichtig ist, da verschiedene Plattformen und Programmiersprachen unterstützt werden sollen. Dieser Aspekt ist auch bei der Interaktion mobiler Agenten mit CORBA Services relevant, wenn z.B. ein in Tcl geschriebener Agent mit einem in C++ realisierten Server kommunizieren soll.

Im folgenden Abschnitt wird die Vorgehensweise bei der Definition einer Objektschnittstelle veranschaulicht.

Die Schnittstellenbeschreibung erfolgt in IDL mit Hilfe einer Reihe syntaktischer und semantischer Konstrukte. Anschliessend wird sie mit einem IDL-Kompiler in eine Art Headerdatei der gewählten Programmiersprache übersetzt. Diese Übersetzung erfolgt nach den Regeln der Sprachabbildung (Language Mapping) in eine Programmiersprache, für die das Language Mapping definiert ist (z.B. Java, C++, Smalltalk, C, COBOL). Abbildungen für andere Sprachen, die derzeit noch nicht von der OMG standardisiert sind, gibt es ebenfalls. Die eigentliche Implementierung wird dann in der gewählten Programmiersprache vorgenommen.

Jede auf CORBA basierende Applikation benötigt Zugriff auf das IDL Typensystem. Dies ist notwendig, da die Applikation Kenntnis über die Werte der Typen haben muss, die bei einer Anfrage als Argument übergeben werden. Viele Applikationen benötigen lediglich statische Kenntnis des IDL Typensystems. Bei diesem statischen Ansatz muss bei jeder inkompatiblen Veränderung des Typensystems die Anwendung ebenfalls angepasst werden, d.h. der Code muss jedesmal neu generiert und in die Applikation integriert werden. Das CORBA Interface Repository (IR) erlaubt es, dass auf das IDL Typensystem zur Laufzeit zugegriffen werden kann. Das IR selbst ist ein CORBA-Objekt, dessen Operationen genau wie bei jedem anderen Objekt aufgerufen werden. Der Vorteil besteht darin, dass Applikationen nicht laufend neu kompiliert werden müssen, wenn ein neuer Schnittstellentyp dem IDL Typensystem hinzugefügt wird. Statt dessen ermittelt die Applikation die für sie notwendige Information dynamisch und macht sich die Typinformation erst dann zunutzte, wenn sie tatsächlich benötigt wird.

Die IDL Typen werden, wie in Abbildung 3.3 dargestellt in Kategorien eingeteilt.

Objektreferenz ist eine Referenz auf ein beliebiges anderes Objekt

Basistypen sind die von vielen Programmiersprachen bekannten Typen. Nennenswert ist der Typ Any, der Werte beliebigen Typs aufnehmen kann.

Zusammengesetzte Typen bestehen aus mehreren Basistypen. Auch in dieser Kategorie gibt es einen erwähnenswerten Typ: Except repräsentiert eine Ausnahme, die bei der Ausführung einer Operation auftreten kann.

Schnittstellendefinitionen auf Basis der OMG-IDL benutzen die folgenden Hauptkonstrukte:

Module gruppieren Teile der Definition die eine gewisse Zusammengehörigkeit aufweisen. Sie können weitere Moduldefinitionen und Interfacebeschreibungen enthalten.

Interfaces beschreiben die von einem CORBA-Objekt bereitgestellten Dienste. Diese Dienste erscheinen in Form von Operationen und ähneln Methoden in objektorientierten Programmiersprachen wie C++ und Java. Weiterhin enthalten sie Attribute und Exceptions welche das Objekt beschreiben.

Operationen sind Prozeduren, die von Clients ausgeführt werden können. Eine Operation besteht aus einem Namen und aus einer Signatur. Die Signatur beschreibt Anzahl und Typ der Parameterliste und des Resultats. Die Parameter werden unterschieden in in, out und inout Parameter. Diese Unterscheidung beruht auf der Semantik der Parameterübergabe (call by value oder call by reference). Weiterhin beinhaltet die Signatur eine Angabe, welche Exceptions durch die Operation ausgelöst werden können.

Es besteht auch die Möglichkeit eine Operation als "oneway" zu deklarieren, dies bedeutet, dass das Objekt, welches diese Methode aufruft, nicht blockieren wird. Statt dessen wird es die Remote-Methode aufrufen und anschließend sofort mit der Verarbeitung fortfahren während das Remote-Objekt die Remote-Methode ausführt. Der Vorteil dieser Vorgehensweise ist der, dass das aufrufende Objekt mit seiner Arbeit fortfahren kann, anstatt darauf zu warten, dass das Remote-Objekt die Anfrage abschließt.

Die Flexibilität des oneway-Aufrufmodells hat jedoch ihren Preis: Da der Methodenaufruf zurückgegeben wird bevor die Ausführung der Methode abgeschlossen wurde kann die Methode keinen Wert liefern. Darüber hinaus kann eine oneway-Methode keine Exceptions auslösen. Das aufrufende Objekt hat keine Möglichkeit festzustellen, ob die Methode erfolgreich ausgeführt wurde; die Infrastruktur von CORBA macht einen bestmöglichen Versuch die Methode auszuführen, d.h. eine erfolgreiche Ausführung wird nicht gewährleistet.

Attribute sind Variablen, für die beim Mapping auf eine Programmiersprache zwei Zugriffsroutinen erstellt werden. Die Zugriffsroutinen werden vom Attributnamen beispielsweise durch Voranstellen von _get_ (Datenzugriff) und _set_ (Datenänderung) abgeleitet. Erfolgt eine Attributdeklaration als read­only, so wird nur die Datenzugriffsroutine generiert.

Exceptions dienen der Behandlung von Fehlern, welche bei der Operationsausführung auftreten.

IDL unterstützt einige andere nützliche Konstrukte. Darunter fallen auch die Fähigkeiten, sich auf jeden IDL-Typen durch einen benutzerdefinierten Typnamen zu beziehen (typedef), sowie einen Typnamen zu deklarieren ohne ihn zu definieren (Vorwärtsdeklaration), was für die Behandlung von zirkulären Abhängigkeiten hilfreich ist.

3.2.4 Stubs und Skeletons

Zusätzlich zur Generierung von Programmiersprachentypen generieren die IDL-Compiler auf der Client-Seite Stubs und auf der Server-Seite Skeletons. Ein Stub ist ein Mechanismus der die Anfrage eines Clients erzeugt und weiterleitet, während ein Skeleton einen Mechanismus darstellt der Anfragen zur CORBA Objektimplementation befördert. Da beide direkt aus der IDL-Spezifikation übersetzt werden sind Stubs und Skeletons normalerweise schnittstellenspezifisch.

Bei der Verwendung von Stubs und Skeletons spricht man auch von statischen Aufrufen (static invocation). Der Stub dient zur Konvertierung der Anfrage aus dem Format der Programmiersprache in ein passendes CORBA-äquivalentes Format zur Übertragung über den Verbindungsweg zum Zielobjekt (Marshalling^[3] ).

Ist die Anfrage bei dem Zielobjekt angekommen, so muß sie aus dem "Übertragungsformat" zurückkonvertiert werden in das Format der Programmiersprache der Objektimplementation (Unmarshalling³ ). Dies übernimmt das Skeleton. Anschließend sendet es die Anfrage an das Objekt.

3.2.5 Dynamic Invocation Interface

Das Dynamic Invocation Interface (DII) erlaubt es einem Client, eine beliebige Methode auf einem beliebigen Objekttyp aufzurufen, wobei beides erst zur Laufzeit festgelegt wird. Clients können also Anfragen an Objekte stellen deren Schnittstellen zur Kompilierungszeit dem Client nicht bekannt sind. Hierzu wird eine dynamische Anfrage instantiiert, die von allen Objekten unterstützt wird. Bevor ein Aufruf ausgeführt werden kann, müssen die erforderlichen Argumente für den Aufruf ermittelt werden. Die Argumenttypen können mit Hilfe des Interface Repository (Kapitel 3.2.7) bestimmt werden. Diese Aufrufmöglichkeit wird verwendet für Applikationen wie Browser, Desktops oder Programmier-Umgebungen.

3.2.6 Dynamic Skeleton Interface

Das Dynamic Skeleton Interface (DSI) entspricht auf der Server-Seite dem DII auf der Client-Seite. Es ermöglicht dem ORB Anfragen an einen Server weiterzuleiten. Genau wie das DII den Clients Aufrufe ermöglicht ohne Zugriff auf die statischen Stubs zu haben, so erlaubt das DSI Aufrufe auf der dem System neu hinzugefügten Schnittstelle, ohne dass dafür die Skeletons statisch in die Applikation hineinkompiliert werden müssen. Durch das DSI wird der Applikation "mitgeteilt", dass auf der Seite der Objektimplementation eine neue Schnittstelle mit neuen Methoden existiert.

3.2.7 Interface Repository

Das Interface Repository (IR) dient der Erfassung von Schnittstelleninformationen und besteht aus CORBA-Objekten. Weil die darin aufgenommenen Daten jederzeit zur Laufzeit abrufbar sind, bietet es – bei entsprechender Implementierung – entfernten Zugriff auf Schnittstellenbeschreibungen. Zu einer solchen Beschreibung gehören alle Informationen, die zuvor in IDL spezifiziert wurden.

Die Strukur des IR ist analog zu IDL hierachisch aufgebaut. Es trägt der verschachtelten Struktur durch seinen rekursiven Aufbau Rechnung und bietet Zugriff auf Definitionen von Attributen, Operationen, Konstanten, Typen, Ausnahmen, Schnittstellen und Modulen. Die entsprechenden Pseudo-Interfaces sind:

in Schnittstellen:

AttributeDef

OperationDef

in Modulen

InterfaceDef

ModuleDef

in Schnittstellen und Modulen:

ConstantDef

TypeDef

ExceptionDef

Anhand der Einträge im Interface Repository ist ein ORB in der Lage, die Signatur, also die Typisierung der Ein- und Ausgabewerte, einer Operation zu ermitteln. Diese Information ist für das Marshalling von großer Bedeutung [47].

3.2.8 Object Adapter

Object Adapter (OA) dienen als Bindeglied zwischen den CORBA-Objektimplementierungen und dem ORB. Sie stellen Mechanismen zur Verfügung, welche benötigt werden, um ein Interface des Clients mit einem Interface des aufgerufenen Objektes zu verbinden. Objekt Adapter sind also, wie in Abbildung 3.4 gezeigt, Schnittstellen, die Methodenaufrufe vermitteln. Sie entkoppeln objektspezifisches Verhalten vom ORB-Kern [44]. Der jeweilige OA paßt hierfür den Aufruf des Clients, der durch den ORB übermittelt wird, so an, dass die geeignete Methode des Objektes aufgerufen werden kann, obwohl der Aufrufende

eventuell die konkrete Schnittstelle des Objektes gar nicht kennt.

In der CORBA-Spezifikation [30] wird von einer genauen Definition der vom Object Adapter bereitgestellten Dienste abgesehen, um das ganze System flexibel und anpassungsfähig zu halten. Abhängig davon welche Dienste bereits im ORB-Kern realisiert sind, leitet der OA, unter Bereitstellung einer Schnittstelle, die Methodenaufrufe an den ORB weiter. Nicht vom ORB unterstützte Dienste können durch den OA realisiert werden.

Es gibt mehrere Arten von Objekt Adaptern. Der Basic Object Adapter (BOA) wurde in der ersten CORBA-Spezifikation eingeführt und in der Version 2.3 [37] vom flexibleren Portable Object Adapter (POA) ersetzt. Bei beiden handelt es sich um "Allzweck"-Objekt Adapter, die für viele Standardanwendungen geeignet sind. Der BOA sollte eine Mindestfunktionalität gewährleisten. Er realisiert die Aktivierung, Registrierung und Deaktivierung von Objektimplementierungen sowie die hierzu notwendige Generierung und Interpretation der Objektreferenzen.

Der POA soll unter anderem durch die Eigenschaft der Portabilität ermöglichen, den Quellcode ohne Änderungen mit dem ORB eines anderen Herstellers weiterzuverwenden. Im Gegensatz zum BOA kann eine Serveranwendung mehrere POAs haben, um beispielsweise verschiedene Arten von CORBA-Objekten zu unterstützen. Eine ausführliche Betrachtung dieser CORBA-Komponente findet sich in [40].

3.3 CORBA Services

In der OMA, deren Bestandteil CORBA ist, sind eine Reihe von Diensten definiert, die für Anwendungen allgemein hilfreich sind. Diese Dienste reichen vom nahezu unverzichtbaren Name Service bis zu Diensten höherer Ebenen, wie beispielsweise dem Transactionservice. Wie bei allen ihren Spezifikationen hat die OMG auch für CORBA keine Implementierungen für diese Dienste definiert, stellt aber die Schnittstellen zur Verfügung über welche auf die Dienste zugegriffen werden kann. Die eigentliche Implementierung der Dienste ist dann Sache der verschiedenen Hersteller von CORBA-Produkten. Hierbei ist es wichtig zu wissen, dass die Produkte zur Implementierung der CORBA Services oft getrennt von den CORBA-ORB-Produkten angeboten werden und dass die Implementierung der CORBA Services nicht Voraussetzung dafür ist, dass ein Produkt z.B. mit CORBA 2 kompatibel ist.

Im folgenden Abschnitt werden die wichtigsten CORBA Services kurz vorgestellt [45].

3.3.1 Der Concurrency-Control Service

Dieser Dienst stellt eine Schnittstelle zur Verwaltung von parallelen Abläufen in gemeinsam benutzten CORBA-Objekten zur Verfügung. Dies erfolgt durch Verwendung unterschiedlicher Typen von Sperren, die der Dienst unterstützt. Hierzu gehören Readers-Writers-Sperren und Intention-Sperren. Die Funktionen dieses Dienstes sind vergleichbar mit den Funktionen von Multithread-Anwendungen.

3.3.2 Der Event Service

Dieser Dienst [36] stellt einen Mechanismus zur Verfügung, mit dem CORBA-Objekte Ereignisse senden und empfangen können. Er dient dem asynchronen Nachrichtenaustausch zwischen Objekten.

Hierzu gehören folgende Funktionen:

Zuverlässige Übermittlung, die (vereinfacht gesagt) sicherstellt, dass ein Ereignis sein(e) Ziel(e) erreicht.

Unterstützung für Push- und Pull-Modelle bei der Ereignisübermittlung.

Anonymes Messaging, bei dem der Erzeuger eines Ereignisses nichts von der Identität des Nutzers weiß und umgekehrt.

Ereigniskanäle; dieser Mechanismus entspricht dem System »Herausge­ber/Interessent« (Publisher/Subscriber), bei dem der Nutzer bestimmte Ereignistypen quasi abonnieren kann.

3.3.3 Der Externalisation Service

Dieser Dienst stellt Schnittstellen für die Auslagerung (Serialisierung) und die Einlagerung (Deserialisierung) von Objekten zur Verfügung. Wenn ein Objekt ausgelagert wurde, kann es innerhalb desselben oder eines anderen Prozesses eingelagert werden. Ferner können Objekte in einem portierbaren Dateiformat ausgelagert werden (dieses ist in der Spezifikation für den Auslagerungsdienst festgelegt). Eine mögliche Anwendung für diesen Dienst ist ein Übergabe-durch-Wert-Mechanismus für CORBA-Objekte.

3.3.4 Der Licensing Service

Über diesen Dienst kann der Hersteller Strategien definieren, mit denen die Verwendung der Dienste eingeschränkt werden kann. Der Dienst unterstützt drei Lizenzierungsstrategien:

Über die Zeitstrategie wird festgelegt, dass für eine Lizenz ein Anfangszeitpunkt, ein Ablaufdatum und eine Dauer gelten.

Über die Wertzuordnung wird die Lizenzierung anhand von Einheiten (Messung der Resourcenauslastung, Anzahl der gleichzeitigen Benutzer usw.) festgelegt.

Über die Nutzerstrategie werden Dienste zur Nutzung durch einen bestimmten Benutzer oder Computer verfügbar gemacht.

Funktionen, die dieser Dienst zur Verfügung stellt, werden sich in Zukunft noch weiter verbreiten, unter der Voraussetzung, dass Konzepte wie die nutzungsabhängige Zahlung oder das Mieten von Software realisiert werden. So wäre es beispielsweise denkbar, dass ein gelegentlicher Benutzer einer Bildbearbeitungssoftware diese bezahlt, ausgehend von der Häufigkeit der Nutzung bestimmter Grafikfilter. In dem Maße, in dem ein Gerüst für den elektronischen Handel verfügbar wird ist denkbar, dass mehr Software unter diesen Bedingungen angeboten wird.

3.3.5 Der Lifecycle Service

Dieser Dienst bietet Funktionen und Regeln zum Erstellen, Löschen, Kopieren und Verschieben von CORBA-Objekten an. Mit dem Lifecycle Service wird ferner auch das Konzept einer Objektfabrik [10] unterstützt, bei der es sich um ein CORBA-Objekt handelt, welches andere CORBA-Objekte erstellt.

Objektfabriken

Da ein Client keinen Zugriff auf den Adressraum eines CORBA-Servers hat, kann er dort auch nicht eigenständig ein neues Objekt erzeugen. In einigen Programmiersprachen wird zur Instanziierung neuer Objekte der new -Operator benutzt. Bei CORBA-Anwendungen bedient man sich einer Objektfabrik, welche Objekte eines bestimmten Typs, nach dem Schema in Abbildung 3.5, erzeugt. Sie liefert eine Referenz auf jedes neue Objekt zurück an den Client, der die Objekt-Erzeugung angefordert hat.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5: Objekterzeugung mittels einer Objektfabrik

Die in Kapitel 5 vorgestellte Implementierung einer CORBA-Schnittstelle für mobile Agenten macht ebenfalls von dem Mechanismus der Objektfabrik Gebrauch.

3.3.6 Der Name Service

Der Name Service [34] ermöglicht es CORBA-Objekten, registriert und über ihre Bezeichnung von anderen Objekten gefunden zu werden. Hierbei wird das Konzept des Bezeichnungskontexts verwirklicht, der eine Gruppe von eindeutigen Namen enthält. Der Name Service unterstützt auch eine verbundartig aufgebaute Architektur, was bedeutet, dass die Bezeichnungs-Server im Netzwerk verteilt sein und trotzdem zusammenarbeiten können.

So wird CORBA-Objekten bei der Durchführung des Standard-Bindevorgangs eine Bezeichnung zugeordnet, über die sie von anderen Objekten gefunden werden können. Diese Funktion stellt einen "minimalen Name Service" dar; der tatsächliche Name Service kann weitaus umfangreichere Funktionen zur Verfügung stellen.

In der vorliegenden Arbeit wird der CORBA Name Service benutzt um die Implementierung einer Schnittstelle für mobile Agenten zu realisieren. In Kapitel 5 wird noch ausführlicher auf die Arbeitsweise und Funktion dieses Services eingegangen.

3.3.7 Der Trader Service

Wie auch der Name Service ermöglicht der Trader Service das Auffinden von CORBA-Objekten durch andere Objekte. In diesem Fall erfolgt die Suche nicht anhand einer Bezeichnung, sondern die Suche des Client-Objekts nach Diensten erfolgt über Operationsnamen, Parameter und Ergebnistypen.

Der Name Service und der Trader Service unterscheiden sich wie das Telefonbuch und das Branchenbuch. Der Name Service entspricht dem normalen Telefonbuch in dem eine bestimmte Person gesucht werden kann wenn man ihren genauen Namen kennt. Der Trader Service entspricht eher dem Branchenbuch in dem nach einem Unternehmen (dessen Namen nicht bekannt ist) gesucht wird das z.B. eine bestimmte Dienstleistung anbietet. So können Sie im Frankfurter Telefonbuch nach »Bernhardt Computerservice« suchen, in den Gelben Seiten nach den EDV-Service Unternehmen in Frankfurt.

3.3.8 Der Objektpersistenzdienst

Dieser Dienst stellt eine Reihe von Schnittstellen zur Verfügung, mit denen die Objektpersistenz verwaltet wird. In der Regel werden die Implementierungen für diesen Dienst von den Datenbankherstellern zur Verfügung gestellt.

Unter persistenten Objekten versteht man Objekte, die während eines bestimmten Zeitraums bestehen. Dies bedeutet, dass die Lebensdauer des Objekts die einer jeden Anwendung überdauern kann. Während der Zeit in der das Objekt nicht verwendet wird, befindet es sich in einem permanenten Speicher, wie einer Datenbank oder einer unstrukturierten Datei; es kann dann bei Bedarf wieder "aufgeweckt" werden. So wäre z.B. ein mit einem Textverarbeitungsprogramm erstelltes Dokument ein persistentes Objekt, weil es möglich ist, das Programm zu schließen und später wieder auszuführen, wobei das Objekt dann erneut aufgerufen werden kann. In einer CORBA-Anwendung ist es manchmal hilfreich, CORBA-Objekte als persistent zu definieren. In dem implementierten Name Service beispielsweise wäre es denkbar, die erzeugten Objekte und Kontexte als persistente Objekte in einer Datei "nameservice-root.inf" zu speichern. Dies bedeutet, im Falle einer (vorübergehenden) Deaktivierung des Implementation Repository und damit auch des Name Service, z.B. durch eine Rechnerstörung, dass nach der Reaktivierung die Objekte wieder mit dem aktuellen Status zur Verfügung stehen.

3.3.9 Der Property Service

Über diesen Dienst können Objekte Gruppen von Eigenschaften über Definitionen nach dem Schema "Name/Wert" definieren. Bei jeder Definition ist der Name einfach eine CORBA-Zeichenkette, der Wert ein CORBA-Objekt vom Typ any. Der Zugriff auf die Eigenschaften kann beschränkt werden, so dass eine Eigenschaft nur gelesen bzw. nicht geändert werden kann.

Die Verwendung von Eigenschaften zur Beschreibung von Objekten findet immer weitere Verbreitung, insbesondere dadurch, dass Objektmodelle wie JavaBeans immer mehr an Bedeutung gewinnen. Für die Objekte einer umfangreichen Anwendung oder einer Gruppe von Anwendungen könnten eine Reihe von Standard­eigenschaften definiert werden, was die Objektverwaltung stark vereinfachen würde. Wenn beispielsweise in einer Bankanwendung für jedes Objekt eine Eigenschaft "Standort" definiert wäre, können die Standorte der Objekte vom Typ Bank, Geldautomat, Kunde usw. einheitlich für die gesamte Anwendung definiert werden.

3.3.10 Der Query Service

Dieser Dienst unterstützt die Verwendung von Abfragen für Objekte. In diesen Abfragen können Prädikate zur Angabe der Objekte enthalten sein, auf die sich die Operation beziehen soll, wobei Attributwerte angegeben werden. Der Query Service unterstützt ferner sowohl die Indexierung von Objekten als auch verschachtelte Abfragen. Die Abfragefunktion stellt eine datenbankähnliche Semantik für CORBA-Objekte zur Verfügung. Genauso wie in einer Anwendung Abfragen für Tabellen und Datensätze einer relationalen Datenbank durchgeführt werden können, ermöglicht der Query Service einer Anwendung die Durchführung von Abfragen für CORBA-Objekte.

3.3.11 Der Relationship Service

Der Relationship Service dient zur Darstellung von Beziehungen zwischen Objekten. Er stellt eine vollständige Prüfung der Integritätsbedingungen für Beziehungstypen und Beziehungsarten (1:1, 1:n, n:m) und wird auch zusammen mit dem Lebenszyklusdienst zum Kopieren, Verschieben und Entfernen miteinander in Beziehung stehender Objekte verwendet. Die Verwaltung der Relationen zwischen Objekten ist natürlich auch ohne den Beziehungsdienst möglich, seine Verwendung verringert allerdings die Komplexität bei der Verwaltung vielschichtiger Beziehungen.

3.3.12 Der Security Service

Über den Security Service werden Schnittstellen für die folgenden Sicherheits-funktionen definiert:

Identifikation und Identitätsüberprüfung der Benutzer, durch die festgestellt wird, ob es sich tatsächlich um den angegebenen Benutzer handelt.

Zugriffsberechtigungen und Zugriffsbeschränkungen, durch die festgelegt wird, welche Benutzer Zugriff auf welche Dienste oder Objekte haben dürfen.

Sicherheitsprotokollierung, durch die Datensätze der durchgeführten Benutzeraktionen zur Verfügung gestellt werden.

Kommunikationssicherheit, zu der die Identitätsüberprüfung der Benutzer gegenüber den Diensten (und umgekehrt), der Integritätsschutz und der Geheimhaltungsschutz gehören.

Funktionen zur Unwiderlegbarkeit, entsprechend denen für digitale Signaturen, d.h., die Herkunft der Daten oder der Empfang der Daten kann unwiderlegbar bewiesen werden.

Verwaltung der verschiedenen Sicherheitsstrategien.

Die Sicherheit ist in einer Reihe von Anwendungen ein ganz zentraler Aspekt. So müssen beispielsweise bei kommerziellen Bankanwendungen buchstäblich alle Systemaspekte abgesichert werden. Dies geht von der Identitätsüberprüfung und Identifizierung der Kunden bis hin zur Sicherheit der Kommunikation zwischen Banken und Geldautomaten.

3.3.13 Der Timer Event Service

Der Timer Event Service stellt dem Benutzer die aktuelle Uhrzeit zur Verfügung, er dient zur zeitlichen Ordnung von Ereignissen und ermöglicht das Generieren von Ereignissen mit Hilfe von Zeitgebern.

3.3.14 Der Transaction Service

Der Transaction Service stellt die Schnittstellen zur Verfügung, die zur Unterstützung von Transaktionsfunktionen benötigt werden. Hierbei werden sowohl flache als auch verschachtelte Transaktionsmodelle und externe Transaktionsverarbeitungs-Monitore unterstützt. Es ist auch möglich, dass die Transaktionsdienste zusammenarbeiten.

3.4 Zusammenfassung

Ein verteiltes Objektmodell, dass Software- und Hardwareheterogenität gewährleistet, ermöglicht die Nutzung von Objekten über Prozess- und Rechnergrenzen hinweg. Es bildet die Grundlage für die Kommunikation in verteilten Systemen. Die OMG hat in der OMA-Spezifikation ein solches verteiltes Objektmodell beschrieben. Die aus dieser Spezifikation resultierende Common Object Request Broker Architecture stellt einen Softwarebus zur Verfügung, der die Verwaltung von Objekten und Methodenaufrufen regelt. In der OMA ist unter anderem die Interface Definition Language zur Schnittstellenbeschreibung definiert. Eine weitere Hauptkomponente, die das OMA Referenzmodell festlegt, ist der Object Request Broker. Er stellt die Infrastruktur zum transparenten Informationsaustausch zwischen Client- und Serverobjekten zur Verfügung. Außerdem beinhaltet die OMA Spezifikation die Definition der Object Services, Common Facilities, Domain Services und Application Objects.

Basierend auf diesem Referenzmodell beschreibt die CORBA-Spezifikation, wie in diesem Kapitel erläutert, unter anderem:

die Funktionsweise von Stubs und Skeletons zur Erzeugung und Weiterleitung von Anfragen an CORBA-Objekte;

das, die Bindung zur Laufzeit unterstützende, flexible Dynamic Invocation Interface auf der Client-Seite sowie das Dynamic Skeleton Interface auf der Server-Seite;

das Interface Repository zur Erfassung von Schnittstelleninformationen;

die Funktion von Objekt Adaptern.

Der dritte Abschnitt dieses Kapitels beschäftigte sich mit aufgabenspezifischen Komponenten, welche in der OMG-Terminologie als CORBA Services bezeichnet werden. So wurden z.B. elementare Dienste wie der Name Service, Event- oder Lifecycle Service und höhere Dienste wie Licensing-, Concurrency-Control- oder Trader Service erläutert.

Die in diesem Kapitel beschriebenen Grundlagen wurden in einer CORBA-Implementierung umgesetzt, deren Vorstellung in Kapitel 4.4 erfolgt. Es handelt sich hierbei um die an der Goethe-Universität Frankfurt entwickelte Middleware MICO.

Kapitel 5 befasst sich mit der Implementierung einer CORBA-Schnittstelle für mobile Agenten. Exemplarisch für die hier beschriebenen CORBA Services wird dort die Erstellung einer Schnittstelle zum CORBA Name Service realisiert.

[...]

---

^[1] Horizontale Dienste können bereichsübergreifend eingesetzt werden.

^[2] Vertikale Dienste werden nur für bestimmte Einsatzbereiche verwendet.

^[3] Als Marshalling bezeichnet man die Normalisierung programmiersprachlicher Daten auf CORBA-Daten. Unmarshalling bezeichnet den umgekehrten Vorgang.