Verteilte Systeme. Interprozesskommunikation Teil 2

Transkript

1 Verteilte Systeme Interprozesskommunikation Teil 2 1

2 Interprozesskommunikation Dieser Teil der Vorlesung Applikationen, Dienste RemoteMethodInvocation und RemoteProcedureCall Anforderung/Antwort-Protokoll (request-reply protocol) Marshalling und externe Datendarstellung Middlewareschichten UniversalDatagramProtocol und TransmissionControlProtocol 2

3 R emote entfernt, rechnerfern, entlegen Übersetzung R emote besser wäre: extern P rocedure Prozedur, Funktion, Verfahren M ethod Methode, Prozedur, Operation, Verfahren C all Aufruf, Anruf, Ruf I nvocation Anrufung, Beschwörung, Anfrage, Aufruf Entfernter Prozeduraufruf Entfernter Methodenaufruf 3

4 Verteiltes Objektsystem Lokal Entfernt Rechner Prozess Objekt Interaktion v e r s u s 4

5 Das Objektmodell System: Sammlung miteinander interagierender Objekte, von denen jedes aus einer Menge von Daten und einer Menge von Methoden besteht Wichtige Begriffe (Auswahl, vereinfacht): Objektreferenz: die Adresse /eindeutige Identität eines Objekt Schnittstellen: Definition der Zugangspunkte eines Objekts; definiert durch die Signatur der Methoden Ereignisse/Aktionen: initiiert durch ein Objekt, das eine Methode eines anderen Objekts aufruft; resultiert in der Zustandsänderung von Objekten oder/und weiteren Ereignissen/Aktionen Exceptions/Ausnahmen: eine Möglichkeit, Fehler in einem Programm auf saubere Art und Weise zu behandeln Garbage Collection: Freigabe nicht mehr benutzten Speichers 5

6 Das verteilte Objektmodell Verteiltes System: Interagierende Objekte sind auf mehr als einen Prozess verteilt Wichtige Begriffe (Auswahl, vereinfacht): Entfernte Objektreferenz: die Adresse /eindeutige Identität eines Objekts im ganzen verteilten System Entfernte Schnittstellen: die Schnittstelle eines entfernten Objekts (interface definition language, IDL) Ereignisse/Aktionen: Ereignisse/Aktionen von Objekten können Prozessgrenzen überschreiten Exceptions/Ausnahmen: verteilte Ausführung des Systems erweitert das Spektrum möglicher Fehler Garbage Collection: Freigabe nicht mehr benutzten Speichers wird im verteilten System schwieriger 6

7 Entfernte und lokale Methodenaufrufe entfernter Aufruf lokaler Aufruf lokaler Aufruf lokaler Aufruf entfernter Aufruf Jeder Prozess hat Objekte, einige, die entfernte Aufrufe erhalten können - entfernte Objekte genannt -, einige, die nur lokale Aufrufe erhalten können Objekte müssen die entfernte Objektreferenz eines Objektes in einem anderen Prozess kennen, um dessen Methoden aufrufen zu können. Wo bekommen sie diese Referenz her? Die entfernte Schnittstelle spezifiziert, welche Methoden entfernt aufgerufen werden können 7

8 Entfernte Objektreferenz Über Raum und Zeit garantiert eindeutig! Bestehen aus Internetadresse: gibt den Rechner an Port-Nummer und Zeit: Identifizieren eindeutig den Prozess Objektnummer: Identifiziert das Objekt Schnittstelle: beschreibt die entfernte Schnittstelle des Objekts Werden erzeugt von einem speziellen Modul - dem entfernten Referenzmodul - wenn eine lokale Referenz als Argument an einen anderen Prozess übergeben wird und in dem korrespondierenden Proxy gespeichert. 32 bits 32 bits 32 bits 32 bits Internetadresse Port-Nummer Zeit Objektnummer Schnittstelle des entfernten Objektes Achtung: Diese Art der Refernz erlaubt kein Verschieben des Objektes in einen anderen Prozess! 8

9 Schnittstellen entfernter Objekte Die entfernte Schnittstelle gibt an, wie auf entfernte Objekte zugegriffen wird (Signatur der Methodenmenge). 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. 9

10 CORBA hat Strukturen, Java hat Klassen Schnittstellen entfernter Objekte: Beispiel Corba IDL struct Person { string name; string place; long year; entfernte Schnittstelle } ; interface PersonList { Signatur: Definition readonly attribute string listname; void addperson(in Person p) ; der Methoden void getperson(in string name, out Person p); long number(); }; Parameter sind in, out oder inout entfernter Aufruf entfernte Schnittstelle m1 m2 m3 Daten Implementierung der Methoden m4 m5 m6 lokaler Aufruf 10

11 Entwurfsprobleme Lokale Aufrufe werden genau einmal ausgeführt. Dies kann für entfernte Aufrufe nicht immer der Fall sein. Was sind die Alternativen? Führt zur Definition einer Fehlersemantik Was ist der Transparenzgrad der entfernten Aufrufe? Was ist gegeben, was muß der Programmierer selber sicherstellen? 11

12 Aufrufsemantik Ein lokaler Aufruf wird genau einmal durchgeführt. Ein entfernter Aufruf erreicht diese Qualität zunächst nicht. Warum nicht? 1) Verlust der Auftragsnachricht 2) Verlust der Ergebnisnachricht 3) Ausfall des Servers 4) Ausfall des Clients Client 4) 2) 1) Server 3) 12

13 at least once Semantik at least once Semantik Fehlersemantik at most once Semantik at most once Semantik Timeout Client Request Server Timeout Client Request Server Liste der Requests Timeout Request Reply Bearbeitung des Requests Timeout Request Reply Bearbeitung des Requests; Request eintragen Timeout Request Reply Bearbeitung des Requests Ergebnis kann kann verschieden sein! sein! Timeout Request Reply Acknowledgement Liste der Requests überprüfen; Verwerfen des 2. Requests Request löschen 13

14 Fehlersemantik Fehlersemantik Fehlerfreier Ablauf Nachrichtenverluste Ausfall des Servers Maybe Ausführung: 1 Ausführung: 0/1 Ausführung: 0/1 Ergebnis: 1 Ergebnis: 0 Ergebnis: 0 At-least-once Ausführung: 1 Ausführung: >= 1 Ausführung: >=1 Ergebnis: 1 Ergebnis: >= 1 Ergebnis: >=1 At-most-once Ausführung: 1 Ausführung: 1 Ausführung: 0/1 Ergebnis: 1 Ergebnis: 1 Ergebnis: 0 Exactly-once Ausführung: 1 Ausführung: 1 Ausführung: 1 Ergebnis: 1 Ergebnis: 1 Ergebnis: 1 14

15 Transparenz Zugriffstransparenz ermöglicht den Zugriff auf lokale und entfernte Ressourcen unter Verwendung identischer Operationen. Ist realisiert: die Operationen sind identisch, die Syntax evtl. unterschiedlich. Positionstransparenz (Ortstransparenz) erlaubt den Zugriff auf die Ressourcen, ohne dass man ihre Position/ihren Ort kennen muss. Ist realisiert. Nebenläufigkeitstransparenz erlaubt, dass mehrere Prozesse gleichzeitig mit denselben gemeinsam genutzten Ressourcen arbeiten, ohne sich gegenseitig zu stören. Ist nicht realisiert. Replikationstransparenz erlaubt, dass mehrere Instanzen von Ressourcen verwendet werden, um die Zuverlässigkeit und die Leistung zu verbessern, ohne dass die Benutzer oder Applikationsprogrammierer wissen, dass Repliken verwendet werden. Ist manchmal realisiert. 15

16 Transparenz Fehlertransparenz erlaubt das Verbergen von Fehlern, so dass Benutzer und Applikationsprogrammierer ihre Aufgaben erledigen können, auch wenn Hardware- oder Softwarekomponenten ausgefallen sind. Ist teilweise realisert (siehe Fehlersemantik) Mobilitätstransparenz erlaubt das Verschieben von Ressourcen und Clients innerhalb eines Systems, ohne dass die Arbeit von Benutzern oder Programmen dadurch beeinträchtigt wird. Mittels Namensdienst realisiert. Leistungstransparenz erlaubt, dass das System neu konfiguriert wird, um die Leistung zu verbessern, wenn die Last variiert. Ist nicht realisiert. Skalierungstransparenz erlaubt, dass sich System und Applikationen vergrößern, ohne dass die Systemstruktur oder die Applikationsalgorithmen geändert werden müssen. Ist durch die Objektorientiertheit bereits gegeben. 16

17 Implementierung Kommunikationsmodul: zuständig für das Request-/Reply- Protokoll Entferntes Referenzmodul: Übersetzt zwischen entfernten und lokalen Objektreferenzen; besitzt meist eine entfernte Objekt-Tabelle, in der diese Zuordnung eingetragen wird. Beim ersten Aufruf wird die entfernte Objektreferenz von diesem Modul erzeugt. 17

18 Objekt A Client Proxy B Entferntes Referenzmodul Rolle von Proxy und Skeleton Proxy: Proxy: macht macht RMI RMI transparent für für Client. Client. Klasse Klasse implementiert entfernte Schnittstelle. Marshals Requestund und unmarshalsreply. Leitet Leitet Requestweiter. Request Reply Kommunikationsmodul Kommunikationsmodul Ausführung des des Request/Reply Protokolls Server Dispatcher B Skeleton B Objekt B Entferntes Referenzmodul Dispatcher: wählt wählt Methode im im Skeleton aus. aus. Übersetzung zwischen lokalen lokalen und und entfernten Objektreferenzen Skeleton: implementiert Methoden der der entfernten Schnittstelle. Unmarshals Request und und Marshals Reply. Reply. Ruft Ruft Methode in in entferntem Objekt Objekt auf. auf. 18

19 Verteilungstransparenz: Referenz- und Kopiersemantik Entfernte Methodenaufrufe sollten Parameterübergabe- Semantik der verwendeten Programmiersprache respektieren: In Java Übergabe von Werten per Kopie, Übergabe von Objekten per Referenz In C++ freie Wahl der Übergabeart Probleme: Entfernte Referenzen auf Werte prinzipiell nicht möglich Entfernte Referenzen auf Objekte nur möglich, wenn entsprechende Stubs und Skeletons existieren Empfänger benötigt Implementierungsklasse für erhaltenes Objekt (Kopiersemantik) bzw. Stub (Referenzsemantik) 19

20 Beispiel für Objektübergabe Betrachte folgende Objektklasse: import B; public interface A { extends Remote { public void setb(b b) throws Throwable; public B getb() throws Throwable;}} public class AServant extends UnicastRemoteObject implements A { private B b; public void setb(b b) { this.b = b; } public B getb() { return this.b; }} ASkeleton AServant B 20

21 Beispiel für Objektübergabe: Kopiersemantik 1. Clientobjekt hält Referenz auf Instanz von A, ruft darauf Methode getb() auf. 2. Stub übermittelt Methodenaufruf an Skeleton 3. Skeleton delegiert Methodenaufruf an Servant 4. Servant übergibt Referenz auf Instanz von B an Skeleton Klientenobjekt AStub "getb" ASkeleton AServant B Adressraum 1 Adressraum 2 21

22 Beispiel für Objektübergabe: Kopiersemantik 8. Stub übergibt Verweis auf neue Instanz an Aufrufer 7. Stub lädt Klasse B, dekodiert Zustand und erzeugt damit neue Instanz von B 6. Kodierter Zustand wird an Stub übertragen 5. Skeleton kodiert Zustand von Instanz gemäß Wire Protocol Klientenobjekt AStub codierter Zustand von B ASkeleton AServant B B Adressraum 1 B.jar Adressraum 2 22

23 Beispiel für Objektübergabe: Referenzsemantik 1. Clientobjekt hält Referenz auf Instanz von A, ruft darauf Methode getb() auf. 2. Stub übermittelt Methodenaufruf an Skeleton 3. Skeleton delegiert Methodenaufruf an Servant 4. Servant übergibt Referenz auf Instanz von B an Skeleton Klientenobjekt AStub "getb" ASkeleton AServant B Adressraum 1 Adressraum 2 23

24 Beispiel für Objektübergabe: Referenzsemantik 8. A-Stub übergibt Verweis auf B-Stub an Aufrufer 7. A-Stub erzeugt neuen B-Stub, der Netzwerkadresse von B-Skeleton enthält 6. A-Skeleton sendet Netzwerkadresse von B-Skeleton an A-Stub 5. A-Skeleton erzeugt neues Skeleton für B, falls nicht bereits vorhanden Klientenobjekt AStub (hostname, port) ASkeleton AServant BStub BSkeleton B Adressraum 1 B.jar Adressraum 2 24

25 Weitere Aspekte der Objektübergabe Festlegung der Übergabesemantik i.a. durch Typ des formalen Parameters: Referenzen und keine Referenzen sind zunächst alles Werte! Die Übergabesemantik regelt die Art der Interpretation. Referenzübergabe, wenn formaler Parameter bestimmtes Interface (in Java z.b. java.rmi.remote) implementiert Wertübergabe sonst Bei Wertübergabe Komplikationen möglich: Wenn übergebenes Objekt direkt oder indirekt andere Objekte referenziert, müssen diese ebenfalls übergeben werden (mit welcher Übergabesemantik?) Sharing von Objekten muss auf der Clientseite rekonstruiert werden Wenn übergebenes Objekt echter Untertyp des formalen Parameters ist, ist u.u. Upcast erforderlich 25

26 Implementierung RMI-Software: Softwareschicht zwischen Objekten und Kommunikations- und entfernten Referenzmodulen. Schnittstellen-Compiler erzeugt automatisch Klassen für Dispatcher, Skeleton und Proxy Server-Programm enthält Klassen für Dispatcher, Skeleton und alle davon unterstützten entfernten Objekte (Servant- Klassen) sowie einen Initialisierungsabschnitt Client-Programm enthält Klassen für Proxies aller entfernten Objekte. Factory-Methode: Ersetzen Konstruktoren in den entfernten Schnittstellen, d.h. sind normale Methoden, die entfernte Objekte erzeugen können. 26

27 Implementierung Binder: Namensdienst, der Clients Objektreferenzen vermitteln kann Server-Thread: Um zu verhindern, dass ein entfernter Aufruf einen anderen Aufruf verzögert, weisen Server der Ausführung jeden entfernten Aufrufs einen eignen Thread zu! Aktivierung: Erzeugung einer Instanz und initialisierung der Instanzvariablen. Persistenter Objektspeicher: Verwaltet persistente Objekte, also Objekte, die zwischen Aktivierungen weiterbestehen. Verteiltes garbage collection: Stellt sicher, dass in einem verteilten System garbage collection durchgeführt wird. Problem: Referenzen, die nur in Nachrichten vorhanden sind. 27

28 Beispiel: Java-RMI 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 eine entfernte Schnittstelle 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 (on-demand)- Instanziierung von Objekten. 28

29 Java-RMI: Schnittstellen-Definitionen Schnittstellen werden definiert Mit Hilfe des Java interface Konstrukts Indem sie die Eigenschaften der remote Schnittstelle 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. 29

30 Java-RMI: Das entfernte Objekt Um den von der Schnittstelle versprochenen Dienst zu erbringen, muss es ein entferntes Objekt geben, das die Methoden der Schnittstelle implementiert. Gewöhnlich erweitert es die Klasse UnicastRemoteObject was aus dem Objekt einen nichtreplizierten Server macht, der über TCP kommuniziert. Object Remote RemoteObject RemoteStub RemoteServer UnicastRemoteObject 30

31 Java-RMI: Der RMI-Compiler Basierend auf der Implementierung des Objekts mit seinen Methoden kann man nun automatisch Stubs und Skeletons implementieren. JDK stellt ein Werkzeug namens rmic für diesen Zweck zur Verfügung. Folgender Aufruf > rmic DatumImpl Erzeugt zwei Dateien: DatumImpl_Stub.class DatumImpl_Skel.class 31

32 Java-RMI: Die RMI-Registry Die RMI-Registry, implementiert durch das Programm rmiregistry, ist der Namensdienst für Java RMI. Server registrieren entfernte Objekte unter einem Namen. Clients fragen die Datenbank ab, um die Referenz für einen entfernten Dienst zu erhalten. Namensdienste behandeln wir noch ausführlich. 32

33 Java-RMI: Die Klasse Naming void rebind (String name, Remote obj) This method is used by a server to register the identifier of a remote object by name. void bind (String name, Remote obj) This method can alternatively be used by a server to register a remote object by name, but if the name is already bound to a remote object reference an exception is thrown. void unbind (String name, Remote obj) This method removes a binding. Remote lookup(string name) This method is used by clients to look up a remote object by name. A remote object reference is returned. String [] list() This method returns an array of Strings containing the names bound in the registry. //ComputerName:Port/ObjectName This is the name used in the namingservice 33

34 Java-RMI: Erzeugen einer Anwendung 1. Definiere die entfente Schnittstelle 2. Implementiere die entfernte Schnittstelle durch ein entferntes Objekt 3. Generiere Stubs und Skeletons mit rmic 4. Schreibe einen Client 5. Starte den Namensdienst mit rmiregistry 6. Starte den Server 7. Starte den Client 34

35 Beispiel: Datumsabfrage Das Beispiel implementiert einen RMI-Server, der das aktuelle Datum seiner Maschine zurückgibt. Wir müssen selbst die folgenden Dateien schreiben: Datum.java die Schnittstelle DatumImpl.java das entfernte Objekt DateServer.java der Server DateClient.java der Client 35

36 Beispiel: Datumsabfrage Suffix kein (z.b. Datum) Impl (z.b. DatumImpl) Server (z.b. DatumServer) Client (z.b. DatumClient) _Stub (z.b. DatumImpl_Stub) _Skel (z.b. DatumImpl_Skel) Bedeutung Eine entfernte Schnittstelle Eine Serverklasse, die diese Schnittstelle implementiert Ein Serverprogramm, das Serverobjekte erzeugt Ein Clientprogramm, das entfernte Methoden aufruft Eine Stub-Klasse, automatisch mit rmic erzeugt Eine Skel-Klasse, automatisch mit rmic erzeugt (nur für < JDK 1.1) 36

37 Beispiel: Datum.java import java.rmi.*; import java.util.date; interface Datum extends Remote { public Date getdate() throws java.rmi.remoteexception; } Verwendet von Client und Server Muss sich auf dem Clientrechner und dem Serverrechner befinden! 37

38 import java.rmi.*; import java.rmi.server.*; import java.util.date; Beispiel: DatumImpl.java class DatumImpl extends UnicastRemoteObject implements Datum { public DatumImpl() throws RemoteException { super(); } public Date getdate() throws java.rmi.remoteexception { return new Date(); } } Implementiert die entfernten Objekte Muss sich auch nur auf dem Serverrechner befinden! Mittels rmic DatumImpl werden Stub und Skeleton erzeugt 38

39 Beispiel: DatumServer.java import java.rmi.*; import java.rmi.server.*; import java.util.date; public class DatumServer { public static void main(string[] args) { try { DatumImpl dateserver = new DatumImpl(); Naming.bind("DateServer", dateserver); } catch (Exception e) { System.out.println("DatumServer: Exception:"); System.out.println(e.getMessage()); } } } Implementiert die Serverfunktionalität (z.b. Erzeugen der Objekte) Muss sich auch nur auf dem Serverrechner befinden! 39

40 import java.rmi.*; import java.util.date; public class DatumClient { Beispiel: DateClient.java public static void main(string[] args) { try { Datum dateserver = (Datum) Naming.lookup("//:1099/DateServer"); Date when = dateserver.getdate(); System.out.println(when); } catch (Exception e) { System.out.println("DatumClient: Exception."); System.out.println(e.getMessage()); } } } Adresse der RMIRegistry Implementiert den Client Muss sich auch nur auf dem Clientrechner befinden! 40

41 Java-RMI: Automatische Objektaktivierung In großen Systemen mit Tausenden von Objekten ist es unrealistisch, immer alle Objekte im Speicher aktiv zu haben. Mit Hilfe des Java-Aktivierungsmechanismus können Objekte persistent gemacht und erst bei Bedarf wieder instanziiert werden. Dieses Objektmanagement wird durch den Dämon rmid realisiert. Jini basiert weitgehend auf diesem Aktivierungsmechanismus. 41

42 Middleware Applikationen, Dienste Middleware Verteilungsplattform: Transparenz der Heterogenität existierender Hardware und Betriebssysteme Verteilung Betriebssystem Plattform Computer- und Netzwerkhardware 42

43 Definition von Middleware "Middleware is the intersection of the stuff that network engineers don't want to do with the stuff that applications developers don't want to do. "Middleware today encompasses everything to the right of the clients and to the left of the legacy systems. It resides above the OS and below the application logic. "Middleware: the slash in client / server. some think of the Web as the ultimate in middleware. 43

44 Arten von Middleware Generisch Object Request Broker Objektzugriff übers Netz Remote Procedure Call (RPC) Aufruf einer entfernten Prozedur Message Passing Send/Receive Kommunikation Virtual Shared Memory Zugriff auf virtuell gemeinsamen Speicher Speziell Dateitransfer Fernzugriff auf gemeinsame Dateien Datenbankzugriff Datenzugriff auf entfernte DB Transaktionsverarbeitung Koordination verteilter Transaktionen Groupware Zusammenarbeit verteilter Gruppen Workflow Organisation arbeitsteiliger Prozesse 44

45 Standardisierung von Middleware (Offizielle) Internationale Standardisierung ISO International Standardisation Organisation ITU International Telecommunication Union DIN, ANSI, BSI, AFNOR,... Semi-offizielle Internationale Standardisierung OpenGroup (früher X/OPEN bzw. OSF) IEEE Institute of Electrical and Electronic Engineers IETF Internet Engineering Taskforce W3C World Wide Web Consortium Konsortien OSF Open Software Foundation (heute: OpenGroup) OMG Object Management Group "Industriestandards" 45

46 Object Management Group (OMG) Gründung: April 1989 Ziele: Interoperabilität Anwendungsintegration Portabilität in heterogenen Umgebungen auf der Basis des Objektmodells Mitglieder: über 800 Mitglieder darunter: Apple, AT&T, DEC, HP, IBM, Microsoft, SUN,... Distributed Component Object Model (DCOM) Entwicklungsprozeß: Request for Proposal (RFP) 46

47 Object Management Architecture (OMA) Application Objects ORB Common Facilities Common Object Services Application Objects spezifische Anwendungsgebiete gehören nicht zur Infrastruktur Common Facilities allgemein nützliche Dienste (Drucken, , Datenbanken) nicht notw. Teil aller Infrastrukturen Object Request Broker (Objektbus) Infrastruktur für Kommunikation garantiert Interoperabilität Common Object Services allg. Funktionen zum Erstellen u. Unterhalten von Objekten 47

48 Application Objects: z.b. Business-Objekte Application Objects ORB Common Facilities Andere Schnittstellen Präsentations- Objekt Business- Prozeß- Objekt Komponenten eines Business- Objektes Business- Objekt MVC Andere Business-Objekte Dokument Server Business-Objekte (M, Server) Common Object Services kapseln Speicher, Metadaten, Parallelität u. Regeln einer aktiven Business-Einheit legt fest, wie auf Änderungen in View/Modell reagiert wird Business-Prozeßobjekte (C, Server) kapseln Business-Logik Verwaltung vorwiegend langlebiger Prozesse (Workflow, Transaktion) Präsentationsobjekte (V, Client) grafische Darstellung des Objektes unterschiedliche Präsentationen möglich 48

49 GIOP und IIOP Mit CORBA 2.0 wurde GIOP = General Inter-Orb Protocol als netzwerkunabhängiges Wire Protocol spezifiziert Die (meist verwendete) TCP/IP-Variante heißt IIOP = Internet Inter-Orb Protocol GIOP spezifiziert Nachrichtentypen (Requests, Resultate, Ping,...) Datenaustauschformat ("Common Data Representation") Interoperable Objektreferenzen (IORs) Service-Kontexte (Request-Anhängsel, mit denen Dienste transparent Informationen übermitteln können) 49

50 CORBA Interoperabilität Stub Systemgrenze Skeleton A (Client) A B B (Server) ORB von A ORB IIOP ORB von B 50

51 CORBA Objekte Client Request Result Schnittstelle Op1 Op2 Op3 Op4 Objekt Objekt besteht aus Zustand und Operationen Schnittstelle beschreibt Menge von Operationen für die Clients Operation entspricht angebotenem Service und hat Signatur Signatur ist eine Spezifikation von Argument- und Ergebnisparametern, Exceptions, Kontext Vererbung kann benutzt werden, um neue Schnittstellen aus anderen Schnittstellen zusammenzusetzen kann überall im Netz existieren 51

52 Interface Definition Language Ada IDL Basismechanismus zur Definition von Schnittstellen (Standard) C C++ COBOL IDL IDL IDL Client/Server ORB Unabhängig von spezieller Sprache (deklarativ, d.h. ohne algorithmische Teile, d.h. ohne Implementierungsdetails) Sprachbindung für verschiedene Sprachen IDL-Grammatik ist Teilmenge von C++; zusätzlich Mittel für Verteilungskonzepte Beinhaltet Mehrfachvererbung Java IDL Schnittstellenverzeichnis (Interface Repository), damit selbstbeschreibend Smalltalk IDL IDL ist Kontrakt, der alle und alles zusammenbringt 52

53 Struktur einer CORBA-IDL-Datei module <identifier> { <type declarations>; <constant declarations>; <exception declaration>; interface <identifier> [:<inheritance>] { <type declarations>; <constant declarations>; <attribute declarations>; <exception declaration>; [op_type]<identifiere>(<parameters>) [raises exception][context];... [op_type]<identifiere>(<parameters>) [raises exception][context];... } interface <identifier> [:<inheritance>]...} Definiert einen Namenskontext Definiert eine CORBA-Klasse Definiert eine Methode 53

54 Struktur eines CORBA-2.*-ORB s I Implementation Repository Object Implementation Client Interface Repository Object Adapter Static Skeletons Dynamic Skeleton Invocation ORB Interface Client IDL Stubs Dynamic Invocation Object Request Broker Core (IIOP) 54

55 Aufbau eines CORBA-Servers Applikationscode aktive Servants Hauptprogramm main (String args[]) { ORB main orb (String args[]) { = ORB.init(args); orb orb.connect = ORB.init(args); ( new orb.connect AServant() ( ); new AServant() orb.connect( ); new orb.connect( BServant() ); new BServant() orb.run(); } orb.run(); } Servant Activator ii Default Servant statisch (mit Skeleton)... dynamisch (ohne Skeleton) ORB- Schnittstelle n... Servant Default Active Object Fabrik für Activator Servant Map Objektreferenzen Portable Object Adapter Event Loop Marshalling Engine Request Interceptors für verschiedene Services (optional) ORB-Kern Netzwerk 55

56 Struktur eines CORBA-2.*-ORB s: Client IDL-Stub s (Client) Schnittstelle zu Objektdiensten (Proxy) Generierung durch IDL-Compiler Enthält Code für De-/Kodierung der Operationen u. Partameter Enthält Header-Dateien für Hochsprachen Dynamic Invocation Interface (DII) Finden von aufrufbaren Methoden zur Laufzeit Standard API s für Suche in Metadaten, Parametergenerierung, Remote-Aufruf Interface Repository API Lesen u. Modifizieren von allen (registrierten) Komponentenschnittstellen dynamische Metadatenbank für ORB s ORB Interface API-FUnktionen für lokale Dienste z.b. Konvertierung Objektreferenz in Zeichenkette u. zurück 56

57 Struktur eines CORBA-2.*-ORB s: Server IDL-Stubs (Server) statische Schnittstelle (Skeletons) der angebotenen Dienste werden vom IDL Compiler erzeugt Dynamic Skeleton Interface (DSI) Laufzeit-Verknüpfungsmechanismus für Methodenaufrufe von Komponenten, die keine IDL-basierte Stubs haben z.b. für generische Bridges zwischen verschiedenen ORB s z.b. dynamische Objektimplementierung Object Adapter Laufzeitumgebung für Instanzen von Server-Objekten übergibt ihnen die Anfragen und weist ihnen Objekt-ID s (Objektreferenzen) zu registriert unterstützte Klassen u. Laufzeitinstanzen im Implementation Repository Standard Adapter: Portable Object Adapter (POA), ehemals Basic Object Adapter (BOA) Implementation Repository Laufzeitverzeichnis über unterstützte Klassen, Objektinstanzen, Objekt-ID s (gemeinsamer) Speicher für zusätzliche Informationen, z.b. Prüfprotokolle, Sicherheit, Trace-Informationen 57

58 Methodenaufruf über CORBA Client Anwendung 1) Aufruf IDL Stub 2) Parameter einpacken und Aufruf weiterleiten Objekt Implementierung 5) Auspacken und Aufruf IDL Skeletton 4) Weiterleiten an Schnittstelle Object Adapter 4b) Aktivieren Implementation Repository 4a) Ermitteln der Implementierung Object Request Broker Core 3)Transport über den ORB 58

59 Client- und serverseitige IDL-Implementierung Schnittstellendesigner Anwendungsentwickler interfaces.idl Programmierer IDL-Java Compiler IDL-C++ Compiler client.jar stubs.jar types.hh stubs.cc skels.cc servants.cc Client Server 59

60 Von der IDL zu Schnittstellen-Stubs I 1 Schreibe Deine IDL Definitionen 2 Precompiler 5 Interface Repository Client IDL Stubs Skeletons Füge dem Skeleton den Server Implementierungscode zu 4 Compiler Server IDL Skeletons 3 Instanziiere Objekt Implementierung 7 6 Objekt Adapter Implementation Repository Client Server 60

61 Von der IDL zu Schnittstellen-Stubs II 6 Definiere die Objektklassen mit Hilfe der IDL: 1 Welche Operationen eines Objektes sind verfügbar und wie werden sie aufgerufen? Lasse die IDL-Datei durch einen Sprachen-Precompiler laufen: Generierung der IDL-Dateien und der Sprach-Skeletons. Füge dem Skeleton den Implementierungscode zu: Erzeugung der Server-Klassen. Kompiliere den Code: 4 Importdateien für Schnittstellenverzeichnis, Client-Stubs und Server-Skeletons Binde die Klassendefinitionen mit den Schnittstellenverzeichnissen Lasse die Laufzeitobjekte im Implementierungsverzeichnis registrieren Erzeuge für die Objekte auf dem Server Instanzen Im folgenden wird ein einfaches Beispiel unter JDK gezeigt. 61

62 Definiert den Namenskontext Definiert die Methoden einzahlen und abfragen Schritt 1: Bank1.idl module Bank1 { }; interface IKonto1 { }; double einzahlen (in double betrag); double abfragen (); Definiert die CORBA-Klasse IKonto1 62

63 Schritt 2: IDL-Compiler Zuordnung Referenz --Klasse Klasse Verwaltung out/inout-argumente Schnittstelle ohne ohne Vererbungshierarchie (Tie) (Tie) Von dem Compiler idlj erzeugt 63

64 Schritt 2: IDL-Compiler ab dem JDK 1.3 ist der IDL-Compiler idlj enthalten. Hier JDK Grundsätzlich sind (auf der Seite des Servers) zwei Modelle vorgesehen: Inheritance Model (Klassen-Vererbung) Tie Delegation Model (Schnittstellen-Vererbung) Da Java keine mehrfache Klassenvererbung erlaubt, kann es bei vorhandenem Code nötig sein, dieses Modell zu wählen. Parameter -oldimplbase: Existiert aus Gründen der Kompatibilität zu älteren Versionen. Vererbungsstruktur wie folgt: IKonto1Impl _IKonto1ImplBase IKonto1 CORBA.Object Parameter -oldimplbase: Die Tie-Anbindung des Servants ermöglicht die Implementation über die Schnittstelle _IKonto1Operations, die in keine Vererbungshierarchie eingebunden ist. 64

65 Schritt 3: Implementierung IKonto1Impl.java import Bank1.*; public class IKonto1Impl extends _IKonto1ImplBase { double kontostand; public static boolean debug = true; public void IKontoImpl () { kontostand = 0.0; } public double einzahlen (double betrag) { double k = kontostand; k += betrag; return kontostand = k; } public double abfragen () { double k = kontostand; return kontostand = k; } } 65

66 Schritt 3: Implementierung SunServer.java import java.io.*; import java.util.*; import org.omg.corba.*; import org.omg.cosnaming.*; //Importiere Server-Skeleton import Bank1.*; public class ServerSun { public static void main (String args[]) { try { Properties props = new Properties(); props.put("org.omg.corba.orbinitialport", "1050"); props.put("org.omg.corba.orbinitialhost", "localhost"); ORB orb = ORB.init (args, props); // NamingContext besorgen NamingContextExt ctx = // Weiter auf nächster Folie NamingContextExtHelper.narrow( orb.resolve_initial_references("nameservice")); 66

67 Schritt 3: Implementierung SunServer.java // Neue Instanz der Implementierung IKonto1Impl konto = new IKonto1Impl (); // Namen für neue Instanz vergeben und // Referenz beim Namingservice anmelden NameComponent name[] = ctx.to_name("konto"); ctx.rebind(name, konto); // Do nothing and run... java.lang.object sync = new java.lang.object (); synchronized (sync) { try { sync.wait(); } catch (InterruptedException e) { System.out.println (e); } } } catch (Exception ex) { System.err.println (ex); System.exit (1); } } } 67

68 Schritt 3: Client.java import java.io.*; import java.util.*; import org.omg.corba.*; import org.omg.cosnaming.*; //Importiere den Client-Stub import Bank1.*; public class Client { public static void demo (IKonto1 konto) { System.out.println ("Kontostand alt " + konto.abfragen()); System.out.println ("Kontostand " + konto.einzahlen(50.0)); } // Weiter auf nächtser Folie 68

69 Schritt 3: Client.java public static void main (String args[]) { try {Properties props = new Properties(); props.put("org.omg.corba.orbinitialport", "1050"); props.put("org.omg.corba.orbinitialhost", "localhost"); ORB orb = ORB.init(args, props); // NamingContext besorgen NamingContextExt nc = NamingContextExtHelper.narrow( orb.resolve_initial_references("nameservice")); // Objektreferenz mit Namen "Konto" besorgen org.omg.corba.object obj = nc.resolve_str("konto"); // Narrow-Cast und aufrufen IKonto1 konto = IKonto1Helper.narrow (obj); demo(konto); } catch (Exception ex) { System.err.println (ex); System.exit(1); } } } 69

70 Abschluss: Starten des Servers Der CORBA-Namingservice wird gestartet mit orbd Mit Hilfe des Parameters ORBInitialPort kann der Port für den Service vorgegeben werden. 70

71 Abschluss: Starten des Clients 71

72 Prozeß eines dynamischen Aufrufs Name der Schnittstelle verschaffen: get_interface() Methodenbeschreibung verschaffen: lookup_name(); describe(); Argumentenliste erzeugen: create_list(); add_item()... add_item()... add_item(); Anfrage erzeugen: create_request(object Reference, Method, Argument List); Entfernte Objektmethode aufrufen: RPC verwenden: invoke(); Send/Receive: send_deferred(); get_response(); Datagramm: send_oneway(); 72

73 CORBA 3.0 Messaging (MOM) (asynchroner Methodenaufruf) Server Portability (Portable Object Adapter & Server Framework Adapter) Multiple Interface & Versioning Business Objects Framework (BOF) Java Bindings Pass-by-value Mobile Agents CORBA Components (CCM) Real Time CORBA CORBA Firewall Minimum CORBA ( CORBA für eingebettete Systeme ) 73

74 Idee: Komponenten Komponente = höhere Abstraktionsform von Objekten Bestehen aus einem oder mehreren Objekten, welche in einen Container gepackt werden Komponenten interagieren u. kooperieren über verschiedene BSplattformen, Sprachen, etc. hinweg Bausteine für multitiered Anwendungen Anwendungen bestehen aus (dynamischen) Mengen interagierender Komponenten (monolithische Anwendungen aufbrechen) Dieses Modell hat enorme Konsequenzen bzgl. Entwurf von Software ( Lego-Bausteine ) Vertrieb von Software ( add-on Komponenten, late customizing ) Pflege von Software (Wiederverwendung, Varianten) Funktionalität (aktive, ggf. mobile Objekte) Marketing (Komponenten-Markt) Erfordert Standards und Infrastrukturservices für die Interaktion der Komponenten für die Komponenten selbst (Versionskontrolle, Konfiguration) 74

75 Motivation Häufigkeit der Wiederverwendung Klassen Framework Komponente Vorfabrizierte Anwendung Einsparung 75

76 J2EE Komponentenplattform Die Java 2 Enterprise Edition (J2EE) ist eine Plattform für die komponentenorientierte Entwicklung von Anwendungen. Sie besteht aus: Einer Spezifikation / Guidelines / Testsuite Java Komponenten Java Beans (clientseitig) Java Server Pages und Servlets Enterprise Java Beans (serverseitig) Verschiedene Container: Application, Web, EJB Java Naming and Directory Interface (JNDI) 76

77 EJB Introduction An Enterprise JavaBeans (EJB ) component, or enterprise bean, is a body of code having fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the J2EE server. (J2EE Tutorial: EJB 2.0 ist Bestandteil der J2EE 1.4 Spezifikation EJB 3.0 wird Bestandteil der J2EE 5.0 Spezifikation EJB Container bildet die Laufzeitumgebung (Runtime Environment) 77

78 EJB / J2EE Architektur 78

79 EJB Container Manages the execution of enterprise beans for J2EE applications. Enterprise beans and their container run on the J2EE server. (J2EE Tutorial: Bietet folgende Dienste für EJBs Security Modelle Unterstützung für Transaktionen Naming Services (JNDI registry & lookup) Initiiert und kontrolliert den Lebenszyklus der Beans Datenpersistenz Datenbankverbindungen Ressourcen-Pooling 79

80 EJB Einsatz (Deployment) Enterprise JAR Archiv enthält: Deployment Descriptor: XML file (persistence type, transaction attributes ) Interfaces (Remote und Home Interfaces für den Komponentenzugriff) EJB classes (Implementierungen der Interfaces) Helper classes ( was man sonst braucht) EJB-JAR Module können zusammengefasst werden in einem Enterprise Application Archive (EAR). Siehe für Details über deployment descriptors. 80

81 EJB-JAR.XML <ejb-jar> <display-name> MailApplicationEJB </display-name> <enterprise-beans> <session> <ejb-name> MailReader </ejb-name> <home>...mailreadersessionhome </home> <remote>...mailreadersession </remote> <ejb-class>...mailreadersessionbean </ejb-class> <session-type> Stateful </session-type> <transaction-type> Container </transaction-type> </session> </enterprise-beans> </ejb-jar> 81

82 EJB Typen Session Bean wird für einen einzelnen Client ausgeführt An die Lebenszeit einer Session gebunden Entity Bean repräsentiert objektorientierte Sicht auf Daten (z.b. aus einer Datenbank) Kann von mehreren Clients gleichzeitig angesprochen werden Überdauert Client Session und Serverneustarts. Message-Driven Bean reagiert auf JMS 1 Nachrichten zustandslos, kommuniziert asynchron 1 Java Message Service

83 Session Beans Session Bean Eigenschaften: Verbergen Komplexität der Business Logic Nicht persistent Repräsentieren eine (interaktive) Session für einen Client Können nicht zwischen Clients geteilt werden Beenden mit dem Client Session Bean Modi: Stateless Session Beans: Variablenzustände leben nur während Methodenaufrufen Stateful Session Beans: Variablenzustände bestehen während der Clientsitzung 83

84 Entity Beans Entity Bean Eigenschaften: Erlauben geteilten Zugriff auf persistente Datenspeicher (z.b. relationale Datenbank) Können auch transiente Attribute besitzen Besitzen unique object identifier (primary key) Können in Relation zu anderen Entity Beans stehen Persistenzarten: Bean-managed: Bean verwaltet Zustände selbst, z.b. DB-Zugriffe Container-managed: Container organisiert Datenzugriff (Portabilität!), hierzu EJB Query language (EJB QL) 84

85 Message-Driven Beans Message-Driven Bean Eigenschaften: Asynchrone Prozessierung eingehender Messages Empfängt JMS Messages von Clients Verarbeitet Messages einzeln. Wird asynchron erzeugt Lebt gewöhnlich nur kurz. Repräsentiert keine persistenten Daten (zustandslos), kann aber auf persistente Daten zugreifen. Kann transaktionsorientiert arbeiten. Message-Driven Beans haben keine eigenen Interface Definitionen, werden also nicht direkt von Clients angesprochen 85

86 Lebenszyklus von EJBs Stateful Session Bean Stateless Session Bean Entity Bean Message-Driven Bean 86

87 Zugriff auf Beans Remote Zugriff Ort des Beans ist für den Client transparent Zugriff über JVMs hinweg möglich Zu implementierende Schnittstellen: Home Interface Remote Interface Lokaler Zugriff Ort des Beans ist für den Client nicht transparent Bean und Client müssen in der gleichen JVM liegen Zu implementierende Schnittstellen: LocalHome Interface Local Interface 87

88 Remote Interface (Session-, Entity-Beans) Namenskonvention: classname Erweitert EJBObject Interface Beschreibt die Schnittstellen der Anwendungslogik (Business logic) des Beans Beispiel: public interface MailReaderSession extends EJBObject { } public String getversion() throws RemoteException; public String getusername() throws RemoteException; // mehr Business Logic... 88

89 Home Interface (Session-, Entity-Beans) Namenskonvention: classnamehome Erweitert EJBHome Interface LifeCylce Methoden (create, remove) Finder Methoden (Entity Beans) Das Bean muss für jede create( )-Methode des Interfaces eine entsprechende ejbcreate( )-Methode implementieren Beispiel: public interface MailReaderSessionHome extends EJBHome { public MailReaderSession create() throws RemoteException, CreateException; // evt. weitere create( ) Methoden } 89

90 Local Interface Namenskonvention: classnamelocal Erweitert EJBLocalObject Beschreibt die Schnittstellen der Anwendungslogik (Business logic) des Beans Beispiel: public interface MailReaderSessionLocal extends EJBLocalObject { public String getversion() throws RemoteException; public String getusername() throws RemoteException; // mehr Business Logic... } 90

91 LocalHome Interface Namenskonvention: classnamelocalhome Erweitert EJBLocalHome Interface LifeCylce Methoden (create, remove) Finder Methoden (Entity Beans) Das Bean muss für jede create( )-Methode des Interfaces eine entsprechende ejbcreate( )-Methode implementieren Beispiel: public interface MailReaderSessionLocalHome extends EJBLocalHome { } public MailReaderSession create() throws RemoteException, CreateException; // evt. weitere create( ) Methoden o. find... Methoden 91

92 (Enterprise) Bean Klasse Namenskonvention: classname Implementiert SessionBean, EntityBean oder MessageDrivenBean Konkrete Implementierung der Schnittstellen des Home- und des Remote- Interfaces Enthält Methoden die während des Bean Lifecycles vom EJB Kontainer aufgerufen werden (abhängig vom Typ des Beans) z.b.: ejbcreate (analog zu den create( )-Methoden des Home Interfaces) ejbactivate() ejbpassivate() 92

93 Bean Implementierung (SessionBean, Stateful) public class MailReaderSessionBean implements SessionBean { private String username = null; private String password = null; public void ejbcreate() throws CreateException{ } public void ejbcreate(string login, String password) throws CreateException { this.username = login; this.password = password; } public void setsessioncontext(sessioncontext context) throws EJBException, RemoteException { } public void ejbremove() throws EJBException, RemoteException { } public void ejbactivate() throws EJBException, RemoteException { } public void ejbpassivate() throws EJBException, RemoteException { } } public String getversion() { return "Version 0.1"; } public String getusername() { return this.username; } 93

94 import java.util.hashtable; import javax.naming.context; import javax.naming.initialcontext; import javax.naming.namingexception; import javax.rmi.portableremoteobject; Bean Client import sample.mailapp.beans.mailreadersession; import sample.mailapp.beans.mailreadersessionhome; public class MailCient { public static void main(string[] args) { String version = "no version"; InitialContext jndicontext = null; try { jndicontext = new InitialContext(); // initial context properties are read from the jndi.properties file } catch (NamingException e) { e.printstacktrace(); } continue on next slide 94

95 Bean Client (cont.) // Retrieve the home object. MailReaderSession mailsession = null; try { Object obj = jndicontext.lookup("mailreader"); MailReaderSessionHome home = (MailReaderSessionHome) PortableRemoteObject.narrow(obj, MailReaderSessionHome.class); mailsession = home.create("me","123"); version = mailsession.getversion(); } System.out.println("Is vesion (" + version + ")"); System.out.println("User ("+ mailsession.getusername()+")"); } catch (Exception e1) { e1.printstacktrace(); } 95

96 Message Driven Beans Im Gegensatz zu Entity o. Sessions Beans keine Local, Home o. Remote Interfaces Werden an eine Message-Queue des EJB Kontainers gebunden Muss MessageListener Interface implementieren (onmessage(message amessage) Methode behandelt eingehende Nachrichten) Jeweils genau eine ejbcreate und ejbremove Methode 96

97 Web Services Grundidee: unvereinbare Welten miteinander zu verknüpfen und kommunizieren lassen. Web Services sind Dienste (Softwarekomponenten), die im Web zur Verfügung stehen und miteinander kommunizieren. Offene und Hersteller unabhängige Standards: Eindeutige Identifizierung eines Dienstes (URI) Autonome Dienste, d.h. die Verarbeitung einer Nachricht eines Dienstes kann von außen nicht beeinflusst werden. Einheitliche mark up Sprache für die Kommunikation (XML) mittels Internetprotokollen (z.b. HTTP, SMTP) Einheitliches Nachrichtenformat zum Informationsaustausch (SOAP) Einheitliches Format für die Schnittstellen-/Servicebeschreibung (WSDL) Gemeinsames Verzeichnis, um Services auffindbar zu machen (UDDI) 97

98 Begriffe Web Service Universal Description Discovery and Integration Web Service Description Language Simple Object Access Protocol UDDI XML WSDL XML SOAP 1. Namensdienst (optional) 2. Schnittstellen definitionssprache (optional) 3. Nachrichtenformat XML 98

99 Rollen 99

100 Struktur eines Web Service 100

101 SOAP SOAP Envelope (XML): strukturiertes und typisiertes XML-Dokument, zusätzliche Kontroll-Daten, z.b. bzgl. Transaktionssemantik, Sicherheit, Zuverlässigkeit SOAP Transport Binding: Für Kommunikation genutztes Netzwerkprotokoll (Standard: HTTP, möglich u.a. IIOP) SOAP Encoding Rules: Definition, wie (komplexe) Parameter und Ergebniswerte serialisiert werden SOAP RPC Mechanismus: Vorgänger ist XML/RPC SOAP Intermediaries: Bearbeiten ggf. die Nachricht auf dem Weg vom Sender zum Empfänger (z.b. Protokollierung, Abrechnung) 101

102 Typische SOAP Transaktion: RPC via HTTP 102

103 SOAP über HTTP: Anfrage 103

104 SOAP über HTTP: Antwort 104

105 SOAP Programming: Bean Service public MyBean scramble(mybean bean){ //create return value MyBean retval = new MyBean(); //write text backwards (scramble text value) String text = ""; for(int i =bean.gettext().length();i>0;i--) text+=bean.gettext().substring(i-1,i); //set new text value retval.settext(text); } //return scrambled object return(retval); 105

106 SOAP Programming: Bean Client bean = new MyBean(); call = (Call)service.createCall(); //create bean //create call //create qualified name for attachment type (DataHandler). QName qname = new QName(" my"); //add (de-)serializer for bean call.registertypemapping(mybean.class, qname, BeanSerializerFactory.class, BeanDeserializerFactory.class); call.addparameter("bean", qname, ParameterMode.IN); //register (passed) parameter for bean call.setreturntype(qname); //specify expected return type of web service method call.setoperationname(new QName("scramble")); //specify web service method call.settargetendpointaddress(host + SERVICE_PATH); //specify web service URI Object ret = call.invoke(new Object[] {bean}); //invoke web service with passing bean as parameter. } catch (Exception ex) { 106

107 WSDL Beschreibt abstrakt, d.h. unabhängig vom Nachrichtenformat oder Netzwerkprotokoll, Web Services als eine Menge von Zugriffsendpunkten, die untereinander Nachrichten auf prozedur- oder dokumentenorientierter Weise austauschen WSDL ist eine XML-Grammatik Beschreibung beinhaltet Informationen über: Funktionsweisen eines Web Services Was zulässigen Datenformate (types) Wie Form der Operationsaufrufe (PortType) Wie Ort des Web Services (service) Wo WSDL ist ein Rezept, das dazu dient, die Details der Kommunikation zwischen Anwendungen zu automatisieren. Version 2.0 W3C Candidate Recommendation (2006) 107

108 WSDL Beispiel (V1.1) Datentypen und Nachrichten <types> </types> <message name="getlasttradepricerequest"> <part name="companyname type="xsd:string /> </message> <message name="getlasttradepriceresponse"> <part name="price" type="xsd:float"/> </message> <porttype name="stockquoteporttype"> <operation name="getlasttradeprice"> <input message="myns:getlasttradepricerequest"/> <output message="myns:getlasttradepriceresponse"/> </operation> </ porttype> Aufrufbare Methoden 108

109 WSDL Beispiel (V1.1) <binding name="stockquotesoapbinding type="tns:stockquoteporttype"> <soap:binding style= rpc" transport= http"/> <operation name= GetLastTradePrice"> Soap-spezifische Einstellungen... </operation> </binding> <service name="stockquoteservice"> <port name="stockquoteport" binding="tns:stockquotebinding"> <soap:address location= </port> </service> Client Server Kommunikation Ort des Web Services 109

110 UDDI Es gab bisher keinen allgemeinen Standard, zum Auffinden von Diensten. Yahoo und Google sind unzureichend. Plattformunabhängiger universeller Rahmen (UNIVERSAL), um Services zu beschreiben (DESCRIPTION), Unternehmen zu finden (DISCOVERY) und die Services zu integrieren (INTEGRATION) Globaler Verzeichnisdienst Entspricht einer verteilten Datenbank (UBR: UDDI Business Registry) UDDI Kommunikation mittels SOAP UDDI API aus XML Elementen 110

111 Informationen White Pages Yellow Pages Green Pages Adresse, Kontaktinformationen, Ansprechpartner Branchenverzeichnis, Kategorisierung nach Unternehmen: Einordnung des Unternehmens gemäß Geschäftsbereich technische Informationen zu angebotenen Dienstleistungen und Verweise zu genauen Spezifikationen 111

112 Policies Zur Beschreibung von Qualitätseigenschaften eines Dienstes, wie etwa Transaktionsunterstützung, Sicherheit, oder geschäftlich relevanten Informationen, wie etwa Kosten, Zahlungsart. Grundelemente: Assertion. Assertion für Sicherheit geben z.b. Verschlüsselungsverfahren vor. Mittels Operatoren und Assertions können komplexere Policy-Ausdrücke formuliert werden. Zuordnung mittels Attachments (Referenzierung der Policy in einem Attachment). Zuordnung zu einzelnen Web Services, einzelnen Operationen eines Dienstes oder einzelnen Nachrichten möglich. Effektive Policy eines Elementes setzt sich aus den Policies der übergeordneten Policies und der eignen zusammen. 112

113 Policies <Policy xmlns:f1= olicies > <ExactlyOne> <All Id= StammKunde > <f1:monatlichezahlung/> <f1:datengeheimhaltung/> </All> <All Id= Laufkundschaft > <f1:zahlungpronutzung/> <f1:kreditkarte/> <f1:datenweitergabe/> </All> </ExactlyOne> </Policy> Stammkunden und Laufkundschaft werden unterschiedlich behandelt: Stammkunden zahlen monatlich und deren Daten werden geheim gehalten. Laufkundschaft zahlt für jede einzelne Nutzung mit Kreditkarte und deren Daten werden weitergegeben. f1 ist der Namensraum des Anwenders. 113