Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Vs9.7 1 9.7 Web-Dienste Idee:Web Server für beliebig programmierte Dienste einsetzen, d.h. Web als Middleware Warum? Allgegenwart des Web verspricht allgemeine.

Ähnliche Präsentationen


Präsentation zum Thema: "Vs9.7 1 9.7 Web-Dienste Idee:Web Server für beliebig programmierte Dienste einsetzen, d.h. Web als Middleware Warum? Allgegenwart des Web verspricht allgemeine."—  Präsentation transkript:

1 vs Web-Dienste Idee:Web Server für beliebig programmierte Dienste einsetzen, d.h. Web als Middleware Warum? Allgegenwart des Web verspricht allgemeine Akzeptanz in heterogener Welt (statt CORBA,.NET,...) sowie Ausnutzung etablierter Infrastruktur (besonders Web-Tunnel durch Firewall; Sicherheit?)  Standard: SOAP (ehemals Simple Object Access Protocol ) für Codierung von Aufrufen und Ergebnissen mit XML

2 vs9.7 2 Konsequenzen:  Aufgerufen werden Dienste (mit Schnittstellen), keine Objekte: Web-Dienste (Web Services)  Wegen XML-Codierung wesentlich langsamer als z.B. CORBA-IIOP  Dienst immer erreichbar, wenn Web Server erreichbar (Port 80), auch über Firewall-Grenzen hinweg.  Keine prinzipielle Beschränkung auf HTTP und Web Server: z.B. auch SMTP + geeignet konfigurierter Mail Server, oder...  Entwicklungsumgebungen und Generatoren für Vertreter- und Treiber-Code sind stark herstellerabhängig !  „Web-Fernaufrufe“? SOAP ist tatsächlich nicht mehr als ein Fernaufruf-Protokoll !

3 vs9.7 3 Standardisiert sind ferner: WSDL-Web Services Description Language beschreibt Schnittstellen (ports) von Diensten mit ihren Parametern UDDI-Universal Description and Discovery Interface Schnittstelle für Dienstverzeichnisse BPEL-Business Process Execution Language CDL -Choreography Description Language usw. Sprachen zur Beschreibung von Dienst-Interaktionen

4 vs9.7 4 intermediary initial sender ultimate receive r SOAP Idee: Transport von XML-Dokumenten als Nachrichten entlang eines Transport-Pfads Dave Winer et al. (Userland, Microsoft) 1998 : XML-RPC weiterentwickelt zu SOAP (W3C) 2000 XML binding A binding B initial sender ultimate receiver intermediary protocol A protocol B

5 vs9.7 5 SOAP Envelope SOAP Header SOAP Header Block Header beschreiben Erweiterungen und Optionen Verarbeitung je nach Typ durch - bestimmte Zwischenstation - alle Zwischenstationen - endgültiger Empfänger SOAP Body Inhalt wird nur vom endgültigen Empfänger verarbeitet SOAP-Nachricht

6 vs9.7 6 SOAP-Header Header ermöglichen Erweiterung des SOAP-Nachrichtenaustauschs - features: security, reliability,... - MEP = message exchange pattern: request-response, oneway,... - sonstige "SOAP-Module" für Verarbeitung Standard-Attribute steuern Header-Verarbeitung - role : Bezeichnet Station(en), für die der Header bestimmt ist - mustUnderstand : Header muss verarbeitet werden, oder Nachricht darf nicht weitergeleitet werden (Fehler) - relay : Header muss an die nächste Station weitergeleitet werden, wenn er nicht verarbeitet wurde Station darf/muss Header verarbeiten und entfernen, sowie neue Header einfügen – auch Kopien alter Header

7 vs9.7 7 Protokoll-Bindung Protokoll-Bindung ist verantwortlich für - Serialisierung des XML-Infosets - Übertragung an die nächste Station - Deserialisierung/Wiederherstellung des XML-Infosets Weitere Funktionen: - Unterstützung optionaler features - Realisierung eines oder mehrerer MEPs - Optimierung der Übertragung - uvm. Typische Bindung: HTTP - Transport mit XML-Serialisierung in HTTP-Body - zwei MEPs: POST (request-reply), GET (response only)

8 vs9.7 8 POST /reservations HTTP/1.1 Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: 492 FT35ZBQ SOAP über HTTP, MEP=POST

9 vs9.7 9 Binär-Daten SOAP-Nachrichten sind zwangsweise XML-Dokumente - Wie überträgt man damit Nicht-XML-Daten?... JPEG-Bilder, PDF-Dokumente, digitale Unterschriften,... Typische Behandlung: Kodierung als BASE64 Texte, aber dann - umständliche Handhabung - aufwändige Umkodierung - aufgeblähte Übertragungseinheiten Lösung: Alternative Serialisierung des Infosets als MIME/Multipart - XOP: XML-binary Optimized Packaging sowie - MTOM: SOAP Message Transmission Optimization Mechanism

10 vs /aWKKap... Base64 content...GGyQ= Faa7vR... Base64 content...Oi2VQ=

11 vs MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary; type="application/xop+xml"; start=" "; startinfo="application/soap+xml; action=\"ProcessData\"" Content-Description: SOAP message with my pic and sig in it --MIME_boundary Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml; action=\"ProcessData\"" Content-Transfer-Encoding: 8bit Content-ID:

12 vs MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID:.. binary octets for JPEG image... --MIME_boundary Content-Type: application/pkcs7-signature Content-Transfer-Encoding: binary Content-ID:... binary octets for signature... --MIME_boundary-- Weitere Informationen zu SOAP:

13 vs WSDL Web Services Description Language Wasbeinhaltet der Dienst- Typen, Nachrichten Wiewird der Dienst angeboten- Bindung Wowird der Dienst bereitgestellt- Service XML-Sprache zur Beschreibung aller Aspekte von Web-Diensten: Signatur in Java wäre etwa: float checkAvailability (Date checkin, Date checkout, String roomtype) throws InvalidDataError Beispiel: Prüfen, ob im Hotel "GreatH" Zimmer verfügbar sind. Angabe von Check-In-Tag, Check-Out-Tag und Zimmer-Typ liefert Preis in Euro, oder meldet ParameterFehler.

14 vs This document describes the GreatH Web service.... optional, auch externes Schema möglich... verwendet Typen... verwendet Interface... verwendet Interface, Bindung

15 vs Eingebettete XML-Schema-Typdefinitionen für Operationen Anfrage Antwort Fehle r

16 vs Interface beschreibt logisches Kommunikationsmuster

17 vs SOAP über HTTP MEP

18 vs Veröffentlichung der Dienst-Beschreibung: ● Web-Server entsprechend targetNamespace ● UDDI Publishing/Inquiry-API Weitere Informationen:

19 vs JAX-RPC Einschränkungen der SEI: ● Schnittstelle erbt von java.rmi.Remote ● Methoden deklarieren java.rmi.RemoteException ● Eingeschränktes Typsystem: ● primitive und "einfache" Typen, Holder, Arrays ● "valuetypes" mit public members oder getters/setters Idee: SOAP und WSDL nicht manuell produzieren, sondern hinter geeigneter Entwicklungsumgebung verstecken Vorgehen: Java-Schnittstelle SEI = Service Endpoint Interface definieren und entsprechende Implementierung für Web-Dienst erstellen

20 vs Erstellen der Server-Konfigurationsdatei für - Auswahl der zu behandelnden SEI - Festlegung des Dienst-Namens - Abbildung von Java-Paketen auf targetNamespace URIs SOAP-Anbindung Generierung mit wscompile -gen:server - erstellt WSDL-Datei zu SEI - erstellt Mapping-Datei von WSDL nach Java - erstellt SOAP-Treiber (Servlet) Bereitstellung mit deploytool - erzeugt und konfiguriert WAR-Datei - installiert WAR-Datei in application server

21 vs SOAP-Client Beschaffung der Schnittstelle mit wscompile -import -keep - lädt die WSDL-Datei von Dienst-URL - erzeugt entsprechende Java-Schnittstelle im Ziel-Paket Erstellen der Client-Konfigurationsdatei mit - URL des zu benutzenden Dienstes - Angabe des gewünschten Java-Pakets für die Schnittstelle Weitere Informationen: Kapitel 8 Erzeugung von Vertretern alternativ - statisch mit wscompile -gen:client - dynamisch zur Laufzeit mittels DynamicProxy


Herunterladen ppt "Vs9.7 1 9.7 Web-Dienste Idee:Web Server für beliebig programmierte Dienste einsetzen, d.h. Web als Middleware Warum? Allgegenwart des Web verspricht allgemeine."

Ähnliche Präsentationen


Google-Anzeigen