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

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 !

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

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

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

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

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)

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=" type="once-and-only-once"/> <m:retrieveItinerary env:encodingStyle=" xmlns:m=" FT35ZBQ SOAP über HTTP, MEP=POST

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

vs <soap:Envelope xmlns:soap=' xmlns:xmlmime=' /aWKKap... Base64 content...GGyQ= Faa7vR... Base64 content...Oi2VQ=

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: <soap:Envelope xmlns:soap=' xmlns:xmlmime=' <xop:Include xmlns:xop=' href='cid: <xop:Include xmlns:xop=' href='cid:

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:

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.

vs <description xmlns=" xmlns:wsoap= " xmlns:soap=" Namensraum für Schnittstellen, Bindung, Dienst targetNamespace= " xmlns:tns= " Namensraum für eingebettete Typdefinitionen xmlns:ghns = " > This document describes the GreatH Web service.... optional, auch externes Schema möglich... verwendet Typen... verwendet Interface... verwendet Interface, Bindung

vs Eingebettete XML-Schema-Typdefinitionen für Operationen <xs:schema xmlns:xs=" targetNamespace=" xmlns=" Anfrage Antwort Fehle r

vs <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" /> Interface beschreibt logisches Kommunikationsmuster

vs <binding name="reservationSOAPBinding" interface="tns:reservationInterface" type=" wsoap:protocol=" <fault ref="tns:invalidDataFault" wsoap:code="soap:Sender"/> <operation ref="tns:opCheckAvailability" wsoap:mep=" SOAP über HTTP MEP

vs <service name="reservationService" interface="tns:reservationInterface"> <endpoint name="reservationEndpoint" binding="tns:reservationSOAPBinding" address=" Veröffentlichung der Dienst-Beschreibung: ● Web-Server entsprechend targetNamespace ● UDDI Publishing/Inquiry-API Weitere Informationen:

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

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

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