PROC SOAP, PROC HTTP und der ganze REST · 16. KSFE in Leipzig, 8. und 9. März 2012 Martin Haffner: PROC SOAP, PROC HTTP und der ganze REST 08.03.2012 HMS Analytical Software GmbH
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
16. KSFE in Leipzig, 8. und 9. März 2012Martin Haffner: PROC SOAP, PROC HTTP und der ganze REST
08.03.2012
HMS Analytical Software GmbHwww.analytical-software.de 1
• "There are many things that might be called ‘Web services’ in the world at large" (W3C)
• "eine Software‐Anwendung, die mit einem Uniform ResourceIdentifier (URI) eindeutig identifizierbar ist und deren Schnittstelle als XML‐Artefakt definiert, beschrieben und gefunden werden kann" (Wikipedia)
• "a software system designed to support interoperable machine‐to‐machine interaction over a network" (W3C)
• "Da stellen wir uns mal ganz dumm und sagen: Ein Webservice, das ist ein großer, runder, schwarzer Raum – also eine Blackbox ‐ , die hat zwei Löcher, also Schnittstellen. In das eine geben wir die Anfragen rein, und aus dem anderen – das kommt später ‐ kommen die Ergebnisse wieder raus. Es steht alles bei Wikipedia was ich sage, nur nicht so schön!"(frei nach der Feuerzangenbowle)
Woher kennt man den Aufbau von Request und Response?
9
SOAP• Jeder SOAP-Webservice stellt eine Beschreibung seiner
angebotenen Services in Form einer WSDL-Datei (XML) bereit
• Es gibt Tools, die WSDL-Dateien parsen und daraus beispielhafte Requests und Responses erzeugen, die man als Vorlage nehmen kann (z.B. soapUI: http://www.soapui.org/)
REST• Ansätze zur standardisierten Beschreibung mit WADL
sind vorhanden, aber nicht durchgängig verbreitet• In der Regel muss man sich auf die Dokumentation
verlassen, die der Anbieter des Webservices bereitstellt
Webservices: Die "Lingua Franca" (oder der "Babelfisch") der IT
• Universelle Einsetzbarkeit: Jedes System, das HTTP beherrscht, kann Webservices nutzen oder anbieten
• Entkopplung: Weder Client noch Server müssen Details (Betriebssystem, Datenbank, Middleware…) ihres Kommunikationspartners kennen
• Solange die Schnittstelle gleich bleibt, kann die Implementierung des Webservice jederzeit geändert werden, ohne dass der Konsument davon etwas merkt
• Für SAS: Universelle Zugriffsmöglichkeit auf jede andere Art von System, auch wenn SAS dafür noch keine eigene Schnittstelle anbietet
10
16. KSFE in Leipzig, 8. und 9. März 2012Martin Haffner: PROC SOAP, PROC HTTP und der ganze REST
08.03.2012
HMS Analytical Software GmbHwww.analytical-software.de 6
Was haben Webservices mit SAS zu tun…? Ein kleiner Vorgriff.
SAS als Webservice‐Konsument: wenn im Rahmen eines SAS‐Programms Informationen benötigt werden, die woanders als Webservice angeboten werden.SOAP‐Schnittstellen: PROC SOAP, Data Step‐Funktionen, WSDL‐LibnameREST‐Schnittstelle: PROC HTTP
SAS als Webservice‐Anbieter:Wenn ein eigenes SAS‐Programm im Intranet (oder Internet) zur Verfügung gestellt werden sollSchnittstelle (SOAP/REST): Stored Processes
12
16. KSFE in Leipzig, 8. und 9. März 2012Martin Haffner: PROC SOAP, PROC HTTP und der ganze REST
08.03.2012
HMS Analytical Software GmbHwww.analytical-software.de 7
Wie kommt man von seinen Daten zum XML‐Request, und wie zieht man aus der XML‐Response Ergebnisse?• SAS bietet eine Vielzahl von Tools für den XML‐Zugriff
– XML Libname‐Engine– XML‐Maps– PROC XSL– …
• Siehe Tutorial "XML mit SAS leicht gemacht" von Andreas Adlichhammer, KSFE 2011– http://www.analytical‐
• Klare Antwort: Es kommt drauf an • Mit einer XML‐Map kommt man eigentlich fast immer ans
Ziel.• Bei einfachen XML‐Strukturen genügt evtl. auch ein XML‐
Libname ohne Angabe einer Map.– Hier gilt: einfach probieren!
• Wenn einem tatsächlich eine XML‐Struktur über den Weg läuft, die man mit einer Map nicht abdecken kann, kann man immer noch XSL verwenden– Bei Webservice‐Ergebnissen aber eher unwahrscheinlich
• Man kann natürlich auch immer noch die XML‐Response im Data Step parsen. Damit kann man garantiert jede XML‐Response verarbeiten– Viel Spaß
16
16. KSFE in Leipzig, 8. und 9. März 2012Martin Haffner: PROC SOAP, PROC HTTP und der ganze REST
08.03.2012
HMS Analytical Software GmbHwww.analytical-software.de 9
• Zusätzlich können Benutzername und Passwort übergeben werden (auch aus Metadaten-Server)
• Für POST-Anfragen kann mit dem Request auch eine komplette Datei mitgeschickt werden (über einen zweiten Fileref). Wichtig: In diesem Fall Content-Type über Option CT= angeben!
• Performance hängt von sehr vielen Faktoren ab: Netzwerk‐Geschwindigkeit, Performance des aufgerufenen Webservice und der von ihm angesprochenen Komponenten (Datenbank…)
• Einige Tendenzen sind aber dennoch feststellbar:– PROC SOAP ist in SAS 9.3 deutlich schneller als in SAS 9.2 (nach unseren Messergebnissen bis zu ca. 30 Prozent)
– PROC SOAP oder Data Step‐Funktionen machen keinen großen Unterschied
– Ein Aufruf eines REST‐Webservice ist wegen des schlankeren Protokolls in der Regel performanter als der Aufruf eines gleichwertigen SOAP‐Service.
22
16. KSFE in Leipzig, 8. und 9. März 2012Martin Haffner: PROC SOAP, PROC HTTP und der ganze REST
08.03.2012
HMS Analytical Software GmbHwww.analytical-software.de 12
• Der Webservice hat die gleichen Eingabe‐Parameter wie der Stored Process
• Die Response des Webservice enthält die für den Stored Process definierten Ausgabeparameter – und nicht das, was der Stored Process ggf. nach _WEBOUT schreibt!
• Das Umsetzen der Stored Process‐Parameter von oder nach XML übernimmt SAS – es muss nicht selbst programmiert werden
• Es ist nicht notwendig, den Stored Process explizit als Webservice zu deployen!• Ein einziger Stored Process unterstützt automatisch beide Schnittstellenformate,
XML und JSON• Wie bei SOAP enthält die Response des Webservice die für den Stored Process
definierten Ausgabeparameter – und nicht das, was der Stored Process ggf. nach _WEBOUT schreibt!
• Die Umsetzung der Parameter nach XML oder JSON erledigt SAS automatisch
• Mit den SAS‐Prozeduren PROC SOAP und PROC HTTP (bzw. den entsprechenden Data Step‐Funktionen) ist es möglich, auf jeden SOAP‐ oder REST‐basierten Webservice zuzugreifen. Der Webservice muss nichts davon wissen, dass er gerade mit SAS kommuniziert.
• Somit sind Datenaustausch, Aufruf von Funktionen, ganz allgemein die Kommunikation mit jedem System, das Webservices unterstützt, möglich, ohne dass erst aufwändige Schnittstellen programmiert werden müssen
• Über die Webservice‐Anbindung des Stored Process Server kann auch umgekehrt jedes SAS‐Programm als Webservice bereitgestellt werden. So kann SAS‐Funktionalität in andere Systeme eingebunden werden, ohne erst neue Schnittstellen entwerfen zu müssen.
• Gerade die neue JSON/REST‐Schnittstelle zu Stored Processeseröffnet auch sehr komfortable Möglichkeiten des Datenaustausch zwischen SAS und Webfrontends
Besuchen Sie uns auch auf unserem Messestand! Dort … … können Sie im Anschluss mit dem Referenten diskutieren… finden Sie Demos zu diesem Vortrag … können Sie sich über das Angebot von HMS informieren… gibt es Jobangebote … gibt es Informationen für Studenten zu Praktika und Abschlussarbeiten bei