Service-Orientierte Architekturen
Werbung
Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 5: Web Services II Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda ([email protected]) (Vorläufiger) Aufbau der Vorlesung Kapitel 1 2 3 4 (11.5.) Thema Organisation, Einführung in Software-Architekturen Einführung in Service-Orientierte Architekturen Design Prinzipien von Service-Orientierten Architekturen Web Services I (SOAP, WSDL) 5 (18.5.) Web Services II (Axis2) 6 (25.5.) Modellierung von Geschäftsprozessen (BPEL, BPMN) 7 (1.6.) Vertiefung und Backup Web Services 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 Ziele dieser Unterrichtseinheit Grundlagen des Web Services Framework verstehen Implementierungen eines Web Service basierend auf AXIS2 verstehen und eigenständig anwenden können Analyse von AXIS2 in Hinblick auf die Entwurfsprinzipien einer SOA Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 3 Aufbau dieser Veranstaltung Kapitel 5: Einführung in Web Services, Teil 2 1 Überblick über AXIS2 2 Service-Entwicklung mit AXIS2 3 Aufrufmuster in AXIS2 (inkl. WS-Addressing) 4 Bewertung von AXIS2 5 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 4 Aufbau einer SOAP-basierten Web Services Architektur UDDI (-compatible) Directory Return“possibleservices” : WSDL[ ] Discover “aService” SOAP SOAP Publish “aService” : WSDL SOAP Service Consumer Service Bind / Interaction Web Service Provider Web Service “aService” : WSDL SOAP • XML-basiertes Nachrichtenformat für den Aufruf / Interaktion mit einem Web Service WSDL (Web Service Description Language) • XML-basierte Meta-Sprache zur Beschreibung der Schnittstelle eines Web Service UDDI (Universal Description, Discovery and Integration) • Directory-Service für die Publikation und Suche von Web Services Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Überblick AXIS2 Laufzeitumgebung für Web Services basierend auf den W3-Standards SOAP und WSDL Bibliotheken für die Erstellung von Web Service-Clients Tools für die automatische Generierung von Source Code und WSDLDokumenten Plug-ins für Eclipse für das vereinfachte Deployment eigener Services und für eine vereinfachte Code-Generierung Web-Oberfläche für die Administration von AXIS2 bzw. von Web Services Weitere Infos unter: http://ws.apache.org/axis2/ Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 6 Installation von AXIS2 Zwei Installationen von AXIS2 sind verfügbar: - - Aktuelle Version: Version 1.5.1 http://ws.apache.org/axis2/download/1_5_1/download.cgi Standard Binary Version - Entwickler-Version mit vielen Beispielen und einen Standalone Web Server zum Testen von Web Services - Entwicklungstools (Java2WSDL und WSDL2Java) WAR Distribution - Version für das Deployment von Web Services (ohne Entwicklungstools) - Download als .war File (axis2.war), das in jedem Servlet Container installiert werden kann (z.B. Tomcat) - File muss in das Directory ../webapps/ kopiert werden Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 7 Servlet und Servlet Container Ein Servlet ist eine Java-Klasse (package javax.servlet.*), mit der ein Java Programm ein HTTP-Request empfangen und verarbeiten kann. - Kapselung des HTTP-Requests in eine objektorientierte Struktur (Klasse HttpServletRequest) - Zentrale Methoden: doGet(), doPost(), doPut(), doDelete() u.a. - Ausgabe von dynamischen HTML oder XML Code Implementierung der Java Servlet API (aktuell: 3.0) von der Firma SUN Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 8 Servlet und Servlet Container POST web/my HTTP/1.1 Host myserver.com Content-Type: application/ soap+xml …. „Mini“-HTTP-Server Web Browser, Java Programm Servlet-Container (Java) doGet() Servlet „Anwendung 1“ doGet() Servlet „Anwendung 2“ Application-Server Servlet-Klassen müssen in speziellen Laufzeitumgebungen (Servlet Container) installiert werden Servlet-Container nimmt einen HTTP-Request entgegen und kompiliert diesen in ein Java-kompatibles Format - Übergabe des Request an Methode doGet() bzw. doPost() eines selektierten Servlets (Bestimmung durch URL) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 9 Architektur von AXIS2 (High-Level View) POST web/my HTTP/1.1 Host myserver.com Content-Type: application/ soap+xml SOAP Envelope …. „Mini“-HTTP-Server <<Service Consumer>> ServletContainer (Java) AXIS2 (= Servlet-Anwendung) doPost() Web Service n Web Service 1 Application-Server Deployment von AXIS2 als Servlet-Anwendung in einem Servlet-Container - Weiterleitung des kompilierten HTTP-Requests inkl. SOAP-Envelope an AXIS2, hier Selektion und Aufruf an den Service (durch URL bestimmt) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 10 Handler in AXIS2 Handler dienen dazu, die Kernfunktionalität von AXIS2 zu erweitern, indem sie bestimmte Funktionen implementieren, die dann in den Verarbeitungsprozess ein- und ausgehender Nachrichten eingefügt werden können. Nicht zu verwenden für anwendungsspezifische Daten ( SOAP Body) Nur Auswertung von anwendungsunabhängigen Daten ( SOAP Header) Anwendung: - - - - - Logging Überprüfung von sicherheitsrelevanten Aspekten Transaktionen Sessionverwaltung Erweiterte Adressierungskonzepte Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 11 Handler in AXIS2 Implementierung von Handlern nach einer generischen Schnittstelle - Wichtige Methode: - InvocationResponse invoke( MessageContext context ) Definition von Handler in Handler-Flows - - - Interface org.apache.axis2.engine.Handler Eingehende Flows (Behandlung von eingehenden Requests) Ausgehende Flows (Behandlung von ausgehenden Responses) Handler können Abhängigkeiten zu anderen Handlern oder aber auch Angaben zur Reihenfolge mitbestimmen Definition und Verwaltung der Flows in der Konfigurationsdatei axis2.xml Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 12 Module in AXIS2 Mit Modulen kann die Funktionalität von AXIS2 erweitert werden (Plugin Konzept) In den meisten Fällen realisieren Module Funktionserweiterungen, indem sie mehrere zusammenhängende Handler installieren, die dann für bestimmte Services zugeordnet werden können Module können auch Web Services enthalten Beispiele: - - - WS-Addressing WS-Security WS-AtomicTransactions Module werden in der Datei module.xml spezifiziert Engagement von Modulen zu Services: - - - Global für alle Services: in Datei axis2.xml Local für einen Service: in Datei services.xml Manuell oder per Web-Schnittstelle Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 13 Nachrichtenfluss in AXIS2 (Detail-Sicht auf Architektur) AxisEngine MC-Req SOAP Request H1 H2 Hn IN FLOW MC-Req Message Receiver Web Service AXIS Servlet Http Transport Utils MC-Res MC-Res SOAP Response Transport Sender Hm H1 OUT FLOW AxisEngine Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 14 Aufbau dieser Veranstaltung Kapitel 5: Einführung in Web Services, Teil 2 1 Überblick über AXIS2 2 Service-Entwicklung mit AXIS2 3 Aufrufmuster in AXIS2 (inkl. WS-Addressing) 4 Bewertung von AXIS2 5 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 15 Der Code-First Ansatz Implementierung (Source Code) einer Komponente liegt zuerst vor Ableitung der abstrakten Schnittstellen-Beschreibung (WSDL) Generierung von Proxy-Klassen (Stubs) für einen Client Verwendung und Integration der Komponente als Web Service Input für KomponentenImplementierung (z.B. Java) WSDL-Generator erzeugt WSDL-kompatible Beschreibung der Schnittstelle Input für Proxy-Klasse für Client (Java) Source CodeGenerator Proxy-Klasse für Client (C++) Proxy-Klasse für Client (C#) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 16 Der Contract-First Ansatz Spezifikation der anwendungsspezifischen Datentypen in verschiedenen XML-Schemata Spezifikation der auszutauschenden Nachrichten (XML-Schema) Ableitung des WSDL-Files aus den Schemata Client-Proxy (Stub) und Service-Skeleton Generierung Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Der Contract-First Ansatz Datentypen I Datentypen I (XML-Schema) (XML-Schema) Input für Input für Nachrichten (XML-Schema) Input für WSDL-Tool WSDL-kompatible Beschreibung der Schnittstelle Input für Source CodeGenerator Service-Skeleton (Java, C++,...) Proxy-Klasse für Client (Java) Klassen für Datentypen Proxy-Klasse für Client (C++) Klassen für Nachrichten Proxy-Klasse für Client (C#) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 18 Contract-First vs. Code-First – ein Vergleich Code-First - Vorteile: - Nachteile: Bestehende Komponenten (Altbestände) können als Web Service integriert werden Probleme bei der Umwandlung von komplexen, programmiersprachen-spezifischen Datentypen Probleme bei der Interoperabilität zwischen verschiedenen Programmiersprachen Contract-First - Vorteile: - Geringere Interoperabilitätsprobleme, da frühzeitige Einigung auf gemeinsame anwendungsspezifische Datentypen Nachteile: Schlechte Tool-Unterstützung, schlechte Compiler Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 19 Code-First bei AXIS AXIS2 erlaubt die Entwicklung und Inbetriebnahme von Web Services von POJOs („Plain Old Java Objects“) Keine AXIS-spezifischen Klassen, Packages, Code-Fragmente sind notwendig - Anders als beim Sun Java Web Services Developer Pack (JWSDP)! Folgerung: “Alt-Systeme” können ohne Erweiterung des Source-Codes integriert werden Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 20 Implementierung der Klasse „PartnerChange“ als Web Service public class PartnerChange { public PartnerChange(){ } public String deletePartner( Partner partner ){ if ( partnerVorhanden( partner )) { deletePartnerINT ( partner ); return "Partner gelöscht"; } return "Partner nicht gefunden"; } public String changePartner( Partner partner ){ Object ref = null; if (!partnerVorhanden( partner )) { ref = legePartnerNeuAn( partner ); // nur Neuanlage } else { ref = getReference( partner ); //anhand PrimKey } changeAndSaveProperties( ref , partner ); //Übertrage neue Werte } return "Erfolgreiche Änderung"; Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 21 Paketierung der Klassen des Service Die resultierenden Klassen werden compiliert und in ein spezielles Archiv (.aar) gepackt - - Packen nach ZIP, dann Unbennenung Tools (z.B. Eclipse, AXIS2-Wizard-Service-Generator unter http://archive.apache.org/dist/ws/axis2/tools/1_4/ Aufbau des Archivs: - PartnerChangeService.aar de service PartnerChange.class Partner.class ... lib META-INF services.xml Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Spezifische Klassen (POJO!) und Libraries für den Service Spezieller Deployment Deskriptor zur weiteren Definition des Service Folie 22 Der Deployment Decriptor services.xml Der Deployment Descriptor „services.xml“ konfiguriert den Web Service für das eigentliche Deployment (Installation) Aufgaben: - - - Identifikation der relevanten Operationen Zuordnung des Kommunikationsstils (RPC, Document) Zuordnung von Modulen Aufbau: <service> <description>PartnerChangeService</description> <parameter name = „PartnerChange“> de.service.PartnerChange </parameter> <operator name=„deletePartner“> <messageReceiver class=„org.apache.axis2.rpc.receivers.RPCMessageReceiver“ /> <operation> .... // weitere Operationen </service> Deployment descriptor „services.xml“ Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 23 Das Administrator-Interface AXIS2 bietet ein Web-basiertes Frontend zum Hochladen, Löschen und zur Statuskontrolle (Administration) von Services an. Link: http://<yourhost>8080/axis2/axis2-admin/ Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 24 Hot Deployment und Hot Update von Services Die hochgeladenen Services werden unter <webapps>/axis2/WEB-INF/ services hochgeladen Module (Handler) werden unter <webapps>/axis2/WEB-INF/modules hochgeladen (Format *.mar) Manuelles Hochladen in das Directory ist auch möglich AXIS2 unterstützt das Hot Deployment von Web Services, d.h. der Service steht nach der Kopie in das WEB-INF Verzeichnis unmittelbar zur Verfügung ohne den AXIS2-Server neu zu starten Support auch vom Hot Update: - - - Änderung eines einzelnen, bereits im Betrieb befindenden Web Service zur Laufzeit Beispiel: Änderung der Zuordnung einer Klasse zu einem Service (Änderung der services.xml Datei) Änderung werden ohne Neustart des Servers übernommen Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 25 WSDL2Java und Java2WSDL AXIS2 stellt zwei wichtige Tools zur Entwicklung bereit - WSDL2Java - Aus einer Java-Klasse wird eine WSDL-Datei erzeugt Kommandozeilen-Befehle - Aus einer gegebenen WSDL-Datei werden die Stub-Klassen für einen Javabasierten Client und (optional) für den Server entwickelt Java2WSDL - Verfügbar nur in der Standard Binary Edition Verfügbar für Windows und UNIX, sehr gut implementiert Tool-Support für Eclipse - - AXIS2-Wizard-Code-Generator (recht „bugy“) http://archive.apache.org/dist/ws/axis2/tools/1_4/ Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 26 Stub-Generierung mit WSDL2Java Mit dem Tool WSDL2Java können aus einer WSDL-Beschreibung eines Web Service die für den Client relevanten Stub-Klassen erzeugt werden Befehl: - wsdl2java –uri http://localhost/axis2/services/PartnerChangeService?wsdl -o C:/ClientCode – p de.services.client.example - - - - Der Aufruf erzeugt den Client-Stub (= eine Java-Klasse) „PartnerChangeServiceStub“, der im Verzeichnis „C:/ClientCode“ abgelegt wird Die Klasse gehört dem Package an, das mit dem Parameter –p spezifiziert wurde Die intern gebrauchten Datentypen (hier: Partner) werden als Inner Classes zu der Stub-Klasse generiert (Auslagerung mit Parameter –u ) Für die Request-Nachricht und die Response wird eine eigene Klasse generiert Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 27 Implementierung des Service Consumers basierend auf generierten Stubs package de.services.client.example; import java.rmi.RemoteException; import import import import import org.apache.axis2.AxisFault; org.apache.ws.axis2.*; org.apache.ws.axis2.MyServiceStub.ChangePartner; org.apache.ws.axis2.MyServiceStub.ChangePartnerResponse; org.apache.ws.axis2.MyServiceStub.Partner; public class Client { public static void main ( String [] args ) throws RemoteException { MyServiceStub stub = new MyServiceStub("http://localhost:8080/axis2/services/PartnerChangeService"); // Request erzeugen ChangePartner partnerRequest = new ChangePartner(); Partner partner = new Partner(); partner.setName("Maier"); partnerRequest.setPartner( partner ); //Service aufrufen und Ergebnis aus Response holen ChangePartnerResponse response = stub.changePartner(partnerRequest); String antwort = response.get_return(); System.out.println("Ergebnis der Änderung: " + antwort); }} Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 28 Service Consumer ohne Code-Generierung Der Client zum Aufruf eines Web Service lässt sich auch ohne CodeGenerierung implementieren. Zentrale Klassen, die benötigt werden (bei der Codegenerierung weitesgehend gekapselt durch die „Stub“-Klasse): Klasse (aus Package Bedeutung org.apache.axis2.client) ServiceClient Kapselung von Methoden zur Interaktion auf einen Web Service, ggf. mit weiteren Options noch weiter konfiguriert; Setzen von HeaderInformationen Options Konfigurationsdaten für den Aufruf eines Web Service (z.B. Kommunikationsmuster, Übernahme der EndpointReference) EndpointReference Endpunkt und Ziel-Adresse des Web Service RPCServiceClient Spezieller Client für den RPC-Kommunikationsstil Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 29 AXIOM als Basis für XML-Nachrichten AXIS2 verwendet das Framework AXIOM zur Erzeugung und Interpretation von XML-Nachrichten XML-Nachrichten werden zwischen einem Service-Client und einem Web Service ausgetauscht Zentrale Klassen: Klassen Bedeutung org.apacheaxiom.om.OMElement Kapselung eines XML-Dokuments. Übergabe an Web Service (Request) und Rückgabe nach Verarbeitung an den ServiceClient (Response) org.apache.axis2.databin ding.utils.BeanUtil Operationsparameter (RPC-Style) werden hier umgewandelt in ein XML-Dokument (OMElement) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 30 Aufruf eines Web Service mit ServiceClient public void sendRequest() throws AxisFault{ // Service-Client mit Optionen und Endpoint referenzieren ServiceClient sender = new ServiceClient(); Options options = sender.getOptions(); EndpointReference targetEPR = new EndpointReference("http://localhost:8080/axis2/services/PartnerChangeService"); options.setTo( targetEPR ); // Selektiere die Operation "deletePartner" in ein XML-Fragment QName deletePartner = new QName("Link to XML-Schema" , "deletePartner" ); //Parameter für die Operation "deletePartner“ übergeben Partner partner = new Partner(); // Üergabe der Werte ... Object[] opArgs = new Object[] { partner }; // OMElement mit der RequestNachricht erzeugen OMElement request = BeanUtil.getOMElement(deletePartner, opArgs, null, false, null); //Request an Web Service schicken (synchron, IN-OUT bzw. Request-Response) OMElement response = sender.sendReceive( request ); // diese Datentypen sollen zurückgeliefert werden Class[] returnTypes = new Class[] { String.class }; //Antwort mit BeanUtil zu deserialisieren Object[] result = BeanUtil.deserialize( response, returnTypes, null); //Ermittlung des String String antwort = (String) result[0]; } Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 31 Aufruf eines Web Service mit RPCServiceClient public void sendRequestRPC() throws AxisFault{ RPCServiceClient sender = new RPCServiceClient(); Options options = sender.getOptions(); EndpointReference targetEPR = new EndpointReference("http://localhost:8080/axis2/services/PartnerChangeService"); options.setTo( targetEPR ); // Selektiere die Operation "deletePartner" in ein XML-Fragment QName deletePartner = new QName("Link to XML-Schema" , "deletePartner" ); //Parameter für die Operation "deletePartner“ übergeben Partner partner = new Partner(); // Übergabe der Werte ... Object[] opArgs = new Object[] { partner }; // diese Datentypen sollen zurückgeliefert werden Class[] returnTypes = new Class[] { String.class }; //Request an Web Service schicken (synchron, IN-OUT bzw. Request-Response) Object[] response = sender.invokeBlocking( deletePartner ,opArgs, returnTypes ); //Ermittlung des String String antwort = (String) response[0]; } Vorteil: - - Kapselung der Erzeugung des OMElement-Objekt Kürzerer Source Code Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 32 Weitere Infos zum ServiceClient Ein ServiceClient benötigt immer eine Laufzeitumgebung von AXIS2, um Requests verschicken und empfangen zu können Die Laufzeitumgebung wird repräsentiert durch ein Objekt der Klasse ConfigurationContext, das über sämtliche Informationen der Laufzeitumbeung verfügt - Weitere Services - Installierte Module Ist der Service in einem Server eingebettet, so wird der ConfigurationContext des Servers übernommen Ist der ServiceClient nicht in einem Server (z.B. Tomcat) eingebunden, so wird eine Default-Konfiguration aus dem Kernel erzeugt (axis2-kernel.jar) erzeugt Über die Methode „addHeader( OMElement header ) kann ein SOAP-Header explizit hinzugefügt werden. Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 33 Aufbau dieser Veranstaltung Kapitel 5: Einführung in Web Services, Teil 2 1 2 Überblick über AXIS2 3 Aufrufmuster in AXIS2 (inkl. WS-Addressing) 4 Bewertung von AXIS2 5 Zusammenfassung und Ausblick Service-Entwicklung mit AXIS2 Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 34 Synchrone und asynchrone Aufrufmuster AXIS2 bietet die Möglichkeit, Nachrichten synchron sowie asynchron zu verschicken (Erweiterung gegenüber AXIS1.x) - Unterscheidung (API-Level-Asynchronität) - - Aufrufmuster (Message Exchange Patterns) Synchron (Blockierendes API): Service Consumer wartet nach Absetzen des Service-Aufrufs auf die Antwort und bleibt während der Wartezeit blockiert Asynchron (Nicht-blockierendes API): Service Consumer kann nach Absetzen des Service-Aufrufs weiter operieren, Rückgabe über Callback-Handler Konform zu unseren Entwurfsprinzipien für eine SOA (siehe Kapitel 2/3) - - Asynchronität sorgt für eine lose Kopplung zwischen Service Consumer und Provider des Web Service Service Consumer kann auch z.B. beim Ausfall des Service Provider weiter operieren Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 35 Transport-Level-Asynchronität Weitere Unterscheidung bei AXIS2: Transport-Level-Asynchronität - Probleme beim Standard-Transportprotokoll HTTP: - - - Anzahl der notwendigen Verbindungen während des Service-Aufrufs zwischen dem Consumer und dem Provider Typisches Zwei-Wege-Protokoll: per Default wird dieselbe Verbindung für den Transport eines Requests und der zugehörigen Response (+ Empfangsbestätigungen) verwendet Probleme bei sehr langläufigen Transaktionen: möglicher Time-Out beim Service Consumer Service Consumer könnte Response nicht mehr empfangen Time-Out kann verlängert werden Nicht immer praktikabel, da u.U. hoher Ressourcenverbrauch Ansatz bei AXIS2 - Etablierung von zwei unterschiedlichen Verbindungen für den Transport von Request und Response Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 36 Übersicht der möglichen Aufrufmuster Durch die Kombination von API-Auswahl und Anzahl der eingesetzten Verbindungen ergeben sich vier Aufrufmuster: AXIS2 unterstützt über die Klasse ServiceClient alle Aufrufmuster API Anzahl der Verbindungen Beschreibung Blockierendes API 1 Synchroner Aufruf des Web Service, Aufruf z.B. über HTTP Nicht-blockierendes API 1 Asynchroner Aufruf des Web Service, Einsatz von CallbackHandler, Aufruf z.B. über HTTP Blockierendes API 2 Synchroner Aufruf des Web Service, Aufruf z.B. über SMTP (selten eingesetzt), oder HTTP (neuer HTTP-Prozess) Nicht-blockierendes API 2 Asynchroner Aufruf des Web Service, , Aufruf z.B. über SMTP (selten eingesetzt), oder HTTP (neuer HTTP-Prozess) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 37 Request-Response mit blockierenden API – eine Verbindung <<Service Consumer>> ServiceClient (Klasse von AXIS2) Request Response H T T P <<Service Provider >> RPCServiceClient sender = new RPCServiceClient(); Options options = sender.getOptions(); EndpointReference targetEPR = new EndpointReference(...); options.setTo( targetEPR ); //Request an Web Service schicken (synchron, IN-OUT bzw. Request-Response) Object[] response = sender.invokeBlocking( deletePartner ,opArgs, returnTypes ); //Alternative: SendReceive, Rückgabe ist ein XML-Document OMElement requestPayload = createRequestPayload(); //Erzeugung des Request-Docs OMElement responsePayload = sender.sendReceive(requestPayload); Nachteil: Antwortzeit kann sehr lange dauern, ServiceClient wird geblockt Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 38 Request-Response mit nicht-blockierenden API – eine Verbindung <<Service Consumer>> ServiceClient (Klasse von AXIS2) Callback-Handler Request Response H T T P <<Service Provider >> org.apache.axis2.client.async.Callback callback = new org...Callback(){ public void onComplete(AsyncResult result) { // Analyse des SOAP-Bodies Object obj1 =result.getResponseEnvelope().getBody(); //Analyse des SOAP-Headers Object obj2 = result.getResponseEnvelope().getHeader(); } } public void onError(Exception result) { // ... } sender.sendReceiveNonBlocking(requestPayload, callback); Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 39 Request-Response mit nicht-blockierenden API – zwei Verbindungen Request <<Service Consumer>> ServiceClient (Klasse von AXIS2) Transport Sender ACK Response Callback-Handler Client-Side Server ACK <<Service Provider >> H T T P ServiceClient sender = new ServiceClient(); Options options = sender.getOptions(); // Client-seitige Integration des Modules "WS-Adressing" sender.engageModule( new QName( Constants.MODULE_ADDRESSING)); // Erzeugung eines separaten Serverprozesses options.setUseSeparateListener(true); // Payload erzeugen.. // Request verschicken mit Referenz auf Callback sender.sendReceiveNonBlocking(requestPayload, callback); Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 40 WS-Adressing Das WS-Adressing Module erlaubt die Spezifikation von getrennten Adressangaben innerhalb einer SOAP-Nachricht für die flexible Interaktion zwischen Service Konsumenten und Service Providern Basiert auf einer Spezifikation von W3C (2006) Geeignet für Zwei-Wege Aufrufmuster (siehe letzte Folien) Verwendung von unterschiedlichen Transport-Protokollen innerhalb einer Request-Response Sequenz Informationen werden im SOAP Header eingefügt Wichtige Informationen: - - - - - - To: An welchen Endpunkt soll die Nachricht versendet werden? From: Welches ist die Adresse des Absenders ReplyTo: An welchen Endpunkt soll die Response geschickt werden? FaultTo: An welchen Endpunkt sollen Fehlermeldungen geschickt werden? MessageID: Zu welchem Callback-Handler bezieht sich die Request (vom Service Client oder Consumer definiert) RelatesTo: Zu welchem Callback-Handler bezieht sich die Request (vom Service Provider gesetzt, i.d.R. aus MessageID) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 41 Beispiel-Request mit WS-Addressing POST /axis2/services/PartnerChangeService Host: myserver.de ... <soapenv:Envelope>.... <soapenv:Header> <wsa:To> <wsa:Address> http://myserver.com/axis2/services//PartnerChangeService </wsa:Address> </wsa:To> <wsa:ReplyTo> <wsa:Address> http://anotherserver.com/axis2/services/anonService83833993211/output </wsa:Address> </wsa:ReplyTo> <wsa:MessageID> urn:uuid:F4f8fdjkd9c99d </wsa:MessageID> .... </soapenv:Envelope> Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 42 Einweg-Aufruf mit nicht blockierendem API <<Service Consumer>> ServiceClient (Klasse von AXIS2) Request ACK H T T P <<Service Provider >> ServiceClient sender = new ServiceClient(); Options options = sender.getOptions(); // Payload erzeugen.. // Request verschicken ohne Rückgabewerte oder Callback sender.fireAndFortget( requestPayload ); Server liefert einen HTTP-Reponse mit Status-Code 202 („Accepted“) Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 43 Aufbau dieser Veranstaltung Kapitel 5: Einführung in Web Services, Teil 2 1 2 3 Überblick über AXIS2 Service-Entwicklung mit AXIS2 Aufrufmuster in AXIS2 (inkl. WS-Addressing) 4 Bewertung von AXIS2 5 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 44 Diskussion Service Schnitt Referenzfreiheit ist immer gegeben - Grobe Granularität - - - Abhängig von der Entwicklung der Service-Schnittstellen In einer Service-Klasse können auch private Methoden definiert werden, somit ist eine Basis für Redundanzfreiheit gegeben Session-Kontext - - Abhängig von der Entwicklung der Service-Schnittstellen Redundanzfreiheit - Implementierung von eher feingranularen Services bei AXIS2 üblich Grobgranular durch workflow-basierte Laufzeitumgebungen Normalform - Aufrufe werden immer per Kopie durchgeführt (Call-By-Value) Abhängig von der Entwicklung der Service-Schnittstellen und –Implementierung Session-Kontext kann über Header mitgeliefert werden Technische Neutralität - Gegeben durch die Verwendung von Standards wie WSDL, WS-Adressing Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 45 Anpassbarkeit AXIS2 garantiert eine hohe Anpassbarkeit einer service-orientierten Architektur durch das „explizit machen“ der Architektur der Laufzeitumgebung - Handler-Konzept - Module-Konzept - Hot Deployment von neuen Services - Hot Update von laufenden Services Anpassbarkeit von Verbindungen zwischen Services: - - - Abhängigkeiten zwischen Web Services können in AXIS2 nicht realisiert und angepasst werden Nachbildung eventuell über Handler-Konzept möglich, aber umständlich Verbesserung erst durch BPEL Keine Adaptivität, keine Tailorabilität Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 46 Performanz Erreicht durch besseres XML-Parsing durch das Framework AXIOM XML-Dokument wird nie zu Ende geparst, nur bis der Ziel-Code erreicht - Verbesserte Serialsierung und De-Serialisierung von XML-Dokumenten Alternative DOM: Nachricht wird komplett in eine objekt-orientierte Struktur umgewandelt, hoher Ressourcenverbrauch Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 47 Skalierbarkeit Durch die flexible Adressierung und durch das Händler-Konzept sind die Verbindungen nicht starr Anfragen sondern können unter Umständen (z.B. hohe Client oder ServerAuslastung) umgeleitet oder priorisiert werden AXIS2 ist leichtgewichtig, daher ist das Klonen einer AXIS2 Instanz recht einfach Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 48 Loose Coupling und Sicherheit Durch verschiedene Aufrufmuster wird eine lose Kopplung zwischen Service Consumer und Provider erreicht Kein Enterprise Service Bus realisiert - Würde die lose Kopplung noch verringern Sicherheit - Wird durch das Modul „WS-Security“ erreicht, Vorstellung und Diskussion erfolgt später... Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 49 Aufbau dieser Veranstaltung Kapitel 5: Einführung in Web Services, Teil 2 1 2 3 4 5 Überblick über AXIS2 Service-Entwicklung mit AXIS2 Aufrufmuster in AXIS2 (inkl. WS-Addressing) Bewertung von AXIS2 Zusammenfassung und Ausblick Prof. Dr. Sascha Alda, Hochschule Bonn-Rhein-Sieg, FB Informatik. c/o 2010 Folie 50
