Programmieren II WebServices KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu
Service-orientierte Architektur (SOA) Architekturkonzept, da sich aus Diensten zusammensetzt. 3 Komponenten: Konnektoren: register Registrierung eines Dienstes bei einer Registry find Suchanfrage eines Dienstnutzers an ein Registry bind Herstellen der Bindung eines Dienstes an einen Nutzer execute "Absetzen" einer Anfrage an einen (gebundenen) Dienst 2 W. Süß, T. Schlachter
Service-orientierte Architektur Strikte Trennung von Realisierung eines Dienstes und seiner Beschreibung. Zu jedem Dienst existiert eine separate Schnittstelle (Service Interface) welches den Dienst eindeutig beschreibt. Durch plattformunabhängige Beschreibungstechniken kann nicht nur der Dienst, sondern sogar die zur Realisierung verwendete Plattform abstrahiert werden. Verteilbarkeit (Deployability) - Dienste müssen in verschiedenen Umgebungen lauffähig sein. Dabei sind Eigenschaften wie Plattformund Ortstransparenz zu berücksichtigen. Verfügbarkeit (Availability) - Dienste sollen stets für ein breites Kundenfeld verfügbar sein. (Redundante Installation um Ausfallsicherheit und Verfügbarkeit zu gewährleisten) Sicherheit (Security) 3 W. Süß, T. Schlachter
Web Services Web Services ermöglichen z.b. Abwicklungen von Dienstleistungen und Geschäften über das Internet. Web Services bedeutet automatisierte Kommunikation zwischen Applikationen übers Internet. Es werden also nicht HTML-Seiten zu einem Webbrowser geschickt, die von einem Menschen betrachtet werden, sondern Programme tauschen Daten und starten auf entfernten Rechnern Funktionen (Remote Procedure Call). Während bisher bei verteilten Systemen die elektronische Kommunikation über Rechnergrenzen hinweg meistens per CORBA, RMI oder DCOM erfolgte, nutzen Web Services einfaches XML, meistens über HTTP (SOAP). Web Services basieren auf den Standards SOAP, WSDL und UDDI. 4 W. Süß, T. Schlachter
Web Services mit SOAP Standardisiert, wie auf entfernten Rechnern Funktionen aufgerufen werden und wie automatisierbarer Datenaustausch erfolgt. Das Besondere an SOAP Web Services ist die allgemeine Akzeptanz, Kommunikation ist sogar zwischen den beiden Plattformen Sun/Java und Microsoft/.NET möglich. Anwendungen mit SOAP-Schnittstelle lassen sich leicht kombinieren. 5 W. Süß, T. Schlachter
Anwendungsszenario für Web Services mit SOAP 6 W. Süß, T. Schlachter
Beispiel Onlineshop Ein Kunde möchte in einem Onlineshop Artikel bestellen. Der Onlineshop ist in einem Applikationsserver realisiert. Dieser Applikationsserver überprüft über den SOAP Web Service des Servers A, ob die angegebene Adresse gültig ist, verifiziert über den SOAP-Dienst B die Kreditkartennummer, ermittelt über den SOAP-Dienst C die für das jeweilige Land zu berechnenden Steuern (Umsatzsteuer, Luxussteuer,...), erfragt beim SOAP-Dienst D tagesaktuelle Währungsumrechnungskurse, um den Endpreis korrekt berechnen zu können und zeigt dem Benutzer alle Ergebnisse gesammelt im Webbrowser an. 7 W. Süß, T. Schlachter
Probleme bei Web Services Zuverlässigkeit der Services Vielzahl von Serviceschnittstellen Performance bei der Prozessverteilung Haftung für Leistungen 8 W. Süß, T. Schlachter
SOAP - Simple Object Access Protocol SOAP ist ein Protokollstandard des W3C (http://www.w3.org/tr/soap). Damit werden Applikationen webfähig und Kommunikation zwischen verteilten Applikationen und Objekten wird ermöglicht und standardisiert. SOAP ist ein Remote-Prozeduraufruf-Mechanismus, der mit dem Datendarstellungsprotokoll XML die Anfrage und das Ergebnis verschlüsselt. Informationen, die nicht in XML-ASCII-Text übersetzt werden sollen, wie zum Beispiel Bild- und andere Binärdateien, werden per MIME angehängt. SOAP kann mit verschiedenen Transportprotokollen verwendet werden. Meistens wird HTTP gewählt, aber zum Beispiel könnten SOAP-Anfragen auch per E-Mail über die SMTP/POP3-Protokolle versandt werden. 9 W. Süß, T. Schlachter
SOAP - Simple Object Access Protocol Die Standard-Internetprotokolle erleichtern den Betrieb auch über Firewalls hinweg, was mit CORBA, RMI und DCOM schwieriger zu realisieren wäre. SOAP ist unabhängig von Betriebssystemen, Programmiersprachen und Objektmodellen, kann verschiedene Plattformen verbinden (z.b..net und Java) und ist leichter zu implementieren als CORBA und DCOM. Eine Besonderheit von SOAP ist seine Zustandslosigkeit. Dies bietet Vorteile, zum Beispiel kann besser skaliert werden, aber auch Nachteile, wenn Session- Daten zugeordnet werden müssen (z.b. Warenkorb). Die wichtigsten Vorteile von SOAP sind: Allgemein akzeptierte Standardisierung, Plattformunabhängigkeit, Offenheit, Robustheit und Skalierbarkeit. Der gravierendste Nachteil ist: Mehr Overhead und dadurch etwas geringere Performance wegen des verwendeten Datendarstellungsprotokolls XML. 10 W. Süß, T. Schlachter
Probleme bisheriger Lösungen Herstellerabhängig (RMI, COM, DCOM) Geringe Verbreitung (Corba) Binäre Formate Nicht XML-konform Port der Anwendung oft geschlossen, keine feste Portnummer 11 W. Süß, T. Schlachter
Was ist SOAP? SOAP = XML + HTTP + Anwendungen Kommunikationslösung W3C-Standard Minimalistische Lösung Teil des Web Service Konzepts Nicht objektorientiert 12 W. Süß, T. Schlachter
Vorteile von SOAP Unterstützt durch größte Softwarehersteller Einfachere Kombination verschiedener Dienste Kosten für die Integrations-Middleware sinkt Viele Anwendungen online verfügbar Programmiersprachen-Unabhängigkeit Lesbarer Text (human readable) Datentypen (jenseits des Strings) 13 W. Süß, T. Schlachter
Aufbau einer SOAP Message Format XML Definition durch XML-Schema SOAP Envelope SOAP Header SOAP Body 14 W. Süß, T. Schlachter
SOAP Aufbau Transport-Umschlag (HTTP, SMTP,...) SOAP- Dokument <SE:Envelope> <SE:Header>(optional) Delivery Information <SE:Body>(required) Nutzdaten (payload) <SE:Fault> (optional) 15 W. Süß, T. Schlachter
Eine kleine Anfrage (SOAP-Request) POST /Sample HTTP/1.1 Host: www.sampleserver.com Content-Type: text/xml; charset="utf-8" Content-Length: 234 SOAPAction: "GetLastTradePrice" müssen übereinstimmen <SE:Envelope xmlns:se=http://schemas.xmlsoap.org/soap/envelope/ SE:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SE:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>def</symbol> </m:getlasttradeprice> </SE:Body> </SE:Envelope> 16 W. Süß, T. Schlachter
Und die Antwort (SOAP-Response) HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: 178 <SOAP-ENV:Envelope xmlns:soap- ENV=http://schemas.xmlsoap.org/soap/envelope/ SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m="some-uri"> <Price>34.5</Price> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 17 W. Süß, T. Schlachter
SOAP-Request POST /perl/soaplite.cgi HTTP/1.0 Host: services.xmethods.net:80 Content-Type: text/xml; charset=utf-8 Content-Length: 546 SOAPAction: "" <?xml version='1.0' encoding='utf-8'?> <SOAP-ENV:Envelope xmlns:soap- ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <SOAP-ENV:Body> <ns1:babelfish xmlns:ns1="urn:xmethodsbabelfish" SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <translationmode xsi:type="xsd:string">de_en</translationmode> <sourcedata xsi:type="xsd:string">hallo Welt, Guten Tag</sourcedata> </ns1:babelfish> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 18 W. Süß, T. Schlachter
SOAP-Response HTTP/1.1 200 OK Date: Thu, 03 Sep 2008 08:01:13 GMT Server: Apache/1.3.22 (Unix) Enhydra-Director SOAPServer: SOAP::Lite/Perl/0.52 Content-Length: 546 Connection: close Content-Type: text/xml; charset=utf-8 <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap- ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP- ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema"> <SOAP-ENV:Body> <namesp1:babelfishresponse xmlns:namesp1="urn:xmethodsbabelfish"> <return xsi:type="xsd:string">hello world, good day</return> </namesp1:babelfishresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 19 W. Süß, T. Schlachter
WSDL Web Services Description Language WSDL (http://www.w3.org/tr/wsdl) ist ein XML-Derivat zur Beschreibung der Schnittstellen von Web Services. Spezifiziert einen Web Service. Darin werden Nachrichtenstrom-Formate und Funktionsaufrufe werden definiert. Eine WSDL-Datei kann automatisch aus einer Java- Source-Datei erzeugt werden (z.b. mit dem AXIS- Framework). Aus einer WSDL-Datei kann automatisch passender Java- Source-Code erzeugt werden kann (das bieten die praktisch alle IDEs). 20 W. Süß, T. Schlachter
WDSL Inhalte Service Interface Datei Datentypen Message Typen Operationen Port-Typen Bindings Server Implementations Datei Port Service 21 W. Süß, T. Schlachter
WSDL - Beispiel <?xml version="1.0" encoding="utf-8"?> <definitions > <types> <s:schema elementformdefault="qualified" targetnamespace./> <s:element name="echo"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="echostring" type="s:string"> </s:sequence> </s:complextype> </s:element> <s:element name="echoresponse"> <s:element name="string" nillable="true" type="s:string" /> 22 W. Süß, T. Schlachter
UDDI - Universal Description, Discovery, and Integration UDDI (http://www.uddi.org) ist ein webbasiertes Informationssystem für Web Services. Globaler Verzeichnisdienst Eintragen der eigenen Web Services Suchen nach Web Services Dynamische Anfrage vor Serviceaufruf Öffentliche UDDI-Server bei HP, IBM, Microsoft, SAP 23 W. Süß, T. Schlachter
Inhalt von UDDI White Pages Firmenname und Adresse Kontaktinformationen, WebSite Yellow Pages Business Type, Ort (Adresse), Produkte Industriezweig Green Pages Technische Informationen zum Business Pointer zur WSDL Beschreibung (Text) 24 W. Süß, T. Schlachter
Zusammenspiel von UDDI, WSDL und SOAP 25 W. Süß, T. Schlachter
Die SOAP Engine Apache AXIS Apache AXIS ist eine Open Source Implementierung des Web Service Standards SOAP unter der Lizenz der Apache Software Foundation. AXIS kann für die Entwicklung von Clients, Servern und Gateways verwendet werden. Das Hosting von Web Services, d.h. der Betrieb und das Anbieten von Web Services kann ebenfalls mit AXIS durchgeführt werden. http://ws.apache.org/axis/java/index.html Sehr gute Beschreibung von SOAP Web Services mit AXIS unter http://www.torsten-horn.de/techdocs/java-soap-axis.htm 26 W. Süß, T. Schlachter
Apache SOAP und AXIS (1) Eine verbreitete SOAP-Implementierungen ist das ursprünglich von IBM entwickelte und dann der Apache Group übergebene Apache SOAP und dessen Nachfolger Apache AXIS. Bei Nutzung solcher Frameworks muss sich der Entwickler nicht unbedingt mit dem von SOAP verwendeten XML- Format ("Envelope", "Header", "Body",...) auseinander setzen, da die XML-Daten automatisch erzeugt und geparst werden. Apache SOAP basiert auf Java und besteht aus Client- Bibliotheken, Server-Bibliotheken und einem Servlet, mit dem eingehende Anfragen verarbeitet werden. 27 W. Süß, T. Schlachter
Apache SOAP und AXIS (2) Mit den Client-Bibliotheken wird die SOAP-Anfrage erstellt, an den Server gesendet und die Antwort entschlüsselt. Clientseitig müssen spezielle Klassen und Methoden aufgerufen werden, wie zum Beispiel "Call", "settargetobjecturi()", "setmethodname()", "setparams()", "invoke()" und "getreturnvalue()". Die serverseitigen Module werden in einen Webserver integriert, zum Beispiel im Tomcat. Die per SOAP aufrufbaren Klassen und Methoden brauchen nicht besonders angepasst zu werden. Allerdings muss in einer zusätzlichen XML-Datei ein Deployment-Deskriptor (Bereitstellungs-Beschreibung) zur Verfügung gestellt werden, in dem die zu verwendenden Klassen, Methoden und Aufrufparameter definiert werden und mit dem sie bei der SOAP Engine registriert werden (deployed). 28 W. Süß, T. Schlachter
Ausprobieren! Alles weitere zur Installation des AXIS-Frameworks sowie einige erste Beispiele in den Übungsaufgaben zu Web Services (auf Basis des AXIS-Frameworks). 29 W. Süß, T. Schlachter