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

Documentos relacionados