Denny Sternberg
Webservices
Entwicklercamp 2015
>> Bei Fragen, einfach fragen!
2
Denny Sternberg
• Seit 2001 entwickeln und admininstrieren von Lotus Domino
• IBM Certified Application Developer, System Administrator
• Instructor seit 2003
06182 - 7869432
W e b s e r v i c e
Web Serv ices – worum geht es?
3
>>
„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)
W e b s e r v i c e
Web Services – worum geht es?
4
>>
• 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
W e b s e r v i c e
Web Services - Entwicklung
5
>>
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
Vorteile von Web Services
6
>>
Offene Punkte/Fehlende Funktionalität
• Sicherheit von Diensten
• Transaktionskontrolle
• Prozess-Steuerung
Diese Punkte muss die Applikation selber beinhalten oder der Entwickler selber implementieren
Nachteile von Webservices
7
>>
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)
Gibt es andere Arten von „Service“ ?
8
>>
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
Kurze Beschreibung von REST
9
Webserv ices
10
>>
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
Was sind Webservices?
11
SOAP, WSDL, UDDI
12
>>
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
Beide basieren auf XML
SOAP, WSDL, UDDI
13
>>
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
UDDI
14
SOAP Serv ice Imp lementa t ion Process
L ive Demo Be isp ie l : Password Reset Domino
15
>> Password Reset
16
>>
<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
WSDL
17
>>
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
Erstellen des WSDL
18
Demo WSDL F i le
19
>>
• Classen und Objekte(Komplexe Datentype) erstellen
– Typ Definition
Code Erstellprozess
20
>>
• Code erstellen der die eingehenden XML „Objekte“ kontrolliert/validiert und in die Ziel Objekte
umsetzt(LS, Java,….)
Code Erstellprozess
21
>>
• Den eigentlichen Code aufrufen und ausführen, dabei den „Response code“ mit Werten und
Objekten erzeugen und als XML ausgeben
Code Erstellprozess
22
Demo
23
Webserv ice Verwenden
24
>> Password Reset
25
>>
Importieren des WSDL
• Achtung: Datentypen sind nicht immer
alle kompatibel
• Nicht alle Tools arbeiten auf die gleiche
Weise
Konsumieren
26
>>
• 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“)
Aus der Developer Sicht
27
Demo
28
>> Password Reset
29
>>
• Herstellerneutral
• Framework neutral
• Standard basiert auf HTTP und XML
• Kann einfache und komplexe Datentypen verwenden
• Einfach zu implementieren
Zusammenfassung von SOAP
30
Was kann sch ie f gehen?
31
>>
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“
Was kann schief gehen? (Spezifikation)
32
>>
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)
33
>>
• 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
Was kann schief gehen? (Security)
34
>>
• Verwenden alle UTF-8 haben wir wenig Probleme
• ABER:
– Nicht jeder macht es
– ISO
– Chinesisch
– UTF-16
– SHF-JIS
Was kann schief gehen? (Character Sets)
35
Demo: Domino Usermanagement
Prov ider
36
37
>> Konzept
38
>>
39
Demo: Teamca lendar
Consumer
40
41
>>
• ws.Setcredentials("User", "Password")
– Run as Web User
• Ws.Setendpoint( „url“ )
– Lenkt den Webservice auf diese URL
– Zur Laufzeit (nicht im Consumer Hardcodieren)
Kleines Extra
42
>> Das wars, Fragen?
43