1. Einführung 2. DTD 3. XML Schema 4. XPath 5. XSLT 6. XSL-FO 7. XQuery 8. Web Services 9. XML und Datenbanken

Transkript

1

2 Web Services

3 1. Einführung 2. DTD 3. XML Schema 4. XPath 5. XSLT 6. XSL-FO 7. XQuery 8. Web Services 9. XML und Datenbanken

4 Definition: Architektur Verwendung

5 Web Services: Definition A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machineprocessable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. [1] [1] Vgl. W3C, 2004, Web Services Architecture, Abschnitt 1.4 What is a Web service?, W3C Working Group Note 11 February 2004 unter

6 Web Services: Definition Die nachfolgenden Konzepte lassen sich grundlegend aus dieser Definition ableiten: Interoperabilität: Die Technologie soll Software-Architekturen ermöglichen, die auf verteilten Netzwerkressourcen installiert sind und möglichst einfach einen Austausch zwischen ihnen ermöglichen. Dies betrifft verschiedene Anwendungen in unterschiedlichen Programmiersprachen oder natürlich auch unterschiedliche Betriebssysteme. Maschine-zu-Maschine-Kommunikation: Es stehen nicht konkrete Benutzereingaben im Vordergrund, sondern vielmehr der strukturierte und vielfältig angetriebene Datenaustausch zwischen Software- Einheiten. Maschinenlesbare Beschreibung der Schnittstelle: Damit auch die Nutzung, das Auffinden und Auswählen von Web Services in automatisierter Form durch Software-Einheiten vorgenommen werden kann, werden die Schnittstellen in einer standardisierten Weise beschrieben und ebenfalls automatisiert ausgewertet. Strukturierte Nachrichtenaustausch auf Basis von SOAP: Als Quasi-Standard für ein umschließendes und grundlegend strukturiertes Nachrichtenformat wird SOAP benutzt. Es ist ebenfalls ein XML-Standard bzw. ein XML-Format wie die eigentlich übertragenen Daten. Strukturierte Nachrichtenübertragung über HTTP: Die bestehenden Netzwerkübertragungsmöglichkeiten und darunter insbesondere HTPP werden für die Datenübertragung genutzt. Strukturierte Nachrichtendarstellung in XML: Die eigentlichen Nachrichten erfolgen in einem XML- Format, das speziell für die Anwendung entwickelt wurde oder auch wieder einem Standard folgt, der außerhalb der konkreten Anwendung existiert. Verwendung zusätzlicher XML-Standards: Für die Beschreibung von Datentypen, die Struktur der Nachrichten sowie zusätzlche Anforderungen wie Sicherheit werden weitere XML-Standards bzw. Standards des W3C eingesetzt. Dadurch wird u.a. gewährleistet, dass durch ausschließlich standardisierte und herstellerunabhängige Technologien ein hoher Verbreitungsund Nutzungsgrad eingehalten wird.

7 Web Services: Funktionsweise Nachfrager Übereinstimmung Semantik und Webservice- Beschreibung Anbieter Semantik wsdl. xml Agent (Nachfrager) Interaktion soap.xml Agent (Anbieter) Funktionsweise eines Webservice

8 Web Services: Webservice und Agent Der Begriff Webservice selbst wird mehr in Form eines Konzepts verstanden. Es handelt sich um eine Software, die als Agent verstanden werden kann und die den Dienst durch den Empfang und den Versand von Nachrichten implementiert. Der Agent ist dabei diejenige Entität, die für den Nachrichtenaustausch zur Verfügung steht, während der Webservice durch die angebotenen Operationen errichtet wird. Beide Konzepte (Agent und Webservice) sollen deutlich voneinander getrennt werden. Der Agent wird durch eine gegebene Programmiersprache implementiert, deren genaue Verwendung sich genauso ändern kann wie die genutzte Programmiersprache selbst. Sofern allerdings die verschiedenen eingesetzten Technologien die gleichen Operationen anbieten, handelt es sich um denselben Webservice.

9 Web Services: Anbieter und Nachfrager Ein Webservice wird auf Bestreben und unter der Zielsetzung seines Besitzers eingerichtet. Dies können eine Person oder eine Organisation wie z.b. auch ein Unternehmen sein. Die einrichtende Einheit wird als Anbieter verstanden, welche einen geeigneten Agenten für das Angebot eines Webdienstes erstellt. Auf der anderen Seite existiert ein Nachfrager, der ebenfalls in konkreter Gestalt einer Person oder Organisation auftreten kann und der den angebotenen Dienst nutzen möchte. Dies geschieht über einen nachfragenden Agenten, der mit dem Agenten des Anbieters geeignete und vom Anbieter in ihrem Format festgelegte Nachrichten austauscht und Antworten empfängt. In den verschiedenen Anwendungsfällen für Webservices gibt es genügend Beispiele für Einsatzbereiche, in denen der erste Schritt gerade nicht vom Nachfrager ausgeht, sondern vom Anbieter, aber dies soll die beiden Konzepte nicht in ihrer Benennung und Beschreibung verändern oder beeinflussen.

10 Web Services: Beschreibung Die Webservices-Beschreibung ist zunächst nicht notwendigerweise im vom W3C vorgeschlagenen und standardisierten WSDL-Format zu verfassen. Vielmehr ist für die Basisarchitektur überhaupt eine Dienstbeschreibung notwendig, welche ebenfalls als maschinenlesbares Dokument vorliegt und inhaltlich die Operationen und ihre Signaturen festlegt. Darüber hinaus soll es auch das Nachrichtenformat beschreiben - sofern keine primitiven Datentypen wie bei einfachen Methoden zum Einsatz kommen -, das Transportprotokoll und sonstige technische Informationen wie Netzwerkadressen enthalten, die für die konkrete Nutzung des Diensts unverzichtbar sind.

11 Web Services: Nutzung Für die Verwendung von Webservices ist eine Reihe von Schritten notwendig, die sich folgendermaßen charakterisieren lassen. Zunächst müssen Anbieter und Nachfrager überhaupt Kenntnis voneinander erlangen und sich gegenseitig bekannt machen. Dies geschieht im einfachsten Fall außerhalb der Software, indem für den Entwickler eines nachfragenden Agenten bereits die Netzwerkadresse und möglicherweise auch die Funktionsweise und die Bedeutung des Dienstes geläufig ist. Alternativ kann dies allerdings auch im Rahmen einer automatisierten Suche in einem Verzeichnis unter Zuhilfenahme eines weiteren Dienstes gelingen. Beide Parteien müssen sich über die Formate der ausgetauschten Nachrichten einigen. Darüber hinaus ist auch eine Einigung bzgl. der Bedeutung des Dienstes zu erzielen. Dies kann sowohl maschinengesteuert sein als auch völlig unabhängig von der durch den Programmierer in der realen Welt erfolgen. Die Beschreibung von Dienst und seine Bedeutung werden von beiden Parteien umgesetzt. Für die Nutzung des Dienstes tauschen Nachfrager und Anbieter Nachrichten in einem vorab festgelegten bzw. akzeptierten Format aus. Dieser Nachrichtenaustausch ist das eigentliche Ziel der gesamten Interaktion und kristallisiert die Bedeutung und die angebotenen Funktionalität des Dienstes in Form von ausgeführten Operationen und Aufgaben.

12 Web Services: Nutzung 1. Parteien entdecken sich / lernen sich kennen Nachfrager 2. Übereinstimmung Semantik und Webservice- Beschreibung Anbieter 3. Eingabe Semantik und Beschreibung wsdl. xml Semantik Semantik wsdl. xml Semantik wsdl. xml 3. Eingabe Semantik und Beschreibung Agent (Nachfrager) Nutzung eines Webservice 4. Interaktion soap.xml Agent (Anbieter)

13 Web Services: Standards Prozesse Entdeckung Orchestrierung Aggregation Nachrichten (SOAP) Webservice-Beschreibungen (WSDL) Sicherheit Management Basis-Technologien XML DTD XML Schema Kommunikation HTTP SMTP FTP JMS IIOP

14 Web Services: Standards

15 Web Services: Standards Der SOAP-Standard ist ein festgelegtes Datenformat in XML für den Nachrichtenaustausch. Es bietet verschiedene Elemente und Attribute, die einen XML-Rahmen für andere, frei zu modellierende XML-Strukturen bilden, die übertragen werden sollen. Es handelt sich dabei um eine erweiterbare Struktur, deren Ausprägungen in Dateiformat über unterschiedliche Kommunikationskanäle wie HTTP, SMTP, FTP, RMI/IIOP oder sonstige proprietäre Protokolle für den Nachrichtentransport ausgetauscht werden können. Das Akronym löst sich offiziell nicht mehr zu verschiedenen einzelnen Wörtern auf, wobei die Dokumentation zwei unterschiedliche Möglichkeiten anbietet, wie man die verschiedenen Buchstaben verstehen kann und die gleichzeitig auch zwei Grundverständnisweisen von SOAP anbieten. Die eine Auflösung führt zu Service Oriented Architecture Protocol und soll die Möglichkeit in den Vordergrund stellen, Dienste aufrufen und damit nutzen zu können. Die zweite mögliche Auflösung führt zu Simple Object Access Protocol und soll die SOAP RPC (Remote Procedure Call)- Repräsentation betonen, mit deren Hilfe ein entferntes Objekt aufgerufen werden kann, wobei die serialisierte Parameterliste gerade über die Kapselung in einer SOAP- Datei gelingt.

16 Web Services: Standards Für die Beschreibung von Webservices existiert ein weiteres standardisiertes XML-Format namens WSDL (Webservices Description Language), welches solche Angaben wie Operationsnamen, erwartete Parameter bzw. Datenstrukturen beinhaltet sowie weitere Informationen wie z.b. die Adresse, unter welcher der Dienst aufgerufen werden kann, enthält. Diese Datei eignet sich weniger zum selbstständigen Lesen; sie wird auch nicht vom Dienstentwickler tatsächlich von Hand erstellt, sondern über die Plattform, auf welcher der Dienst installiert und abrufbar ist, automatisch generiert. Sie kann in unterschiedlichen Programmiersprachen für die Entwicklung von Zugriffspunkten, Proxy-/ Stellvertreter-Objekten und ähnlichen Techniken genutzt werden.

17 Web Services: Standards

18 Fragen...

19 Webservice-Modelle: Grob- und Feinstruktur der Modelle

20 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Das W3C-Dokument "Web Services Architecture, W3C Working Group Note 11 February 2004" ( stellt im Abschnitt "2.3 The Architectural Models" ( vier verschiedene Architekturmodelle dar, die typische Webservice-Konstruktionen widerspiegeln. Dabei lassen sich natürlich tatsächlich vorhandene Dienste nicht immer vollständig einem dieser Basismodelle zuordnen. Dies kann zum einen daran liegen, dass ein gegebener Dienst Eigenschaften mehrerer Modelle in sich vereint, zum anderen ist dagegen auch bereits in den Modellen eine gewisse Überschneidung untereinander zu sehen, sodass diese Basisarchitekturen mehr als Referenzmodelle und Leuchttürme gelten sollen, was Webdienste bieten bzw. wie sie aufgebaut sein können.

21 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Folgende Modelle lassen sich unterscheiden: Nachrichtenorientierte Modell konzentriert sich auf Nachrichten und deren Struktur, Transport und Austausch, aber nicht für ihre Bedeutung Serviceorientierte Modell konzentriert sich auf die Bereitstellung von Diensten und die Bedeutung von Nachrichten, mit denen die Dienste angetrieben werden Ressourcenorientierte Modell konzentriert sich auf Ressourcen und ihre Besitzer Sicherheits-/Regelorientiertes Modell konzentriert sich auf Sicherheitsaspekte, Erlaubnisse und Profile Regelorientiertes Modell Regel Serviceorientiertes Modell Ressourcenorientiertes Modell Aktion Ressource Nachrichtenorientiertes Modell Nachricht Verwoben mit / Enthaltend

22 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Serviceorientiertes Modell Im Abschnitt "2.3.2 The Service Oriented Model" ( wird ein Modell beschrieben, dessen Fokus auf den beiden Bausteinen Dienst (engl. service) und Aktivität (engl. action) liegt. Sein Ziel ist es, die Beziehungen der Agenten und den zur Verfügung gestellten und nachgefragten Diensten herauszustellen und zu erklären. Sein Fundament bildet das nachrichtenorientierte Modell, stellt allerdings den Dienst bzw. die Aktivität in den Mittelpunkt. Im Zentrum des Modells steht der Dienst, der Aktivitäten und Operationen auf Basis von eingehenden Daten ausführt bzw. selbst Daten als Antwort versenden kann. Er wird von einem Nachfrager genutzt und von einem Anbieter bereitgestellt. Beide stellen Agenten dar, die eine Person oder Organisation verkörpern können. Sie besitzen nicht nur den Dienst, sondern stellen ihn auch für die Nutzung zur Verfügung. Dabei können auch bestimmten Sicherheitsrichtlinien oder überhaupt Regeln (engl. policy) zum Einsatz kommen, welche die Verwendung mit Blick auf einen bestimmten Zielzustand (engl. goal state) näher beschreiben. Der Dienst erfüllt eine bestimmte Dienstaufgabe (engl. service task), die selbst wieder eine Kristallisation einer Dienstrolle (engl. service role) ist, die vom Dienst umgesetzt bzw. gespielt wird. Diese wird wiederum von der besitzenden Person oder Organisation eingerichtet und gefordert. Die ausgeführte Dienstaufgabe resultiert in einer Aktion, welche selbst wiederum den von der Organisation geforderten Zielzustand hervorbringt. Diese Aktion kann eine Nachricht verarbeiten oder zu einer Nachricht in Form einer Antwort führen. Eine Dienstschnittstelle (engl. service interface) legt das Nachrichtenformat fest, wobei diese Beschreibung wiederum von einer allgemeinen Dienstbeschreibung abhängt, die auf der einen Seite die Dienstschnittstelle und auf der anderen Seite die Bedeutung der Dienstaufgabe beschreibt. Schließlich besitzt der Dienst noch eine weitere Eigenschaft. Er kann selbst wieder als Ressource gelten, weil er ja unter einer bestimmten Adresse (URI) aufgerufen werden kann.

23 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Serviceorientiertes Modell Agent Person / Organisation nutzt besitzt / kontrolliert Service beschreibt Nachricht benachrichtigt Meta-Daten

24 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Nachrichtenorientiertes Modell Im Abschnitt "2.3.1 Message Oriented Model" ( wird ein Model beschrieben, dessen Fokus hauptsächlich auf den Nachrichtenaustausch und die Verarbeitung von übertragenen Nachrichten liegt. Dabei ist die Bedeutung (Semantik) der einzelnen Nachrichten oder die Beziehung zwischen diesen nachrangig und außerhalb der Architektur. Es konzentriert sich mehr auf die technischen Bereiche, d.h. auf die Beziehungen zwischen Sendern und Empfängern sowie den Nachrichtentransport/-austausch selbst. Im Zentrum des Modells steht die Nachricht. Sie besitzt Sender und Empfänger, die selbst wieder als Agenten auftreten. Der Empfänger besitzt eine Adresse, zu der die Nachricht geschickt werden soll. Diese wiederum ist vom Mechanismus des Nachrichtentransports bekannt, der neben dem eigentlichen Transport auch für die Verlässlichkeit/Integrität/Unveränderlichkeit der Nachricht zuständig ist. Die Nachricht besteht aus einem Kopf (engl. header) und einem Körper (engl. body) wie viele andere Nachrichten in Softwareanwendungen auch. Neben diesen beiden Bereichen besitzt sie mit Blick auf das SOAP-Format auch einen Briefumschlag (engl. envelope), der hier als Zusammenstellung bzw. Eltern-Element für Körper und Kopf auftritt. Er enthält also beide genannten Bereiche.

25 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Nachrichtenorientiertes Modell Agent liefert verarbeitet hat Nachricht liefert Körper hat Kopf Transport

26 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Ressourcenorientiertes Modell Im Abschnitt "2.3.3 The Resource Oriented Model" ( beschreibt man eine Architektur, deren Zentrum eine Ressource bildet. Sie gelten als besonders wichtiges und zentrales Konzept von Webdiensten, da bspw. ein Webservice selbst auch wieder eine Ressource darstellt. Das Modell konzentriert sich dabei auf die Schlüsselaspekte, die einer Ressource zu eigen sind und die unabhängig von ihrer Rolle als Webservice zu betrachten sind. Dies betrifft die Besitzverhältnisse, Sicherheitsrichtlinien und andere Regeln sowie die allgemeine Verwendung. Im Zentrum des Modells steht eine Ressource. Sie besitzt einen URI, d.h. eine Netzwerkadresse, unter der sie aufgerufen werden kann. Diese befindet sich in einer Ressourcenbeschreibung (engl. resource description), welche sich auf eine Sicherheitsrichtlinie (engl. policy) beziehen kann. Die Ressourcen können eine Repräsentation aufweisen. Eine Person oder Organisation besitzt die unter dem URI auffindbare Ressource und legt die Sicherheitsrichtlinien oder andere die Ressource betreffende Regeln fest. Die Ressource wird von einem Agenten entdeckt, wobei dieser wiederum einen Entdeckungsdienst (engl. discovery service), d.h. einen Verzeichnisdienst für Webservices, zu Rate zieht. Dieser Verzeichnisdienst stellt selbst wiederum einen Dienst bzw. auch eine Ressource dar. Er indiziert die Ressourcenbeschreibung, welcher den URI enthält und damit zur eigentlichen Ressource führt.

27 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Ressourcenorientiertes Modell URI Repräsentation hat kann haben Ressource besitzt / kontrolliert Person / Organisation

28 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Sicherheitsorientiertes Modell Im Abschnitt "2.3.4 The Policy Model" ( wird eine Architektur mit (Sicherheits-)Regeln und Richtlinien im Zentrum beschrieben. Neben Sicherheitsfragen können diese auch Qualitäts- oder Verwendungsfragen betreffen. Die Sicherheit bedient sich konzeptuell des Prinzips der Beschränkung, die das Verhalten von Aktionen oder die Ressourcennutzung betreffen. Gleiches gilt prinzipiell auch für Qualitätsanforderungen. Alle diese Ausprägungen von Richtlinien werden in diesem Modell mit anderen wesentlichen Bausteinen in Beziehung gesetzt, sodass es insgesamt eine einfache Sicherheitsarchitektur vorstellt, die allerdings im konkreten Fall von einer Vielzahl anderer Bereiche berührt wird. Im Zentrum des Modells steht eine Richtlinie (engl. policy). Sie betrifft eine Domäne (engl. domain), die eine Richtlinienbeschreibung (engl. policy description) besitzt, welche wiederum die Richtlinie beschreibt. Die Richtlinie selbst wird von einer Person oder Organisation eingerichtet, die durch sie notwendige Beschränkungen festlegt. Die Person oder Organisation besitzt Agenten und Ressourcen, wobei die Agenten sich auf Ressourcen beziehen. Die Agenten erfordern Erlaubnisse, um bestimmte Aktivitäten (engl. action) durchführen zu können. Diese Erlaubnisse werden in Form der Richtlinien erteilt, organisiert oder auch verweigert. Die Ressource steht unter der Kontrolle eines Wächters (engl. permission guard), welcher die Einhaltung der Erlaubnisse bzw. der Richtlinien erzwingt. Er ermöglicht dadurch die Ausführung von Aktionen. Diese Aktionen wiederum zielen auf Ressourcen ab. Neben dem Wächter, welcher die Erlaubnisse kontrolliert, existiert ein weiterer Wächter (engl. audit guard), der für die Aufzeichnung und Protokollierung von Ressourcenzugriffen und die Durchführung von Aktionen verantwortlich ist. Er stellt die Verpflichtungen (engl. obligation) sicher, welche durch die Richtlinie eingefordert werden.

29 Web Services: Technische Umsetzungsmöglichkeiten und Architektur Sicherheitsorientiertes Modell Person / Organisation Agent unterworfen richtet ein Regel Ressource über über Aktion

30 Fragen...

31 SOAP: Definition XML, XML Schema Aufbau Beispiel

32 SOAP: Definition Obwohl das Akronym SOAP[1] ausdrücklich nicht mehr im Standard definiert wird, so gibt es zwei grundlegende Weisen, in denen es dann doch definiert werden kann: Service Oriented Architecture Protocol: Diese Auflösung weist eher darauf hin, dass hier eine Softwarearchitektur ermöglicht wird, die Dienste für externe Interessenten wie z.b. andere Softwareeinheiten angeboten bzw. mit diesem Protokoll als Datenübertragunstechnik durchgeführt werden können. Simple Object Access Protocol: Diese Auflösung bezieht sich auf eine optionale Variante von SOAP, nämlich die PRC (remote procedure call)- Repräsentationen und beschreibt eher die allgemeine Technik, Funktionalitäten von Softwareeinheiten von außerhalb bzw. entfernt aufgerufen werden können. [1] Vgl.: W3C, 2004, Web Services Architecture, Abschnitt SOAP unter

33 SOAP: Definition Als Material für die Darstellung und Spezifikation von SOAP stellt das W3C im Wesentlichen folgende Dokumente bereit: Einführung (SOAP Version 1.2 Part 0: Primer, Nachrichtenstruktur (SOAP Version 1.2 Part 1: Messaging Framework, Kopfdaten (Resource Representation SOAP Header Block, Ein XML Schema für die SOAP-Nachricht ist unter verfügbar.

34 SOAP: Definition Das SOAP-Format ist aus XML-Sicht nicht besonders umfangreich, da es im Wesentlichen als Container für die zum Server übermittelte Nachricht in XML- Format dient. Je komplexer diese Nachricht ist, desto geringeren Anteil am XML- Baum haben die eigentlichen SOAP-Elemente. Während jeder Webservice eine eigene XML-Nachricht erwartet, dient SOAP dazu, der gesamten Nachricht einen Rahmen zu geben, der automatisiert ausgelesen werden kann und der es ermöglicht, die eigentliche Nachricht von zusätzlichen Informationsbestandteilen zu trennen. SOAP wird aufgrund seiner Elementbezeichnungen immer als Brief dargestellt, da seine wesentlichen Elemente Header und Body in einem Envelope-Element platziert werden und tatsächlich Kopfdaten und den eigentlichen Inhalt enthalten. Zum Server wird allerdings nicht nur eine XML-Nachricht geschickt, sondern tatsächlich eine gesamte HTTP-Anfrage, normalerweise per POST. Eine solche Gesamtanfrage besteht bspw. aus den nachfolgenden Zeilen, wobei diese unbedingt notwendig sind und das Protokoll, die HTTP-Version, den Host, die Anfrageart, die Gesamtlänge der Nachricht und die aufgerufene Methode bezeichnen. Danach erst beginnt der XML-Teil der Nachricht. Sofern man also tatsächlich selbst eine solche Nachricht versenden will, muss in der Anfrage auch dieser Beginn enthalten sein.

35 SOAP: Bedeutung von XML Der gesamte Datenaustausch und die Datenbeschreibung selbst bestehen aus XML-Formaten. XML[1] selbst stellt damit eine Schlüsseltechnologie für die Web Service-Architektur dar, wobei es letztendlich nur die Vorgaben für die allgemeine und abstrakte Datenstruktur liefert. Die Grund-Architektur ermöglicht es daher auch, eigene XML-Formate für den Datenaustausch zu nutzen. Die Datenbeschreibung (Web Services Description Language, WSDL), die Syntax der Beschreibung (XML Schema) sowohl das allgemeine Austauschformat (SOAP) und die Sicherheitsdaten werden wiederum in vom W3C vorgegebenen XML-Formaten gespeichert. Dadurch nutzt man, was die ausgetauschten Daten anbetrifft, eigene Formate und greift allerdings auf standardisierte Formate für die Grundkonzeption einer Anwendung zurück. [1] Vgl.: W3C, 2004, Web Services Architecture, Abschnitt XML unter

36 SOAP: Bedeutung von XML Schema Für die Angabe eines Vokabulars, d.h. für eine grundlegende Datenmodellierung bietet XML Schema die geeigneten Techniken an. Es ersetzt die zusammen mit dem XML-Standard eingeführte Document Type Definition (DTD), welche für XML selbst das Datenmodell bildet. In einer DTD lassen sich zwar bereits grundsätzliche Eigenschaften von XML-Strukturen festlegen wie die Benennung von Elementen und Attributen sowie die Zuordnung von Attributen zu Elementen, ebenso wie die Hierarchiebeziehungen zwischen den Elementen und ihre Kardinalitätseigenschaften, aber es ist nicht möglich, weitergehende Bedingungen für die Textknoten anzugeben. Mit XML Schema dagegen existiert eine umfangreiche Syntax im XML-Format, was ebenfalls bei der DTD nicht gegeben war, da hier ein Spezialformat verwendet wurde. Es besteht die Möglichkeit, Auslagerung und Wiederverwendung für XML Schema-Dokumente durchzuführen, ebenso wie vordefinierte und sogar eigene Datentypen zu verwenden. Die Modellierung erstreckt sich also bei XML Schema nicht nur auf die oben genannten Bereiche, sondern auch auf die Eigenschaften der Textknoten.

37 SOAP: Bedeutung von XML Schema (Datentypen)

38 SOAP: Aufbau Das Dokument hat folgenden Aufbau: Das Wurzelelement heißt Envelope. Es enthält die Namensräume für XML Schema (Präfix: xs, und SOAP selbst (Präfix: env, Zusätzlich kommen im Regelfall noch wenigstens ein Namensraum für die Benutzernachricht hinzu. Es enthält ein optionales Header- und ein verpflichtendes Body-Element. Das Header-Element kann vier SOAP-Standardattribute im gleichen Namensraum und weitere Attribute in einem benutzerdefinierten Namensraum enthalten. Die benutzerdefinierten Informationen sollten tatsächlich als Kopfinformationen aufgefasst werden. Zu den Standardattributen gehören bspw. mustunderstand (Verpflichtung des Empfängers, die Kopfdaten zu verarbeiten) oder encodingstyle (Serialisierungsart von nicht-xml-daten). Das Body-Element kann Attribute und Elemente eines anderen Namensraums enthalten. Insbesondere die Kind-Elemente sind bedeutsam, da sie die eigentlich transportierte Nachricht beinhalten.

39 SOAP: Aufbau

40 SOAP: Aufbau Das Dokument hat folgenden Aufbau: Das Fault-Element stellt die Fehlermeldung eines Webservices dar. Dabei kann es sich entweder um einen technischen Fehler, einen Verarbeitungsfehler von XML oder einen benutzerdefinierten Fehler handeln. Im letzten Fall wird dieses Element programmatisch ausgegeben, in den anderen Fällen dagegen automatisch vom Server erzeugt. Es kann eine Reihe von Kind-Elementen enthalten: Ein verpflichtendes Code-Element mit einer Fehlernummer in einem ebenfalls verpflichtenden Value-Element sowie einer Unterfehlernummer in einem optionalen Subcode-Element. Ein verpflichtendes Reason-Element mit der Angabe eines Grundes in einem oder mehreren Text-Elementen. Ein optionales Node-Element mit der Angabe, an welcher SOAP-verarbeitenden Stelle (Knoten in Form eines URI) der Fehler auftrat. Ein optionales Role-Element mit der Angabe, welche Rolle der Knoten eingenommen hat. Dies sind vorgegebene URIs, wie sie auch im Header-Element im role-attribut erscheinen können. Ein optionales Detail-Element mit Attributen und Kindern eines anderen Namensraums, die zusätzliche applikationsspezifische Informationen enthalten.

41 Fragen...

42 WSDL: Definition Aufbau

43 WSDL: Definition Die Web Services Description Language (WSDL[1]) dient dazu, die relevanten und konzeptionellen Eigenschaften von Web Services in einem XML-Format zu sammeln und damit zu beschreiben. Diese Beschreibungen sind durch das standardisierte Format wie alle anderen XML- Formate maschinenlesbar und werden im so genannten Entdeckungsprozess von Web Services ebenfalls automatisiert in Form eines Verzeichnisses gesammelt, strukturiert und können mit Hilfe des Verzeichnisses auch wieder für die Verwendung gefunden werden. Neben der planerischen Komponente, die im engen Zusammenhang mit dem XML Schema für die Beschreibung der ausgetauschten Daten steht, hat die WSDL auch eine beschreibende und dokumentierende Komponente. Das Ziel solcher Beschreibungen ist letztendlich, dass eine Möglichkeit gefunden wird, Web Services strukturiert zu entdecken, ihre Funktionalität zu erkennen und dann natürlich auch zu nutzen. [1] Vgl.: W3C, 2004, Web Services Architecture, Abschnitt WSDL unter

44 WSDL: Definition A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services: Types a container for data type definitions using some type system (such as XSD). Message an abstract, typed definition of the data being communicated. Operation an abstract description of an action supported by the service. Port Type an abstract set of operations supported by one or more endpoints. Binding a concrete protocol and data format specification for a particular port type. Port a single endpoint defined as a combination of a binding and a network address. Service a collection of related endpoints. [1] [1] Vgl. W3C, 2004, Web Services Description Language (WSDL) 1.1 unter

45 WSDL: Aufbau Ein Dienst wird durch sechs Elemente beschrieben: Types für die Angabe von Datentypdefinitionen der ausgetauschten Nachrichten Message für die abstrakte Beschreibung der ausgetauschten Nachricht, die mit den Datentypen verknüpft sind. porttype für die Angabe von abstrakten Operationen, die sich auf Eingabe- und Ausgabe-Nachrichten beziehen. Binding für die genaue Angabe eines konkreten Protokolls und Datenformats, welche von den Operationen und Nachrichten benötigt wird und sich auf einen speziellen porttype bezieht. Port für die Angabe einer Adresse, an welcher eine Bindung gefunden wird. Service für die Angabe einer Sammlung von verknüpften Ports und damit des eigentlichen Web Service.

46 WSDL: Aufbau Struktur eines WSDL- Dokuments <definitions> <types> </types> <message> </message> <porttype> </porttype> <binding> </binding> <service> </service> </definitions> <definitions> <types> hier werden die verwendeten Datentypen beschrieben </types> <message name= KontoAnfrage > hier werden die Parameter einer Nachricht beschrieben </message> <message name= KontoAuskunft >... </message> <porttype name= KontoZugriffsPort > <operation name= KontoZugriff > <input message= KontoAnfrage /> <output message= KontoAuskunft /> </operation> </porttype>... <binding name= KontoAuskunftSoap >... </binding> <service name= KontoAuskunftsService >... </service> </definitions>

47 WSDL: Aufbau <definitions> - Wurzelelement - Definiert Namespaces*, die im WSDL Dokument gebraucht werden * Namespaces in XML: - Namensräume, durch URI identifiziert - Verhindert Konflikte durch Elemente mit gleichem Namen - Namespace hat Gültigkeit innerhalb eines Elements und aller untergeordneten Elemente <definitions targetnamespace=" xmlns:tns=" xmlns:xsd1=" xmlns:soap=" xmlns=" <import namespace="uri" location="uri"/> * </definitions>

48 WSDL: Aufbau <types> - optional (bei Verwendung einfacher Datentypen) - um komplexe Datentypen zu beschreiben - Einfache Datentypen werden bereits vom XML Schema* offeriert (z.b: string, integer, float, double, date,...) * XML Schema Definition (XSD): - Neuerung vonn Document Type Definition (DTD) - Beschreibt Struktur eines XML Dokuments - In XML geschrieben <definitions... > <types> <xsd:schema... />* </types> </definitions>

49 WSDL: Aufbau <message> - Beschreibt Nachrichten zwischen Client und Service - Besteht aus verschiedenen Parts - Part: Name und Typ Nachricht von Client zum Service: Part entspricht einem Parameter des Funktionsaufrufes Nachricht von Service zum Client: Part entspricht einem Rückgabewert des Funktionsaufrufes <definitions... > <message name="nmtoken"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> </definitions>

50 WSDL: Aufbau <porttype> - Beschreibt die Operationen 4 Arten von Operationen: One-way: Endpunkt erhält nur eine Nachricht und gibt keine Antwort. Request-response: Endpunkt erhält eine Nachricht und sendet eine Antwort. Solicit-response: Der Endpunkt sendet eine Nachricht und erhält eine passende Nachricht. Notification: Der Endpunkt sendet eine Nachricht. <wsdl:definitions... > <wsdl:porttype name="nmtoken"> <wsdl:operation name="nmtoken"... /> * </wsdl:porttype> </wsdl:definitions>

51 WSDL: Aufbau

52 WSDL: Aufbau Notification: Der Endpunkt sendet eine Nachricht. <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken"> <wsdl:output name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:porttype > </wsdl:definitions>

53 WSDL: Aufbau Solicit-response: Der Endpunkt sendet eine Nachricht und erhält eine passende Nachricht. <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken" parameterorder="nmtokens"> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:porttype > </wsdl:definitions>

54 WSDL: Aufbau One-way: Endpunkt erhält nur eine Nachricht und gibt keine Antwort. <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken"> <wsdl:input name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:porttype > </wsdl:definitions>

55 WSDL: Aufbau Request-response: Endpunkt erhält eine Nachricht und sendet eine Antwort. <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken" parameterorder="nmtokens"> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:porttype > </wsdl:definitions>

56 WSDL: Aufbau <binding> Definiert für jede Operation eines porttypes: - Nachrichtenformat (Codierung) - Protokoll WSDL 1.2 definiert Binding für - SOAP HTTP 1.1 GET/ POST - MIME <wsdl:definitions... > <wsdl:binding name="nmtoken" type="qname"> * <-- extensibility element (1) --> * <wsdl:operation name="nmtoken"> * <-- extensibility element (2) --> * <wsdl:input name="nmtoken"? >? <-- extensibility element (3) --> </wsdl:input> <wsdl:output name="nmtoken"? >? <-- extensibility element (4) --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <-- extensibility element (5) --> * </wsdl:fault> </wsdl:operation> </wsdl:binding> </wsdl:definitions>

57 WSDL: Aufbau <port> - Servicenamen name gibt einen einzigartigen Namen für diesen Port an binding referenziert eine Bindung im Dokument extensibility elements (1) werden für die Angabe der Port-Adresse verwendet <wsdl:definitions... > <wsdl:service... > * <wsdl:port name="nmtoken" binding="qname"> * <-- extensibility element (1) --> </wsdl:port> </wsdl:service> </wsdl:definitions>

58 WSDL: Aufbau <service> - Servicenamen name gibt einen einzigartigen Namen für diesen Port an binding referenziert eine Bindung im Dokument extensibility elements (1) werden für die Angabe der Port- Adresse verwendet <wsdl:definitions... > <wsdl:service name="nmtoken"> * <wsdl:port... />* </wsdl:service> </wsdl:definitions>

59 WSDL: Aufbau Weitere Elemente: <documentation> <import> Lesbare Beschreibung des Web Services Importiert ein anderes WSDL Dokument oder ein XML Schema Ermöglicht Aufspaltung in Module z. B: - Typendefinition (XML Schema) abstrakte WSDL Definitionen (messages und porttypes) konkrete WSDL Definitionen (bindings und services)

60 WSDL: Namensräume Präfix Namensraum-URI Definition wsdl WSDL Namensraum. soap WSDL Namensraum für WSDL SOAP-Bindung. http mime soapenc soapenv xsi xsd tns (various) WSDL Namensraum für WSDL HTTP GET & POST Bindungen. WSDL Namensraum für WSDL MIME binding. Zeichensatz-Namensraum von SOAP 1.1 Envelope Namensraum vonsoap 1.1 Instanz-Namensraum von XML Schema XSD XML Schema-Namensraum XSD this namespace (tns) für Referenzierung des aktuellen Dokuments (Beispiele).

61 Fragen