9.7 Web-Dienste. Web Server für beliebig programmierte Dienste einsetzen, d.h. Web als Middleware

Transkript

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 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 vs9.7 1

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! vs9.7 2

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 CDL usw. - Business Process Execution Language - Choreography Description Language Sprachen zur Beschreibung von Dienst-Interaktionen vs9.7 3

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

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

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 Station darf/muss Header verarbeiten und entfernen, sowie neue Header einfügen auch Kopien alter Header 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 vs9.7 6

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) vs9.7 7

8 POST /reservations HTTP/1.1 SOAP über HTTP, MEP=POST Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: 492 <?xml version='1.0'?> <env:envelope xmlns:env=" > <env:header> <myns:reliablemessaging xmlns:myns=" type="once-and-only-once"/> </env:header> <env:body> <m:retrieveitinerary env:encodingstyle=" xmlns:m=" <m:reservationcode>ft35zbq</m:reservationcode> </m:retrieveitinerary> </env:body> </env:envelope> vs9.7 8

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 vs9.7 9

10 <soap:envelope xmlns:soap=' xmlns:xmlmime=' <soap:body> <m:data xmlns:m=' <!-- Two binary components: a photo and a signature --> <m:photo>/awkkap... Base64 content...ggyq=</m:photo> <m:sig>faa7vr... Base64 content...oi2vq=</m:sig> </m:data> </soap:body> </soap:envelope> vs9.7 10

11 MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary; type="application/xop+xml"; 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: <soap:envelope xmlns:soap=' xmlns:xmlmime=' <soap:body> <m:data xmlns:m=' <!-- Two binary components: a photo and a signature --> <m:photo><xop:include xmlns:xop=' href='cid: <m:sig><xop:include xmlns:xop=' href='cid: </m:data> </soap:body> </soap:envelope> vs9.7 11

12 --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: vs9.7 12

13 9.7.2 WSDL Web Services Description Language XML-Sprache zur Beschreibung aller Aspekte von Web-Diensten: Was beinhaltet der Dienst - Typen, Nachrichten Wie wird der Dienst angeboten - Bindung Wo wird der Dienst bereitgestellt - Service 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. Signatur in Java wäre etwa: float checkavailability (Date checkin, Date checkout, String roomtype) throws InvalidDataError vs9.7 13

14 <?xml version="1.0" encoding="utf-8"?> <description xmlns=" xmlns:wsoap= " xmlns:soap=" Namensraum für Schnittstellen, Bindung, Dienst targetnamespace= " xmlns:tns= " Namensraum für eingebettete Typdefinitionen xmlns:ghns = " > <documentation>this document describes the GreatH Web service. </documentation> <types>... </types> optional, auch externes Schema möglich <interface>... </interface> verwendet Typen <binding>... </binding> verwendet Interface <service>... </service> verwendet Interface, Bindung </description> vs9.7 14

15 Eingebettete XML-Schema-Typdefinitionen für Operationen <types> <xs:schema xmlns:xs=" targetnamespace=" xmlns=" <xs:element name="checkavailability" type="tcheckavailability"/> <xs:complextype name="tcheckavailability"> <xs:sequence> Anfrage <xs:element name="checkindate" type="xs:date"/> <xs:element name="checkoutdate" type="xs:date"/> <xs:element name="roomtype" type="xs:string"/> </xs:sequence> </xs:complextype> Antwort <xs:element name="checkavailabilityresponse" type="xs:double"/> <xs:element name="invaliddataerror" type="xs:string"/> </xs:schema> </types> Fehler vs9.7 15

16 <interface name = "reservationinterface" > <fault name = "invaliddatafault" element = "ghns:invaliddataerror"/> <operation name="opcheckavailability" pattern=" style=" safe = "true"> <input messagelabel="in" element="ghns:checkavailability" /> <output messagelabel="out" element="ghns:checkavailabilityresponse" /> <outfault ref="tns:invaliddatafault" messagelabel="out"/> </operation> </interface> Interface beschreibt logisches Kommunikationsmuster vs9.7 16

17 <binding name="reservationsoapbinding" SOAP über HTTP interface="tns:reservationinterface" type=" wsoap:protocol=" <fault ref="tns:invaliddatafault" wsoap:code="soap:sender"/> MEP <operation ref="tns:opcheckavailability" wsoap:mep=" </binding> vs9.7 17

18 <service name="reservationservice" interface="tns:reservationinterface"> <endpoint name="reservationendpoint" binding="tns:reservationsoapbinding" address=" </service> Veröffentlichung der Dienst-Beschreibung: Web-Server entsprechend targetnamespace UDDI Publishing/Inquiry-API Weitere Informationen: vs9.7 18

19 9.7.3 JAX-RPC 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 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 vs9.7 19

20 SOAP-Anbindung Erstellen der Server-Konfigurationsdatei für - Auswahl der zu behandelnden SEI - Festlegung des Dienst-Namens - Abbildung von Java-Paketen auf targetnamespace URIs 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 vs9.7 20

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