WS06/07Prof. Dr. Andreas Schmietendorf1 Programmierung von Client/Server- Anwendungen Verwendung...
-
Upload
karlotte-geil -
Category
Documents
-
view
106 -
download
0
Transcript of WS06/07Prof. Dr. Andreas Schmietendorf1 Programmierung von Client/Server- Anwendungen Verwendung...
WS06/07 Prof. Dr. Andreas Schmietendorf 1
Programmierung von Client/Server-Anwendungen
Verwendung allgemeiner Middlewareansätze
WS06/07 Prof. Dr. Andreas Schmietendorf 3
Ü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 4
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
WS06/07 Prof. Dr. Andreas Schmietendorf 5
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
WS06/07 Prof. Dr. Andreas Schmietendorf 6
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
WS06/07 Prof. Dr. Andreas Schmietendorf 8
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 9
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 10
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
WS06/07 Prof. Dr. Andreas Schmietendorf 11
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 12
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
WS06/07 Prof. Dr. Andreas Schmietendorf 13
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 14
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 15
Verteilte Informationssysteme
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
WS06/07 Prof. Dr. Andreas Schmietendorf 16
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 17
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 18
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 19
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 20
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 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); };
};
WS06/07 Prof. Dr. Andreas Schmietendorf 21
Verteilte Informationssysteme
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
WS06/07 Prof. Dr. Andreas Schmietendorf 22
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 23
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 24
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 25
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 26
Verteilte Informationssysteme
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);
};};
WS06/07 Prof. Dr. Andreas Schmietendorf 27
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 28
Verteilte Informationssysteme
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
WS06/07 Prof. Dr. Andreas Schmietendorf 29
Verteilte Informationssysteme
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);}}}
WS06/07 Prof. Dr. Andreas Schmietendorf 30
Verteilte Informationssysteme
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;}
WS06/07 Prof. Dr. Andreas Schmietendorf 31
Verteilte Informationssysteme
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(); }
}
...
WS06/07 Prof. Dr. Andreas Schmietendorf 32
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);}
//Event des Mitarbeiter-Einfügen-Button auswertenvoid button2_actionPerformed(ActionEvent e){
String id = textField1.getText(); String na = mitarb.ma_anzeigen(id); textField2.setText(na);}...
WS06/07 Prof. Dr. Andreas Schmietendorf 33
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 34
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 35
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 36
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 37
Verteilte Informationssysteme
Aussehen der Applikationen (Client und Server):
WS06/07 Prof. Dr. Andreas Schmietendorf 38
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 39
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 40
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 41
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 43
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 44
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
WS06/07 Prof. Dr. Andreas Schmietendorf 45
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