Systemarchitekturen für Verteilte Anwendungen. Implementierungsvarianten

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 Standard- Dienste (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,... Application protocols: HTTP, SMTP, FTP,... Applications Other user applications User space Application Programming Interface (API) IGMP RARP ICMP ARP TCP IP UDP RIP Transport OSPF Network OS kernel LAN DL technology WAN DL technology Data Link

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 Best effort -Dienst Keine Garantie für Auslieferung eines Pakets Korrekte Reihenfolge R2 yx R1 x yx yx DA,SA data Routing tables Router R1 DA Next hop y R3, R4...... R5 R3 yx R4 yx Router R3 DA Next hop y R6...... yx R6 y Router R6 DA Next hop y -......

1-8 IPv4-Adressen 32 bits Binäre und dezimale Darstellung 31 23 15 7 0 Binary: 1 1 0 1 0 1 0 0 0 1 1 1 1 1 1 0 1 1 0 1 0 0 0 0 1 0 0 0 0 1 1 1 Dotted decimal: 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 212. 126. 208. 135 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 client Internet address = 138.37.94.248 message other ports server Internet address = 138.37.88.249

1-14 Beispiel: Telnet-Server und Clients neptun.elc.ro 141.85.43.8 hugo.int.fr 139.29.100.11 zola.int.fr 139.29.35.18 port: 3135 HTTP client TCP IP HTTP connection telnet port: 80 TCP connection 141.85.43.8 : 3135, 139.29.100.11: 80 IP datagrams HTTP server TCP IP HTTP connection TCP connection 139.29.35.18 : 5768, 139.29.100.11: 80 IP datagrams port: 5768 HTTP client TCP IP

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 create UDP socket Server create UDP socket create datagram create datagram buffer send datagram receive datagram create datagram buffer create and send datagram receive datagram

1-18 Ein UDP-Client 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 EinServerSocket ist passiv und wartet nach dem Aufruf der accept-methode auf Verbindungsaufbauwünsche von Clients. EinSocket 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 create Stream socket Server create Server socket connect write data on stream wait for connection 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

1-28 Abbildung von Datenstrukturen auf Nachrichten 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 U 1

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 Programm in Sprache X Kommunikation? Programm in Sprache Y Kodiere Nachricht 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 65 12 61 This is the content Tag: Typ ID Länge der Daten 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 Verteiltes Objektsystem Rechner 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 A remote invocation B local C invocation local E invocation local invocation D remote invocation F Rechner Prozess Objekt

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 Data remote interface m1 { implementation m2 m3 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 Application Objects Distrib. Documents Informat. Managem. Systems Managem... Object Request Broker Naming Event Service Trader Persistence Security.. Common Object Services

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 GIOP/IIOP ORB 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 Stub Skeleton 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 IDL-Compiler translate IDL into X translate IDL into Y Program in language X communication? Program in language Y Stub translate message into CDR Message in CDR format translate message into Y 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 IDL compiler IDL Server developer IDL compiler Sourcen Client ausführbare Programme Server

1-58 CORBA in Enterprise Applications CORBA-Objekte können die komplette Business-Logik- Ebene 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 Später dazu mehr Servlet Servlet Web Server Object Object Object CORBA Object Server

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 desremote interface erben Und indem sieremoteexceptions 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 Finden SOAP (über HTTP) Veröffentlichen WSDL Interagieren Dienstregister Dienstnutzer Dienstanbieter WSD

1-64 Warum XML? Verbindet alles mit jedem! Web Services als universelle Middleware- Technologie 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: "" Content-Length: Accept-Encoding: 348 gzip Content-Encoding: gzip <?xml version='1.0'?> <env:envelope [ xmlns:env="http://www.w3.org/2003/05/soap-envelope">? <env:body> 鲠 3 F Ҩ + tʓ>nᄆ AyJ ȕª `ÑUº [ ] <res:reservationrequest xmlns:res="http://sunshinecars.example.org/reservation"> [ ] </res:reservationrequest> </env:body> </env:envelope>

1-66 Ergebnis: marginale Verbesserung 120.000 Datenaufkommen [Bytes] 100.000 80.000 60.000 40.000 SOAP Corba RMI SOAP (gzip) 20.000 0 1 5 10 15 20 25 30 35 40 45 50 Anzahl ausgetauschter Nachrichten (n)

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