SOAP und WSDL in der Praxis Wie wird WSDL verwendet?

Transcrição

Lernziele
; Prinzipielle Aufbau von WSDL-Beschreibungen
; Protokoll-Bindungen in WSDL
; Google-WSDL lesen können
SOAP und WSDL in der
Praxis
© Klaus Schild, 2004
; Vor- und Nachteile von WSDL
Wie wird WSDL verwendet?
Anforderungen der Praxis
heute
heute
Erweiterungen von SOAP/WSDL
1
2
Wie wird WSDL
verwendet?
.net und Apache Axis
Aus einer WSDL-Beschreibung wird automatisch eine
Schnittstelle zur Anwendung (Stubs) generiert.
Stubs abstrahieren von SOAP und vom konkreten
Übertragungsprotokoll.
Web-Dienst erscheint als lokale Bibliothek.
umgekehrt kann auch aus Anwendungsprogramm
automatisch eine WSDL-Beschreibung erzeugt werden
3
4
WebWeb-Dienste: Die Vision
Beispiel:
personalisierte Informations-Webseite benötigt
Echtzeitkurse von bestimmten Aktien einer bestimmten
Börse
Informations-Webseite sucht entsprechenden WebDienst für Echtzeitkurse und ruft diesen automatisch auf.
dynamische Einbindung
Einbindung
dynamische
zur Laufzeit
Laufzeit
zur
XML Spy

Î
aus WSDL-Beschreibung SOAP-Nachricht generieren
Parameter der SOAP-Anfrage anpassen
SOAP-Nachricht an Web-Dienst senden
sehr gut geeignet zum schnellen testen
5
6
1
Aufruf des Dienstes
Dynamische Einbindung zur Laufzeit
öffentliches
Verzeichnis
1. Anwendung sucht in einem Verzeichnis einen WebDienst, z.B. für Echtzeitkurse von Aktien
2. Suchergebnis: WSDL-Beschreibung
3. Anwendung erzeugt aus WSDL-Beschreibung Stubs
4. Anwendung ruft Web-Dienst als lokale Bibliothek auf
Dienst muss
muss automatisch
automatisch gefunden
gefunden
Dienst
und aufgerufen
aufgerufen werden.
werden.
und
Dienst finden
WSDL beschreibt zwar die
Syntax der Schnittstelle,
nicht aber die Bedeutung
der Prozedur/Parameter.
Bedeutung muss außerhalb
von WSDL festgelegt
(standardisiert) sein
8
Dienst:
Standard
kostenpflichtig
oder kritisch
Dienst:
kein Standard
Um einen Anbieter
automatisch zu finden,
muss der Dienst
kostenlos und unkritisch
sein.
automatisch
manuell
Dienst:
Standard
kostenlos
unkritisch
Dienst:
Standard
kostenpflichtig
oder kritisch
automatisch
Dienst:
Standard
kostenlos
unkritisch
gesucht: Anbieter des
Web-Dienstes (seine
WSDL-Beschreibung)
Dienst abrufen
manuell
Dienst finden
gegeben: standardisierter
Web-Dienst
manuell
automatisch
automatisch
Dienst:
kein Standard
Um den Web-Dienst
automatisch abzurufen,
muss er standardisiert sein:
Die Realität
Dienst finden
Dienst abrufen
Dienst:
Standard
gegeben: WSDLBeschreibung
Beispiel: Float Aktienkurs(Integer WKN, String Boersenplatz)
7
manuell
manuell
automatisch
automatisch
Anbieter
Dienst abrufen
SOAP-Nachrichten
manuell
Nachfrager
Dienst finden
WSDLBeschreibung
WSDLBeschreibung
Dienst:
kein Standard
standardisierte
Informationsdienste
(kostenlos und
unkritisch)
standardisierte
Informationsdienste
(kostenpflichtig
und/oder kritisch)
Google-Web-Dienst,
E-Business
andernfalls Rücksprache
und Verhandlungen nötig
9
10
Schlussfolgerung
Einbindung eines Web-Dienstes
zur Laufzeit:
Vollautomatisches Einbinden prinzipiell mit WSDL
möglich, wird aber die Ausnahme bleiben.
zur Entwicklungszeit:
kein vollautomatisches Einbinden, aber WSDL erleichtert
das Einbinden ganz erheblich
11
Anforderungen der
Praxis
12
2
Anforderung des Praxis
Realisierung mit SOAP
Zulieferer
Unternehmen
Absender eindeutig identifizierbar?
Bestellung
(SOAP-Nachricht)
Nachricht unversehrt?
Nachricht genau einmal übermittelt?
Antwort nach bestimmter Zeit garantiert?
Passt die Nachricht in den Geschäftsprozess?
keine der Anforderungen von SOAP direkt unterstützt
können aber mit Zusatzinformationen im Briefkopf der
SOAP-Nachricht realisiert werden
Passt die Nachricht in den Geschäftsprozess (z.B. keine
Bestellung ohne vorherige Bestellanfrage)?
13
Zusatzinformationen im SOAPSOAP-Briefkopf
digitale Signatur
Î Identifikation des Absenders
14
So einfach ist es dann doch nicht…
Zulieferer
Unternehmen
Bestellung
(SOAP-Nachricht)
Passt die Nachricht in den Geschäftsprozess?
Î Unversehrtheit der Nachricht
Anforderung einer Empfangsbestätigung
Problem der Interoperabilität (Zusammenarbeitsfähigkeit):
Î Nachricht mindestens einmal zugestellt
Zulieferer soll ersetzt werden.
eindeutige Nachrichtenreferenz
Neuer Zulieferer bekommt WSDL-Beschreibung.
Î Erkennung von Duplikaten
WSDL beschreibt zwar die Syntax der Schnittstelle,
einschl. der Zusatzinformationen im Briefkopf.
Verweis auf vorherige Nachrichten, z.B. Bestellanfrage
Î Berücksichtigung des Workflows
Was die Bedeutung der Zusatzinformationen ist, muss
zwischen Unternehmen und Zulieferer geklärt werden.
15
16
Beispiel Fax
Interoperabilität von WebWeb-Diensten
Fax ist hingegen uneingeschränkt interoperabel:
SOAP/WSDL zwar akzeptierte internationale Standards.
Ein Faxgerät kann durch ein anderes ersetzt werden,
ohne mit potentiellen Sendern Protokolle auszuhandeln:
wie z.B. der Eingang eines Fax bestätigt wird
Grund: es gibt einen allgemein akzeptierten
internationalen Fax-Standard
SOAP ist ein Format, mit dem Web-Dienste Nachrichten
austauschen.
WSDL beschreibt die Syntax der Schnittstelle eines
Web-Dienstes.
Wie aber z.B. ein Sender authentifiziert werden kann,
wird weder in SOAP noch WSDL festgelegt.
Î Ein Web-Dienst kann nicht ohne weiteres durch einen
anderen ersetzt werden, selbst wenn beide die gleiche
abstrakte Schnittstelle haben.
17
18
3
Lösung: Erweiterungen von SOAP/WSDL
Beispiel
Sicherheit:
WS Security
Zuverlässigkeit
WS Reliable Messaging
qualitativen Aspekten (quality of service):
WS Policy
geschäftlicher Workflow:
BPEL
sehr gute Übersicht:
http://www-306.ibm.com/software/solutions/webservices/pdf/
SecureReliableTransactedWSAction.pdf
19
WS Reliable
Reliable Messaging
Messaging wird
wird exemplarisch
exemplarisch betrachtet
betrachtet
WS
20
Beispiel
Buchungsanfrage:
Unternehmen ruft Buchungsprozedur eines
Reiseunternehmens auf
Buchung nimmt häufig längere Zeit in Anspruch.
Zuverlässige
Kommunikation
deshalb asynchroner Aufruf der Buchungsprozedur
21
Asynchrone Buchungsprozedur
22
Zuverlässige Buchungsanfrage
RPC-Aufruf
RPC-Aufruf
Client
Anfrage
(request)
Server
Anfrage
akzeptiert
(accept)
Client
Anfrage
(request)
Server
Ergebnis
Anfrage
akzeptiert
(accept)
Ergebnis
Aufruf lokaler
Prozedur
Aufruf lokaler
Prozedur
Anfrage (request):
Buchungsanforderung wird vom Client aufgerufen
Client wartet bis er vom Server Bestätigung der
Annahme bekommen hat.
genau einmal zustellen
Annahme (accept):
mindestens einmal zustellen
Ergebnis:
genau einmal zustellen
Annahme immer vor Ergebnis, ansonsten wird evtl. eine
zweite Buchungsanfrage gestellt.
Server schickt später das endgültige Ergebnis der
Buchungsanfrage
RPC abgeschlossen
auf accept
warten
RPC abgeschlossen
auf accept
warten
ÎAnnahme und
und Ergebnis
Ergebnis bilden
bilden eine
eine Sequenz
Sequenz
ÎAnnahme
23
24
4
WS Reliable Messaging
Beispiel
XML-Protokoll für zuverlässige Kommunikation
kann im Briefkopf von SOAP-Nachrichten oder in
WSDL-Beschreibungen verwendet werden
gemeinsamer Vorschlag von BEA, IBM, Microsoft und
TIBCO
von März 2003
noch kein etablierter Standard
Î http://www-106.ibm.com/developerworks/library/ws-rm/

Sequenz von
von drei
drei Nachrichten
Nachrichten
Sequenz
jede
Nachricht
genau
einmal zustellen
zustellen
jede Nachricht genau einmal
Reihenfolge beachten
beachten
Reihenfolge
Empfang bestätigen
bestätigen
Empfang
25
Beispiel
26
Sequenz von SOAPSOAP-Nachrichten senden
27
28
Erste SOAPSOAP-Nachricht
Erste SOAPSOAP-Nachricht
<S:Envelopexmlns:wsrm="http://schemas.xmlsoap.org/ws/2003/03/rm"
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2003/03/rm"
<S:Envelope
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing">
<S:Header>
<S:Header>
<wsa:MessageID>
<wsa:MessageID>
http://Business456.com/guid/71e0654e-5ce8-477b-bb9d-34f05cfcbc9e
</wsa:MessageID>
</wsa:MessageID>
<wsa:To>http://fabrikam123.com/serviceB/123</wsa:To>
<wsa:ReplyTo>
<wsa:ReplyTo>
<wsa:Address>http://Business456.com/serviceA/789</wsa:Address>
</wsa:ReplyTo>
</wsa:ReplyTo>
WS RM
RM benutzt
benutzt WS
WS
WS
<wsrm:Sequence>
<wsrm:Sequence>
Addressing
Addressing
<wsu:Identifier>http://Business456.com/RM/ABC</wsu:Identifier>
<wsrm:MessageNumber>1</wsrm:MessageNumber>
Nachricht hat
hat eindeutige
eindeutige
Nachricht
</wsrm:Sequence>
</wsrm:Sequence>
Referenz(MessageID)
(MessageID)
Referenz
</S:Header>…
…
</S:Header>
<S:Envelopexmlns:wsrm="http://schemas.xmlsoap.org/ws/2003/03/rm"
xmlns:wsrm="http://schemas.xmlsoap.org/ws/2003/03/rm"
<S:Envelope
<S:Header>
<S:Header>
<wsa:MessageID>
<wsa:MessageID>
WS RM
RM benutzt
benutzt WS
WS Utilities
Utilities
WS

Sequenz
hat
eindeutige
Referenz(Identifier)
(Identifier)
</wsa:MessageID>

Sequenz
hat
eindeutige
Referenz
</wsa:MessageID>
erste
erste Nachricht
Nachricht der
der Sequenz
Sequenz(MessageNumber)
(MessageNumber)

<wsa:ReplyTo>
<wsa:ReplyTo>
</wsa:ReplyTo>
</wsa:ReplyTo>
<wsrm:Sequence>
<wsrm:Sequence>
</wsrm:Sequence>
</wsrm:Sequence>
</S:Header>…
…
</S:Header>
29
30
5
Zweite SOAPSOAP-Nachricht
Dritte und letzte SOAPSOAP-Nachricht
<S:Envelope…>
…>
<S:Envelope
<S:Header>
<S:Header>
<wsa:MessageID>
<wsa:MessageID>
http://Business456.com/guid/daa7d0b2-c8e0-476e-a9a4-d164154e38de
http://Business456.com/guid/daa7d0b2-c8e0-476e-a9a4-d164154e38de
</wsa:MessageID>
</wsa:MessageID>
<wsa:ReplyTo>
<wsa:ReplyTo>
</wsa:ReplyTo>
</wsa:ReplyTo>
<wsrm:Sequence>
<wsrm:Sequence>
</wsrm:Sequence>
</wsrm:Sequence>
neue Nachrichten-Referenz
Nachrichten-Referenz
neue
</S:Header>......
</S:Header>
<S:Envelope…>
…>
<S:Envelope
<S:Header>
<S:Header>
<wsa:MessageID>
<wsa:MessageID>
http://Business456.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
</wsa:MessageID>
</wsa:MessageID>
<wsa:ReplyTo>
<wsa:ReplyTo>
</wsa:ReplyTo>
</wsa:ReplyTo>
<wsrm:Sequence>
<wsrm:Sequence>
<wsrm:LastMessage/>
<wsrm:LastMessage/>
neue Nachrichten-Referenz
Nachrichten-Referenz
</wsrm:Sequence>
neue
</wsrm:Sequence>
</S:Header>…
…
</S:Header>
alte Sequenz-Referenz
Sequenz-Referenz
alte
alte Sequenz-Referenz
Sequenz-Referenz
alte
31
Bestätigung
32
Bestätigung
<S:Envelope…>
…>
<S:Envelope
<S:Header>
<S:Header>
<wsa:MessageID>
<wsa:MessageID>
http://fabrikam123.com/guid/0baaf88d-483b-4ecf-a6d8-a7c2eb546817
</wsa:MessageID>
</wsa:MessageID>
<wsa:To>http://Business456.com/serviceA/789</wsa:To>
<wsa:ReplyTo>
<wsa:ReplyTo>
<wsa:Address>http://fabrikam123.com/serviceB/123</wsa:Address>
</wsa:ReplyTo>
</wsa:ReplyTo>
<wsrm:SequenceAcknowledgment>
<wsrm:AcknowledgmentRangeUpper="1"
Upper="1"Lower="1"/>
Lower="1"/>
<wsrm:AcknowledgmentRange
Lower="3"/>
</wsrm:SequenceAcknowledgment>
</S:Header>…
…
</S:Header>
erste und
und dritte
dritte Nachricht
Nachricht angekommen
angekommen
erste
33
Zweite Nachricht nochmals senden
34
Zweite Nachricht nochmals senden
<S:Envelope…>
…>
<S:Envelope
<S:Header>
<S:Header>
<wsa:MessageID>
<wsa:MessageID>
</wsa:MessageID>
</wsa:MessageID>
…
…
<wsrm:Sequence>
<wsrm:Sequence>
</wsrm:Sequence>
</wsrm:Sequence>
<wsrm:AckRequested>
<wsrm:AckRequested>
</wsrm:AckRequested>
</wsrm:AckRequested>
</S:Header>…
…
zweite Nachricht
Nachricht der
der Sequenz
Sequenz
</S:Header>
zweite
Bestätigung vom
vom Empfänger
Empfänger verlangt
verlangt
Bestätigung
35
36
6
Endgültige Bestätigung
Endgültige Bestätigung
<S:Envelope…>
…>
<S:Envelope
<S:Header>
<S:Header>
<wsa:MessageID>
<wsa:MessageID>
</wsa:MessageID>
</wsa:MessageID>
<wsa:ReplyTo>
<wsa:ReplyTo>
</wsa:ReplyTo>
</wsa:ReplyTo>
Lower="1"/>
</S:Header>…
…
</S:Header>
Sequenz vollständig
vollständig empfangen
empfangen
Sequenz
37
Was gibt es noch?
Integration in SOAP oder WSDL?
wsu:Expires: Verfallsdatum und -zeit
WS-RM-Elemente können im Briefkopf einer SOAPNachricht erscheinen.
wsrm:SequenceFault: Fehlermeldung bzgl. Sequenzen,
wie z.B. wsrm:SequenceTerminated oder
wsrm:InvalidAcknowledgement
Elemente wie z.B.
<wsrm:DeliveryAssurance Value="wsrm:AtLeastOnce"/>
wsrm:DeliveryAssurance: verlangte Zuverlässigkeit, z.B.
AtLeastOnce oder InOrder
machen in SOAP-Nachrichten allerdings keinen Sinn.
Solche Elemente werden in einer WSDL-Beschreibung
integriert.
wsrm:InactivityTimeout: wie lange ein Empfänger
höchstens auf die nächste Nachricht warten muss
39
Zweistufige Integration in WSDL
Gleiches Vorgehen auch bei anderen Erweiterungen:
WS Addressing
…
WS Policy
WSDL
40
<wsdl:definitionsname="PurchaseOrder"
name="PurchaseOrder"…>
…>
<wsdl:definitions
<wsdl:messagename="OrderRequest">
name="OrderRequest">
<wsdl:message
<wsp:Policy>
<wsp:Policy>
<wsrm:DeliveryAssuranceValue="wsrm:ExactlyOnce"
Value="wsrm:ExactlyOnce"
<wsrm:DeliveryAssurance
wsp:Usage="wsp:Required"/>
wsp:Usage="wsp:Required"/>
</wsp:Policy>
</wsp:Policy>
…
…
</wsdl:message>
</wsdl:message>
<wsdl:messagename="OrderAccept">
name="OrderAccept">
<wsdl:message
…
…
hier wsp:Policy
wsp:Policy als
als Erweiterungselement
Erweiterungselement
</wsdl:message>
hier
</wsdl:message>
… tatsächlich erlaubt aber WSDL für message und
…
tatsächlich erlaubt aber WSDL für message und
</wsdl:definitions>
</wsdl:definitions>
portType keine Erweiterungselemente
2. Diese Kommunikationsregeln werden dann in WSDL
integriert.
WS Security
Beispiel
1. WS-RM-Elemente werden als Kommunikationsregeln
(policy) formuliert – und zwar mit Hilfe von WS Policy.
WS RM
38
portType keine Erweiterungselemente
daher etwas
etwas andere
andere Kodierung
Kodierung mit
mit Attributen
Attributen
daher
41
42
7
Bewertung der Erweiterungen
+ einzelne Erweiterungen unabhängig voneinander
+ meist gemeinsame Vorschläge von Microsoft und IBM
Bewertung der
Erweiterungen
-
noch keine etablierten Standards
-
WS Policy Grammatik zur Festlegung von qualitativen
Aspekten, einzelne qualitative Aspekte müssen noch
standardisiert werden
prinzipiellen Hürden,
Hürden, jedoch
jedoch noch
noch
Keine prinzipiellen
Keine
ein langer
langer Standardisierungsweg
Standardisierungsweg zu
zu gehen!
gehen!
ein
43
44
Lernziele
; Wie wird WSDL verwendet?
; Anforderungen der Praxis
; Erweiterungen von SOAP/WSDL
Kurze Wiederholung von
Themen, die bei Rücksprachen
Probleme bereiteten.
nächste
nächste
Woche
Woche
Diskussionswürdiges
45
8