Webservices. Entwicklercamp Denny Sternberg

Transkript

1 Webservices Entwicklercamp 2015 Denny Sternberg

2 Bei Fragen, einfach fragen! Denny Sternberg Seit 2001 entwickeln und admininstrieren von Lotus Domino IBM Certified Application Developer, System Administrator Instructor seit

3 W e b s e r v i c e Web Services w orum geht es? 3

4 W e b s e r v i c e Web Services worum geht es? Ein Web Service ist eigentlich nicht viel mehr als eine dynamische Webseite. Der Unterschied besteht darin, dass normale Webseiten die Sprache HTML verwenden und sie normalerweise ein Browser dem Anwender präsentiert. Im Unterschied dazu liefert ein Web Service XML-Daten, die nicht für die unmittelbare Anzeige gedacht sind, sondern von einem speziellen Client-Programm weiterverarbeitet werden... (c t) 4

5 W e b s e r v i c e Web Services - Entwicklung 2000: W3C-Konsortium (Microsoft, IBM, Sun...) verabschieden SOAP-Spezifikation (Simple Object Access Protocol) 2000: REST (Representational State Transfer) wird von Roy Fielding in seiner Dissertation beschrieben 2001: WSDL (Web Services Description Language) 2002: Google und Amazon veröffentlichen Web-Service-Schnittstellen 2005: Yahoo! veröffentlicht Web-Service-Schnittstelle 5

6 Vorteile von Web Services Alle Vorteile komponentenbasierter Architekturen wie CORBA, J2EE oder.net Unabhängigkeit von Plattformen, Systemen, Sprachen Flexibilität, evolutionäres Vorgehen der Entwicklung Skalierbarkeit, Wiederverwendbarkeit, Integration,... Verwendung der bestehenden Business Logik und Datenspeichers Hohe Akzeptanz und Verbreitung basiert auf im Internet etablierten Standards (HTTP,XML) einfach (leichtgewichtige Kommunikation), relative niedrige Einstiegshürde 6

7 Nachteile von Webservices Offene Punkte/Fehlende Funktionalität Sicherheit von Diensten Transaktionskontrolle Prozess-Steuerung Diese Punkte muss die Applikation selber beinhalten oder der Entwickler selber implementieren 7

8 Gibt es andere Arten von Service? Alles mögliche kann ein Service sein Client/Server Architekturen SOA (Service Oriented Architecture) ABER, zwei Arten sind stark verbreitet: SOAP (Simple Object Access Protokoll) REST ( Representational State Transformation) 8

9 Kurze Beschreibung von REST 9 Es dreht sich in einer REST-Architektur alles um Ressourcen Adressierbarkeit: Jede Ressource muss über einen eindeutigen Unique Resource Identifier (kurz URI) identifiziert werden können. Zustandslosigkeit: Die Kommunikation der Teilnehmer untereinander ist zustandslos. Dies bedeutet, dass keine Benutzersitzungen (etwa in Form von Sessions und Cookies) existieren, sondern bei jeder Anfrage alle notwendigen Informationen wieder neu mitgeschickt werden müssen. Einheitliche Schnittstelle: Jede Ressource muss über einen einheitlichen Satz von Standardmethoden zugegriffen werden können. Beispiele für solche Methoden sind die Standard-HTTP-Methoden wie GET, POST, PUT, und mehr. Entkopplung von Ressourcen und Repräsentation: Das bedeutet, dass verschiedene Repräsentationen einer Ressource existieren können. Ein Client kann somit etwa eine Ressource explizit beispielsweise im XML- oder JSON-Format anfordern. Domino: URL Command:?readviewentries&outputformat=json

10 10 Webservices

11 Was sind Webservices? Komponente, die ihre Funktionalität über eine veröffentlichte Schnittstelle anbietet und über ein offenes Protokoll im Internet zugreifbar sind Verwendet ausschließlich die Internetstandards XML und HTTP Bausteine: WSDL (Web Service Definition Language) UDDI (Universal Service Description, Discovery, and Integration) SOAP (Simple Object Access Protocol) ist kompliziertet wie REST Erfordert Technologie Designen und in der Laufzeit 11

12 12 SOAP, WSDL, UDDI

13 SOAP, WSDL, UDDI Die drei Technologien ergänzen sich, sind aber unabhängig voneinander! SOAP (Simple Object Access Protocol): Übernimmt die Aufgabe des Protokolls Nachrichtenübertragung vom Server zum Client und umgekehrt Unterliegt den W3C-Standards WSDL (Web Services Description Language): Beschreibungssprache für den Webservice Beschreibung von Operationen und Nachrichten unabhängig von den Netzwerkprotokollen Gibt die URLs/Endpunkte an 13 Beide basieren auf XML

14 UDDI Der Service Provider veröffentlich seine Services bei einem Server Broker Ablage der WSDL- Datei bei einem UDDI Register Weitere Informationen zum Web Service Anbieter und technische Beschreibung Hat sich bis heute nicht wirklich durchgesetzt 14

15 SOAP Service Implementation Process Live Demo Beispiel: Password Reset Domino 15

16 16 Password Reset

17 WSDL <types>: Definiert die einfachen und komplexen Datentypen die verwendet werden. Komplexe Datentypen bestehen aus einer Zusammenstellung von mehreren einfachen Datentypen <message>: Definiert Ein- und Ausgabeparameter <porttype>: Definiert die aufrufbaren Funktionen <binding>: Definiert Nachrichtenformat und das zu verwendende Protokoll <service>: Definiert den Endpunkt, also die Adresse über die der Webservice Provider erreichbar ist 17

18 Erstellen des WSDL 18 Zwei Möglichkeiten: Das WSDL generieren von einer selbst geschriebenen Klasse Code/Interface Programmieren und daraus WSDL erzeugen Generierung des Skelets aus Bestehenden WSDL Erstellung des Codes auf der Basis des Skelets Ähnlich bei der Erstellung des Consumers Welche Tools kann ich verwenden! Java: Apache AXIS ( Sun JAXB (Java Architecture for XML Binding).NET: Visual Studio LotusScript: Domino Designer

19 19 Demo WSDL File

20 Code Erstellprozess Classen und Objekte(Komplexe Datentype) erstellen Typ Definition 20

21 Code Erstellprozess Code erstellen der die eingehenden XML Objekte kontrolliert/validiert und in die Ziel Objekte umsetzt(ls, Java,.) 21

22 Code Erstellprozess Den eigentlichen Code aufrufen und ausführen, dabei den Response code mit Werten und Objekten erzeugen und als XML ausgeben 22

23 23 Demo

24 24 Webservice Verwenden

25 25 Password Reset

26 Konsumieren Importieren des WSDL Achtung: Datentypen sind nicht immer alle kompatibel Nicht alle Tools arbeiten auf die gleiche Weise 26

27 Aus der Developer Sicht Erstellung einer Instance des Services Rufe die Methode auf Erhalte eine Antwort Mögliche Exceptions: Client beim lesen der Response Service Provider (SOAP Response: FAULT ) 27

28 28 Demo

29 29 Password Reset

30 Zusammenfassung von SOAP Herstellerneutral Framework neutral Standard basiert auf HTTP und XML Kann einfache und komplexe Datentypen verwenden Einfach zu implementieren 30

31 31 Was kann schief gehen?

32 Was kann schief gehen? (Spezifikation) Man versucht es nicht Standard!= Standard Spezifikations Anwälte Beispiel Amazon/Google Webservices: Nimm eine WSDL importiere sie in Notes oder RAD Schreibe eine PMR und frag Warum du 100 oder mehr Fehler bekommst Array von Objekten RAD(J2EE), Amazon.NET IBM und Microsoft haben unterschiedlicher Meinung zu den Standards 32

33 Was kann schief gehen? (Security) 33 Welche Security? Was brauchen wir für eine Security? Erreichbarkeit ( Kann ich den Webservice erreichen oder nicht?) Netzwerk Intern/extern XML unlesbar machen (Verschlüsseln?) SSL (einfach) Oder Key basierend Authentifizieren beim aufrufen auf dem Server Digitale Signaturen Gemeinsame Zertifikate Vertrauenswürdige Directories

34 Was kann schief gehen? (Security) Authentifizieren bei der Antwort an dem Client Zugriff auf den Server Authentifizierter User SOAP über Mehrere Server Client -> Server -> Server. Signaturen Reihenfolge der Umsetzung Anmelden und verschlüsseln? Oder Verschlüsseln und Anmelden ACL XML Verschlüsslung oder Signaturen verwenden 34

35 Was kann schief gehen? (Character Sets) Verwenden alle UTF-8 haben wir wenig Probleme ABER: Nicht jeder macht es ISO Chinesisch UTF-16 SHF-JIS 35

36 Demo: Domino Usermanagement Provider 36

37 37

38 38 Konzept

39 39

40 Demo: Teamcalendar Consumer 40

41 41

42 Kleines Extra ws.setcredentials("user", "Password") Run as Web User Ws.Setendpoint( url ) Lenkt den Webservice auf diese URL Zur Laufzeit (nicht im Consumer Hardcodieren) 42

43 43 Das wars, Fragen?