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 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 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 9.7.1 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 <myns:ReliableMessaging xmlns:myns="http://rm.example/" type="once-and-only-once"/> <m:retrieveItinerary env:encodingStyle="http://www.w3.org/2003/05/soap-encoding" xmlns:m="http://travelcompany.example.org/"> 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 vs9.7 10 <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope' xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'> /aWKKap... Base64 content...GGyQ= Faa7vR... Base64 content...Oi2VQ=

11 vs9.7 11 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: <soap:Envelope xmlns:soap='http://www.w3.org/2003/05/soap-envelope' xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'> <xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/me.jpg'/> <xop:Include xmlns:xop='http://www.w3.org/2004/08/xop/include' href='cid:http://example.org/my.hsh'/>

12 vs9.7 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: http://www.w3.org/TR/soap12-part0/http://www.w3.org/TR/soap12-part0/

13 vs9.7 13 9.7.2 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 vs9.7 14 <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" > This document describes the GreatH Web service.... optional, auch externes Schema möglich... verwendet Typen... verwendet Interface... verwendet Interface, Bindung

15 vs9.7 15 Eingebettete XML-Schema-Typdefinitionen für Operationen <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"> Anfrage Antwort Fehle r

16 vs9.7 16 <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" /> Interface beschreibt logisches Kommunikationsmuster

17 vs9.7 17 <binding name="reservationSOAPBinding" 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"/> <operation ref="tns:opCheckAvailability" wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"/> SOAP über HTTP MEP

18 vs9.7 18 <service name="reservationService" interface="tns:reservationInterface"> <endpoint name="reservationEndpoint" binding="tns:reservationSOAPBinding" address="http://greath.example.com/2004/reservation"/> Veröffentlichung der Dienst-Beschreibung: ● Web-Server entsprechend targetNamespace ● UDDI Publishing/Inquiry-API Weitere Informationen: http://www.w3.org/TR/wsdl20-primer http://www.w3.org/TR/wsdl20-primer

19 vs9.7 19 9.7.3 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 vs9.7 20 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 vs9.7 21 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: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.htmlhttp://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html, 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