Sockets - Institut für Betriebssysteme und Rechnerverbund

Systemarchitekturen für
Verteilte Anwendungen
– Implementierungsvarianten –
25.10., 26.10. und 30.11.2014
Institut für Betriebssysteme und
Rechnerverbund
TU Braunschweig
PD Dr. Christian Werner
1-2
Interprozess-Kommunikation
Anwendungsprogramme „leben“ in Prozessen.
Ein Prozess ist ein Objekt des Betriebssystems, durch das
Anwendungen sicheren Zugriff auf die Ressourcen des
Computers erhalten. Einzelne Prozesse sind dazu
gegeneinander isoliert.
Damit zwei Prozesse Informationen austauschen können,
müssen sie Interprozesskommunikation (interprocess
communication, IPC) einsetzen.
IPC basiert auf dem Austausch von Nachrichten (=
Bitfolgen)
Eine Nachricht wird von dem einem Prozess geschickt (dem
Sender).
Sie wird von einem anderen Prozess empfangen (dem Empfänger).
1-3
Synchroner vs. Asynchroner IPC
Synchron:
Sender und Empfänger
blockieren beim Senden bzw.
Empfangen, d.h., wenn ein
„Senden“ ausgeführt wird,
kann der Prozess nur
weiterarbeiten, nachdem das
zugehörige „Empfangen“ im
anderen Prozess ausgeführt
wurde.
Wenn ein „Empfangen“
ausgeführt wird, wartet der
Prozess so lange, bis eine
Nachricht empfangen wurde.
Weniger effizient, aber leicht zu
implementieren
(Synchronisation beim
Ressourcenzugriff wird gleich
miterledigt).
Asynchron:
Das „Senden“ findet nichtblockierend statt, d.h., der
Prozess kann nach dem
Senden der Nachricht sofort
weiterarbeiten.
Empfangen kann blockierend
oder nicht-blockierend sein.
Etwas komplizierter zu
implementieren
(Warteschlangen), aber
effizienter.
1-4
Implementierungsvarianten Verteilter Anwendungen
Anwendung
Middleware
StandardDienste
(FTP, Email,
vor allem WWW)
TCP/UDP über IP
1-5
Überblick
Sockets
UDP/IP
TCP/IP
Middleware
CORBA
Java RMI
Web Services
1-6
TCP/IP Protocol Stack
Web browser,
e-mail, ...
Applications
Other user
applications
User
space
Application protocols:
HTTP, SMTP, FTP, ...
Application Programming Interface (API)
UDP
TCP
IGMP
ICMP
Transport
RIP
IP
RARP
OSPF
Network
ARP
LAN DL
technology
WAN DL
technology
Data Link
OS
kernel
1-7
Das Modell von IP
Datagramme
Einzelne, unabhängig voneinander weitergeleitete Pakete, die
sich ihren Weg zum Ziel suchen
Routing-Tabellen
geben den Ausgang zu
einem Ziel an
R2
yx
„Best effort“-Dienst
Keine Garantie für
Auslieferung eines
Pakets
Korrekte Reihenfolge
R1
x
yx
yx
DA,SA
data
Routing tables
Router R1
DA
y
...
Next hop
R3, R4
...
R5
R3
R4
yx
R6
yx
Router R3
DA
y
...
Next hop
R6
...
yx
y
Router R6
DA
y
...
Next hop
...
1-8
IPv4-Adressen
32 bits
Binäre und dezimale Darstellung
31
Binary:
Dotted decimal:
23
15
7
0
11010100 01111110 11010000 10000111
212
.
126
.
208
.
135
Hierarchische Adressierung
Netzwerk-Nummer + Netzmaske (Classless Interdomain Routing
(CIDR), RFC 1519).
Netzangabe: 134.169.0.0/255.255.0.0 oder alternativ
134.169.0.0/16 (16 = Länge der Netzmaske)
Bildung von Netzhierarchien:
IBR-Netz: 134.169.34.0/23
CIP-Pool im IBR-Netz: 134.169.34.192/26
1-9
Transportschicht: TCP und UDP
Aufgabe der Transportschicht: Datentransport von
einem Prozess auf einem Rechner zu einem (oder
mehreren) anderen Prozessen auf anderen
Rechnern im Internet
Zwei Möglichkeiten
Der grundlegende unzuverlässige Internetdienst genügt,
dann verwende UDP.
Er genügt nicht, dann verwende TCP.
1-10
Eigenschaften von TCP und UDP
TCP setzt einen zuverlässigen Dienst auf IP auf:
Paketauslieferung ist garantiert (bzw. der Sender erhält
zumindest eine Fehlermeldung)
Die Reihenfolge der eingehenden Pakete entspricht der
Sendereihenfolge
UDP garantiert dies nicht, ist aber dafür wesentlich
schneller.
Anwendungen für beide Protokolle?
1-11
Umsetzung von TCP
TCP setzt vor allem die folgenden
Protokollmechanismen ein, um die Effekte erzielen
zu können
Daten sind numeriert, so dass fehlende Daten schnell
festgestellt werden können
Mittels ACKnowledgements teilt der Empfänger den
korrekten Empfang von Daten mit
Mittels Timern stellt der Sender das Ausbleiben von
ACKs fest
1-12
Das TCP/UDP API: Sockets
Das Internet-API über der Transportschicht wird als
Sockets bezeichnet.
Ein Socket kann als Endpunkt einer
Kommunikationsbeziehung betrachtet werden.
Daten werden in Sockets abgelegt und durch Sockets
empfangen.
Es gibt in der Socket-Schnittstelle zwei grundlegende
Typen von Sockets:
Ein Socket, der wie das Ende einer Telefonverbindung funktioniert
Ein Socket, der wie ein Briefkasten funktioniert
Was bedeutet das?
Sockets sind mehr oder weniger in jeder
Programmiersprache erhältlich, u.a. in Java.
1-13
Sockets und TCP/UDP-Ports
Ein Socket wird vor der Kommunikation mit einer TCP/UDP-Portnummer
und einer IP-Adresse assoziiert.
Dadurch kann ein bestimmter Prozess auf einem Rechner identifiziert
werden.
socket
any port
agreed port
socket
message
client
server
other ports
Internet address = 138.37.94.248
Internet address = 138.37.88.249
1-14
Beispiel: Telnet-Server und Clients
hugo.int.fr
139.29.100.11
neptun.elc.ro
141.85.43.8
HTTP
client
port: 3135
TCP
HTTP
connection
HTTP
server
telnet
port: 80
TCP connection
141.85.43.8 : 3135,
139.29.100.11: 80
zola.int.fr
139.29.35.18
port: 5768
TCP
TCP connection
139.29.35.18 : 5768,
139.29.100.11: 80
IP
IP
IP datagrams
HTTP
client
HTTP
connection
TCP
IP
IP datagrams
1-15
Datagram Sockets
Eine Nachricht, die durch einen UDP-Socket
geschickt wird, wird nicht bestätigt bzw. bei Verlust
automatisch erneut geschickt.
Paketfehler können deshalb zum Verlust der
Nachricht führen, ohne dass es die Anwendung
bemerkt.
Maximale Größe der Nachricht: 65.535 Bytes;
größere Nachrichten müssen in der Anwendung
segmentiert bzw. re-assembliert werden!
UDP-Sockets verwenden nicht-blockierendes
Senden und blockierendes Empfangen.
1-16
Java API für UDP-Sockets
Zwei wichtige Klassen:
DatagramPacket
DatagramSocket
DatagramPacket enthält die zu sendende Information.
DatagramSocket besitzt vor allem die Methoden
send(DatagramPacket)
receive(DatagramPacket)
mit der offensichtlichen Funktionalität.
Mehr Informationen finden sich in der API-Beschreibung
unter http://docs.oracle.com/javase/7/docs/api/
im java.net-Package.
1-17
Typische Struktur von UDP-Programmen
Client
Server
create UDP socket
create UDP socket
create datagram
create datagram buffer
send datagram
receive datagram
create datagram buffer
create and send datagram
receive datagram
Ein UDP-Client
1-18
import java.net.*;
import java.io.*;
public class UDPClient{
public static void main(String args[]){
try {
DatagramSocket aSocket = new DatagramSocket();
byte [] m = args[0].getBytes();
InetAddress aHost = InetAddress.getByName(args[1]);
int serverPort = 6789;
DatagramPacket request = new DatagramPacket(m, args[0].length(),
aHost, serverPort);
aSocket.send(request);
byte[] buffer = new byte[1000];
DatagramPacket reply = new DatagramPacket(buffer, buffer.length);
aSocket.receive(reply);
System.out.println("Reply: " + new String(reply.getData()));
aSocket.close();
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e){System.out.println("IO: " + e.getMessage());}
}
}
1-19
Ein UDP-Server
import java.net.*;
import java.io.*;
public class UDPServer{
public static void main(String args[]){
try{
DatagramSocket aSocket = new DatagramSocket(6789);
byte[] buffer = new byte[1000];
while(true){
DatagramPacket request = new DatagramPacket(buffer, buffer.length);
aSocket.receive(request);
DatagramPacket reply = new DatagramPacket(request.getData(),
request.getLength(), request.getAddress(), request.getPort());
aSocket.send(reply);
}
}catch (SocketException e){System.out.println("Socket: " + e.getMessage());
}catch (IOException e) {System.out.println("IO: " + e.getMessage());}
}
}
1-20
Stream Sockets
TCP-Sockets gestatten eine Datenstrom-orientierte
Kommunikation.
Daten werden in einem Strom geschrieben, der vom
Partner in derselben Reihenfolge empfangen wird.
Paketverluste werden von TCP abgefangen, d.h.,
Anwendungen erhalten Daten erst, wenn Sie wirklich
korrekt (in der Reihenfolge) sind.
Vor dem eigentlichen Datenaustausch muss zunächst eine
Verbindung zwischen Client und Server aufgebaut werden.
Verbindungen werden über die Port/IP-Adressinformation
identifiziert.
1-21
Das TCP-Socket-API in Java
Zwei wichtige Klassen:
ServerSocket
Socket
Ein ServerSocket ist passiv und wartet nach dem Aufruf
der accept-Methode auf Verbindungsaufbauwünsche von
Clients.
Ein Socket wird vom Client genutzt. Mittels des
Konstruktors wird implizit eine Verbindung zu einem Server
aufgebaut.
Bei beiden Klassen kann man sich eine Referenz auf den
Ein- bzw. Augabedatenstrom geben lassen. Datenströme
können dann nach dem ganz normalen Java-Schema
genutzt werden.
1-22
Typische Struktur von TCP-Programmen
Client
Server
create Stream socket
create Server socket
connect
wait for connection
write data on stream
read data from stream
write data on stream
read data from stream
1-23
Ein TCP-Client
import java.net.*;
import java.io.*;
public class TCPClient {
public static void main (String args[]) {
try{
int serverPort = 7896;
Socket s = new Socket(args[1], serverPort);
DataInputStream in = new DataInputStream( s.getInputStream());
DataOutputStream out =
new DataOutputStream( s.getOutputStream());
out.writeUTF(args[0]);
String data = in.readUTF();
System.out.println("Received: "+ data) ;
s.close();
}catch (UnknownHostException e){
System.out.println("Sock:"+e.getMessage());
}catch (EOFException e){System.out.println("EOF:"+e.getMessage());
}catch (IOException e){System.out.println("IO:"+e.getMessage());
}
}
}
1-24
Ein TCP-Server
import java.net.*;
import java.io.*;
public class TCPServer {
public static void main (String args[]) {
try{
int serverPort = 7896;
ServerSocket listenSocket = new ServerSocket(serverPort);
while(true) {
Socket clientSocket = listenSocket.accept();
Connection c = new Connection(clientSocket);
}
} catch(IOException e) {System.out.println("Listen :"
+e.getMessage());}
}
}
1-25
TCP Server (Forts.)
class Connection extends Thread {
DataInputStream in;
DataOutputStream out;
Socket clientSocket;
public Connection (Socket aClientSocket) {
try {
clientSocket = aClientSocket;
in = new DataInputStream( clientSocket.getInputStream());
out =new DataOutputStream( clientSocket.getOutputStream());
this.start();
} catch(IOException e) {System.out.println("Connection:“
+e.getMessage());}
}
public void run(){
try {
// an echo server
String data = in.readUTF();
out.writeUTF(data);
clientSocket.close();
} catch(EOFException e) {System.out.println("EOF:"+e.getMessage());
} catch(IOException e) {System.out.println("IO:"+e.getMessage());}
}
}
1-26
Weitere Aufgaben des Programmierers
Sockets stellen nur die grundlegenden Mechanismen zur
Verfügung, es bleibt noch einiges zu tun:
Implementierung komplexerer Systemmodelle wie Request-Reply
(bei Client-Server) oder Gruppenkommunikation
Vor allem aber die Notwendigkeit der homogenen
Datenrepräsentation in heterogenen Umgebungen
Dies sind die grundlegenden Techniken für komplexere
Middleware wie
RPC
Java RMI
CORBA
1-27
Datenrepräsentation und Marshalling
Die meisten Anwendungen bzw. Middleware-Ansätze
nutzen ein gemeinsames Datenformat.
Notwendig wegen der Heterogenität der Umgebungen
Unterschiedliche Hardwarearchitektur
Verschiedene Betriebssysteme
Verschiedene Programmiersprachen
Unter „Marshalling“ versteht man den Prozess der
Transformation einer beliebigen Datenstruktur in eine
übertragbare Nachricht:
„planieren“ der Datenstruktur (in eine zusammenhängende
Nachricht)
Übersetzung in das gemeinsame Format
Abbildung von Datenstrukturen auf Nachrichten
1-28
Ein Nachricht steht zusammenhängend im
Speicher und kann so übertragen werden.
F
I
S
C
H
E
R
\0
1
5
C
A
M P
U
S
U
1
Eine Datenstruktur kann über den Speicher verteilt
sein und so nicht übertragen werden.
F
•
I
S
C
H
E
R
\0 1
5
C
A
M P
U
S
1
U
1-29
Datenrepräsentation
Es gibt eine Reihe bekannter Ansätze für ein
gemeinsames Netzdatenformat.
Idee:
Definiere eine Menge von abstrakten Datentypen und eine
Kodierung (ein genaues Bit-Format) für jeden dieser Typen
Stelle Werkzeuge zur Verfügung, die die abstrakten Datentypen in
Datentypen der verwendeten Programmiersprache übersetzen
Stelle Prozeduren zur Verfügung, die die lokalen Darstellungen der
Datentypen in das kodierte Format übersetzen
Zur Laufzeit: wenn ein bestimmter Datentyp übertragen werden
soll, rufe die Kodierfunktion auf und übertarge das Ergebnis
Auf der Empfängerseite: dekodiere den Bit-String und erzeuge eine
neue lokale Repräsentation des empfangenen Typs
1-30
Abbildungsfunktionen
Abstrakte Datentypen
Übersetzung in
Sprache X
Übersetzung in
Sprache Y
Kommunikation?
Programm in Sprache X
Kodiere Nachricht
Programm in Sprache Y
Dekodiere Nachricht
Nachricht in kodiertem Format
1-31
Bekannte Formate
ASN.1 (ISO OSI)
XDR (Internet RPC)
CDR (CORBA)
Java object serialization
XML
Zwei unterschiedliche Ansätze:
Übertragung in binärer Form
Übertragung als Text
Beispiel ASN.1:
5
Tag: Typ
ID
65
Länge der
Daten
12
61
“This is the content”
Wert: kann selbst wieder strukturiert sein
1-32
Die Realität
Zuerst die schlechte Nachricht: das sieht alles
ziemlich kompliziert aus, und es ist es auch. Als
Socket-Programmierer muss man sich um diese
Dinge selbst kümmern.
Die gute Nachricht: die Aufgabe einer Middleware
ist es, genau diese komplizierten Mechanismen
automatisch zu erledigen. Der
Anwendungsprogrammierer sieht davon nichts
mehr.
Mehr dazu im nächsten Kapitel.
1-33
Middleware in Form verteilter Objektsysteme
Lokales Objektsystem
Rechner
Verteiltes Objektsystem
Prozess
Objekt
1-34
Das Objekt-Modell
System = Sammlung miteinander interagierender Objekte,
von denen jedes aus einer Menge von Daten und einer
Menge von Methoden besteht
Wichtige Begriffe:
Objektreferenz: die „Adresse“ eines Objekt
Schnittstellen: Definition der Zugangspunkte eines Objekts;
definiert durch die Signatur der Methoden
Aktionen: initiiert durch ein Objekt, das eine Methode eines
anderen Objekts aufruft; resultiert in der Zustandsänderung von
Objekten
Exceptions: eine Möglichkeit, Fehler in einem Programm auf
saubere Art und Weise zu behandeln
Garbage Collection: Freigabe nicht mehr benutzten Speichers
1-35
Das verteilte Objektmodell
Interagierende Objekte sind auf mehr als einen
Prozess verteilt
Begriffe:
Entfernte Objektreferenz: die Adresse eines Objekts im
ganzen verteilten System; muss eindeutig sein
Entfernte Schnittstellen: die Schnittstelle eines
entfernten Objekts, oft beschrieben in einer formalen
IDL (interface definition language)
Aktionen: Methodenaufrufe anderer Objekte können
Prozessgrenzen überschreiten
Exceptions: verteilte Ausführung des Systems erweitert
das Spektrum möglicher Fehler
1-36
Entfernte und lokale Methodenaufrufe
local
remote
invocation
A
B
C
E
invocation local
invocation
local
invocation
D
remote
invocation
Objekt
Rechner
Prozess
F
1-37
Schnittstellen entfernter Objekte
Die entfernte Schnittstelle gibt an, wie auf
entfernte Objekte zugegriffen wird.
Ihre Beschreibung enthält
Den Namen der Schnittstelle
Möglicherweise Datentypdefinitionen
Die Signatur aller entfernt verfügbaren Methoden,
bestehend aus
-
Dem Methodennamen
Ihrer Ein- und Ausgabeparameter
Ihrem Rückgabewert
Jede Middleware besitzt eine eigene Sprache, um
solche Schnittstellen zu beschreiben, die IDL.
1-38
Entferntes Objekt und Schnittstelle
remoteobject
remote
interface
{
Data
m1
m2
m3
implementation
of methods
m4
m5
m6
1-39
CORBA: Inhaltsübersicht
Was ist CORBA?
Einsatzgebiete von CORBA
Verteilte Objektsysteme
Architektur von CORBA
Kommunikation zwischen Objekten
CORBA IDL
Entwicklung von CORBA-Anwendungen
CORBA in Enterprise Applications
CORBA-fähige Tools
CORBA-Unterstützung in Java
1-40
Was ist CORBA?
CORBA = Common Object Request Broker
Architecture
Zunächst einmal eine Spezifikation, keine
Implementierung
erstellt von der OMG (Object Management Group,
http://www.omg.org), einem Konsortium von
zahlreichen Firmen und Organisationen
Ziel: Standard für verteilte Objektsysteme,
Interoperabilität versch. Implementierungen
1-41
Einsatzgebiete
Vollständige verteilte Systemimplementierungen
Service-Implementierungen, die von anderen
Anwendungen netzweit genutzt werden können
Erstellen von standardisierten Dienstschnittstellen
für Legacy-Anwendungen, z.B. R/3, DB2, Oracle
etc.
1-42
CORBA-Eigenschaften
CORBA erlaubt das Schreiben von Anwendungen,
die aus einer Sammlung
heterogener
verteilter
miteinander kooperierender Objekte
bestehen.
Heterogen bedeutet hier, die Objekte können
in versch. Programmiersprachen implementiert sein
unter versch. Betriebssystemen laufen
von unterschiedlichen Organisationen betreut werden
1-43
Architektur von CORBA
Common Horiz. And Vert. Facilities
Distrib.
Documents
Informat. Systems
Managem. Managem.
Application Objects
……..
Object Request Broker
Naming
Event
Service
Trader
Persistence
Common Object Services
Security
……..
1-44
Object Request Broker
Zentrale Komponente von CORBA
Hauptaufgabe:
ermöglicht die für die Anwendung transparente
Kommunikation von Objekten über das Netz
lokale und entfernte Methodenaufrufe sehen praktisch
identisch aus
ORB sucht das Objekt für den Aufrufer
Jeder Prozess mit CORBA-Objekten muss einen
ORB besitzen.
ORBs kommunizieren miteinander über das
standardisierte GIOP bzw. IIOP im Internet.
1-45
Realisierung des ORB
AO
AO
AO
ORB
ORB
GIOP/IIOP
ORB
ORB
AO
Dienst
Dienst
1-46
Application Objects
Dies sind die eigentlichen Anwendungsobjekte.
Sie werden vom Anwendungsentwickler
geschrieben.
AOs nutzen die ORBs, um miteinander zu
kommunizieren und um die verschiedenen
CORBA-Dienste zu anzusprechen.
Erstellung von AOs behandeln wir etwas später.
1-47
CORBA-Dienste und Facilities
CORBA definiert eine Reihe von Standarddiensten, die von
Anwendungen verwendet werden können.
Dadurch ergibt sich eine erhebliche Einsparung bei der
Anwendungsentwicklung.
Beispiele:
Persistence Service: erlaubt das Speichern und Laden von
Objekten auf nichtflüchtigem Speicher
Naming Service: Finden von Objekten aufgrund des Namens
Transaction Service: erlaubt das Durchführen von Transaktionen
(„alle Aktionen oder keine“)
Trader Service: „Gelbe Seiten“, Finden von AOs aufgrund von
Eigenschaften
Event Service: Entkopplung von Client und Server; asynchrone
Kommunikation
1-48
Kommunikation zwischen Objekten
Client X
ruft
Methode M von Y
auf
Objekt Y
Methode M
Object Request Broker (Core)
1-49
Virtuelle und tatsächliche Kommunikation
Objektreferenz
Client
Server
Skeleton
Stub
durch den ORB
durchgeführt
1-50
CORBA IDL
Die Implementierung von Objekten kann in verschiedenen
Sprachen erfolgen.
Die Schnittstelle muss jedoch auf standardisierte Weise
erfolgen, damit jeder Nutzer eines Objekts weiß, wie er es
ansprechen kann.
Zu diesem Zweck wird in CORBA die Interface Definition
Language (IDL) verwendet.
Sie erlaubt die Beschreibung der
Signaturen der Methoden eines Objekts sowie
evtl. dazu benötigter Datentypen
1-51
IDL Syntax
IDL-Beschreibung enthalten die folgenden
Elemente
Module: zusammengehörige Definitionen einer
Anwendung, Schlüsselwort module
Datentypen: Definition ähnlich wie in C
Schnittstelle eines oder mehrerer Objekte:
Schlüsselwort: interface
innerhalb einer Schnittstellenbeschreibung: Methoden
und Instanzvariablen, falls diese öffentlich sein sollen
1-52
Beispiel
module QueueApp {
struct PersonenInfo {
string firstname;
string lastname;
int age;
}
interface Queue {
boolean
enqueue(in PersonenInfo pi);
PersonenInfo dequeue();
boolean
isEmpty();
}
}
1-53
IDL Compiler
Großer Vorteil einer standardisierten formalen
Beschreibung einer Objektschnittstelle: sie ist
automatisch behandelbar!
Zum Beispiel lässt sich automatisch Code für eine
Programmiersprache ableiten.
Damit wird ein wesentlicher Schritt bei der
Umsetzung des Designs in eine Implementierung
automatisiert.
Es gibt heute für sehr viele Programmiersprachen
schon IDL-Compiler.
1-54
Ausgaben des IDL-Compilers
Ein typischer IDL-Compiler erzeugt
die Stubs und Skeletons
die leeren Prozeduren (die Köpfe) auf der Server-Seite
ein Serverprogramm, das Client-Anfragen entgegen
nimmt und die entsprechenden Prozeduren aufruft
ein einfaches Client-Programm zum Testen
Der Programmierer muss dann nur noch
die Prozedurrümpfe auf der Server-Seite ausfüllen
das Client-Programm entsprechend der gewünschten
Anwendung modifizieren
1-55
Gemeinsames Format
IDL-Compiler
IDL definition
translate IDL
into X
IDL-Compiler
translate IDL
into Y
communication?
Program in language X
translate message
into CDR
Program in language Y
translate message
into Y
Message in CDR format
Stub
Skeleton
1-56
IDL Stubs und Skeletons
Stubs und Skeletons werden aus der IDL
generiert.
Ein Stub ist die Verbindung zwischen Client und
ORB, ein Skeleton die zwischen Server und ORB.
Nach oben (Client bzw. Server) wird die
Schnittstelle des Objekts übersetzt in die
verwendete Programmiersprache angeboten.
Zum ORB hin wird eine Nachrichtenschnittstelle
angeboten.
Stubs und Skeletons übersetzen demnach das
eine Format in das andere.
1-57
Entwicklung von CORBA-Anwendungen
Client developer
Server developer
IDL
IDL
compiler
IDL
compiler
Sourcen
Client
ausführbare
Programme
Server
1-58
CORBA in Enterprise Applications
CORBA-Objekte können die
komplette Business-LogikEbene einnehmen.
Presentation-Implementierungen werden dann oft als
WWW-Anwendungen realisiert.
Häufige Variante: Servlets als
Front-End, die den Kontakt zu
den CORBA-Objekten
herstellen
Oft für Legacy-Anwendungen
Servlet
Servlet
Web Server
Object
Object
Object
CORBA Object Server
Später dazu mehr
1-59
JAVA RMI als Alternative: Grundlagen
Definiert ein Rahmenwerk für die Kommunikation
von Java-Objekten unabhängig von ihrem Ort
Eine reine Java-Lösung
Alle entfernten Objekte müssen ein entferntes
Interface besitzen
Es sind Werkzeuge vorhanden für die
Generierung von Stubs und Skeletons.
JDK stellt eine Implementierung des Naming
Service zur Verfügung, die RMIregistry.
Ein RMI-Dämon erlaubt einen flexible (ondemand)-Instanziierung von Objekten.
1-60
Schnittstellen-Definition
Schnittstellen werden definiert
Mit Hilfe des Java interface Konstrukts
Indem sie die Eigenschaften des Remote interface erben
Und indem sie RemoteExceptions auslösen können.
Ansonsten können alle Java-Typen verwendet werden.
Neue Klassen können definiert und als Parameter von
Methoden verwendet werden.
import java.rmi.*;
import java.util.Date;
public interface DateServer extends Remote {
public Date getDate() throws RemoteException;
}
1-61
Vergleich: CORBA vs. RMI
RMI ist eine reine Java-Variante, aber ähnlich zu
CORBA
+ Die Programmierung ist einfacher als bei CORBA
+ Komplexe Objekte können übergeben werden
− Nur für Java
Zusammenfassung:
Gute Alternative für reine Java-Lösungen
Die Übertragung von aktiven Objekten wird selten
genutzt (z.B. für mobile Agenten)
1-62
Web Services
Idee: Verbinde die Einfachheit von Java RMI mit
der Plattformunabhängigkeit von CORBA
Web Services:
WSDL (Dienstbeschreibung)
SOAP (Nachrichtenaustausch)
UDDI (Dienstverzeichnis)
Das Zusammenspiel dieser Technologien wird im
sog. „Web-Service-Rollenmodell“ beschrieben
1-63
Web-Service-Rollenmodell
WSD
Dienstregister
Finden
SOAP (über HTTP)
Veröffentlichen
WSDL
WSD
Dienstnutzer
Interagieren
Dienstanbieter
1-64
Warum XML?
„Verbindet alles mit
jedem!“
Web Services als
universelle MiddlewareTechnologie
Grundlage: XML
Daher: beseitigt Probleme mit
inkompatiblen Datentypen,
Zeichen-codierungen,
Byteorders usw.
Hinweis: Performance
schlechter als bei binären
Protokollen!
Vor allem deutlich höheres
Datenaufkommen!
1-65
Intuitiver Lösungsansatz: Textkompression
POST /axis/services/calculator HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.1
Host: localhost
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Accept-Encoding:
gzip
Content-Length: 348
Content-Encoding: gzip
<?xml version='1.0' ?>
‹<env:Envelope
[
xmlns:env="http://www.w3.org/2003/05/soap-envelope">
?鲠3̐
F©Ҩ¤+¡tʓ>nᄆ� ¤A yJ ȕª `ÑUº
[…]
<env:Body>
<res:reservationRequest
xmlns:res="http://sunshinecars.example.org/reservation">
[…]
</res:reservationRequest>
</env:Body>
</env:Envelope>
Ergebnis: marginale Verbesserung
120.000
SOAP
100.000
Datenaufkommen [Bytes]
1-66
Corba
80.000
RMI
SOAP (gzip)
60.000
40.000
20.000
0
1
5
10
15
20
25
30
35
40
Anzahl ausgetauschter Nachrichten (n)
45
50
1-67
Netzprogrammierung vs. Middleware
Direkte
Netzprogrammierung
Direkte Kontrolle aller
Transportparameter
größere Flexibilität bei der
Entwicklung neuer
Protokolle
Kann in vielen Fällen
bessere Performance
bringen
Grosses Problem:
Datenrepräsentation
Middleware
Sehr bequemer Weg zur
Entwicklung von
Anwendungen
Datenrepräsentation,
Objektlokalisierung etc.
muss nicht von der
Anwendung gemacht
werden
Oft viel Overhead
1-68
Diskussion