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

WS06/07 Prof. Dr. Andreas Schmietendorf 1

Programmierung von Client/Server-Anwendungen

Verwendung allgemeiner Middlewareansätze

http://www.fhw-berlin.de/


RPC – Remote Procedure Call



Ü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



Ablauf der Entwicklung

1. Spezifikation der über den RPC-Mechanismus aufzurufenden

Prozeduren (vgl. C-Header-Dateien)

2. Ausprogrammierung von Client- und Server-Komponenten

- Client enthält Aufrufe der zuvor spezifizierten Prozeduren

- Server besteht aus Implementierungen der spezifizierten Prozeduren

3. Programmgenerator (z.B. rpcgen) erzeugt aus der Spezifikation:

- Client-Stubs

- Server-Stubs

4. Client, Server sowie die Stub-Komponenten übersetzen und

binden

5. Start des Servers und danach des Clients



Ablauf der Kommunikation 1

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

2. Client-Stub konvertiert die Eingabeparameter (Marshalling)

Plattformunabhängiges Datenformat

Versenden der Daten inkl. weiterer Angaben (Kennung) über das Netz

3. Empfang der Nachricht des Client-Stubs vom Server-Stub

Umwandlung der Eingabeparameter in das lokale Format

(Unmarshalling)

Aufruf der entsprechenden Prozedur auf der Serverseite



Ablauf der Kommunikation 2

4. Ausführen der entsprechenden Prozedur auf der Server-Seite

Rückkehr zum Server-Stub

5. Aufgaben des Server-Stub

Umwandlung der Ausgabeparameter und Rückgabewert

Rücksenden des Ergebnisses an den Client

6. Client-Stub nimmt die Antwort entgegen

Umwandlung der Ausgabeparameter und Rückgabewert in das lokale

Datenformat

Rückkehr zum Aufrufer auf der Client-Seite



CORBA



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)



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



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!)

O Bject Request Broker (O RB)

Com m on O bject Services (CO RBAservices)Ÿ SecurityŸ NamingŸ TimeŸ ...

Com m on FacilitiesŸ System-ManagementŸ Task-ManagementŸ Information-ManagementŸ ...

ApplicationO bjects




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



CORBA-Architektur

O bject A dapter

O bject R equest B roker C ore (IIO P )

Dyn

am

icIn

voca

tion

OR

BIn

terf

ace

Clie

nt

IDL

Stu

bs Sta

ticS

kele

ton

Dyn

am

icS

kele

ton

Invo

catio

n

C lien tO bject

Im plem entationIn te rface

R epos ito ryIm p lem en ta tion

R epos ito ry




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




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




IDL-Compiler:

Com pilieren undLinken

Client-Executable

Com pilieren undLinken

Server-Executable

IDL-Com piler

Client-Code

IDL-Quelltext

Client-Stub Serv er-Skeleton Objekt-Im plem entierung




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)




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++.




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);




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.




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 attribute string warehouse_name;

// Operationen // Methode für die Erzeugung einfacher Customer-Objekte customer_easy new_customer_easy(in string name,in long key,in boolean hash); };

};




Initialisierungsdienst von CORBA:

N eues O bject C O R B A -A P I O R B

O RB_in it

BO A_in it

list_ in itia l_services

reso lve_in itia l_references

1

2

3

4




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)




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




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.




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.




Beispiel einer einfachen CORBA-IDL:module swt{// (C) 1998 Andreas Schmietendorfinterface 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);

};};




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)




Schritte zur ImplementierungEntwicklung 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




Implementierung des CORBA-Serverspackage swt; // MitarbeiterServer.java: Mitarbeiter-Server Hauptprogrammclass 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);}}}




Implementierung der fachlichen Server-Funktionenpublic 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;}




Implementierung der Applet-Anwendung 1import 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(); }

}

...




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);}

//Event des Mitarbeiter-Einfügen-Button auswertenvoid button2_actionPerformed(ActionEvent e){

String id = textField1.getText(); String na = mitarb.ma_anzeigen(id); textField2.setText(na);}...




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>




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




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




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

...




Aussehen der Applikationen (Client und Server):




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)




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




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)




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



RMI



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



RMI Architektur

Transport Layer (TCP/IP)

Remote Reference Layer

Stubs Sleletons

Client Server

Transport Layer (TCP/IP)

Remote Reference Layer

Stubs Skeletons

Client Server

rmiregistry



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


Documents

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