1 Einführung in CORBA

Transkript

1 1 Einführung in CORBA 1 Einführung in CORBA Grundlagen Die CORBA-ORB-Architektur Die Services von CORBA Die Facilities von CORBA Die Geschäftsobjekte von CORBA IDL zur Beschreibung von CORBA-Objekten Inter-ORB-Kommunikation Dreischichtige Client/Server-Architektur mit CORBA-Objekten Entwicklung einer Client/Server-Anwendung mit CORBA Vorbereitungen Entwicklungszyklus einer CORBA-Anwendung Die Implementierung im Detail Implementierung des Servers Implementierung des Clients Tutorial Die IDL-Datei schreiben Die Server-Objekte implementieren Den Client schreiben Die Anwendung testen 24 Die neue Multi-Tier-Client/Server-Architektur erfordert eine Technologie, die folgende Anforderungen erfüllen muß: Integration von bestehenden Softwaresystemen und Anwendungen Java-Unterstützung, um mobile, plattformunabhängige und objektorientierte Anwendungen realisieren zu können Herstellerunabhängigkeit, um Portabilität gewährleisten zu können Vorteile von OOP (z.b. Vererbung, Polymorphismus, ) ausreichende Sicherheitskonzepte Unterstützung von der Software-Industrie Es gibt eine Anzahl von verschiedenen Technologien, die die Realisierung von verteilten Client/Server-Anwendungen unterstützen. CORBA ist ein von der Software-Industrie entwickeltes Konzept, das alle genannten Anforderungen erfüllt. Insbesondere in Verbindung mit Java können Software-Entwickler leistungsfähige Client/Server-Anwendungen für das Internet entwickeln, die auf standardisierte Technologien basieren. CORBA zeichnet sich vor allem durch folgende Merkmale aus: Grundlage für eine moderne mehrschichtige Client/Server-Architektur Sprach- und Systemunabhängigkeit Interoperabilität zwischen heterogenen Systemen offener Standard stabile Basis für verteilte Objekte Verfügbarkeit von CORBA auf allen bekannten Betriebssystemen CORBA macht Netzwerkkommunikation transparent für Software-Entwickler

2 1.1 Grundlagen CORBA ist in erster Linie nur eine Spezifikation, die die Interoperabilität von verteilten Objekten beschreibt. Bevor das World Wide Web eine große Popularität erlang und insbesondere die Programmiersprache Java, war CORBA hauptsächlich eine High-End- Lösung zur Entwicklung von verteilten Anwendungen, die hauptsächlich von C++- Entwicklern genutzt wurde. Die CORBA-Spezifikation wird derzeit von der Object Management Group (OMG) betreut und gepflegt, ein offenes Konsortium bestehend aus über 700 Firmen, die offene Standards für die Entwicklung von objektorientierten Technologien definiert. CORBA-Objekte können in den Programmiersprachen realisiert werden, die von den CORBA-Anbietern unterstützt werden, sei es in C, C++, Java, Ada, Cobol oder Smalltalk. Weiterhin sind diese Objekte unabhängig von ihren Plattformen, (Windows 95/NT, OpenVMS,, Digital Unix, HP-UX, AIX, etc.) auf denen sie zur Verfügung gestellt bzw. auf sie zugegriffen werden, solange die CORBA-Spezifikation eingehalten wird. Das bedeutet, daß ein vom Internet heruntergeladenes Java-Applet, das unter Windows NT läuft, auf C++-Objekte zugreifen kann, die von einem Unix-Web-Server über das Internet verteilt werden. Sprach- und Systemunabhängigkeit werden durch die Beschreibung von Interfaces der Objekte über die Beschreibungssprache Interface Definition Language (IDL) ermöglicht. IDL erlaubt alle CORBA-Objekte auf die gleiche Art zu beschreiben. Die einzige Anforderung besteht in der Existenz einer Schnittstelle zwischen der IDL und der jeweiligen nativen Programmiersprache (Java, C/C++, Smalltalk, ). CORBA-Objekte kommunizieren über einen sogenannten Object Request Broker (ORB) miteinander, der als Vermittler fungiert, eine Kommunikationsschnittstelle zwischen der Server-Anwendung, der Dienste zur Verfügung stellt, und der diese Dienste nutzende Client-Anwendung. Als Netzwerkprotokoll wird hier das vom CORBA-Standard spezifizierte Internet Inter-ORB Protocol (IIOP) eingesetzt, das auf TCP/IP aufsetzt. Unterschiedliche ORB-Anbieter, die den von OMG verabschiedeten CORBA-Standard folgen, können so miteinander kommunizieren, unabhängig von ihrem jeweiligen darunterliegenden System. Ursprünglich definierte die OMG die Object Management Architecture (OMA), die die Interoperabilität von Software-Anwendungen beschreibt. Eines der Ziele war, ein Standard zu spezifizieren, wie Teile innerhalb einer Anwendung, die Objekte, im Netz verteilt werden. Dies war die Grundlage für die Entstehung von CORBA. Die OMA besteht im wesentlichen aus den vier folgenden Hauptkomponenten: Der Object Request Broker (ORB) ist der Kommunikationsbus zwischen CORBA- Objekten. CORBA-Services definieren Dienste (Services), die auf der Systemebene des ORBs agieren. Beispiele hierfür sind Security, Naming, Transaction oder Persistent Service. CORBA-Facilities definieren Services auf der Anwendungsebene. Geschäftsobjekte (Business Objects) beschreiben Objekte und Anwendungen, die in der realen Welt vorkommen (Flugzeug, Bankkonto oder Auto) Die CORBA-ORB-Architektur Die nachfolgende Abbildung zeigt die wesentlichen Komponenten der CORBA-ORB- Architektur.

3 Abb : CORBA-ORB-Architektur Der Object Request Broker (ORB) ist der Kommunikationsbus zwischen CORBA- Objekten, der einen Mechanismus anbietet, um Anfragen des Clients an die entsprechenden Object Implementations weiterzuleiten, unabhänigig davon, an welchem Ort diese im Netzwerk residieren und unter welchem Betriebssystem sie dort laufen. Hinter einem einfachen Methodenaufruf des Clients verbirgt sich 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 (marshaling) und über das Netzwerk an den Server geschickt. Die Informationen werden auf der Server- Seite wieder decodiert (unmarshaling) 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 entsprechende Objektimplementierung zu finden, sie zu aktivieren, falls erforderlich, die Anfrage an den Objekt zu leiten und entsprechende Rückgabewerte wieder an den Client zurückzugeben. Das ORB Interface stellt einige nützliche Hilfsfunktionen für lokale Dienste bereit, um eine reibungslose Kommunikation der CORBA-Objekte zu gewährleisten. Hierunter fallen die Konvertierung einer Objektreferenz in eine Zeichenfolge und umgekehrt, und das Erstellen von Argumentlisten, die für dynamische Methodenaufrufe benötigt werden. Die CORBA-ORB-Architektur auf der Client-Seite besteht aus folgenden Komponenten: Client Der Client nutzt die vom Server-Programm bereitgestellten Services durch Aufruf der entsprechenden Operationen der Object Implementations. Dabei läuft der Zugriff auf ein entferntes Objekt für den Client vollkommen transparent ab, der lediglich die Aufgabe hat, einen Methodenaufruf abzusetzen ohne sich mit der Netzwerkkommunikation über den ORB befassen zu müssen. Die in Abb gezeigten Komponenten unterstützen diese Transparenz. CORBA IDL Stubs IDL-Stubs stellen die Schnittstellen zu den Objektdiensten bereit. Aus der Sicht des Clients verhält sich der Stub wie ein Proxy-Objekt für ein entferntes Server-Objekt. Die Dienste werden mit Hilfe von IDL definiert, ihre zugehörigen Client-Stubs vom 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

4 Datenanordnungen bleiben für den Client vollkommen transparent, der die Dienste als einfache Methodenaufrufe auffaßt. Dynamic Invocation Interface (DII) Das Dynamic Invocation Interface erlaubt die vom Server bereitgestellten Dienste zur Laufzeit zu finden und diese zu nutzen. CORBA definiert hierfür Standard-APIs für die Suche der Metadaten, die die Server-Schnittstellen definieren, für die Generierung der Parameter, für das Absetzen des Remote-Aufrufs und für das Empfangen der Ergebnisse. Dynamische Methodenaufrufe erfordern keine Client-Stubs, da sie erst zur Laufzeit zusammengesetzt werden. Interface Repository Das Interface Repository ist eine verteilte Laufzeit-Datenbank, die maschinenlesbare Versionen der IDL-definierten Schnittstellen, die Metadaten, beinhaltet. Ein API erlaubt, die Metadaten zu lesen, abzuspeichern und zu verändern. Auf der Server-Seite sind folgende Komponenten zu finden: Object Implementation Die Object Implementations implementieren die in den IDL-Interfaces spezifizierten Schnittstellenbeschreibungen. Sie können in den unterschiedlichsten Sprachen realisiert werden, die vom ORB unterstützt werden. Hierunter fallen unter anderem C, C++, Java, Smalltalk und Ada. CORBA IDL Skeletons IDL 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ärem Strom umgewandelt und an den Client zurückgeschickt. Wie die Stubs werden die Skeletons vom IDL-Compiler aus IDL-Interfaces generiert. Dynamic Skeleton Interface (DSI) Das Dynamic Skeleton Interface ist das Gegenstück zum DII auf der Client-Seite. Es erlaubt eingehende Methodenaufrufe von einem Client, für die keine entsprechenden IDL-kompilierten Skeletons existieren, dynamisch zu bearbeiten. Seine Aufgabe besteht darin, ankommende Anfragen von einem Client zu analysisieren und das dafür vorgesehene Objekt zu finden und den Methodenaufruf abzusetzen. Object Adapter Der Object Adapter nimmt Dienstanfragen der Clients entgegen und aktiviert die entsprechenden Server-Objekte. Er bildet die Laufzeitumgebung der Server-Objekte, übergibt ihnen die Anfragen und weist ihnen Objektreferenzen zu. Der Object Adapter registriert die von ihm unterstützten Klassen und Objekte im Implementation Repository.

5 Implementation Repository Das Implementation Repository bildet eine Laufzeitdatenbank, die Informationen über die von einem Server unterstützten Klassen und Objekte enthält. Weitere Informationen, die mit der Implementierung von ORBs zusammenhängen, z.b. Trace- Informationen, Prüfprotokolle, Sicherheit und andere administrative Daten, sind dort ebenfalls zu finden. Hauptbestandteil von OMA ist der ORB. Die Verfügbarkeit eines ORBs ist die einzige Anforderung von CORBA um verteilte CORBA-Anwendungen realisieren zu können. Manche ORB-Anbieter liefern ihre Produkte ohne vollständige CORBA-Services oder CORBA-Facilities aus, so daß es erforderlich ist, Geschäftsprozesse selbst zu entwickeln. Ohne das Vorhandensein eines ORBs kann jedoch keine CORBA-Anwendung bereit gestellt werden. Der große Vorteil eines ORBs besteht darin, daß beinahe alle Implementierungsdetails zur Kommunikation von Objekten, sei es lokal, im Intra- oder im Internet, weitgehend vom ORB und den zugehörigen Skeleton- und Stub-Klassen den Software-Entwicklern transparent gemacht werden, so daß auf die Realisierung der eigentlichen Aufgaben konzentriert werden kann. Es sind lediglich einmalige Initialisierungen des ORBs im Programm erforderlich, die die Verteilung von CORBA-Objekten im Netz ermöglichen Die Services von CORBA Die CORBA-Services sind Sammlungen von Diensten auf der Systemebene, die selbst in IDL-definierten Schnittstellen zu finden sind. Sie sind als eine Erweiterung und Ergänzung der Funktionalität eines ORBs zu verstehen. Die OMG stellt zur Zeit 15 verschiedene CORBA-Services zur Verfügung. Hier alle Services auf einen Blick: Life Cycle Service Persistence Service Naming Service Event Service Concurrency Control Service Transaction Service Relationship Service Externalization Service Query Service Licensing Service Properties Service Time Service Security Service Trader Service Collection Service Weitere CORBA-Services sind zur Zeit in Arbeit. Der aktuelle Stand der Bemühungen kann jederzeit auf der Homepage von OMG abgefragt werden. Der Einsatz von CORBA-Services erlaubt CORBA-Objekte bestimmte Funktionalitäten zu verleihen, die sich mit der Systemebene befassen. CORBA-Objekte nutzen die CORBA- Services über Inheritance- und Containment-Relationships. So ist es beispielsweise möglich,

6 eine Klasse "Auto" persistent und transaktionell zu machen, indem die entsprechenden CORBA-Services genutzt werden Die Facilities von CORBA CORBA-Facilities sind das Modul für allgemein verwendbare, komplexe Diensteschnittstellen für den Enwickler von Endanwender-Applikationen. Sie definieren Regeln für das Zusammenspiel der Geschäftsobjekte, um effektiv zusammen arbeiten zu können. Zu den in der Entwicklung befindlichen Common Facilities gehören zum Beispiel Drucken, , Datenaustausch, Frameworks für Business-Objekte und Internationalisierung Die Geschäftsobjekte von CORBA Geschäftsobjekte (Business Objects) stellen eine natürliche Art und Weise dar, anwendungsunabhängige Konzepte wie Kunden, Bestellungen, Geld, Zahlungen, Autos oder Patienten zu beschreiben. Mit deren Hilfe werden Systeme entworfen, die die Geschäftsvorfälle aus der realen Welt auf die entsprechenden Objekte abbilden. Diese müssen aber in der Lage sein, miteinander auf der semantischen Ebene zu kommunizieren, um die Gegenstücke aus der realen Welt darstellen zu können. Geschäftsobjekte benötigen sauber definierte Schnittstellen, damit sie unabhängig voneinander entwickelt werden können. Ein Business-Objekt muß in der Lage sein, bestimmte Ereignisse in seiner Umgebung zu erkennen, seine Attribute zu verändern und mit anderen Business-Objekten zu interagieren. Wie jedes CORBA-Objekt exportiert ein Business-Objekt seine Dienste zu den Clients über IDL und kommuniziert mit den anderen Objekten über den ORB. 1.2 IDL zur Beschreibung von CORBA-Objekten CORBA wurde so spezifiziert, daß sie 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, die an die Syntax von C/C++ angelehnt ist. Operationen und Attribute, die von einem Server der "Außenwelt" zur Verfügung gestellt werden, sind in einem Interface beschrieben, das die Syntax von IDL genügt. Aus einem vollständig beschriebenen IDL-Interface werden mit einem IDL-Compiler Stub-Klassen für die Clients und Skeleton-Klassen für den Server für die jeweilige in der zu realisierenden Programmiersprache erzeugt. Ein IDL-Interface beschreibt lediglich die Schnittstellen der zu veröffentlichenden Dienste und Komponenten des Servers. Es enthält keine Implementierungsdetails. Dadurch wird ermöglicht, beispielsweise in Java erstellten Clients auf die in C++ realisierten Server-Objekte zuzugreifen. IDL-Compiler werden mit den ORB- Produkten mitgeliefert. Einige bieten die Möglichkeit an, direkt aus Sourcecode IDL- Interfaces zu generieren. Die strikte Trennung der Schnittstellen von ihrer Implementierung ermöglicht, bestehende Softwaresysteme in eine CORBA-Umgebung zu binden. Die unten vorliegende IDL-Beschreibung ist ein Überblick über die wesentlichen Merkmale der CORBA-IDL. // definiert einen Namensraum module <identifier> { <type declarations>; <constant declarations>;

7 <exception declarations>; // definiert ein CORBA-Interface interface <identifier> [:<inheritance>] { <type declarations>; <constant declarations>; <attribute declarations>; <exception declarations>; // definiert eine Operation [<op_type>] <identifier>(<parameters>) [raises exception][context]; // definiert eine Operation [<op_type>] <identifier>(<parameters>) [raises exception][context]; ; // definiert ein CORBA-Interface interface <identifier> [:<inheritance>] { ; ; Hier eine kurze Beschreibung der wichtigsten Elemente, die eine IDL-Beschreibung ausmachen: Ein Modul stellt einen Namensraum bereit, um mehrere Schnittstellen zu gruppieren. Es wird durch das Schlüsselwort module eingeleitet, dessen Name sich aus einem oder mehreren Bezeichnern zusammensetzt. Dadurch kann eine zusätzliche Ebene in der Hierarchie im IDL-Namensraum eingeführt werden. Datentypen grenzen die möglichen Werte der Parameter, Attribute, Ausnahmen und Rückgabewerte ein, die sie annehmen können. Diese Datentypen werden als CORBA- Objekte bezeichnet, die Sprach-, Betriebssystem- und ORB-übergreifend verwendet werden. CORBA unterscheidet zwischen einfachen und konstruierten Typen. Zu den einfachen CORBA-Typen zählen short, long, unsigned short, unsigned long, float, double, char, boolean, octet, string, enum und any. Die konstruierten Typen sind struct, array, union und sequence. Der Typ struct, ähnlich einer C- Struktur, erlaubt, mit Hilfe von typedefs jeden komplexen Datentyp zu erstellen. Mit dem Typ sequence wird ein Array von Objekten variabler Länge definiert. Der Typ any kann jeden möglichen IDL-Datentyp repräsentieren - einen einfachen, einen konstruierten oder eine Objektreferenz. Jeder IDL-Datentyp von CORBA wird mit Hilfe von IDL-Compilern auf einen nativen Datentyp abgebildet. Interfaces definieren Operationen und Attribute. Eine Schnittstelle ist eine rein deklarative Beschreibung der Services, die von einem Client genutzt werden können und enthalten keine Details über ihre Implementierung. Schnittstellen können von einer oder mehreren Schnittstellen abgeleitet werden. Operationen kennzeichnen Dienste, die ein Client aufrufen kann. Die IDL definiert die Signatur einer Operation, bestehend aus ihren Parametern und Rückgabewert. Ein

8 Parameter kann vom Client zum Server (in), vom Server zum Client (out) oder in beiden Richtungen (inout) übergeben werden. Ein Parameter besitzt einen Datentyp. Der Typ des Rückgabewertes wird durch op_type festgelegt. Fehlerfälle können durch das Werfen von Exceptions angezeigt werden. Ein optionaler Context-Ausdruck beinhaltet eine Menge von Werten für Attribute, die den Kontext eines Clients beschreiben. Er ermöglicht einem Client, Informationen, die seine lokale Umgebung beschreiben, an den Server weiterzugeben. Attribute beschreiben den Zustand eines Interfaces. Für jedes Attribut wird jeweils eine Getter- (wenn das Attribut nicht als read-only deklariert ist) und eine Setter- Methode vom IDL-Compiler erzeugt. Die genaue Grammatik und der gesamte Sprachumfang der IDL sind in der CORBA- Spezifikation von OMG vollständig beschrieben. 1.3 Inter-ORB-Kommunikation In einer mit CORBA entwickelten Client/Server-Anwendung existieren zwei ORBs, die miteinander über ein Netzwerk in Verbindung stehen. Mit Hilfe der ORBs werden die entsprechenden Anfragen des Clients an den Server weitergeleitet. Dieser führt den gewünschten Service aus und gibt die Rückantwort wieder über die ORBs an den Client zurück. Abb. 2.3 verdeutlicht noch einmal diese Kommunikation. Abb. 2.3: Client/Server-Kommunikation über ORBs Hinter diesem Aufruf steckt eine komplexe Netzwerkkommunikation, die über die von der OMG spezifizierte CORBA-Inter-ORB-Architektur beschrieben ist. Zwei wichtige Teile der Architektur sind das General Inter-ORB Protocol (GIOP) und das Internet Inter-ORB Protocol (IIOP). Das General Inter-ORB Protocol (GIOP) spezifiziert eine Menge von Nachrichtenformaten und Datendarstellungen für die Kommunikation zwischen den ORBs. Die in IDL definierten Datentypen werden als Common Data Representation (CDR) in eine einfache Nachrichtendarstellung für Netzwerke abgebildet. GIOP definiert außerdem ein Format für Interoperable Object References (IORs). Ein ORB muß eine IOR von einer Objektreferenz erzeugen, wann immer eine Objektreferenz über ORBs weitergegeben wird. IORs verbinden eine Sammlung von "tagged profiles" mit Objektreferenzen. Die Profile beschreiben dasselbe Objekt, aber jedes beschreibt, wie mit dem Objekt über einen bestimmten ORB-Mechanismus in Kontakt zu treten

9 ist. Ein Profil stellt selbstbeschreibende Daten zur Verfügung, die die ORB-Domäne identifizieren, der eine Referenz zugeordnet ist, und die Protokolle, die es unterstützt. Das Internet Inter-ORB Protocol (IIOP) legt fest, wie GIOP-Nachrichten über ein TCP/IP-Netzwerk ausgetauscht werden. Das IIOP ermöglicht daher, die Busarchitektur und die Technologien des Internets selbst als Basis für eine Inter-ORB- Kommunikation zu verwenden. Daneben können einzelne ORBs aber noch weitere Environment-Specific-Inter-ORB- Protocols (ESIOPs) unterstützen. Entwickler von verteilten Client/Server-Anwendungen werden sich selten mit der Kommunikation der ORBs auseinandersetzen müssen. Interoperabilität wird zwischen ORB- Anbietern garantiert, und nicht zwischen Anbieter und Entwickler. Das Thema soll nicht näher behandelt werden. 1.4 Dreischichtige Client/Server-Architektur mit CORBA- Objekten Business-Objekte eignen sich für die Entwicklung von dreischichtigen Client/Server- Anwendungen, da sie kein monolithisches Stück Code darstellen. Stattdessen können sie jederzeit in andere Komponenten integriert werden, die wiederum eine neue Client/Server- Anwendung abbilden. Business-Objekte können durch mehrere verschiedene visuelle Objekte repräsentiert werden, die sich in der ersten Schicht auf der Seite des Clients befinden. In der mittleren Schicht befinden sich die Server-Objekte, die die persistenten Daten und die Business-Logik repräsentieren. In der dritten Schicht werden Datenbanken und andere überkommene Server-Anwendungen untergebracht. Die Aufteilung der Anwendung in drei Schichten erlaubt eine erhöhte Flexibiltät gegen Änderungen zu gewinnen. Diese Änderungen können sich beziehen auf die fachliche Verarbeitung, die Präsentation anwendungsbezogener Daten, die Benutzerführung und auch auf die Entwicklungsplattform. Diese Flexibilität wird durch eben die beschriebene Schichtentrennung erreicht. Abb. 2.4 zeigt die Integration von CORBA in eine moderne mehrschichtige Client/Server-Architektur. Abb. 2.4: Dreischichtige Client/Server-Architektur mit CORBA-Objekten

10 Die Server-Objekte der mittleren Schicht implementieren die Logik der Anwendung und stellen den Clients, die View-Objekte, die persistenten Daten zur Verfügung, die sie aus den in der dritten Schicht befindlichen Datenbanken beziehen. Die Clients holen sich alle für die Darstellung erforderlichen Daten von den Business-Objekten und müssen sich nicht mit dem Sammelsurium von SQL-Anweisungen, gespeicherten Prozeduren (stored procedures) und Datenbanken der dritten Schicht befassen. Die zweite Schicht übernimmt in diesem Fall die Verantwortung, wodurch eine erhöhte Flexibilität und Wiederverwendbarkeit erreicht wird. 2 Entwicklung einer Client/Server- Anwendung mit CORBA 2.1 Vorbereitungen Mit der Einführung von JDK 1.2 wird ein 100% pure Java Object Request Broker Java IDL mitgeliefert, der mit jedem CORBA-konformen ORB interoperieren kann. Java IDL ist ein freies Produkt von Sun, das einen light-weight ORB, einen Naming-Service und einen IDL- Compiler für Java beinhaltet. Da Java IDL noch ein relativ neues Produkt ist, sind nicht alle erwähnten Funktionalitäten von CORBA implementiert. Für die Entwicklung einer kleinen verteilten Client/Server-Anwendung soll Java IDL aber schon ausreichen, um die technischen Aspekte von CORBA aufzeigen zu können. Für größere Anwendungen stehen kommerzielle Produkte von verschiedenen Herstellern zur Verfügung, für die ein Lizenz erworben werden muß. Hierzu zählen VisiBroker von Visigenic, Orbix von IONA Technologies und IBM's Component Broker Connector. Für die nachfolgenden Beispiele ist Java IDL schon ausreichend. Daher werden im folgenden nur die Tools beschrieben, die Java IDL betreffen. Java IDL enthält einen transienten Naming Service, der vom Server und vom Client genutzt werden kann. Er ist als separater Prozeß zu starten. Der Naming Service speichert die Objektreferenzen mit ihren Namen in eine Art Baumstruktur ab, vergleichbar mit einem Dateisystem. Eine Objektreferenz wird im Naming Service über den Server registriert (bind), die von einem Client über seinen Namen erhalten kann (resolve). Eine Objektreferenz kann über unbind aus dem Naming Service gelöscht werden. Der Naming Service implementiert zwei CORBA-Objekte: NamingContext, das Analogon zu einem Verzeichnis, und BindingIterator, vergleichbar mit einer Datei. Jeder BindingIterator stellt ein Referenzpaar Name/Objekt dar. Weitere Informationen zum Naming Service ist der Dokumentation von JDK 1.2 zu entnehmen. Es ist zu beachten, daß alle gebundenen Objekte im Naming Service verloren gehen, sobald er gestoppt wird. 2.2 Entwicklungszyklus einer CORBA-Anwendung Abb. 3.2 zeigt einen allgemeinen Entwicklungszyklus einer verteilten Client/Server- Anwendung mit Hilfe von CORBA.

11 Abb. 3.2: Ein typischer Entwicklungszyklus einer CORBA-Implementierung. Hier die Schritte im einzelnen: 1. Die zu veröffentlichenden Dienste vom Server werden in einer IDL-Datei beschrieben. Sie enthält alle Operationen, die ein Client aufrufen kann, die Ausnahmen, die dabei auftreten können, und alle erforderlichen Ein- und Ausgabeparameter. Die Datei trägt die Endung '.idl'. Ein Beispiel für eine IDL-Datei: // Datei: Bank.idl // // Autor: Tin-Ho Chan // // Beschreibung // Diese IDL-Datei ist ein Beispiel fuer den Einsatz von CORBA. // Auf einem Server sollen Dienste angeboten, die ermoeglichen, // Konten in einer Bank anzulegen, diese abzufragen und auch // entsprechende Vorgaenge, die zu einer Kontofuehrung gehoeren // ausfuehren zu koennen. Das Modul 'Bank' enthaelt einen // 'KontoManager', der die Konten 'Konto' verwaltet. // Aus Mangel an Sicherheit sollte dieses Beispiel nicht // zu kommerziellen Zwecken genutzt werden. // // Version Datum Aenderungen // // April 1998 Ersterstellung

12 // Modul 'Bank' module Bank { // definiert eine Stringfolge typedef sequence<string> StringArray; // Personendaten struct Person { string name; string vorname; ; // Ausnahme bei Fehlerfall. exception KontoException { string begruendung; ; // Das individuelle Konto mit entsprechenden // Attributen und Operationen. interface Konto { readonly attribute float kontostand; readonly attribute long geheimzahl; readonly attribute long kontonummer; attribute Person person; void einzahlen(in float betrag); void abheben(in float betrag); ; // gibt Konto beim Abmelden wieder frei void unlock(); ; // Der Kontomanager verwaltet die Konten. interface KontoManager { Konto anmelden(in long kontonr, in long geheimzahl) raises (KontoException); Konto oeffnen(in Person daten); void aufloesen(in Konto konto); // hole Infos zu allen Konten in der Bank StringArray holekonteninfos(); ; 2. Mit dem IDL-Compiler werden für die definierten Schnittstellen Client-Stubs und Server-Skeletons erzeugt. Hierzu ist der Befehl $ idltojava -fserver -fclient <IDL-Datei>.idl aufzurufen. Die zwei Flags kennzeichnen, daß Code sowohl für Stubs als auch für Skeletons generiert werden sollen. Für jedes angegebene Modul wird ein Java- Package mit dem Modulnamen erzeugt, in dem die erzeugten Java-Klassen abgelegt werden. Die automatische Generierung von Stubs und Skeletons befreit Programmierer davon, diese zu schreiben und befreit Anwendungen von ihrer Abhängigkeit von bestimmten ORB-Implementierungen. 3. Nun sind alle Vorbereitungen getroffen, um die Server-Anwendung zu realisieren. Für jedes in der IDL-Datei definierte Interface existiert ein entsprechendes Java-Interface, das zu implementieren ist. Dazu ist die zu implementierende Klasse von der Klasse _<interface>implbase abzuleiten, die vom IDL-Compiler erzeugt wurde, wobei

13 <interface> der Interface-Name in der IDL-Datei ist. Hier eine Beispielimplementierung für das obige Interface KontoManager: // aus IDL generiertes Package import Bank.*; import java.util.*; /** * Diese Klasse implementiert die im Interface 'KontoManager' spezifizierten * Schnittstellen, die vom Server angeboten werden. Tin-Ho Chan Ersterstellung */ public class KontoManagerImpl extends _KontoManagerImplBase { private static Random rnd = new Random(); /** * Konten werden in einem Dictionary verwaltet. Als * Schluessel dient die Kontonummer. */ private Hashtable konten = new Hashtable(); /** * Ein neues Konto anlegen. person Personendaten das neu angelegt Konto */ public synchronized Konto oeffnen(person person) { /** * In der Bank ueber ein bestehendes Konto anmelden. kontonr Kontonummer geheimzahl Geheimzahl Konto mit angegebene Kontonummer und Geheimzahl */ public synchronized Konto anmelden(int kontonr, int geheimzahl) throws KontoException { /** * Ein bestehendes Konto aufloesen. konto das aufzuloesende Konto */ public synchronized void aufloesen(bank.konto konto) { /** * Gibt Infos zu allen Konten in der Bank zurueck. Informationen ueber alle Konten */ public String[] holekonteninfos() {

14 4. Um die definierten Dienste den Clients anbieten zu können, müssen einmalige Initialisierungen des ORBs vorgenommen werden (siehe Kap ). 5. Ist der Initialisierungsvorgang abgeschlossen, können sich die Objekte im Naming Service registrieren lassen, und der Server kann auf eingehende Anfragen eines Clients warten (siehe Kap ). 6. Der Client kann nun implementiert werden. Analog zum Server muß zuerst eine einmalige ORB-Initialisierung vorgenommen werden, bevor der Client die Dienste des Servers nutzen kann (siehe Kap ). 7. Über den Naming Service kann sich der Client die dort registrierten Objekte eine Referenz über ihren Namen holen. Diese wird dann verwendet, um die bereitgestellten Dienste des Server-Objekts aufzurufen (siehe Kap ). 8. Der Client wird gemäß den Anforderungen vervollständigt. Er sollte von jeglicher Geschäftslogik befreit sein und nur über ein ansprechendes GUI-Interface verfügen, das die Ergebnisse aus der Kommunikation zwischen Client und Server darstellt. 9. Mit der Fertigstellung von Client und Server werden die Java-Programme kompiliert: $ javac <Server>.java <Client>.java 10. Client und Server verwenden beide den Naming Service. Dazu muß der in JDK 1.2 mitgelieferte Naming Service als separater Prozeß gestartet werden: $ tnameserv [-ORBInitialPort 6000] Der Naming Service horcht in diesem Falle unter der Portadresse 6000 auf eingehende Anfragen. Die Angabe der Portadresse ist optional. Als Default-Wert wird hier 900 angenommen, sofern der Benutzer über Administratorrechte verfügt. 11. Das Server-Programm wird gestartet, das seine Dienste im Naming Service den Clients zur Verfügung stellt. Der Server ist bereit um eingehende Anfragen zu bearbeiten (siehe Kap ). 12. Die Clients können sich nun über den Naming Service die Objektreferenzen vom Server holen und deren Dienste nutzen (siehe Kap ). Die oben beschriebenen Schritte sind für die meisten CORBA-Implementierungen typisch. CORBA erlaubt natürlich Abweichungen. Das Dynamic Invocation Interface bietet mit dem Dynamic Skeleton Interface eine andere Form von CORBA-Implementierung, die aber das gleiche Ziel verfolgt. Die Dokumentation von JDK 1.2 beschreibt dieses Verfahren ausführlich. 2.3 Die Implementierung im Detail Um eine Client/Server-Anwendung in eine CORBA-Umgebung zu integrieren, bedarf es einige Vorbereitungen in der Implementierung. Hierzu zählen die ORB-Initialisierungen, das Binden der Objekte im Naming Service und das Finden dieser Objekte über ihren Namen. Im folgenden werden die erforderlichen Schritte beschrieben, die sowohl im Server-Code als auch im Client-Code zu machen sind. Als Basis dient wie schon oben erwähnt der in JDK 1.2

15 integrierte ORB Java IDL. Sie können aber auch mit ORBs von anderen Herstellern realisiert werden, sofern diese die Programmiersprache Java und den CORBA Naming Service unterstützen Implementierung des Servers Da der Initialisierungsvorgang des ORBs einmalig stattfindet, wird er innerhalb einer Routine vorgenommen, die der Server am Anfang durchläuft, z. B. in der main()-methode. Um Dienste den Clients anbieten zu können, wird ein Objekt im Naming Service abgelegt. Hier die einzelnen Schritte für die Implementierung des Servers. 1. Alle erforderlichen Packages importieren. Für die Initialisierung des ORBs und für die Verwendung des Naming Service stehen folgende Packages zur Verfügung: // Packages fuer Naming Service import org.omg.cosnaming.*; import org.omg.cosnaming.namingcontextpackage.*; // alle CORBA-Implementierungen benötigen dieses Package import org.omg.corba.*; 2. Die Methode festlegen, in der der Initialisierungsvorgang stattfinden soll. Für die weiteren Schritte, wird die main()-methode angenommen. 3. CORBA-System-Exceptions abfangen. Da alle CORBA-Programme zur Laufzeit CORBA-System-Exceptions werfen können, ist es notwendig, die Implementierung der vorher festgelegten Methode in einem try-catch-block zu setzen. Alle Aufrufe die über den ORB ablaufen, können aufgrund von Verbindungsfehlern System-Exceptions werfen. Innerhalb der Methode ist deshalb folgender Block zu setzen. try { // Code fuer CORBA-Aufrufe catch (Exception e) { System.out.println("Client Exception: " + e); e.printstacktrace(system.out); Alle nachfolgenden Sourcecode sind in dem try-block zu setzen. Natürlich können die Exceptions anders behandelt werden. Der oben vorliegende Code dient nur als Beispiel. 4. Ein CORBA-Server benötigt einen lokalen ORB-Objekt, um die Funktionalitäten von CORBA nutzen zu können. Jedes Programm kann eine Referenz auf ein Objekt org.omg.corba.orb über eine vom ORB zur Verfügung gestellte init()-methode erhalten. Parameter für die Methode dienen diverse Informationen über die Umgebung des Servers. ORB orb = ORB.init(args, null); Der Aufruf von init() erlaubt bestimmte Informationen der Server-Umgebung über die Kommandozeile dem ORB zu übergeben. Nähere Informationen zu den Parametern ist der Dokumentation von JDK 1.2 zu entnehmen.

16 5. Der Server ist ein Prozeß, der ein oder meherere Dienste über die Server-Objekte den Clients zur Verfügung stellt. Diese Objekte implementieren die vom IDL-Compiler generierten Interfaces. Es wird daher ein sogenanntes Servant-Objekt instanziiert und dieses dem ORB bekannt gemacht, der die Anfragen eines Clients an das richtige Objekt weiterleiten kann. Servant servantref = new ServantImpl(); orb.connect(servantref); 6. Um die bereitgestellten Objekte den Clients bekannt zu machen, müssen diese über einen Namen im Naming Service gebunden werden. Es wird eine Referenz auf den Naming Service benötigt: org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); Der String "NameService" ist für alle CORBA-ORBs definiert. Der Rückgabewert ist der Namensraum zum Naming Service. 7. Um das Objekt objref als NamingContext verwenden zu können, ist eine Umwandlung des Objekts erforderlich. Dies geschieht mit dem Aufruf: NamingContext ncref = NamingContextHelper.narrow(objRef); Das Objekt ncref hat den Typ org.omg.cosnaming.namingcontext und kann verwendet werden, um auf den Naming Service zuzugreifen und dort Objekte abzulegen. 8. Der nächste Schritt ist das Bereitstellen des Objekts im Naming Service. Hier die erforderlichen Befehle: NameComponent nc = new NameComponent("ServantName", ""); NameComponent path[] = {nc; ncref.rebind(path, servantref); Der Umweg über NameComponent ist erforderlich, da der Naming Service wie eine Art Baumstruktur aufgebaut ist. Der letzte Befehl rebind() bindet das Servant-Objekt im Naming Service mit dem Namen "ServantName". Clients können über resolve("servantname") eine Referenz auf das bereitgestellte Objekt erhalten. 9. Die Initialisierungsvorgänge sind abgeschlossen. Der Server kann auf eingehende Anfragen eines Clients warten. java.lang.object sync = new java.lang.object(); synchronized(sync) { sync.wait(); Der Server wartet auf Aufrufe eines Clients, sofern dieser nicht durch das System gestoppt wird. Ein Beispiel für einen vollständig implementierten Server in Zusammenhang mit der im Kap. 3.2 angegebenen IDL-Datei:

17 // aus IDL generiertes Package import Bank.*; // BankServer verwendet den Naming-Service. import org.omg.cosnaming.*; import org.omg.cosnaming.namingcontextpackage.*; // CORBA-Anwendungen benoetigen diese Klassen. import org.omg.corba.*; /** * Das Programm BankServer stellt eine Server-Anwendung bereit, * Bankkonten zu verwalten. Hierbei handelt es sich nur um ein * Beispiel, die vor allem die technischen Aspekte von CORBA * aufzeigen soll. Es koennen nur Konten angelegt und geloescht * werden. Das Einzahlen und Abheben von virtuellen $$$ ist natuerlich * auch moeglich. Tin-Ho Chan Ersterstellung */ public class BankServer { public static void main(string[] args) { try { // Create and initialize the ORB ORB orb = ORB.init(args, null); // Create the servant and register it with the ORB KontoManager kontomanager = new KontoManagerImpl(); orb.connect(kontomanager); // Get the root naming context org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); NamingContext ncref = NamingContextHelper.narrow(objRef); // Bind the object reference in naming NameComponent nc = new NameComponent("KontoManager", ""); NameComponent path[] = {nc; ncref.rebind(path, kontomanager); // Wait for invocations from clients java.lang.object sync = new java.lang.object(); synchronized(sync) { sync.wait(); catch(exception e) { System.err.println("BankServer exception: " + e); e.printstacktrace(system.out); Implementierung des Clients Da der Initialisierungsvorgang des ORBs einmalig stattfindet, wird er innerhalb einer Routine vorgenommen, die der Client am Anfang durchläuft. Für eine Java-Applikation könnte der Vorgang in der main()-methode stattfinden, für ein Applet hingegen in der init()-methode des Applets. Hier die einzelnen Schritte für die Implementierung des Clients.

18 1. Alle erforderlichen Packages importieren. Für die Initialisierung des ORBs und für die Verwendung des Naming Service stehen folgende Packages zur Verfügung: // Packages fuer Naming Service import org.omg.cosnaming.*; import org.omg.cosnaming.namingcontextpackage.*; // alle CORBA-Implementierungen benötigen dieses Package import org.omg.corba.*; 2. Die Methode festlegen, in der die ORB-Initialisierung stattfinden soll. 3. Da alle CORBA-Programme zur Laufzeit CORBA-System-Exceptions werfen können, ist es notwendig, die Funktionalitäten der vorher festgelegten Methode in einem try-catch-block zu implementieren. Alle Aufrufe die über den ORB ablaufen, können aufgrund von Verbindungsfehlern System-Exceptions werfen. Innerhalb der Methode ist deshalb folgender Block zu setzen: try { // Code fuer CORBA-Aufrufe catch (Exception e) { System.out.println("Client Exception: " + e); e.printstacktrace(system.out); Alle nachfolgenden Sourcecode sind in dem try-block zu setzen. Natürlich können die Exceptions anders behandelt werden. Der oben vorliegende Code dient nur als Beispiel. 4. Ein CORBA-Client benötigt einen lokalen ORB-Objekt, um die Funktionalitäten von CORBA nutzen zu können. Jedes Programm kann eine Referenz auf ein Objekt org.omg.corba.orb über eine vom ORB bereitgestellte init()-methode erhalten. Als Parameter für die Methode dienen diverse Informationen über die Umgebung des Clients. Innerhalb des try-catch-blocks ist folgende Methode aufzurufen: Java-Applet: ORB orb = ORB.init(this, null); Es ist möglich, bestimmte Parameter in der HTML-Seite festzulegen, die die ORB- Kommunikation beeinflußen. Beispielsweise können die Netzwerkadresse des Servers und seine Portadresse mit angegeben werden. Hier ein Beispiel: <applet code=bankclient width=370 height=400> <param name="org.omg.corba.orbinitialhost" value="localhost"> <param name="org.omg.corba.orbinitialport" value="6000"> </applet> Java-Applikation:

19 ORB orb = ORB.init(args, null); Analog zu einem Applet können hier diverse Informationen der Client-Umgebung über die Kommandozeile mitgegeben werden. Die Beschreibungen zu den Parametern ist der Dokumentation von JDK 1.2 zu entnehmen. 5. Um die bereitgestellten Dienste des Servers nutzen zu können, bedarf es eine Referenz auf das entsprechende CORBA-Objekt, die vom Server im Naming Service bereitgestellt hat. Daher wird hier eine Referenz auf den Naming Service benötigt: org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); Der String "NameService" ist für alle CORBA-ORBs definiert. Der Rückgabewert ist der Namensraum zum Naming Service. 6. Um das Objekt objref als NamingContext verwenden zu können, ist eine Umwandlung des Objekts erforderlich. Dies geschieht mit dem Aufruf: NamingContext ncref = NamingContextHelper.narrow(objRef); Das Objekt ncref hat den Typ org.omg.cosnaming.namingcontext und kann verwendet werden, um auf den Naming Service zuzugreifen und die dort abgelegten Objekte zu finden. 7. Der nächste Schritt ist das Finden der vom Server bereitgestellten Objekte. Hier die notwendigen Befehle, um ein Objekt des Servers zu finden: // Resolve the object reference in naming NameComponent nc = new NameComponent("ServantName", ""); NameComponent path[] = {nc; Servant serverref = ServantHelper.narrow(ncRef.resolve(path)); Servant ist dabei eine Referenz auf das vom Server bereitgestellte Objekt. Der Umweg über NameComponent ist erforderlich, da der Naming Service wie eine Art Baumstruktur aufgebaut ist. Wie beim NamingContext wird hier die Methode narrow() angewandt, um eine Referenz Servant zu erhalten. Nun können die spezifizierten Dienste von Servant genutzt werden. Es ist zu beachten, daß alle Methodenaufrufe des Server-Objekts Exceptions werfen können, die aufgrund von Verbindungsfehlern auftreten. Es sind daher entsprechende Vorkehrungen vom Programmierer zu treffen. Hier ein Beispiel der oben beschriebenen Schritte zur Implementierung des Clients. Es wurde als Applet realisiert, das sich kaum von einer Java-Applikation unterscheidet. Der Aufruf der Methode ORB.init() ist nur unterschiedlich. Die Dienste des KontoManagers aus Kap. 3.2 werden hier in Anspruch genommen. // aus IDL generiertes Package import Bank.*; // BankClient verwendet den Naming-Service. import org.omg.cosnaming.*; import org.omg.cosnaming.namingcontextpackage.*;

20 // CORBA-Anwendungen benoetigen diese Klassen. import org.omg.corba.*; /** * Die Klasse stellt einen Client zur Verfuegung, der mit der * Server-Anwendung BankServer kommuniziert. Es koennen die Dienste, * die vom Server angeboten hier genutzt. In diesem Fall die Dienste * fuer die Verwaltung eines 'light' Kontos. Tin-Ho Chan Ersterstellung */ public class BankClient extends Applet implements ActionListener { /** Kontomanager fuer die Verwaltung von Konten */ private KontoManager kontomanager; /** * Initialisiert das GUI-Interface und stellt die Verbindung zum * Server der Bank her. */ public void init() { super.init(); initbankconnection(); /** * Die Verbindung zum Server wird aufgebaut. */ private void initbankconnection() { try { // Create and initialize the ORB ORB orb = ORB.init(this, null); // Get the root naming context org.omg.corba.object objref = orb.resolve_initial_references("nameservice"); NamingContext ncref = NamingContextHelper.narrow(objRef); // Resolve the object reference in naming NameComponent nc = new NameComponent("KontoManager", ""); NameComponent path[] = {nc; kontomanager = KontoManagerHelper.narrow(ncRef.resolve(path)); if (kontomanager==null) connectionerror(new Exception()); catch(exception e) { connectionerror(e);

21 3 Tutorial In diesem Tutorial lernen Sie, wie man mit JDK 1.2 und den dort integrierten Java-ORB Java IDL in Netzen verteilte Anwendungen unter CORBA entwickelt. Unser Ziel ist eine einfache Bank-Anwendung, mit der Sie Konten verwalten sowie Einzahlungen und Abhebungen verarbeiten können. Der Gegenstand des Tutorials ist ein Client-Programm, das auf CORBA- Serverobjekte zugreift und neben der Abfrage des Kontostands Aktionen durchführt, die dynamisch in den Serverobjekten berechnet werden. Mit den Erkenntnissen aus diesem einfachen Beispiel sollten Sie dann in der Lage sein, komplexere Anwendungen auf Basis von Java und CORBA zu entwerfen. Für die nachfolgenden Aufgaben legen Sie ein neues Verzeichnis an und speichern alle unten angegebenen Sourcen dort ab. 3.1 Die IDL-Datei schreiben Da CORBA-Objekte sprachneutral sind, werden die Methodenaufrufe der verschiedenen Programmiersprachen in Schnittstellen gekapselt. Damit wird nicht direkt auf die Implementierung eines Objekts zugegriffen. In CORBA werden diese Schnittstellen für alle Objekte mit der Beschreibungssprache IDL geschrieben. Das Modul Bank in der IDL-Datei Bank.idl kennt zwei Schnittstellen namens Konto und KontoManager, jede mit zweckgebundenen Methoden und Attributen. Der Entwicklungszyklus eines typischen CORBA-Projekts geht davon aus, daß zuerst die Schnittstellendefinition geschrieben wird. Der IDL-Compiler erzeugt anhand dieser Informationen die notwendigen Client-Stubs und Server-Skeletons: $ idltojava -fserver -fclient Bank.idl Der Client spricht mit dem Stub, hält ihn aber für den Server. Sendet der Server Daten an den Client, so kommuniziert der Server mit dem Skeleton, meint aber, daß er mit dem Client spricht. Das Ergebnis des IDL-Compilers ist ein Verzeichnis Bank mit unterschiedlichen Java- Sourcetexten, um die Sie sich momentan aber nicht kümmern müssen. Es handelt sich hierbei im wesentlichen um notwendige Anpassungen für den Einsatz in einer Java-CORBA- Umgebung. (Anmerkung: Aus unerklärlichen Gründen läuft der IDL-Compiler unter Windows 95 nicht. Laden Sie stattdessen diese Zip-Datei herunter, und entpacken Sie sie in Ihr neu angelegtes Verzeichnis. Ihr Verzeichnis sollte nun ein Unterverzeichnis Bank haben, das die vom IDL- Compiler generierten Java-Quelltexte enthält.) 3.2 Die Server-Objekte implementieren Die Aufgabe des Programmierers ist es nun, die Server-Objekte zu implementieren, die ihrerseits die Schnittstellen implementieren. Üblicherweise wird dabei zum Namen der Schnittstelle das Wort Impl hinzugefügt, das die Implementierung kennzeichnet. Also müssen Sie die beiden Klassen KontoImpl und KontoManagerImpl erstellen. Als Hilfe dienen die Kommentare der beiden Klassen.

22 KontoImpl und KontoManagerImpl müssen von einer bestimmten abstrakten Klasse abgeleitet werden, die die Interfaces Konto bzw. KontoManager einbindet. Sie sind im Package Bank zu finden. Machen Sie die erforderlichen Einträge in den Klassen. Hilfe finden Sie im Kap. 3.2, Schritt 3. In einem verteilten System können mehrere Clients auf den Server zugreifen. Daher müssen Vorkehrungen getroffen werden, daß keine Synchronisationsprobleme auftreten. Die Klasse KontoManagerImpl kann von mehreren Clients bedient werden. Erweitern Sie an den betroffenen Stellen der Implementierung um ein bestimmtes Schlüsselwort. KontoImpl kann nur von einem Client bedient werden. Warum? Schauen Sie sich dazu die Methoden oeffnen() und anmelden() von KontoManagerImpl an. Die Antwort finden Sie hier. KontoImpl muß daher nicht synchronisiert werden. Aus der IDL-Datei ist es ersichtlich, daß eine Operation von KontoManager ein Exception werfen kann. Welche Operation und welche Ausnahnme? Hier die Antwort. Suchen Sie die zugehörige Stelle in der Implementierung und ergänzen Sie sie um diesen möglichen Fehlerfall. Die zugehörige Exception-Klasse ist auch aus der Implementierung der Methode ersichtlich. Die Klasse KontoImpl enthält Implementierungen für die in der IDL-Datei spezifizierten Operationen. Versuchen Sie mit Hilfe des vom IDL-Compiler generierten Interfaces Bank.Konto die Klasse KontoImpl um die fehlenden Methodensignaturen zu vervollständigen. Achten Sie sorgfältig auf die Implementierungen. Als Hilfe stehen weiterhin die Kommentare der Klasse zur Verfügung. Bevor CORBA diese Server-Objekte als Services zur Verfügung stellen kann, muß ein CORBA-konformer Server geschrieben werden. Das besorgt das Programm BankServer. Versuchen Sie anhand des Kap den Server zu implementieren. Als Servant soll hier eine Instanz KontoManagerImpl erzeugt und unter dem Namen "KontoManager" im Naming Service gebunden werden. Zu beachten ist, daß die Referenz auf KontoManagerImpl vom Typ KontoManager sein muß, die Schnittstelle für den Client. Damit wäre die Implementierung auf der Server-Seite abgeschlossen. Das Bankmodul ist folgendermaßen verwendbar: Der Kunde geht an ein Terminal und kann entweder ein neues Konto anlegen oder ein bestehendes öffnen. Daraufhin wird sein Konto angezeigt. Der Kunde zahlt einen Betrag ein, wonach der Kontostand aktualisiert und erneut angezeigt wird. Der Kunde hebt einen Betrag vom Konto ab, wobei auch hier der Kontostand aktualisiert und angezeigt wird. Der Kunde kann sein Konto auflösen. Der Kunde kann sich einen Überblick über alle verfügbaren Konten der Bank verschaffen (kommt hoffentlich in der Realität nicht vor). Diese Aktionen gelingen bereits mit diesen einfachen Server-Objekten. Nur der Client für das imaginäre Terminal fehlt noch.

23 3.3 Den Client schreiben Für den Client steht die Klasse BankClient zur Verfügung. Sie ist um den Zugriff auf die Server-Objekte zu erweitern. Der Client wird als Applet realisiert. Mit wenigen Ergänzungen ist er auch als Java-Applikation ablauffähig. Weitere Einzelheiten sind in der Methode main() zu finden. Die Initialisierung des ORBs wird in der Methode initconnection() vorgenommen. Analog zum Server sollen Sie hier die ORB-Initialisierung vollständig implementieren. Alle Einzelheiten sind im Kap zu finden. Achten Sie darauf, daß der Client sowohl als Applet als auch als Applikation verwendet werden kann. Das im Naming Service hinterlegte Objekt mit dem Namen "KontoManager" wird im Attribut kontomanager gespeichert, über das die Dienste von KontoManagerImpl genutzt werden kann. Das indivuelle Konto des Clients wird im Attribut konto geführt. Wie bekommt der Client eine Referenz auf dieses Konto? Schauen Sie sich die Methoden neueskontooeffnen() und kontoanmelden() an und vervollständigen Sie die Implementierung. Hier finden Sie die Lösung. Als GUI-Interface für den Client stehen die Klassen KontoNeuPanel, LoginPanel, MenuPanel, EinzahlenPanel, AbhebenPanel, KontenPanel und BankDialog zur Verfügung. Sie brauchen nicht weiter angepaßt werden. Als kleine Übung können Sie sich die Stellen heraussuchen, wo die Dienste des Servers genutzt werden. Die Namen der Panel- Klassen sagen schon relativ viel über ihre Funktionalitäten aus. Für das Java-Applet benötigen wir noch eine entsprechende HTML-Seite: <html> <body bgcolor=#aaaaaa> <center> <h1>corba-bank</h1> <hr> <applet code=bankclient width=370 height=400> <param name="org.omg.corba.orbinitialhost" value="localhost"> <param name="org.omg.corba.orbinitialport" value="6000"> </applet> </center> </body> </html> Zu beachten sind die Parameter ORBInitialHost und ORBInitialPort, über den der Client kommunizieren soll. Kopieren Sie sich den HTML-Code und speichern Sie ihn in die Datei BankClient.html ab. Damit wäre unser Client vollständig.