9.7 Web-Dienste Idee: Web Server für beliebig programmierte
Transcrição
9.7 Web-Dienste Idee: Web Server für beliebig programmierte
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 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 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 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 binding A initial sender XML binding B ultimate receiver intermediary protocol A vs9.7 protocol B 4 SOAP Envelope SOAP-Nachricht SOAP Header Header beschreiben Erweiterungen und Optionen SOAP Header Block Verarbeitung je nach Typ durch - bestimmte Zwischenstation - alle Zwischenstationen - endgültiger Empfänger SOAP Header Block SOAP Header Block SOAP Body Inhalt wird nur vom endgültigen Empfänger verarbeitet <Content> vs9.7 5 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 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: GET (response only), POST (request-reply) vs9.7 7 SOAP über HTTP, MEP=POST POST /reservations HTTP/1.1 Host: travelcompany.example.org Content-Type: application/soap+xml; charset="utf-8" Content-Length: 492 <?xml version='1.0' ?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header> <myns:ReliableMessaging xmlns:myns="http://rm.example/" type="once-and-only-once"/> </env:Header> <env:Body> <m:retrieveItinerary env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.example.org/"> <m:reservationCode>FT35ZBQ</m:reservationCode> </m:retrieveItinerary> </env:Body> </env:Envelope> vs9.7 8 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 <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope' xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'> <soap:Body> <m:data xmlns:m='http://example.org/stuff'> <!-- 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 MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary; type="application/xop+xml"; start="<[email protected]>"; 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: <[email protected]> <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope' xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'> <soap:Body> <m:data xmlns:m='http://example.org/stuff'> <!-- Two binary components: a photo and a signature --> <m:photo><xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/me.jpg'/></m:photo> <m:sig><xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/my.hsh'/></m:sig> </m:data> </soap:Body> vs9.7 11 </soap:Envelope> --MIME_boundary Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <http://example.org/me.jpg> .. binary octets for JPEG image ... --MIME_boundary Content-Type: application/pkcs7-signature Content-Transfer-Encoding: binary Content-ID: <http://example.org/my.hsh> ... binary octets for signature ... --MIME_boundary-- Weitere Informationen zu SOAP: http://www.w3.org/TR/soap12-part0/ vs9.7 12 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 <?xml version="1.0" encoding="utf-8" ?> <description xmlns="http://www.w3.org/2005/05/wsdl" xmlns:wsoap= "http://www.w3.org/2005/05/wsdl/soap" xmlns:soap="http://www.w3.org/2003/05/soap-envelope" Namensraum für Schnittstellen, Bindung, Dienst targetNamespace= "http://greath.example.com/2004/wsdl/resSvc" xmlns:tns= "http://greath.example.com/2004/wsdl/resSvc" Namensraum für eingebettete Typdefinitionen xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc" > <documentation>This document describes the GreatH Web service. </documentation> <types> ... </types> <interface> ... </interface> <binding> ... </binding> <service> ... </service> </description> optional, auch externes Schema möglich verwendet Typen verwendet Interface verwendet Interface, Bindung vs9.7 14 Eingebettete XML-Schema-Typdefinitionen für Operationen <types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://greath.example.com/2004/schemas/resSvc" xmlns="http://greath.example.com/2004/schemas/resSvc"> <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> Antwort </xs:complexType> <xs:element name="checkAvailabilityResponse" type="xs:double"/> <xs:element name="invalidDataError" type="xs:string"/> </xs:schema> </types> Fehler vs9.7 15 <interface name = "reservationInterface" > <fault name = "invalidDataFault" element = "ghns:invalidDataError"/> <operation name="opCheckAvailability" pattern="http://www.w3.org/2005/05/wsdl/in-out" style="http://www.w3.org/2005/05/wsdl/style/uri" 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 <binding name="reservationSOAPBinding" SOAP über HTTP interface="tns:reservationInterface" type="http://www.w3.org/2005/05/wsdl/soap" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"> <fault ref="tns:invalidDataFault" wsoap:code="soap:Sender"/> MEP <operation ref="tns:opCheckAvailability" wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/> </binding> vs9.7 17 <service name="reservationService" interface="tns:reservationInterface"> <endpoint name="reservationEndpoint" binding="tns:reservationSOAPBinding" address="http://greath.example.com/2004/reservation"/> </service> Veröffentlichung der Dienst-Beschreibung: ● Web-Server ● UDDI entsprechend targetNamespace Publishing/Inquiry-API Weitere Informationen: http://www.w3.org/TR/wsdl20-primer vs9.7 18 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 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 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: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html, Kapitel 8 vs9.7 21