Programmieren II. WebServices. Institut für Angewandte Informatik

Transkript

1 Programmieren II WebServices KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft

2 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

3 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

4 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

5 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

6 Anwendungsszenario für Web Services mit SOAP 6 W. Süß, T. Schlachter

7 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

8 Probleme bei Web Services Zuverlässigkeit der Services Vielzahl von Serviceschnittstellen Performance bei der Prozessverteilung Haftung für Leistungen 8 W. Süß, T. Schlachter

9 SOAP - Simple Object Access Protocol SOAP ist ein Protokollstandard des W3C ( 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 über die SMTP/POP3-Protokolle versandt werden. 9 W. Süß, T. Schlachter

10 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

11 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

12 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

13 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

14 Aufbau einer SOAP Message Format XML Definition durch XML-Schema SOAP Envelope SOAP Header SOAP Body 14 W. Süß, T. Schlachter

15 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

16 Eine kleine Anfrage (SOAP-Request) POST /Sample HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: 234 SOAPAction: "GetLastTradePrice" müssen übereinstimmen <SE:Envelope xmlns:se= SE:encodingStyle=" <SE:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>def</symbol> </m:getlasttradeprice> </SE:Body> </SE:Envelope> 16 W. Süß, T. Schlachter

17 Und die Antwort (SOAP-Response) HTTP/ OK Content-Type: text/xml; charset="utf-8" Content-Length: 178 <SOAP-ENV:Envelope xmlns:soap- ENV= SOAP- ENV:encodingStyle=" <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

18 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=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:babelfish xmlns:ns1="urn:xmethodsbabelfish" SOAP- ENV:encodingStyle=" <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

19 SOAP-Response HTTP/ OK Date: Thu, 03 Sep :01:13 GMT Server: Apache/ (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=" SOAP- ENV:encodingStyle=" xmlns:xsi=" xmlns:soap-env=" xmlns:xsd=" <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

20 WSDL Web Services Description Language 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

21 WDSL Inhalte Service Interface Datei Datentypen Message Typen Operationen Port-Typen Bindings Server Implementations Datei Port Service 21 W. Süß, T. Schlachter

22 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

23 UDDI - Universal Description, Discovery, and Integration UDDI ( 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

24 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

25 Zusammenspiel von UDDI, WSDL und SOAP 25 W. Süß, T. Schlachter

26 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. Sehr gute Beschreibung von SOAP Web Services mit AXIS unter 26 W. Süß, T. Schlachter

27 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

28 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

29 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