Prof. Dr. Andreas Schmietendorf Programmierung von Client/Server-Anwendungen Verwendung allgemeiner Middlewareansätze WS06/07 Prof. Dr. Andreas Schmietendorf

RPC – Remote Procedure Call WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Überblick zum RPC Entwickler nutzt selbes Paradigma für die Kommunikation auf unterschiedlichen Rechnern wie beim lokalen Prozeduraufruf Entwickler spezifiziert die Eigenschaften der Prozedurschnittstelle und implementiert die Komponenten der Anwendung Der notwendige Programmcode für die Realisierung der zur Kommunikation notwendigen Prozesse wird automatisch generiert. Wichtigste RPC-Implementierungen: SUN Microsystems RPC des DCE (Distributed Computing Enviroment) der OSF WS06/07 Prof. Dr. Andreas Schmietendorf

Ablauf der Entwicklung Spezifikation der über den RPC-Mechanismus aufzurufenden Prozeduren (vgl. C-Header-Dateien) Ausprogrammierung von Client- und Server-Komponenten Client enthält Aufrufe der zuvor spezifizierten Prozeduren Server besteht aus Implementierungen der spezifizierten Prozeduren Programmgenerator (z.B. rpcgen) erzeugt aus der Spezifikation: Client-Stubs Server-Stubs Client, Server sowie die Stub-Komponenten übersetzen und binden Start des Servers und danach des Clients WS06/07 Prof. Dr. Andreas Schmietendorf

Ablauf der Kommunikation 1 Aufruf der spezifizierten Prozeduren durch den Client Aktivieren einer gleichnamigen Prozedur des Client-Stubs Läuft auf dem gleichen Rechner ab wie der der Client selbst Client-Stub konvertiert die Eingabeparameter (Marshalling) Plattformunabhängiges Datenformat Versenden der Daten inkl. weiterer Angaben (Kennung) über das Netz Empfang der Nachricht des Client-Stubs vom Server-Stub Umwandlung der Eingabeparameter in das lokale Format (Unmarshalling) Aufruf der entsprechenden Prozedur auf der Serverseite WS06/07 Prof. Dr. Andreas Schmietendorf

Ablauf der Kommunikation 2 Ausführen der entsprechenden Prozedur auf der Server-Seite Rückkehr zum Server-Stub Aufgaben des Server-Stub Umwandlung der Ausgabeparameter und Rückgabewert Rücksenden des Ergebnisses an den Client Client-Stub nimmt die Antwort entgegen Umwandlung der Ausgabeparameter und Rückgabewert in das lokale Datenformat Rückkehr zum Aufrufer auf der Client-Seite WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf CORBA WS06/07 Prof. Dr. Andreas Schmietendorf

OMG – Object Management Group 700 Unternehmen weltweit Ziel: Steigerung der Produktivität der SW-Entwicklung Definierte Standards für interoperable und unabhängig voneinander entwickelbare Applikationskomponenten Ergebnis der OMG: OMA/CORBA OMA - Object-Management-Architecture (Referenzarchitektur für verteilte heterogene objektorientierte Systeme) CORBA Standard für die Interaktion von Kompoenten in vernetzten heterogenen Systemen Ausnahme: Microsoft plaziert DCOM als konkurrierenden Objektbus. (Distributet Component Object Model) WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf CORBA-Merkmale Kern ist der Object Request Broker (ORB) Möglichkeit der Realisierung mehrstufiger C/S-Architekturen Unabhängigkeit von Implementierungssprache und System Interoperabilität zwischen heterogenen Systemen Verfügbar auf gängigen Betriebssystemen (UNIX, NT, MVS,...) Quasi Standard für ORB-Architekturen (Ausnahme DCOM) Nach Festlegung der Schnittstellendefinition können Aufgaben zu einem Informationssystem verteilt, d.h. strukturiert werden Server-Objekte residieren im Netzwerk, Kommunikation erfolgt über GIOP/IIOP (letzteres im Falle von TCP/IP) Angebot an CORBA-Services und CORBA-Facilities WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Was ist ein ORB: Kern des Object Request Broker (ORB) ist der Objectbus Objekte können transparent mit anderen Objekten interagieren Satz von Middleware-Diensten CORBA 2.0 Inter-ORB-Kommunikation (Güte abhängig von der Implementierung!) WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Vorzüge CORBA [nach Orfali 1998]: Statische und dynamische Methodenaufrufe Verknüpfung auf Hochsprachenebene Selbstbeschreibendes System (Meta-Daten zur Laufzeit) Ortstransparenz (ORB-Implementierungen lokal und verteilt) Eingebaute Sicherheit von Transaktionen Polymorphe Nachrichten (vgl. Polymorphie der Objektorientierung) Koexistenz mit existierenden Systemen RPC vs. CORBA RPC - Aufruf einer spezifischen Funktion CORBA - Aufruf einer Methode innerhalb einer konkreten Instanz WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf CORBA-Architektur WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Bestandteile des ORB: Dynamic Invocation - Genormte Schnittstelle zur generischen Requesterzeugung Client IDL Stub - Generierter Code aus dem IDL-Compiler ORB-Interface - Abstrahierte Schnittstelle zum ORB Core (IIOP) Static Skeleton - Generierter Code aus dem IDL-Compiler Dynamic Skeleton - Genormte Schnittstelle zum Request-Empfang Object-Adapter - Trennt die Objectimplementation vom ORB, soll Objekte aktivieren und deaktivieren sowie Request dispatchen ORB-Core - Verteilte Komponenten zwischen Client und Server WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Schritte zur CORBA-Entwicklung/Ausführung: Objektorientierte Modellierung (Identifizierung Server-Klassen) Schnittstellenspezifikation der festgestellten Klassen in IDL File *.idl mittels IDL-Compiler für Zielsprache Übersetzen z.B. Java-Client d.h. IDL-Compiler für Java notwendig z.B. C++ Server d.h. IDL-Compiler für C++ notwendig Stub- (Client) und Skelleton- (Server) Klassen werden generiert Implementierung eines CORBA- und des fachlichen -Servers Implementierung der Client-Anwendung Installation von Client und Server-Anwendungen Start des ORB, des Servers und der Client-Anwendung WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme IDL-Compiler: WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Sprachanbindung CORBA-IDL (Teilmenge von C++): Spezifikation der potentiellen Schnittstelle als erster Schritt einer CORBA-Entwicklung, „Vertrag“ zwischen Client- und Server-Implementierung CORBA-IDL ist rein deklarativ und enthält keine Implementierungsdetails CORBA-IDL definiert unterschiedliche Objekttypen, indem notwendige Methoden, deren Parameter (inkl. Transportrichtung) beschrieben werden IDL spezifizierte Methoden sind in vielen Sprachen verfügbar (Bsp.: C, C++, Cobol, Java, Smalltalk, Ada IDL stellt betriebssystem- und sprachunabhängige Schnittstellen für alle Dienste/Schnittstellen die auf den CORBA-Bus verfügbar sind zur Verfügung Verteilte Dienste (z.B. Ermittlung der aktiven Objekte im Netzwerk und welche Methoden verfügbar) WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme CORBA-IDL im Detail: Einfache Datentypen: long, short, unsigned long, unsigned short, float, double, char, boolean, octet und any (für jeden Wert), Komplexe Datentypen: struct, union, enum, array, string und sequence Ausnahmen/Unterschiede zu C/C++: octet: unsigned char (in C,C++), boolean: unsigned char, long double: twice a double, any: "typedef struct any { TypeCode _type; void *_value; } any;" in C und "class Any { ...; };" in C++. WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Operationen der IDL-Datei: Syntax <op_type_sepc> <identifier> (param1,...); <op_type_sepc> Definition des Returnwertes der Methoden, auch „void“ ist möglich <identifier> Name der Methode param1: in, out, inout <param_type> <identifier> in - Parameter vom Client zum Server out - Parameter vom Server zum Client inout - Parameter vom Client zum Server und zurück param_type - Typ des Parameters identifier - Parmetername string ma_anzeigen(in string pers_ID); WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Attribute der IDL-Datei: Syntax [readonly] attribte <attr_type> <identifier> Attribute werden mit Datentyp und Attributename definiert. Der IDL-Compiler erzeugt daraus entsprechenden set/get-Methoden. Wird das Schlüsselwort readonly angegeben werden nur get-Methoden erzeugt. Bei Attributen können keine Fehler über Exceptions abgefangen werden. Nach Möglichkeit sollte auf die Definition von Attribten verzichtet werden, da so zu viele Instanzen erzeugt werden und die Performance davon verschlechtert wird. WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Beispiel einer einfachen IDL-Datei: module objectbench{ interface customer { // Attribute attribute string name; attribute long key; // Operationen //keine Methode definiert }; interface customer_easy : customer { ... }; interface customer_complex : customer_easy { ... }; interface warehouse { attribute string warehouse_name; // Methode für die Erzeugung einfacher Customer-Objekte customer_easy new_customer_easy(in string name,in long key,in boolean hash); WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Initialisierungsdienst von CORBA: WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Objekt-Referenz (IOR - Interoperable Object References): Information um Objekte durch den ORB zu lokalisieren. Bestandteile einer Objekt-Referenz Repository-ID Hostname (IP-Adresse oder DNS-Name) Portnummer Objekt-key ab Version 2.2 wird der Objekt-key durch POAID und ObjectID Ein CORBA-Client verwendet nur die ersten 3 Bestandteile, so daß die Änderungen ab Version 2.2 keine direkte Auswirkung haben. Praktische Realisierung: OSAgent beim Visibroker (Problem der Anwendung in großen Installationen/Netzwerken) WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Request: Ein Request enthält die folgenden Informationen Zielobjekt (Objekt-Referenz) Operations-Name Parameter Optional - Requestkontext Parameter werden auf Strukturen gemappt, welche wiederum in CORBA-IDL definiert, das GIOP beschreiben. Das abstrakte GIOP kann über jedes verbindungsorientierte Transportprotokoll transportiert werden, wie z.B. im Falle von TCP/IP das IIOP Die Reply enthält die OUT-Parameter bzw. Exceptions WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Synchronisations-Mechanismen (CORBA 2.x): Synchronous, nach einem Methoden-Aufruf ist der Client solange blockiert bis ein Ergebnis bzw. eine Exception zurückgegeben wird. (Standard-Einstellung) Defferred Synchronous, sofern das „Dynamic Invocation Interface genutzt wird kann auch ein verzögertes synchrones Verhalten erzeugt werden. (es besteht keine Möglichkeit der Transaktionssicherung) Asynchronous, nach Aufruf der entfernten Methode wird die Verarbeitung beim Client sofort fortgesetzt. Dafür muß die Operation mit dem Schlüsselwort „oneway“ ausgestattet werden. WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Aufgabenstellung: Auf einem Server sollen zentral Daten gespeichert werden, speziell eine Personal-ID sowie ein dazugehörender Name. Entwicklung einer CORBA-IDL welche entsprechende Methoden für die Kommunikation zwischen Client und Server spezifiziert. Der CORBA-Server sowie die fachliche Server-Anwendung sollen ebenfalls in Java implementiert werden Über einen Java-Applet-Client sollen die Daten eingegeben und abgespeichert werden, bzw. nach Eingabe einer Personal-ID der entsprechende Name ausgegeben werden. Es sind Problembereiche einer CORBA-Kommunikation bei Java-Web-Anwendungen aufzeigen. WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Beispiel einer einfachen CORBA-IDL: module swt { // (C) 1998 Andreas Schmietendorf interface Mitarbeiter { // Attributes attribute string name; attribute string pers_ID; // Operations void ma_erfassen(in string name, in string pers_ID); string ma_anzeigen(in string pers_ID); }; WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Ergebnisse der IDL-Compilierung (Visibroker): Aufruf des IDL-Compilers: idl2java *.idl Generierte Klassen für die Server-Seite: swt._MitarbeiterImplBase.class (Verbund Java und Corba-Objektmodell) swt._example_Mitarbeiter.class (Code-Rahmen fachl. Server-Funktionen) swt.Mitarbeiter.class (Abbildung auf Java-Interface) swt._sk_Mitarbeiter.class (Skeleton/Proxy für Mitarbeiter-Objekt) Generierte Klassen Client-Seite: swt.MitarbeiterHelper.class (Hilfsfunktionen zur Auflösung von Objektref.) swt.MitarbeiterHolder.class (Übergabe/-nahme von in/out-Parametern) swt._st_Mitarbeiter.class (Stub/Proxy für das Mitarbeiter-Objekt) swt._tie_Mitarbeiter.class (Delegation von Operationsaufrufen) WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Schritte zur Implementierung Entwicklung eines CORBA-Servers (MitarbeiterServer.class) Initialisierung des ORB und BOA (Basic Object Adapter) Erzeugen eines Mitarbeiter-Objekt und Export zum ORB Umbenennen_example_Mitarbeiter.class nach MitarbeiterImpl Fachliche Funktion über Ein-/Ausgaben auf Hashtabelle, eventl. Nutzung von Standard SET/GET-Funktionen für Attribute Implementierung eines Applet MitApplet.class, abgeleitet von Applet Grafisches Layout realisieren (Eingabefelder, Buttons, Informationen...) Eingaben verarbeiten (Plausibilitäts-Prüfungen) Ereignisse der Eingabe-Felder bzw. Buttons verarbeiten Verwendung von „remote“ Methoden via CORBA WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Implementierung des CORBA-Servers package swt; // MitarbeiterServer.java: Mitarbeiter-Server Hauptprogramm class MitarbeiterServer { static public void main(String[] args) { try { // Initialize the ORB org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null); // Initialize the BOA org.omg.CORBA.BOA boa = orb.BOA_init(); // Create the Mitarbeiter object MitarbeiterImpl mitarbeiter = new MitarbeiterImpl("My Mitarbeiter"); // Export to the ORB the newly created object boa.obj_is_ready(mitarbeiter); // Ready to service requests boa.impl_is_ready(); } catch(org.omg.CORBA.SystemException e) { System.err.println(e); }}} WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Implementierung der fachlichen Server-Funktionen public class MitarbeiterImpl extends swt._MitarbeiterImplBase { /** Variablen bzw. Object-Vereinbarungen */ private Hashtable mittab = new Hashtable(); ... public MitarbeiterImpl(java.lang.String name) { super(name);} /** Construct a transient object. */ /** Erfassen von Name und Personal-ID in einer Hashtabelle */ public void ma_erfassen(java.lang.String name, pers_ID) {mittab.put(pers_ID,name);} /** Auslesen des Namen zu einer Personal-ID aus der Hashtabelle */ public java.lang.String ma_anzeigen(java.lang.String pers_ID) {name= (String) mittab.get(pers_ID);return name;} WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Implementierung der Applet-Anwendung 1 import java.awt.*; ... public class MitApplet extends Applet { TextField textField2 = new TextField(); Button button1 = new Button(); //Das Applet initialisieren public void init(){ System.out.println("Initializing the ORB"); org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(this, null); // Binden des Mitarbeiter Object System.out.println("Binding to Mitarbeiter Object"); mitarb = swt.MitarbeiterHelper.bind(orb, "My Mitarbeiter"); try { jbInit(); } catch (Exception e) { e.printStackTrace(); } } WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Implementierung der Applet-Anwendung 2 ... //Initialisierung der Komponente public void jbInit() throws Exception{ button1.setLabel("Mitarbeiter einfügen"); label1.setText("Personal ID"); button1.addActionListener(new MitApplet_button1_actionAdapter(this)); //Event des Mitarbeiter-Einfügen-Button auswerten void button1_actionPerformed(ActionEvent e){ String na = textField2.getText(); String id = textField1.getText(); mitarb.ma_erfassen(na,id);} void button2_actionPerformed(ActionEvent e){ String na = mitarb.ma_anzeigen(id); textField2.setText(na);} WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Implementierung der HTML-Webseite <HTML> <TITLE> HTML-Testseite </TITLE> <BODY> MitApplet erscheint in einem Java-fähigen Browser.<BR> <APPLET CODE = swt.MitApplet.class WIDTH = 400 HEIGHT = 300 HSPACE = 0 VSPACE = 0 ALIGN = Middle > <param name=org.omg.CORBA.ORBClass value=com.visigenic.vbroker.orb.ORB> </APPLET> < /BODY></HTML> WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Test/Ausführung der kompletten Anwendung: Sämliche Java-Quellcodedateien (*.java) müssen in Java-Bytecode (*.class) übersetzt werden. Laufender TCP/IP Protokollstack Grundlage für IIOP Konfiguration des Gatekeeper falls der Test über das Netz erfolgt, andernfalls genügen die Standard-Einstellungen Start eines ORB-Agent (Visibroker Smart Agent) auf einer oder mehrerer Maschinen im Netz (Redundanz) Start des Gatekeepers als Firewall (wenn Java-Applet) Start der Server-Anwendung (MitarbeiterServer.class) Start des Applet MitApplet.class im Browser bzw. Applet-Viewer im Rahmen einer HTML-Datei WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Funktionalität des Gatekeeper (Visibroker): Java Sandbox-Security, Java-Applets dürfen nur mit dem Server kommunizieren, von welchem sie geladen wurde.. Beeinträchtigt die Skalierbarkeit der Anwendung Ermöglicht keine dynamische Lastverteilung Lösung beim Visibroker durch den Einsatz des Gatekeepers Proxy-Objekt für die Entgegennahme von Client-Anforderungen die nicht lokal bedient werden können Beim Start des Gatekeepers wird eine gatekeeper.ior Datei geschrieben, diese muß zwingend im gleichen Verzeichnis stehen wie die HTML-Datei mit dem entsprechenden Applet-Tag Abspeicherung der Einstellungen unter gatekeeper.properties WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Konfigurations-Dialog des Gatekeeper: Einstellungen: IP-Adressen (IN/OUT) Port-Adressen (IN/OUT) HTTP-Unterstützung Callback-Service Location-Services Socket-Security-Layer Verzeichnis für *.ior Logging-Level ... WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Aussehen der Applikationen (Client und Server): WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Problembereiche 1: Konfiguration der Laufzeitumgebung, wobei insbesondere die Angabe- von Path bzw. Classpath-Anweisungen zu beachten sind Test von verteilten Applikationen, zum Test der Server-Komponente wird immer eine Client-Komponente benötigt die alle angebotenen Interfaces abtesten kann Verwendung der jeweils richtigen JDK/VM-Version, nur wenige Browser verfügen überhaupt über CORBA-Komponenten Beachtung der Ladezeiten für die CORBA-Umgebung zum Client beim ersten Aufruf. Inter-ORB-Kommunikation (Namen-Konventionen teilweise unterschiedlich) WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Problembereiche 2: Fehler im Design der IDL können in der Implementierung nicht mehr beseitigt werden Keine Möglichkeiten der QoS-Vereinbarungen im Rahmen der IDL-Definitionen Ungenügende Toolunterstützung für die Modellierung einer CORBA-Anwendung. (Rational Rose kann IDL generieren, diese ist aber nicht direkt verwendbar durch einen IDL-Compiler) Tranparenz der generierten Dateien geht verloren, daraus ergeben sich Probleme bei der Fehlersuche bzw. Debugging Derzeit sind keine Design-Richtlinien für CORBA-Schnittstellen vorhanden, welche z.B. Performance-Aspekte berücksichtigen WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Ausblick CORBA Version 3.0: Message Oriented Middleware (MOM) >> Zielstellung u.a. QoS Erweiterung der derzeitigen Synchronisationsmechanismen Erlaubt Clients nicht-blockierende Anfragen (Prozeß bzw. Thread) Erlaubt Clients- und Servern zu unterschiedlichen Zeiten zu laufen Unterstützung von „Normaden-Clients“ über zeitunabhängige Warteschlagen Warteschlangen zur Message-Aufnahme können persistent oder transient sein Server Portablity Zielstellung portabler Server-Implementierungen Ablösung des BOA durch den POA (Portable Object Adapter) WS06/07 Prof. Dr. Andreas Schmietendorf

Verteilte Informationssysteme Ausblick CORBA Version 3.0: Business Objects Framework (BOF) Java Bindings Pass-by-Value Mobile Agents CORBA/DCOM Interoperability  Erweiterungen haben nur eine geringe industrielle Durchdringung erreicht WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf RMI WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf Ziele von Java RMI Kommunikation mit entfernten Java-Objekten soll so erscheinen als ob diese lokal vorhanden wären (zusätzliche Exceptions) Nahtloses Einbinden von Objekten aus verschiedenen Java-Umgebungen Verteiltes Objektmodell (Java Distributet Object Model DOM) Einfaches Entwerfen verteilter Applikationen Übernehmen der Sicherheitsmechanismen durch das DOM sowie Berücksichtigung der „garbage Collection“ aller Objekte Rückruf vom Server zum Applet ermöglichen WS06/07 Prof. Dr. Andreas Schmietendorf

Prof. Dr. Andreas Schmietendorf RMI Architektur WS06/07 Prof. Dr. Andreas Schmietendorf

Stärken/Schwächen von RMI Hoher Abstraktionsgrad, Transparenz für den Entwickler RMI ist nahtlos in Java integriert RMI relativ einfach zu verwenden (keine Zusatzprodukte) Dynamisches Laden von Stub/Skeletons möglich (dyn. Referenzen) Weniger Overhead gegenüber CORBA (ggf. leicht performanter) Client und Server müssen in Java implementiert werden Keine automatische Aktivierung von Servern möglich Keine Kommunikationssicherheit WS06/07 Prof. Dr. Andreas Schmietendorf