Client-Server-Praktikum: Aufgabe 1 CORBA

Transkript

1 Client-Server-Praktikum: Aufgabe 1 CORBA In diesem Tutorial werden Sie die CORBA-Spezifikation kennenlernen und grundlegendes Wissen darüber sammeln. Am Ende des Tutorials sollten Sie in der Lage sein, einfache Anwendungen zu entwickeln welche mit Hilfe von CORBA kommunizieren. 1. Was ist CORBA? Die Common Object Request Broker Architecture (CORBA) ist ein Standard zum Verteilen von Objekten über ein Netzwerk. Er wurde von der Object Management Group (OMG), einem nicht profitorientierten Standardisierungsgremium mit mehr als 700 Mitgliedern (Softwareentwickler, Netzwerkbetreiber, Hardwareproduzenten und kommerzielle Anwender von Computersystemen, unter anderem SUN und IBM) 1991 in der ersten Version definiert. Ziel war, eine Middleware zu schaffen, welche eine orts-, plattform- und implementierungsunabhängige Kommunikation zwischen Applikationen erlaubt. Ein Vermittlungsdienst (Object Request Broker = ORB) gewährleistet dabei das Zusammenarbeiten von Objekten über Rechnergrenzen hinweg. Wirklich interessant geworden ist CORBA seit der Verabschiedung der Version 2.0 im Dezember Diese Version brachte das Kommunikationsprotokoll IIOP, welches die Kommunikation zwischen Object Request Brokern (ORB) verschiedener Hersteller und vor allem auch über das Internet ermöglicht. CORBA zeichnet sich durch folgende Eigenschaften aus: Objektorientierung. Die grundlegenden Einheiten der Architektur sind Objekte. Verteilungstransparenz. CORBA-Programme greifen auf entfernte Objekte mit denselben Mechanismen zu, wie auf lokale Objekte. Der genaue Aufenthaltsort eines Objekts bleibt für seine Klienten in der Regel unbekannt. Effizienz. Die Architektur für den ORB ist von der OMG bewußt so gehalten, daß effiziente Implementationen möglich sind, die z.b. im Falle rein lokaler Kommunikation dem traditionellen Funktionsaufruf nur unwesentlich nachstehen. Hardware-, Betriebssystem- und Sprachunabhängigkeit. Die Komponenten eines CORBA-Programms können auf verschiedenen Betriebssystemen, Hardwarearchitekturen und mit verschiedenen Programmiersprachen realisiert werden. Offenheit. Über den ORB können Programme verschiedener Hersteller zusammenarbeiten. Der Anwender erhält dadurch die Freiheit, jede Komponente bei dem Anbieter kaufen zu können, der seinen individuellen Bedürfnissen am besten gerecht wird. Softwareentwickler erhalten die Chance, am Softwaremarkt von morgen teilzuhaben und Angebote großer Firmen mit spezialisierten Produkten zu ergänzen. CORBA stellt also zum einen eine beachtliche Menge technologischen Know-hows und zum anderen einen selten erreichten Konsens innerhalb der Computerindustrie dar. 1/7

2 2. Begriffe und Abkürzungen ORB: Der Object Request Broker (ORB) ist der Kommunikationsbus zwischen CORBA-Objekten. Er bietet einen Mechanismus an, um Anfragen des Clients an die entsprechenden Objekt-Implementierungen weiterzuleiten, und zwar unabhänigig davon, an welchem Ort sich diese im Netzwerk befinden und unter welchem Betriebssystem sie dort laufen. Der Client braucht dabei nicht zu wissen, ob sich das Objekt auf dem gleichen Computer befindet oder auf einem Remotecomputer irgendwo im Netz sitzt. Er muß nur den Namen des Objekts oder die Objektreferenz kennen und wissen, wie man die Schnittstelle des Objekts benutzt. Der ORB kümmert sich um die Details: Das Lokalisieren des Objekts, die Weiterleitung des Aufrufs und das Zurückliefern des Resultats. Hinter einem einfachen Methodenaufruf des Clients verbirgt sich also eine komplexe Netzwerkkommunikation, die vom ORB gehandhabt wird: Eine Anfrage des Clients, bestehend aus dem Methodenaufruf und den Parametern, wird in einem binären Strom umgesetzt (marshalling) und über das Netzwerk an den Server geschickt. Die Informationen werden auf der Server-Seite wieder decodiert (unmarshalling) und die gewünschte Operation ausgeführt. Rückgabewerte werden auf die gleiche Weise wieder über den ORB an den Client gesendet. Zusammengefaßt hat der ORB die Aufgabe, die dem Aufruf des Clients entsprechende Objektimplementierung zu finden, sie falls erforderlich zu aktivieren, die Anfrage an das Objekt zu leiten und entsprechende Rückgabewerte wieder an den Client zurückzugeben. Abbildung 1 aus VisiBroker 3.0 Programmers Guide Stubs und Skeletons: Stubs stellen für den Client die Schnittstellen zu den Server-Diensten (Objektmethoden) bereit. Aus der Sicht des Clients verhält sich der Stub wie ein Proxy-Objekt für ein entferntes Server-Objekt. Die Server- Objekte werden mit Hilfe von IDL definiert, ihre zugehörigen Client-Stubs von einem IDL-Compiler generiert. Ein Stub beinhaltet Code für die Umsetzung der Methodenaufrufe mit ihren Parametern in einfache Nachrichtenströme, die an den Server gesendet werden. Die zugrundeliegenden Protokolle oder Dinge wie Datenanordnungen bleiben für den Client vollkommen transparent, der die Dienste als einfache Methodenaufrufe auffasst. Skeletons stellen das Gegenstück zu den Client-Stubs dar. Sie stellen die statischen Schnittstellen für jeden vom Server unterstützten Dienst bereit. Sie beinhalten Code, um eingehende Nachrichten in normale Methodenaufrufe umzusetzen und diese auszuführen. Rückgabewerte werden wieder über die Skeletons in einem binären Strom umgewandelt und an den Client zurückgeschickt. Wie die Stubs werden die Skeletons vom IDL-Compiler aus IDL-Interfaces generiert. 2/7

3 IDL: CORBA wurde so spezifiziert, daß es sprach- und betriebssystemunabhängig ist. Dazu ist eine einheitliche Schnittstellenbeschreibung der zu verteilenden CORBA-Objekte erforderlich. Diese Beschreibungssprache ist im CORBA-Standard als IDL (Interface Definition Language) definiert und an die Syntax von C/C++ angelehnt. Die Operationen und Attribute, die von einem Server der "Außenwelt" zur Verfügung gestellt werden sollen, werden zunächst in einem Interface mittels IDL beschrieben. Aus einem vollständig beschriebenen IDL-Interface werden dann mit einem IDL-Compiler Stub-Klassen für die Clients und Skeleton-Klassen für den Server in der jeweiligen Programmiersprache erzeugt. Ein IDL-Interface beschreibt dabei lediglich die Schnittstellen der zu veröffentlichenden Dienste und Komponenten des Servers. Es enthält keine Implementierungen. Dadurch wird ermöglicht, daß beispielsweise in Java erstellte Clients auf in C++ realisierte Server-Objekte zugreifen. Interface Repository: Das Interface Repository ist eine vom ORB unterhaltene Online-Datenbank, die zu jeder Objekt-Klasse die Beschreibung ihrer Interfaces enthält. Implementation Repository: Das Implementation Repository enthält Informationen zu allen Objekt-Instanzen. Jedes Objekt wird darin durch eine eindeutige Objektreferenz identifiziert. Da CORBA-Objekte keine laufenden Prozesse sein müssen, ermöglicht das Implementation Repository jederzeit die Aktivierung eines angesprochenen Objekts. BOA: Der BOA (Basic Objekt Adapter) ist für die Verbindung der Server-Objekte mit dem ORB zuständig. Er hat die Aufgabe, Objekte im Implementation Repository zu registrieren und Objekte zu aktivieren und zu deaktivieren. Da der BOA serverseitig Portabilitätsprobleme mit ORBs unterschiedlicher Hersteller hatte, wurde seit dem Corba Standard 2.2 der BOA durch einen POA (Portable Objekt Adapter) ersetzt, welcher außer Portabilität noch zusätzliche, hier nicht erwähnte, Features enthält. Objektreferenzen und IOR: Eine Objektreferenz ist eine Zeichenkette, die ein Objekt innerhalb eines verteilten CORBA-Systems eindeutig kennzeichnet. ORBs unterschiedlicher Hersteller übermitteln Objektreferenzen nach dem IOR-Standard (IOR = Interoperable Object Reference). IIOP: Das IIOP (Internet Inter ORB Protocol) ist ein Netzwerkprotokoll für die Kommunikation zwischen ORBs. 3. Das Vorgehen bei der Entwicklung mit CORBA Prinzipiell erfolgt die Entwicklung einer CORBA-Anwendung stets in den gleichen drei Schritten: 1. IDL-Datei schreiben, d.h. die Schnittstelle der (Server-)Objekte spezifizieren, und mit dem IDL-Compiler kompilieren 2. Server implementieren 3. Client implementieren Der von uns im Praktikum verwendete Object Request Broker ist der Open Source ORB JacORB. Dieses Paket enthält unter anderem die CORBA-Klassen, den IDL-Compiler, sowie weitere für die Entwicklung und den Betrieb von CORBA-Anwendungen nötige Werkzeuge und Programme. Die Online-Produktdokumentation dazu finden Sie unter der URL 3/7

4 Bei der Programmierung gehen Sie wie folgt vor: IDL-Datei schreiben Nehmen wir an, Sie möchten eine Klasse "MeineKlasse" mit vier Methoden im Netz zur Verfügung stellen. Ihr IDL-Interface könnte dann in etwa so aussehen: module Test { interface MeineKlasse { void tunix(); long tuwas(in float zahl); short tuwas2(inout long zahl); float tuwas3(out short zahl); }; }; Die Art eines jeden Parameters (in, inout, out) gibt dabei an, ob mit dem jeweiligen Parameter nur ein Wert an die Methode übergeben werden soll (in), oder ob über diesen Parameter auch ein Wert zurückgegeben wird (inout, out). Sie schreiben also die IDL-Datei und speichern sie z.b. unter dem Namen Test.idl ab. Anschließend kompilieren Sie sie mit dem Kommando idl Test.idl. Nicht erschrecken: Der IDL-Compiler legt Ihnen nun ein Verzeichnis mit dem Namen Test an, in dem sich eine Unzahl von Dateien befindet, die sich von den ORB-Klassen ableiten und über weitere Vererbung die entsprechenden Methoden soweit anpassen, bis sie mit den IDL-Interfaces übereinstimmen. Für Java werden dabei sehr viele Dateien erzeugt, da Java keine Mehrfachvererbung unterstützt und außerdem nur eine Klasse pro Datei erlaubt ist. Je nach Compileroptionen und Art der Klasse werden so pro in der IDL-Datei definierter Klasse ca. fünf Dateien generiert, die alle zusammen das Package Test bilden. Wir werden weiter unten noch auf diese Dateien zurückkommen. Dieses Verzeichnis muss dem Compiler für die Übersetzung des Servers und des Clients bekannt sein. Server (in Java) implementieren Hier müssen Sie zunächst die Klassen mit den Methoden, die Sie bereitstellen möchten, implementieren. Nach erfolgreicher Implementierung müssen Sie den ORB und POA im Server initialiseren und mittels des POA die Objekte beim ORB registrieren. Zuletzt muss dann noch die Objektreferenz in einer globalen IOR-Datei gespeichert werden, falls kein Nameserver benutzt wird. Client (in Java) implementieren Die Methoden, mit denen der Client das von ihm gewünschte Objekt erhält, befinden sich in der vom IDL-Compiler generierten Klasse MeineKlasseHelper.java. Besonders wichtig ist hierbei die Methode narrow. Prinzipiell muss wieder, falls kein Nameserver benutzt wird, die Objektreferenz aus einer globalen IOR-Datei gelesen werden und mit der oben genannten Methode dann zu dem entsprechenden Objekt gecasted werden. Anschließend kann man damit problemlos wie mit einem lokalen Objekt umgehen. Den Code kompilieren Sie haben nun also folgende Dateien vorliegen, die Sie mit dem Compile-Kommando javac *.java compilieren können: MeinServer.java, MeineKlasseImpl.java und MeinClient.java, sowie das generierte Verzeichnis Test. Auf der Serverseite benötigen Sie MeinServer.java, MeineKlasseImpl.java und das Verzeichnis Test, auf den Clientrechnern 4/7

5 hingegen nur MeinClient.java und das Verzeichnis Test. Beachten Sie bitte die Hinweise zur Java-Laufzeitumgebung. Die Programme ausführen Ausgeführt werden Client sowie auch Server durch das Kommando jaco Client bzw. jaco Server. Falls kein Namerserver benutzt wird, muss als Parameter noch der Pfad zur IOR- Datei mitangegeben werden. 4. Die vom IDL Compiler erzeugten Dateien MeineKlasse.java Enthält das Interface Ihrer Klasse MeineKlasseHelper.java Enthält nützliche Methoden, um das damit verbundene Objekt zu handhaben. Für Objekte wie structures, enumerations, und unions hält die Helperklasse Methoden zum Schreiben und Lesen bereit. Außerdem bietet sie Methoden wie z.b. narrow MeineKlasseHolder.java Zuständig für die Übergabe von out und inout Parameter _MeineKlasseStub.java Die Stub-Klasse MeineKlassePOA.java und MeineKlassePOATie.java Die Skeleton-Klassen 5. Installation von JacORB Folgende Aufgabenstellung wurde mit den JacORB Binaries getestet. Hier wird Ihnen nun ein kurzer Überblick gegeben wie Sie JacORB installieren. Installation auf den Pool-Rechnern Sand 6/7 Zuerst muss das heruntergeladene JacORB Archiv in einen Ordner entpackt werden, z.b. in den Ordner /home/[user]/jacorb wobei [user] Ihr Username auf Ihrem Linux System darstellt. Anschließend muss der System-Pfad um den Jacorb BIN-Ordner erweitert werden. Dazu fügen Sie einfach der Datei /home/[user]/.bashrc folgende Zeile hinzu: > export PATH=$PATH:/home/[user]/jacorb/bin Anschließend sollten alle offenen Terminals neugestartet werden. Im JacORB Verzeichnis müssen Sie nun noch folgenden Befehl ausführen: > ant idlcmd > ant jaco Anschließend müssen Sie noch den JacORB Nameservice konfigurieren. Dazu müssen Sie die Konfigurationsdatei jacorb.properties durch den nun folgenden Befehl erstellen: > cp /home/[user]/jacorb/etc/jacorb_properties.template jacorb.properties 5/7

6 In der Konfigurationsdatei müssen nun folgende Zeilen entsprechend angepasst werden: ORBInitRef.NameService=file:/home/[user]/jacorb/ns.file jacorb.naming.ior_filename=/home/[user]/jacorb/ns.file Wobei die Datei /home/[user]/jacorb/ns.file eine schreibbare Datei sein sollte und in unserem Fall die IOR-Datei repräsentiert. Eine ausführlichere Anleitung finden Sie ebenfalls in der JacORB-Dokumentation. 6. Ihre Aufgabe Stellen Sie eine halbfertige Implementation eines verteilten Minitaschenrechners fertig. Die dazu notwendigen Dateien finden Sie auf der Praktikumsseite. Der Minitaschenrechner unterstützt die Operationen Addition, Subtraktion, Multiplikation, Division und zusätzlich das Quadrieren und Potenzieren. Da wir in dieser Aufgabe fiktiv annehmen dass der Client sehr leistungsschwach ist und keine Rechenoperationen ausführen kann, benutzt er die vom Server bereitgestellten Rechenobjekte BasicArithemtics und SpecialArithmetics um die Operationen remote auf dem Server auszuführen. Der Code des Minitaschenrechners ist folgendermaßen aufgebaut: Calc calc.idl Client Client.java Server BasicArithmeticsImpl.java SpecialArithmeticsImpl.java Server.java In der Datei calc.idl finden sie die Schnittstellenbeschreibungen für die Objekte BasicArithmetics und SpecialArithmetics. Erweitern Sie diese Datei um eine Subtraktion und eine Multiplikation für das Objekt BasicArithmetics. In die Dateien BasicAritmeticsImpl.java und SpecialArithmeticsImpl.java kommt die Implementierung der Objekte. Dies ist ebenfalls Teil Ihrer Aufgabe. Die Datei Server.java implementiert den Server. Hier muss von Ihnen der ORB und POA initialisiert werden, die Objekte instanziiert und die Referenzen der IOR-Datei hinzugefügt werden. Zum Schreiben in die Datei finden Sie im Code bereits einen PrintWriter pw über den Sie mit pw.println(string) zeilenweise in die Datei schreiben können. Zuletzt müssen Sie den Client in der Datei Client.java vervollständigen. Hierzu müssen Sie aus den aus der IOR-Datei eingelesenen Objektreferenzen lokale Remote-Objekte erstellen. Testen Sie anschließend Ihre Implementation indem Sie sämtliche Java-Dateien mit javac übersetzen und anschließend den Server und Client mit folgendem Befehl starten: > jaco Server /home/[user]/jacorb/ns.file > jaco Client /home/[user]/jacorb/ns.file Abzugeben ist der funktionierende Code, ein Screenshot der erfolgreichen Ausführung des Servers und Clients und nachfolgend beantwortete Fragen gepackt im zip oder tar.gz Format. 6/7

7 Folgende Verständnisfragen sollten ebenfalls beantwortet und mit abgegeben werden: 1. Warum benötigt man bei diesem Versuch eine IOR-Datei? 2. Nennen Sie mindestens drei ORBs von anderen Herstellern. 3. Beschreiben Sie ein Szenario in dem es sinnvoll ist CORBA zu benutzen. Optionale Aufgabe: 4. Testen Sie die CORBA-Aufgabe über das Netzwerk! Benutzen Sie hierzu zwei Rechner mit unterschiedlichen ZDV-Accounts. Achten Sie darauf dass die IOR- Datei von beiden Accounts aus gelesen werden kann. Ein hierfür nützliches Kommando zur Rechtevergabe ist im Andrew File System der Befehl fs. 7/7