Web Services - Zusammenfassung. Autor: Roman Bühler

Transkript

1 Web Services - Zusammenfassung Autor: Roman Bühler (r1buehle@hsr.ch)

2 Web Services Zusammenfassung... 1 Allgemeines... 1 Begriffserklärungen... 1 Grundlagen... 1 Einsatzgebiete... 2 Welche Risiken haben verteilte Systeme?... 2 XML... 2 XML als Basis... 2 DOM (Document Object Model)... 3 SAX (Simple API for XML)... 3 WSDL... 4 Allgemein Hauptelemente / Abstraktionsebenen... 4 WSDL Beispiel... 5 Sprachelemente Operation Types... 6 SOAP... 7 Allgemein... 7 Message-Aufbau... 7 Beispiel Message - Request... 8 Beispiel Message Response... 9 UDDI Allgemein Verschiedene Register Einsatzgebiete Registrierung Suche UDDI Datenstrukturen ebxml Allgemein XML-RPC Allgemein Funktionsweise - Grob Funktionsweise Verfeinert Datentypen Request Format Response Format Zusammenspiel der drei Basis-Technologien RB i

3 Web Services Zusammenfassung Allgemeines Begriffserklärungen XML Extensible Markup Language - Beschreibungssprache - Darauf bauen Web Services auf WSDL Web Services Description Language - Abstraktion der Web Services - Beschreiben die Service Schnittstellen - XML-basierte Technologie zur Definition der Web Service Schnittstellen, Datentypen, Interaktionsmuster, Protokolle SOAP Simple Object Access Protocol - Stellt Kommunikationsmechanismen zur Verfügung, mit deren Hilfe Web Services miteinander kommunizieren können - Definition eines Umschlages und einer Serialisierung von XML- Dokumenten sowie Konventionen für die RPC-basierte Kommunikation UDDI Universal Description and Integration - Registry und Repository Service zum Speichern und bestimmen von Web Service Interfaces - Mechanismus für Speicherung und Kategorisierung von Business- Informationen und Verweisen auf dazu gehörige Web Service Interfaces ebxml Electronic Business XML - Architektur und Spezifikationen zur Automatisierung von Business- Prozessen zwischen Geschäftspartnern Grundlagen - Web Services transformieren XML-Dokumente in und aus IT Systemen - Web Services sind XML-Applikationen in Form von Programmen, Objekten oder Datenbanken - Web Services lehnen sich an HTML und HTTP an o Einweg-Kommunikation (GET) o Asynchrone Kommunikation o Programmiersprachen-unabhängige Datenformate RB

4 - Web Services sind ähnlich wie Adapter - Web Service Aufrufe sind analog zu traditionellen Methoden/Prozedur-Aufrufen Einsatzgebiete - lokal als Client um auf Internet-Applikationen zuzugreifen - In der Enterprise-Application-Integration zur Verbindung unterschiedlicher Technologien und und Applikationen - als Wrapper für Backend-Systeme Welche Risiken haben verteilte Systeme? 8 Trugschlüsse: - Netzwerk ist zuverlässig - Latenzzeit = null - Bandbreite = unendlich - Netzwerk ist sicher - Topologie ändert sich nie - es gibt einen Administrator - Transportkosten = null - Netzwerk ist homogen XML XML als Basis - Web Services verwenden unterschiedliche XML Standards o zur Definition der Elemente, Attribute und Tags o XML-Schema zur Definition der Datentypen, des Inhalts, Struktur und erlaubter Elemente o Namespaces: Eindeutig definierte Namen für das XML Dokument und die Applikationen o Information Set: abstrakte Repräsentation der Dokumente o XPointer: Pointer auf bestimmte Dokumentteile o XPath: Suchbegriffe für mehrere Dokumenhte o XSLT (Stylesheet Language Translation): XML in XML Transformationsbeschreibung o DOM (Document Object Model) und SAX (Simple API for XML) o Beschreibt, wie die Daten manipuliert werden o Beschreibt, wie die Protokolle gebunden werden (z.b. SOAP) RB

5 DOM (Document Object Model) - kann das Dokument mehrmals lesen - enthält ein Objektmodell (Struktur des Dokuments) - liest das Dokument in den Hauptspeicher SAX (Simple API for XML) - liest das Dokument nur einmal - benötigt weniger Speicher - generiert Callbacks (beim Einlesen der Tags) RB

6 WSDL Allgemein - WSDL beschreibt was ein Service tut, wie er aufgerufen wird und wo er gefunden wird - WSDL ist der Kern des Web Service Frameworks, im Einzelnen beschreibt man in WSDL: o Darstellung unterschiedlicher Datentypen o Operationen auf Messages o Mapping von Messages auf den Netzwerk-Transport - WSDL Interfaces sind vergleichbar mit CORBA oder DCOM Interfaces - dient zum Beschreiben und bearbeiten von SOAP Messages - ist ein Rezept, welches beschreibt, wie die Applikations-Apllikations- Kommunikation abzuwickeln ist - WSDL ist für Web Services wie IDL für CORBA 3 Hauptelemente / Abstraktionsebenen 1. Datentyp-Definition o Bestimmt die Struktur und den Inhalt der Message 2. Abstrakte Operationen o Bestimmt die Operationen, welche auf dem Message Inhalt ausgeführt werden dürfen 3. Service Bindung o Bestimmt den Netzwerk-Transport, mit dem die Message übermittelt wird RB

7 WSDL Beispiel <definitions name="hertzreserveservice" targetnamespace=" xmlns=" xmlns:soap=" xmlns:hrs=" <import namespace=" location="file://d:/jaws/book/code/chapter03/wsdl/hertzreserve/hertz_reserve.x sd"/> <message name="hertzreserve"> <part name="request" type="hrs:inputmessage"/> </message> <message name="hertzreserveresponse"> <part name="response" type="hrs:outputmessage"/> </message> <porttype name="hertzreserveporttype"> <operation name="exec"> <input message="hrs:hertzreserve"/> <output message="hrs:hertzreserveresponse"/> </operation> </porttype> </definitions> RB

8 Sprachelemente <definitions> - Container für die Servicebeschreibung - Globale Definitionen (Namensräume) <import> - gleiche Funktion wie include (Java: import) bei Programmierung - bessere Modularisierung möglich <types> - Definition eines neuen eigenen Datentypen - Unterscheidung zwischen <simpletype> und <complextype> <message> - Beschreibung des Message-Austausches - Message-Daten werden abstrakt beschrieben <porttype> - spezifiziert ein Subset von Operationen für einen Endpunkt eines Web Services - (eindeutige Adresse für eine Gruppe von Aktionen, welche einen einzigen Endpunkt besitzen) - Beschreibung ist abstrakt und operationell (Interfaces in Java) <binding> - Bindung an ein konkretes Protokoll (HTTP, SOAP, MIME oder eigenes Protokoll) - <soap-binding> - Bindung wird als SOAP-Message identifiziert <soapoperation> - enthält Informationen über die Operation als Ganzes <soap-body> - Enthält Informationen, wie die MessageTeile in der SOAP Message zusammengesetzt werden <soap-fault> - spezifiziert die Inhalte der SOAP Fault <soap-header> <soap- - gestatten es dem Benutzer, Headers zu definieren headerfault> <soapaddress> - Adressenbindung dient der Angabe einer Adresse für einen Port (eine URI) 4 Operation Types The request-response type is the most common operation type, but WSDL defines four types: Type One-way Request-response Solicit-response Notification Definition The operation can receive a message but will not return a response The operation can receive a request and will return a response The operation can send a request and will wait for a response The operation can send a message but will not wait for a response RB

9 SOAP Allgemein - SOAP ist der Weg, wie man in XML Daten versendet, empfängt und beschreibt das Wie - In SOAP wird alles mittels SMTP oder HTTP transportiert wenig Firewall Probleme, einfacher Aufbau, universell einsetzbar - SOAP unterstützt synchrone und asynchrone Kommunikation - SOAP stellt den Kommunikationsmechanismus für die Verbindung zum Web Service zur Verfügung - SOAP definiert das Messaging Framework für den Austausch von XML Daten - Das Framework ist simpel, einfach zu implementieren und neutral (Betriebssystem, Programmiersprache, Plattform) - SOAP ist eine minimale Basis, auf der komplexere Mechanismen aufgebaut werden können - Headerinhalt: Encoding; Crypto; Skalierbarkeit; Fehlertoleranz; QoS Message-Aufbau SOAP-Messages enthalten (mindestens) einen Umschlag, einen Kopf und einen Rumpf: - Umschlag (Envelope) [Muss] Definiert Start und Ende der Message - Kopf (Header) Enthält optionale Attribute, welche für die Vearbeitung der Message wichtig sind - Rumpf (Body) [Muss] Enthält die in XML beschriebene Messages - Anhänge (Attachment) Optionale Dokumente - RPC Interaktion Definiert, wie RPC-ähnlich mit SOAP kommuniziert werden muss - Verschlüsselung (Encoding) Definiert, wie einfache und komplexe Daten in der Message übermittelt werden können RB

10 Beispiel Message - Request <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle= xmlns:soap-env= xmlns:xsd= xmlns:xsi= xmlns:soap-enc= > <SOAP-ENV:Body> <getkurs> <wkn xsi:type= xsd:string >blabla</wkn> </getkurs> </SOAP-ENV:Body> </SOAP-ENV:Envelope> RB

11 Beispiel Message Response <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle= xmlns:soap-env= xmlns:xsd= xmlns:xsi= xmlns:soap-enc= > <SOAP-ENV:Body> <getkursresponse SOAP-ENV:encodingStyle= > <getkursreturn xsi:type= SOAP-ENC:Array SOAP-ENC:arrayType= xsd:string[3] xmlns:soap-enc= > <item>wert 1</item> <item>wert 2</item> <item>wert 3</item> </getkursreturn> </getkursresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> RB

12 UDDI Allgemein - UDDI registriert und publiziert Web Service Definitionen - Das UDDI Framework definiert ein Datenmodell in XML und SOAP API s für die Registrierung und die Suche von Web Services - UDDI ist ähnlich wie DNS in TCP/IP (replizierte Datenbanken) aufgebaut - UDDI ist ein Verzeichnis von Web Services Verschiedene Register White Pages Yellow Pages Green Pages Grundlegende Infos über eine Firma. Adressen, Kontaktinfos, eindeutige Kennzeichen. Unterschiedliche Kategorisierungen (Taxonomien). Damit können andere diesen Web Service finden Technische Informationen. Diese beschreiben das Verhalten und unterstützende Funktionen der Web Services sowie Infos über deren Adresse. Einsatzgebiete - Für den Geschäftsmann: Eine Art Internet Suchmaschine für Web Services - Software Entwickler: Dienste eintragen, Register abfragen. - Registrierung 1. WSDL Beschreibung erstellen 2. Registrierung mittels UDDI API Suche 1. Client sucht einen Dienst mittels UDDI API 2. Bestimmen der WSDL des Dienstes 3. Generieren der Client Message 4. Versenden der Message zum Dienst RB

13 UDDI Datenstrukturen <businessentity> - grundlegende Infos über ein Business (Kontaktinfos, Kategorisierung, eindeutige Identifizierung, Beschreibungen, Beziehungen mit anderen Businesses) <publisherassertion> - definiert eine öffentliche Relation zwischen zwei <businessentity> Strukturen <businessservice> - eine <businessentity> enthält eine oder mehrere <businessservice> Strukturen - Repräsentiert einen logische Service Klassifikation, mehrere Services (manuelle oder elektronische) - Beschreibung ist wiederverwendbar <bindingtemplate> - ein <businessservice> enthält eine oder mehrere <bindingtemplate> Strukturen - Pointer auf technische Beschreibungen - Zugriffs-URL - Textbeschreibungen (optional) - Referenzen auf eine oder mehrere <tmodel> Strukturen <tmodel> - abstrakte Beschreibung für bestimmte Spezifikationen oder Verhalten eines Web Services - Fingerprint für den Zugriff auf Web Services - enthält Pointer auf die aktuelle Spezifikation der Web Services - gibt also Auskunft über die Einsatzmöglichkeit eines Web Services ebxml Kommt vermutlich (hoffentlich) nicht an der Prüfung. Allgemein - Die Spezifikation von ebxml geht über die Definition von Web Services hinaus - Spezifikation basiert auf SOAP - WSDL wird nicht verwendet - Spezifiziert QoS, Sicherheit, Garantiertes Messaging RB

14 XML-RPC Allgemein - ist eines der einfachsten und fehlertolerantesten Web Service Konzepte - man kann eine beliebige Programmiersprache wählen - RPC passt in das prozedurale Programmierparadigma der 90er Jahre - XML-RPC ist sehr geeignet um unterschiedliche Rechnerumgebungen zu integrieren - XML-RPC ist eine leichtgewichtige Lösung für einfachste Anwendungsfälle Funktionsweise - Grob 1. Daten verpacken 2. Daten übermitteln 3. Daten entpacken Das Ganze geschieht 2mal, sofern man auch einen Wert zurück erhält. Funktionsweise Verfeinert 1. Der Client führt einen Prozeduraufruf aus 2. Der Client verpackt Methodennamen und Parameter in XML ein 3. Der Client setzt einen HTTP POST Request ab 4. Server empfängt den Request und leitet diesen and den XML-RPC Listener weiter 5. Listener parst die Nachricht nach Methodenname und Parameter und sucht passende Methode 6. Methode liefert eine Antwort an den XML-RPC Prozess 7. Prozess verpackt die Antwort in XML 8. Web Server sendet Antwort an den Client zurück 9. Client entpackt und verarbeitet die Nachricht synchron Da das HTTP Protokoll eingesetzt wird, ist die Kommunikation zustandslos (Kontext einer Transaktion zwischen 2 Anfragen wird nicht gespeichert) und synchron (auf ein Request folgt immer ein Response) RB

15 Datentypen - Einfache Datentypen: o Integer o Fliesskomma o Boolean o String o datetime o binary <value><int>n</int></value> <value><double>n</double></value> <value><boolean>0</boolean></value> <value>string</value> <value><datetime.iso8601> <value><base64> </base64></value> - Zusammengesetzte Datentypen o Arrays <value><array><data> <value></value> <value></value> </data></array></value> o struct <value><struct> </struct></value> <member> <name></name> <value></value> </member> <member> <name></name> <value></value> </member> Request Format - Ein Request besteht aus 2 Teilen: o HTTP Header o XML Payload POST /meinservice.php HTTP/1.0 User Agent: PHP XMLRPC 1.0 Host: xmlrpc.meinpc.com Content-Type: text/xml Content-Length: 216 <?xml version= 1.0?> <methodcall> <methodname>print</methodname> <params><param> <value>test</value> </param></params> </methodcall> RB

16 Response Format - 2 Möglichkeiten o Korrekte Antwort o Fehlermeldung <?xml version= 1.0?> <methodresponse> <params><param> <value> <string>test</string> </value> </param></params> </methodresponse> <?xml version= 1.0?> <methodresponse> <fault> <value><struct> <member> <name>faultcode</name> <value><int>3</int></value> </member> <member> <name>faultstring</name> <value> <string>fehler</string> </value> </member> </struct></value> </fault> </methodresponse> - Header HTTP/ OK Date: Wed 18 Dec :43:00 GMT Server: Apache Connection: close Content-Type: text/xml Content-Length: 818 Der Response Code ist immer 200 OK! RB

17 Zusammenspiel der drei Basis-Technologien Applikation SOAP Client HTTP Request HTTP Response SOAP Processor WSDL Web Service Business Logik Lookup UDDI Repository» Der Client sucht den Dienst in der UDDI Registry» Mit der Beschreibung findet er den Dienst auf einem Host (SOAP Prozessor)» Der Client sendet eine Anfrage mithilfe von HTTP» Und erhält das Ergebnis ebenfalls über HTTP RB