Webservices Entwicklercamp 2015 Denny Sternberg
Bei Fragen, einfach fragen! Denny Sternberg Seit 2001 entwickeln und admininstrieren von Lotus Domino IBM Certified Application Developer, System Administrator Instructor seit 2003 dsternberg@fum.de 06182-7869432 2
W e b s e r v i c e Web Services w orum geht es? 3
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
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
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
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
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
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 Webservices
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 SOAP, WSDL, UDDI
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
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
SOAP Service Implementation Process Live Demo Beispiel: Password Reset Domino 15
16 Password Reset
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
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 (http://ws.apache.org/axis2) Sun JAXB (Java Architecture for XML Binding).NET: Visual Studio LotusScript: Domino Designer
19 Demo WSDL File
Code Erstellprozess Classen und Objekte(Komplexe Datentype) erstellen Typ Definition 20
Code Erstellprozess Code erstellen der die eingehenden XML Objekte kontrolliert/validiert und in die Ziel Objekte umsetzt(ls, Java,.) 21
Code Erstellprozess Den eigentlichen Code aufrufen und ausführen, dabei den Response code mit Werten und Objekten erzeugen und als XML ausgeben 22
23 Demo
24 Webservice Verwenden
25 Password Reset
Konsumieren Importieren des WSDL Achtung: Datentypen sind nicht immer alle kompatibel Nicht alle Tools arbeiten auf die gleiche Weise 26
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 Demo
29 Password Reset
Zusammenfassung von SOAP Herstellerneutral Framework neutral Standard basiert auf HTTP und XML Kann einfache und komplexe Datentypen verwenden Einfach zu implementieren 30
31 Was kann schief gehen?
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
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
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
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
Demo: Domino Usermanagement Provider 36
37
38 Konzept
39
Demo: Teamcalendar Consumer 40
41
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 Das wars, Fragen?