• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Software engineering - Kommunikationsprotokolle (WS 2011/2012)
 

Software engineering - Kommunikationsprotokolle (WS 2011/2012)

on

  • 196 views

 

Statistics

Views

Total Views
196
Views on SlideShare
196
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Software engineering - Kommunikationsprotokolle (WS 2011/2012) Software engineering - Kommunikationsprotokolle (WS 2011/2012) Presentation Transcript

    • Kommunikationsprotokolle – Kommunikationsprotokolle – Christoph Stollwerk Software-Engineering: Basistechnologien MA Medienwissenschaft Wintersemester 2011/12 15.11.2011 Folie 1 / 96
    • Kommunikationsprotokolle – Gliederung – Einleitung Konzepte verteilter Anwendungen Erforderlichen Programmiertechniken CORBA SOA ORB WebServices Dienste WSDL Stringifizierte Objektreferenzen SOAP Serversicht & Klientensicht UDDI Kritik REST Folie 2 / 96
    • Kommunikationsprotokolle Einleitung – Kommunikation in verteilten Anwendungen – Folie 3 / 96
    • Kommunikationsprotokolle – Verteilte Anwendungen – Was ist das? • Gegenteil einer lokalen Anwendung – Prozesse interagieren miteinander • Prinzipieller Datenaustausch mittels Kooperation oder Kommunikation Folie 4 / 96
    • Kommunikationsprotokolle – Verteilte Anwendungen – Vorteile (Vorraussetzungen) • Bewältigung gemeinsamer Aufgabe geographisch getrennt • Stabilität / Robustheit / Dezentralisierung / Stand-by-PC´s • Aufgabenteilung aus Hardwarevorgaben • Aufgabenteilung aus Wirtschaftlichkeit • Performanzgewinn Folie 5 / 96
    • Kommunikationsprotokolle – Verteilte Anwendungen – Nachteile • Generelle erhöhte Komplexität • Erschwerte Bedingungen im Software-Lebenszyklus: 1. 2. 3. 4. 5. 6. Entwurf Implementation Testen Debuggen Betrieb Versionierung & Konfiguration Lösung: Techniken zur Beherrschbarkeit von Komplexität Folie 6 / 96
    • Kommunikationsprotokolle – Verteilte Anwendungen – Ein Zwischenstand • Geschwindigkeitsausbau des Internets treibt Gebrauch von Web-Applikationen schon seit Jahren an: – – • Gründe für verteilte Anwendungen – – – – • Grid-Computing Peer-to-Peer Systeme Natur der Aufgabe Robustheit durch duplizierte Ressourcen Wirtschaftlichkeitserwägungen Erweiterte Funktionalität Für uns ist es deshalb wichtig, sich aller Vor- und Nachteile bewusst zu sein, um zu entscheiden ob, warum und wie eine Anwendung verteilt werden soll. Folie 7 / 96
    • Kommunikationsprotokolle Einleitung – Konzepte verteilter Anwendungen – Folie 8 / 96
    • Kommunikationsprotokolle – Konzepte verteilter Anwendungen – Verteilungstransparenzen • Zugriffstransparenz • Ortstransparenz • Migrationstransparenz • Relokationstransparenz • Persistenztransparenz • Nebenläufigkeitstransparenz • Replikationstransparenz • Fehlertransparenz Folie 9 / 96
    • Kommunikationsprotokolle – Konzepte verteilter Anwendungen – Skalierbarkeit • Zweites großes Entwurfsziel verteilter Anwendungen – WWW so stark dezentral => skalierbare Struktur • Dimensionen: – Größe • Zentrale Dienste, Daten und Algorithmen – Geographische Verteilung • Latenzzeiten und Nachrichtenverteilung – Administrative Verteilung • Sicherheit und Kosten/Nutzen, Folie 10 / 96
    • Kommunikationsprotokolle – Konzepte verteilter Anwendungen – Architekturen Folie 11 / 96
    • Kommunikationsprotokolle – Konzepte verteilter Anwendungen – Kommunikationsparadigmen • • • • Sockets*# Nachrichtenbasierte Kommunikation* Prozedurfernaufruf (Remote Procedure Call)* Methodenfernaufruf (Remote Method Invocation)# • Sprachunabhängiger Methodenfernaufruf (CORBA/Jini) Technologie ist … * … prominent aber ggf. obsolet # … heute stark im Einsatz aufzufinden Folie 12 / 96
    • Kommunikationsprotokolle – Konzepte verteilter Anwendungen – Remote Procedure Call Folie 13 / 96
    • Kommunikationsprotokolle Einleitung – Erforderliche Programmiertechniken – Folie 14 / 96
    • Kommunikationsprotokolle – Erforderliche Programmiertechniken – Threads / Objektsperren / Serialisierung / Sicherheit • Java ist inhärent Multithreadingfähig – Erweitern der Klasse Thread – Implementieren der Schnittstelle Runnable • Neben Event-Listening ist Netzwerkkommunikation zentral • Objektsperren sind notwendig bei gleichzeitigem Zugriff • Serialisierung zerlegt in Byte-Ströme zwecks – Speicherung – Transport • Sicherheitsmanager (Security Manager) Folie 15 / 96
    • Kommunikationsprotokolle – Erforderliche Programmiertechniken – Model-View-Controller • Architekturmuster zur Strukturierung von SoftwareEntwicklung – Datenmodell – Präsentation – Programmsteuerung • Ziel ist flexibler Programmentwurf – Spätere Änderung – Erleichterte Erweiterung Folie 16 / 96
    • Kommunikationsprotokolle – Erforderliche Programmiertechniken – Model-View-Controller Light • Modell (model): – Verarbeitet darzustellende Daten – Ist von Präsentation und Steuerung unabhängig • Präsentation (view): – Darstellung der benötigten Daten aus dem Modell – Entgegennahme von Benutzerinteraktion • Steuerung (controller) – Verwaltet Präsentationen – Verarbeitet Benutzerinteraktion vom View – Ändert keine, aber entscheidet welche Daten geändert werden Folie 17 / 96
    • Kommunikationsprotokolle – Erforderliche Programmiertechniken – Model-View-Controller Beispiel • Das MVC-Entwurfsmuster definiert auch den Rahmen für die Entwickler von GUI-Frameworks. Ein fertiges GUIFramework beinhaltet: – eine Präsentation (view) in Form ausimplementierter GUI-Widgets – die Vereinbarung eines zugrundeliegenden Datenmodells in Form von Schnittstellen, – die Vereinbarung von Ereignissen auf Grund von Benutzerinteraktionen in Form von Schnittstellen und ausimplementierten Klassen, sowie – die Vereinbarung von Ereignissen auf Grund von Modelländerungen in Form von Schnittstellen und ausimplementierten Klassen. Folie 18 / 96
    • Kommunikationsprotokolle CORBA – Eine universal Schnittstelle – Folie 19 / 96
    • Kommunikationsprotokolle – CORBA – Common Object Request Broker Architecture • Spezifikation von OMG • Unterstützt Kooperation verteilter Anwendungen über sprachunabhängige Methodenaufrufe • Basiert auf Corba-Objekten – Interface Definition Language (IDL) • Kommunikations zwischen Objekte findet über Interoperable Object References (IORs) statt. Folie 20 / 96
    • Kommunikationsprotokolle – CORBA – Object Management Architecture Folie 21 / 96
    • Kommunikationsprotokolle – CORBA – Interface Definition Language • Spezifikationssprache zur Beschreibung von Serverobjekten – Serverobjekt besteht aus Mappings von Sprachen • IDL-Konstrukte beinhalten Abbildungsregeln Stubs Skeletons Folie 22 / 96
    • Kommunikationsprotokolle CORBA – IDL – Folie 23 / 96
    • Kommunikationsprotokolle – CORBA – Object Management Architecture Folie 24 / 96
    • Kommunikationsprotokolle – CORBA – IDL - Module • Oberste Ebene der Spezifikation sind Module 1. 2. 3. 4. 5. 6. 7. Schnittstellen Konstanten Typdeklarationen ValueTypes Ausnahmen Helferklassen Module Schachtelung Folie 25 / 96
    • Kommunikationsprotokolle – CORBA – 1. Schnittstellen • Schnittstellen sind zentrales Konzept und kann bestehen aus: 1. 2. 3. 4. 5. Operationen Attribute Konstanten Typdeklarationen Ausnahmen Folie 26 / 96
    • Kommunikationsprotokolle – CORBA – 1. Schnittstellen • Schnittstellen sind zentrales Konzept und kann bestehen aus: 1. 2. 3. 4. 5. Operationen Attribute Konstanten Typdeklarationen Ausnahmen Folie 27 / 96
    • Kommunikationsprotokolle – CORBA – Schnittstellen (Vererbung) Folie 28 / 96
    • Kommunikationsprotokolle – CORBA – 1. Operationen .. • • .. sind Methoden (Java) oder Funktionen (C/C++) Aber IDL ist reine Spezifikationssprache zur Schnittstellenbeschreibung (keine Operationsrümpfe!) IDL–Operation bestehen aus: • – – – – – der optionalen Angabe des Schlüsselworts oneway, einem Rückgabetyp, einem Operationsnamen, einer Liste von Parametern (in, out, inout) optional einer Liste möglicher Ausnahmen. Folie 29 / 96
    • Kommunikationsprotokolle – CORBA – 1. Operationen • Parameter und Rückgabetypen: – – – • alle Basistypen und alle konstruierten Typen alle Objekttypen in Form von IDL–Schnittstellen alle ValueTypes Es wird immer eine Objektreferenz übergeben – Sonst ValueType verwenden (ganzes Objekt) Folie 30 / 96
    • Kommunikationsprotokolle – CORBA – 2. Attribute • Attributdeklarationen kann zum Lesen und Schreiben genutzt werden. Folie 31 / 96
    • Kommunikationsprotokolle – CORBA – 3. Konstanten Folie 32 / 96
    • Kommunikationsprotokolle – CORBA – 3. Konstanten Folie 33 / 96
    • Kommunikationsprotokolle – CORBA – 4. Typdeklarationen • • • • • • Basistypen Aufzähltypen Strukturen Unions Arrays Sequenzen Folie 34 / 96
    • Kommunikationsprotokolle – CORBA – 5. ValueTypes • Erlauben Wertübergabe (Object–By–Value) Folie 35 / 96
    • Kommunikationsprotokolle – CORBA – 6. Ausnahmen Folie 36 / 96
    • Kommunikationsprotokolle CORBA – Keine ruhige Kugel – Folie 37 / 96
    • Kommunikationsprotokolle – CORBA – Object Request Broker Zudem statt statischer Methodenfernaufrufe Dynamische: – – Dynamische Serveraktivierung Dynamische Methodenaufrufe (DII & DSI) Folie 38 / 96
    • Kommunikationsprotokolle CORBA – Dienste – Folie 39 / 96
    • Kommunikationsprotokolle – CORBA – Naming Service • Oder: Wie ein Klient in den Besitz einer entfernten Objektreferenz gelangt? – – • Lokation eines CORBA-Serverobjektes frei wählbar Keine zwingende Verbindung zum logischen Namen Aber: Wie bekommt ein Klient eine Referenz auf den CORBA Naming Service? – ORB: list_initial_references() & resolve_initial_references() Folie 40 / 96
    • Kommunikationsprotokolle – CORBA – Trading Service • Dienstvermittlungs Dreisprung 1. 2. Dienstanbieter registriert sich über Dienstbeschreibung und Objektreferenz (Export) Klient kann Anfrage über Eigenschaften machen • 3. • • Constraint Language vom OMG Rückgabe passender Dienste Trader können als Föderation auftreten Policies regeln Trader-Angebote Folie 41 / 96
    • Kommunikationsprotokolle CORBA – Stringifizierte Objektreferenzen – Folie 42 / 96
    • Kommunikationsprotokolle – CORBA – Stringifizierte Objektreferenzen • • • Bestehen nur aus druckbaren Zeichen Dienen zur persistenten Speicherung von Objektreferenzen Operationen der IDL-Schnittstelle des ORB Namespace: • In Java Folie 43 / 96
    • Kommunikationsprotokolle CORBA – Serversicht & Klientensicht – Folie 44 / 96
    • Kommunikationsprotokolle – CORBA – Serversicht Das Erstellen und Starten eines CORBA-Serverobjektes besteht aus den Schritten: 1. Erstellen der IDL–Spezifikation 2. Implementieren des Serverobjekts 3. Erzeugen einer CORBA–Referenz 4. Starten des Serverobjekts Folie 45 / 96
    • Kommunikationsprotokolle – CORBA – Serversicht Folie 46 / 96
    • Kommunikationsprotokolle – CORBA – Serversicht (1. IDL erstellen) • Folgendes wird für den Server erzeugt: – Alle notwendigen Schnittstellen • • – Signaturschnittstellen für Hello Operationenschnittstellen HelloOperations portabler Adapter (POA) • – HelloPOA = Objektadapter (Helfer- und Behälterklassen für die selbstdefinierten Parametertypen) Folie 47 / 96
    • Kommunikationsprotokolle – CORBA – Serversicht (2. Implementierung des Serverobjekts) • POA‘s müssen in der Implementierung erweitert werden. • Null-Referenzen müssen aufgefangen/umgewandelt werden Folie 48 / 96
    • Kommunikationsprotokolle – CORBA – Serversicht (3. Erzeugen einer CORBA–Referenz) • Erzeugen einer Serverobjekt-Instanz • Erzeugen einer zugehörigen CORBA-Referenz 1. Initialisieren des ORB‘s 2. POA organisieren 3. CORBA-Referenz erzeugen Folie 49 / 96
    • Kommunikationsprotokolle Folie 50 / 96
    • Kommunikationsprotokolle – CORBA – Serversicht (3. Erzeugen einer CORBA–Referenz) • Anmelden beim Naming Service – – • Besorgen einer Referenz CORBA-Referenz an den Naming Service binden Ein CorbaModelFactory um CORBA-Serverobjekt als CORBA-Referenz beim Naming Service anzumelden Folie 51 / 96
    • Kommunikationsprotokolle – CORBA – Serversicht (3. Starten des Serverobjekts) • Bevor Serverobjekt gestartet werden kann muss Naming Service gestartet werden: • Serverobjekt kann gestartet werden. – Dazu als Parameter den Port des Naming Service übergeben Folie 52 / 96
    • Kommunikationsprotokolle – CORBA – Klientensicht Durch Aufruf von Wird clientseitige Java-Datei erzeugt, die beinhaltet: • Signaturschnittstelle Hello • Operationsschnittstelle HelloOperations • Der Klientenstub HelloStub • Helfer-/Behälterklassen Folie 53 / 96
    • Kommunikationsprotokolle – CORBA – Klientensicht • Immer wiederkehrende Schritte eine CORBA Klienten 1. 2. Fernaufruf von Methoden 3. – Holen der Referenz ( Naming Service) Starten des Klientenapplikationsobjekts Ein Beispiel… Folie 54 / 96
    • Kommunikationsprotokolle – CORBA – Folie 55 / 96
    • Kommunikationsprotokolle – CORBA – CORBA-Server vs. CORBA-Client Mit der Technologie RMI-IIOP kann eine CORBA Anwendung komplett in Java implementiert werden. IDL-Interface und Stubs werden aus RMI-Interface erzeugt. Folie 56 / 96
    • Kommunikationsprotokolle – CORBA – Kritik Hohe Abstraktion = erschwerte intuitive Einarbeitung Ortstransparenz in CORBA kann Methodenfernaufrufe in ungeahnte Komplexitäten treiben Designmängel = teuer & lange Implementierung Keine Implementierung, sondern nur Spezifikation • • • • – • Vielzahl in-/funktioneller Implementationen CORBA (IIOP) nutzt TCP/IP = WebServer Firewalls geben nur Port 80 frei Sicherheitintensive Calls nur über Aufsätze realisierbar • – ORBACUS FreeSSL Transport Vorteile • Performance, Skalierbarkeit, Fehlertoleranz, Failover, Massendatenverarbeitung Folie 57 / 96
    • Kommunikationsprotokolle SOA SOAP/ESB/EDA/EAI/DSI/CEP/UDDI/WSDL/ XML/RPC/HTTP/IIOP/DCOM/DCE/JWSDP/ HÄH? Folie 58 / 96
    • Kommunikationsprotokolle – SOA – Was ist das eigentlich? FALSCH RICHTIG SOA .. SOA .. • .. ist Technologie • .. Architektonisches Paradigma um verteillte System zu realisieren • .. ist revolutionär • .. ist evolutionär • .. ist Ende der Fahnenstange • .. ist Mittel zum Zweck • .. setzt neue Maßstäbe • .. kann und sollte inkrementeller Prozess sein Folie 59 / 96
    • Kommunikationsprotokolle – SOA – Was fällt auf? Folie 60 / 96
    • Kommunikationsprotokolle – SOA – Was fällt auf? Quelle: SUN Microsystems Folie 61 / 96
    • Kommunikationsprotokolle – SOA – Im Klartext • In einer SOA werden Funktionen und komplette Businessprozesse – – • standardisiert. unternehmensweit zugänglich gemacht Beispiel: – – Abteilung A hat Software in C++ als Desktopanwendung Abteilung B eine webbasierte JAVA-Lösung – Eigentlich nicht direkt kompatibel, aber dank SOA-basierter Anwendungsschicht werden Prozesse und Funktionen geordnet zugreifbar. Folie 62 / 96
    • Kommunikationsprotokolle – SOA – Schon längst vorhanden.. • Richtig! Aber nichts davon ist plattformunabhängig – • Ausnahmen: RFC, CORBA (sehr komplex), Eigenes Höheres Abstraktionsniveau ist also erforderlich: – – Vereinheitlichung eines Vorgehensmodells Bzw. Abstraktion von Unternehmensprozessen • SOA lässt ‚Wahl der Technik‘ offen • Objektorientierte Programmierung vs. Komponentenbasierte Programmierung Folie 63 / 96
    • Kommunikationsprotokolle – SOA – Komponenten • Abstraktion von Unternehmensprozessen in wiederverwendbare Services wird in 3 Rollen geteilt: – Verzeichnisdienst – Dienstanbieter – Dienstbenutzer Folie 64 / 96
    • Kommunikationsprotokolle – SOA – Etablierte Technologien • Verzeichnisdienste nutzten oft UDDI • Dienstanbieter sind in aller Regel WebServices • Dienstnutzer binden Services zumeist per SOAP an • Spezifikation von Webservices über WSDL‘s • Leichte Dienstnutzer werden gerne per REST angebunden Folie 65 / 96
    • Kommunikationsprotokolle Webservices – Begriffdefinition – Folie 66 / 96
    • Kommunikationsprotokolle – Webservices – Definition des W3C “A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specially WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.” Folie 67 / 96
    • Kommunikationsprotokolle – Webservices – Definition des W3C (Nr.2) “The World Wide Web is more and more used for application to application communication. The programmatic interfaces made available are referred to as Web services..” Keywords: Web service, software system, interface, WSDL, SOAPmessages, HTTP, XML serialization Folie 68 / 96
    • Kommunikationsprotokolle – Webservices – Definition • Entfernter Dienst der – – – Über Nachrichten aufgerufen werden kann In WSDL beschrieben ist In UDDI verzeichnet ist Folie 69 / 96
    • Kommunikationsprotokolle – WebService – WebService vs. Webanwendung • Webanwendung bietet Benutzerschnittstelle • WebService bietet entfernt zugreifbare API • Webanwendung kann WebService nutzen um Funktionalität zu erfüllen • Beispiele ? Folie 70 / 96
    • Kommunikationsprotokolle WebServices – WSDL – Folie 71 / 96
    • Kommunikationsprotokolle – WebServices – WSDL • XML-basierte Sprache zur Spezifikation der Schnittstellen von WebServices • Lokation von WebServices • Vergleichbar mit CORBA-IDL oder JAVA-RMI • Wurzelelement: definitions – (enthält Namen & ggf. Namespaces) • Folgende Beschreibungselemente vorhanden – Datentypen (types) – Nachrichten (messages) – Port-Typen (port types) – Dienste (services) Folie 72 / 96
    • Kommunikationsprotokolle – WebServices – WSDL - Beispiel • HelloWorld-Dienst – Wurzel: genutzte NameSpaces & Import <definitionsname="HelloService" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:tns="http://www.Webserviceprovider.de/wsdl/HelloService.wsdl " xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> Folie 73 / 96
    • Kommunikationsprotokolle – WebServices – WSDL - Beispiel • Nachrichten: Definition von Nachrichtenformaten für Anfragen und Antworten • Part-Elemente: – Anfrage Namen und Typen der Eingabeparameter – Antwort Namen und Typen der Ergebnisse Folie 74 / 96
    • Kommunikationsprotokolle – WebServices – WSDL - Beispiel • Port-Typen: Definition von Operationen, bestehend aus Anfrage und/oder Antworten • Hello_PortType enthält Operation, die erst aus Anfrage, dann aus Antwort besteht Folie 75 / 96
    • Kommunikationsprotokolle – WebServices – WSDL - Operationsmuster Folie 76 / 96
    • Kommunikationsprotokolle – WebServices – WSDL - Beispiel • Bindung: Spezifiert Nachrichtenformate und Transportprotokoll für zuvor definierte Port-Typen • Hier SOAP-Bindings: <soap:body> enthalten.. – .. Namen der gerufenen Webmethoden. – .. Einträge für jeden Parameter & Rückgabewert • RPC/Encoded: Parametertypen stehen in den SOAP-Nachrichten • RPC/Literal: Format der Nachricht enspricht separater Schema-Def. • Document/Literal: Keine Regeln bzgl. Des Inhalts des <soap:body>-Elements. WebService und Klient müssen sich über das Format der ausgetauschen Dokumente einig sein. Das Format der SOAP-Nachrichten entspricht der separaten Schema-Definition Folie 77 / 96
    • Kommunikationsprotokolle – WebServices – Folie 78 / 96
    • Kommunikationsprotokolle – WebServices – WSDL - Beispiel • Dienst: Angabe eines Endpunktes, unter dem der Dienst zugegriffen werden kann. Folie 79 / 96
    • Kommunikationsprotokolle WebServices – SOAP – Folie 80 / 96
    • Kommunikationsprotokolle – WebServices – SOAP • Austausch von XML-Nachrichten über HTTP/HTTPS zum Datenaustausch/Remote Procedure Call • Weiterentwicklung von XML-RPC • Prinzip: – Klient schickt Dienstanfrage per SOAP-Nachricht an Server – Server schickt Ergebnisse als SOAP-Nachricht wieder zurück Folie 81 / 96
    • Kommunikationsprotokolle – WebServices – Aufbau eine SOAP-Nachricht • Wurzel SOAP-Envelope – Header kann Meta-Info halten – Body hält Nutzdaten, zb Ergebnisse etc Folie 82 / 96
    • Kommunikationsprotokolle – WebServices – Aufrufnachricht für entfernte Hello-World-Prozedur Folie 83 / 96
    • Kommunikationsprotokolle – WebServices – AntwortNachricht der Hello-World-Prozedur Folie 84 / 96
    • Kommunikationsprotokolle – WebServices – SOAP Vor-/Nachteile • Vorteile: – Menschlich lesbar – Offener, weit verbreiteter Standard viele Support etc • Nachteile: – Wenig kompate Darstellung (Latenz) – XML-Nachrichten müssen in Speicherdarstellung geparst werden (Laufzeitineffizienz) Folie 85 / 96
    • Kommunikationsprotokolle – WebServices – SOAP Vorgehensmodelle • Contract First: 1. 2. Generierung von Implementierungsstubs 3. • WSDL-Schnittstelle definieren Manuelle Ergänzung Code First: 1. Code liegt vor 2. Manuelle Ergänzung durch Annotationen 3. Generierung eines WSDL-Schnittstellendefinition Folie 86 / 96
    • Kommunikationsprotokolle WebServices – UDDI – Folie 87 / 96
    • Kommunikationsprotokolle – WebServices – Historie • Ursprüngliche Idee – öffentliche Broker-Infrastruktur von UDDI-Diensten, die Sammlung bilden und anfragenden Klienten passende Dienste liefern – IBM, Microsoft, SAP haben öffentlich UDDI-Server Anfang 2006 abgeschafft. • • Heutzutage spielt sich UDDI firmen-intern ab Prominente Frameworks: – Apache CXF – Apache Axis (J2EE) – JAX-WS (J2EE) Folie 88 / 96
    • Kommunikationsprotokolle WebServices – REST – Folie 89 / 96
    • Kommunikationsprotokolle – WebServices – Historie • Leichtere Alternative zu schweren XML-Bäumen • Populär im mobilen Endgeräte Bereich • auf die Dissertation von Roy Fielding aus dem Jahr 2000 • Rückbesinnung auf Grundprinzipien, die das Web erfolgreich gemacht haben Folie 90 / 96
    • Kommunikationsprotokolle – WebServices – Prinzipien • Adressierbarkeit – Erleichtert eindeutige Identifizierung (URI) – Verbessert Wiederverwendbarkeit • Diverse Repräsentationen – Zb. HTML/JSON/XML – Kodierte Dokumente werden übertragen • Zustandslosigkeit (stateless) – Jede Nachricht enthält alles Info zum Vorgang – Verbessert Skalierbarkeit (Lastverteilung) • Operationen – feste Anzahl – Viele gleiche Anfragen immer selber Ergebnis Folie 91 / 96
    • Kommunikationsprotokolle – WebServices – Grundidee • Ressourcenzentrischer Ansatz • zustandslose, atomare Operationen • Verwendung der HTTP-Anfragetypen, um lesend und schreibend auf Ressourcen zuzugreifen: – GET: angegebene Ressource (URI) lesen – POST: Daten zur angegebene Ressource hinzufügen – PUT: angegebene Ressource anlegen oder ändern – DELETE: löscht angegebene Ressource – HEAD: fordert Metadaten zu angegebener Ressource an – OPTIONS: prüft, welche Operationen zu angegebener Ressource zur Verfügung stehen Folie 92 / 96
    • Kommunikationsprotokolle – Literatur – „Kommunikation in verteilten Anwendungen - Einführung in Sockets, JavaRMI, CORBA und Jini“ Prof.Dr.Oliver Haase 2.Aufl. von 2008 Folie 93 / 96
    • Kommunikationsprotokolle – Literatur 2 – Service-orientierte Architekturen mit Web Services - Konzepte, Standards, Praxis “ Ingo Melzer 3.Aufl. von 2008 Folie 94 / 96
    • Kommunikationsprotokolle ? Fragen?! ? ? Folie 95 / 96
    • Kommunikationsprotokolle Herzlichen Dank! Folie 96 / 96