Service-Orientierte Architekturen

Transkript

1 Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 8: REST Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

2 (Vorläufiger) Aufbau der Vorlesung Kapitel Thema 1 Organisation, Einführung in Software-Architekturen 2 Einführung in Service-Orientierte Architekturen 3 Design Prinzipien von Service-Orientierten Architekturen 4 (11.5.) Web Services I (SOAP, WSDL) 5 (18.5.) Web Services II (Axis2, WS-Adressing) 6 (25.5.) Web Services III (BPEL) 7 (1.6.) Web Services IV (Sicherheit, WS-Security) 8 (8.6.) REST Architekturen 9 (15.6.) Einführung in Swordfish 11 (22.6.) Exception Handling in SOA (Gastvortrag) 12 (29.6.) SOA Point of View von Accenture (Gastvortrag) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 2

3 Ziele dieser Unterrichtseinheit Grundlagen des REST-Ansatzes als Alternative zu den bisher dargestellten Technologien zur Entwicklung von Web Services verstehen Bewertung und Einordnung des Ansatzes Implementierungstechniken kennenlernen Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 3

4 Aufbau dieser Veranstaltung Kapitel 8: Einführung in REST 1 Einführung REST 2 Implementierung mit RESTlet 3 Implementierung mit AXIS2 4 Bewertung des Ansatzes 5 Anwendungsszenarien 6 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 4

5 Aufbau einer SOAP-basierten Architektur mit HTTP POST web/my HTTP/1.1 Host myserver.com Content-Type: application/ soap+xml SOAP Envelope. <<entity>> Person getaddress() Client Host <<Service Consumer>> HTTP <<WebService>> ERPService Application Server Web Service ERPService : WSDL <<entity>> Address getcity() SOAP verwendet bekannte Web-Protokolle zur Übertragung von SOAP-Nachrichten Standard ist HTTP: Verwendung der POST-Methode Alternative: SMTP, TCP / IP Web Service übernimmt Dispatcher Rolle <<control>> Process Relocation performrelocation() Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010

6 Binding - SOAP over HTTP SOAP kann HTTP zur Übertragung von SOAP-Nachrichten verwenden Standard-Binding, da transparente Übertragung über Port 80 Ausschließliche Verwendung der POST-Methode des HTTP Protokolls Übernahme der Adress-Daten aus WSDL POST /axis2/services/erpservice HTTP 1.1 Host myserver.com Content-Type: application/soap+xml SOAPAction: urn:getaddress <s:envelope xmlns:s=" <s:header> </s:header> <s:body> <GetAddress xmlns:m=" <m:nachname> Alda </m:nachname> </m:getaddress> </s:body> </s:envelope> HTTP Header HTTP entity-body = SOAP Nachricht HTTP-Request inkl. SOAP Nachricht Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010

7 REST REST stellt einen alternativen Ansatz für die Realisierung von Web Services dar. Basiert auf der Doktorarbeit von Roy Thomas Fielding Ansatz: Zugriff auf einen Web Services durch die unmittelbare Verwendung des HTTP-Protokolls Ressourcen-orientierte Sicht Verwendung von einfachen, vorgegebenen Methoden Unterschied zu W3C-basierten Web Services Kein Nachrichtenformat ( vgl. SOAP) Keine Beschreibung der Schnittstelle ( vgl. WSDL) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 7

8 Aufbau einer REST-basierten Web Services Architektur GET Client POST URL Ressource Ressource PUT Delete Repräsentation Repräsentation HTTP Methoden (=Web Services) Meta-Modell Ressource = Web Seiten, Funktionen, Bilder, Dokumente etc. Eine Ressource kann verschiedene Repräsentationen haben (z.b. XML, JSON) Über eine URL eindeutig identifizierbar und lokalisierbar Zugriff über vier HTTP-Methoden (ggf. weitere Methoden) Web Services Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

9 Hierarchische Anordnung von Ressourcen Ressourcen in REST können hierarchisch angeordnet und verwaltet werden: Ressource (Container) Ressource (Container) Ressource (Item) Ressource (Item) Ressource (Item) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 9

10 Adressierung von Ressourcen Ressourcen in REST können hierarchisch angeordnet und verwaltet werden: Ressource (erp) Ressource (rechnungen) Ressource (lieferscheine)... Ressource (rechnung1) Ressource (rechnung2) In Rest adressiert unter: Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 10

11 HTTP-Methoden in REST GET Abfrage einer Repräsentation einer Ressource POST Hinzufügen einer Ressource in einer gegebenen Hierarchie DELETE Löschen einer Ressource PUT Aktualisierung Daten einer vorhandener Ressource (Statusänderung) Hinzufügen einer Ressource, die nicht in einer gegebenen Hierarchie anderen Ressourcen untergeordnet ist Weitere Implementierungen verwenden weitere Methoden (z.b. HEAD, OPTIONS) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

12 Navigation in einer REST-Architektur Eine Repräsentation kann Links enthalten, die auf weitere Ressourcen verweisen Durch Navigation zu einer anderen Ressource (bzw. zu einer anderen Repräsentation) wechselt Client seinen Zustand Status-Transfer über Repräsentationen REST = REpresentational State Transfer HTTP OK Content-Type: text/xml <adresse> <name>alda</name> <stadt>bonn, NRW</stadt> <telefon xlink:href= </adresse> HTTP Response Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

13 Illustration einer REST-Architektur RESTful Architektur mit zwei Ressourcen: adressspeicher = Kollektion von Adressen (Container) adresse = eine konkrete Adresse (Item) :adressspeicher alda :adresse maier :adresse Visualisierung der GET-Methode (auf Ressource adressspeicher ): Bonn, NRW Köln, NRW GET /adressspeicher/ Host: myserver.com Accept: text/xml HTTP Request Verarbeitung durch Application Server HTTP OK Content-Type: text/xml <adressspeicher> <adresse> <name>alda</name> <stadt>bonn, NRW</stadt> </adresse> <adresse> <name>maier</name> <stadt>köln, NRW</stadt> </adresse> </adressspeicher> Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o HTTP Response

14 Illustration einer REST-Architektur RESTful Architektur mit zwei Ressourcen: adressspeicher = Kollektion von Adressen (Container) adresse = eine konkrete Adresse (Item) :adressspeicher Visualisierung der GET-Methode (auf Ressource adresse ): alda :adresse Bonn, NRW maier :adresse Köln, NRW GET /adressspeicher/ alda Host: myserver.com Accept: text/xml Verarbeitung durch Application Server HTTP OK Content-Type: text/xml <adresse> <name>alda</name> <stadt>bonn, NRW</stadt> </adresse> HTTP Request HTTP Response Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

15 Illustration einer REST-Architektur RESTful Architektur mit zwei Ressourcen: adressspeicher = Kollektion von Adressen (Container) adresse = eine konkrete Adresse (Item) :adressspeicher Visualisierung der POST-Methode: alda :adresse Bonn, NRW maier :adresse Köln, NRW POST /adressspeicher/ schulz Host: myserver.com Accept: text/xml <adresse> <stadt> Münster, NRW </stadt> </adresse> HTTP Request Verarbeitung durch Application Server schulz :adresse Münster, NRW erzeugt HTTP OK Content-Type: text/xml HTTP Response Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

16 Illustration einer REST-Architektur RESTful Architektur mit zwei Ressourcen: adressspeicher = Kollektion von Adressen (Container) adresse = eine konkrete Adresse (Item) :adressspeicher Visualisierung der PUT-Methode (Update): alda :adresse Aachen, NRW maier :adresse Köln, NRW PUT /adressspeicher/ alda Host: myserver.com Accept: text/xml <adresse> <stadt> Aachen, NRW </stadt> </adresse> HTTP Request Verarbeitung durch Application Server aktualisiert HTTP OK Content-Type: text/xml HTTP Response Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

17 Illustration einer REST-Architektur RESTful Architektur mit zwei Ressourcen: adressspeicher = Kollektion von Adressen (Container) adresse = eine konkrete Adresse (Item) :adressspeicher Visualisierung der PUT-Methode (Hinzufügen): alda :adresse Aachen, NRW maier :adresse Köln, NRW PUT /telefonnummern Host: myserver.com Accept: text/xml <rechnungen>. </rechnungen> Verarbeitung durch Application Server erzeugt :rechnungen HTTP OK Content-Type: text/xml HTTP Request HTTP Response Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

18 Weitere Eigenschaften einer RESTful Architektur Zustandslose (Stateless) Web Service Server unterhält keinen Zustand eines Service bzw. eines Clients Client kann eigenen Applikationszustand unterhalten Nachfolge-Aktivitäten werden aus Repräsentationen abgeleitet (Links) Unterstützung von Caches Application Server kann Response als Cache fähig oder nicht Cache fähig deklarieren (z.b. zur Abspeicherung auf Intermediaries) HTTP OK Content-Type: text/xml Cache-Control: max-age=600 [ ] HTTP Response Erhöhung der Skalierbarkeit und Performance (User-Wahrnehmung) einer RESTful Architektur, Einsparung von Netzwerklast Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

19 Software Bibliotheken für REST Eine Vielzahl von Software Bibliotheken für die Entwicklung einer RESTbasierten Web Services Architektur stehen zur Verfügung Unterstütze Programmiersprachen: Java, Ruby, Python Open Source Software Bibliotheken für Java: Java-API für REST JAX-RS 1.0 (Referenzimplementierung Jersey) RESTlet AXIS2 Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

20 Aufbau dieser Veranstaltung Kapitel 8: Einführung in REST 1 Einführung REST 2 Implementierung mit RESTlet 3 Implementierung mit AXIS2 4 Bewertung des Ansatzes 5 Anwendungsszenarien 6 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 20

21 Übersicht RESTlet RESTlet ist eine Open-Source Implementierung des REST-Ansatzes Implementierung basiert auf Java Deployment in einem Servlet-Container oder Stand-Alone Unterstützung aller Web Service Methoden (GET, POST, PUT, DELETE) Download und weitere Informationen: Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010

22 Implementierung einer REST-Architektur Definition und Implementierung der Ressourcen Erweiterung der Klasse ServerResource Bestimmung der Repräsentationen Bestimmung der Zugriffsmethoden Definition und Implementierung der Hierarchie Bestimmung von URL für den Zugriff auf der Hierarchie Zuordnung wie über eine URL auf Ressourcen zugegriffen werden kann (Klasse Router) Kapselung von zugehörigen Ressourcen in einer Application Zugriff über eine Application über eine Component (Stand-Alone) Parametrisierung mit einem HTTP-Server Übergabe der Application Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010

23 Code-Demo: Verwendung von RESTlet Implementierung der Ressource Adresse import org.restlet.*; public class AdressRessource extends ServerResource { private String adressforname; private Adresse protected void doinit() throws ResourceException { } // Ermittlung des Key-Attribut (Name = Inhaber der Adresse) aus der URI, // für das die Adresse geliefert werden soll: this.adressforname = (String) getrequest().getattributes().get( user"); // Ermittlung der Adresse this.adresse = DB.getAdresse( adressforname public Representation toxml() { } } // Erzeugung des XML Codes basierend auf den übergebenen Key-Attribut Java Code Ressource Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

24 Code-Demo: Verwendung von RESTlet Implementierung des ERPService import org.restlet.*; public class ERPService extends Application public Restlet createroot() { // Erzeuge einen Router für die Ressourcen. Router router = new Router( getcontext() ); // Definiere einen Pfad für die Ressource ErpService" router.attach("/erpservice", ErpService.class); // Definiere einen Pfad für die Ressource Adresse mit parametrisierten Key router.attach("/erpservice/adressen/{user}", AdressRessource.class); return router; } } Java Code ERP-Service (für Servlet) Coding Compile javac *.java Generate Servlet Run Server Keine Stub-Erzeugung notwendig! Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

25 Code-Demo: Verwendung von RESTlet Implementierung des ERPService in einem Application Server import org.restlet.*; public class StandAloneApplicationServer { public static void main(string[] args) throws Exception { // Create a new Component. Component component = new Component(); // Add a new HTTP server listening on port component.getservers().add(protocol.http, 8182); // Attach the sample application. component.getdefaulthost().attach( new ERPService()); } } // Start the component. component.start(); Java Code Application Server (inkl. ERPService) Coding Compile javac *.java Run Server Keine Stub-Erzeugung notwendig! Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

26 Code-Demo: Verwendung von RESTlet Implementierung des REST Client import org.restlet.resource.clientresource; public class RESTClient { public static void main(string[] args) throws IOException, ResourceException { // Aufbau zum Application Server, Einbindung der Ressource "Adresse ClientResource adresse = new ClientResource(" // Zugriff über den RESTful Web Service "get adresse.get(); adresse.getresponseentity().write(system.out); } } Java Code REST Client (Auszug) Coding Compile javac *.java Run Client Java RESTClient Keine Stub-Importierung notwendig! REST-Service auch ohne Client-Anwendung testbar (in Browser) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

27 Aufbau dieser Veranstaltung Kapitel 8: Einführung in REST 1 Einführung REST 2 Implementierung mit RESTlet 3 Implementierung mit AXIS2 4 Bewertung des Ansatzes 5 Anwendungsszenarien 6 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 27

28 REST in AXIS2 AXIS2 kann als REST-Container verwendet werden Jeder installierte Web Service kann auch über über einen REST-Endpunkt angesprochen werden ( eigenes Servlet) Unterscheidung bzgl. Servlet-Mapping: URL für SOAP-Aufruf: URL für REST-Aufruf: Nur Unterstützung der GET und POST Methode! Grundlegende Idee von REST nicht vollständig unterstützt Adress-Konvention: " Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 28

29 REST in AXIS2 Nachteil bei HTTP-GET: im Prinzip können nur einfache Standardwerte übergeben werden, da alles in einer URL ausgedrückt wird Rückgabe über HTTP-Response kann durchaus wieder komplexe Datenstrukturen besitzen Bei der Übergabe von komplexen Datenstrukturen ist man auf HTTP-POST angewiesen Daten stehen im HTTP-Body des Requests Nur synchroner Aufruf möglich (Request / Response) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 29

30 Aufruf eines REST-Service Auf Server-Seite ist ein Web Service nicht weiter anzupassen REST-Binding wird von AXIS2 automatisch erzeugt Auf Client-Seite muss in der Klasse ServiceClient einige Options gesetzt werden: options.setproperty( Constants.Configuration.ENABLE_REST, Constants.VALUE_TRUE ); options.setproperty( Constants.Configuration.HTTP_METHOD, Constants.Configuration.HTTP_METHOD_POST ); Rest analog wie beim Aufruf eines SOAP Web Services (vgl. Kapitel 5) Definition der Operation nebst Parameter Unterschied: Im HTTP-Body wird nur der Methodenaufruf in reines XML codiert, kein SOAP ( sehr viel schlanker) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 30

31 Aufbau dieser Veranstaltung Kapitel 8: Einführung in REST 1 Einführung REST 2 Implementierung mit RESTlet 3 Implementierung mit AXIS2 4 Bewertung des Ansatzes 5 Anwendungsszenarien 6 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 31

32 Gegenüberstellung der Eigenschaften von SOAP vs. REST Kriterium SOAP REST Skalierbarkeit Anpassparkeit Hinzufügen neuer Domänen- Konzepte (Objekt, Prozess) Abhängig von Zustandsmanagement der Architektur ab. Erfordert Neu-Implementierung des Web Service Hohe Skalierbarkeit durch zustandslose Web Services Flexible Erweiterung von Ressourcen erhöhen Skalierbarbeit Durch das Konzept flexibel unterstützt (Methoden POST und PUT) Sicherheit Firewalls kennen im Normalfall Bedeutung von SOAP-Bodies nicht (nur HTTP-Requests mit POST Befehl) Firewalls können auf Basis der HTTP- Methoden und URLs REST-Request filtern (z.b. nur GET-Methoden) Performance Performance abhängig von Implementierung. Hoher Overhead durch Marshalling von XML-Dokumenten Cache-Konzept erhöht die Performance (aus User-Sicht). Geringer Overhead durch kleine Nachrichten (Strings, JSON) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

33 Gegenüberstellung der Eigenschaften von SOAP vs. REST Kriterium SOAP REST Verbreitung und Akzeptanz des Konzepts Standards Lesbarkeit / Intuition der Dokumente Typisierung (Typ- Sicherheit) Verzeichnis- Konzept Verbreitung und Akzeptanz der WS- Standards durch Global Player der Industrie (z.b. IBM, SAP, Microsoft) Sehr viele Standards vorhanden (z.b. weitere wie BPEL), jedoch wenige Weiterentwicklungen XML XML Allgemein gute Lesbarkeit Nur einfache Datentypen bei GET Strenge Typisierung bei Request und Response sowie in Methoden-Definition senkt Fehlerquote zur Laufzeit Unterstützt im Grund-Konzept (UDDI), von der Industrie nicht sonderlich unterstützt Wenige Implementierungen in Industrie verbreitet, als Alternative zum W3C- Standard aber erkannt Basiert zwar auf Standards, jedoch keine REST-spezifischen Standards URL (XML, JSON ) Allgemein gute Lesbarkeit Komplexe Datentypen Kein Typ-System vorgegeben. Dadurch Gefahr von Fehlinterpretationen während der Laufzeit (bei Übergabe URL) Nicht vorhanden, neue Services werden durch Links in den Repräsentation angeboten Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

34 Aufbau dieser Veranstaltung Kapitel 8: Einführung in REST 1 Einführung REST 2 Implementierung mit RESTlet 3 Implementierung mit AXIS2 4 Bewertung des Ansatzes 5 Anwendungsszenarien 6 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 34

35 Applikationsszenarien SOAP Web Services Unterstützung von (teil-)automatisierten Geschäftsprozessen Orchestration von Web Services Workflow-Sprache BPEL Transaktionale Systeme Zustandsbehaftete Architekturen ( Warenkorb-Systeme ) REST Web Services Unterstützung CRUD (Create, Read, Update, Delete) Applikationen Web 2.0 Anwendungen (z.b. Mash-Ups) Aktuelle Beispiele einer REST-Anwendung: Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

36 Aufbau dieser Veranstaltung Kapitel 8: Einführung in REST 1 Einführung REST 2 Implementierung mit RESTlet 3 Implementierung mit AXIS2 4 Bewertung des Ansatzes 5 Anwendungsszenarien 6 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 36

37 Zusammenfassung REST und SOAP sind beides effektive Ansätze zur Entwicklung von Web Services Architekturen SOAP: Akzeptierter Standard basierend auf soliden Techniken der Informatik und direkt verwendbar mit weiteren Standards (z.b. BPEL) REST: Bietet durchaus mehr Flexibilität bei der Entwicklung von Architekturen, höhere Skalierbarkeit REST oder SOAP? The winner is? : Keine eindeutige Aussage möglich Einsatz je nach Gewichtung oder Bewertung der Eigenschaften Abhängig vom Applikationsszenarien Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

38 Anhang Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010

39 Code-Demo: Verwendung von RESTlet Implementierung der Ressource Adresse (ausführlich) import org.restlet.*; public class AddressRessource extends ServerResource { private String adressforname; private Adresse protected void doinit() throws ResourceException { } // Ermittlung des Key-Attribut (Name = Inhaber der Adresse) aus der URI, // für das die Adresse geliefert werden soll: this.adressforname = (String) getrequest().getattributes().get( user"); // Ermittlung der Adresse this.adresse = DB.getAdresse( adressforname public Representation toxml() { DomRepresentation representation = new DomRepresentation( MediaType.TEXT_XML); } } // Generate a DOM document representing the item. Document d = representation.getdocument(); Element adressitem = d.createelement("adresse"); d.appendchild( adressitem ); Element stadtname = d.createelement("stadt"); stadtname.appendchild( d.createtextnode( this.adresse.getstadt() ); adressitem.appendchild( stadtname ); return representation; Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o

40 Ergebnis der Evaluierung Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010