Kommunikationsmodelle Kapitel 4. Professionelle Implementierungen

Transkript

1 Kommunikationsmodelle Kapitel 4. Professionelle Implementierungen Sommersemester 2015 H.-A. Schindler (auf Grundlage einer Vorlesung von Winfried E. Kühnhauser bis ss 2010 ) 4.3 XML-RPC, SOAP, Web-Services Winfried E. Kühnhauser CSI Technische Universität Ilmenau Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 1 -

2 4.3.1 Hintergrund Ø Umsetzung neuerer Idee die erst mit immer weiter fortschreitender Vernetzung besonders auch über Internet möglich wurde: SOA. SOA (service-oriented architecture) = [in verständlicherem Deutsch: dienste-orientierte (Software-)Architektur] - zunächst nur theoretisches Konzept, abstrakte Herangehensweise (Paradigma), - keine Implementierung. (wie z.b. auch objektorientierte Herangehensweise) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 2 -

3 SOA-Idee u irgendwo im Netz existierende einzelne Basis-Anwendungen als Dienstleister (Server) aufgefasst u können zu komplexen Anwendungssystemen (dynamisch) zusammengebaut werden Zusammenbau extrem einfach; Inhomogenitäten usw. spielen keine Rolle (Hintergrund: Umgang mit den 7 Plagen ) so mit einer SOA neue komplexe Anwendungssysteme kostensparend aufbaubar nutzen dabei Teile der bestehenden IT-Infrastruktur (und stellen somit auch eine Form von Software-Wiederverwendung dar) SOA-Idee bietet sich u.a. besonders für Industrie an Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 3 -

4 SOA-Idee: Probleme 1. Implementierung Ø geeignete Form der praktischen Umsetzung der Idee muss gefunden werden 2. Verwendete Technologien Ø bei einer Implementierung verwendete Techniken u. Technologien müssen angestrebten Zielen entsprechen Ø Nur dann wird solche Implementierung akzeptiert Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 4 -

5 SOA-Idee: Implementierung u im Allgemeinen immer verschiedene Möglichkeiten (theoretisch beliebig viele) u betrachtete Technologien u u u XML-RPC, SOAP Web-Services stellen Teile einer vielversprechenden Implementierung dar. Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 5 -

6 SOA-Idee: Technologien u Middleware-Plattformen (z.b. CORBA): verwendete Ansätze viel zu schwerfällig. (CORBA verlangt z.b. auf jedem Rechnerknoten Vorhandensein des ORBs usw.) u für SOA verwendbarer Ansatz: sollte Kommunikation zu vernetzender Dienste trotz aller Inhomogenitäten ( die 7 Plagen ) noch wesentlich einfacher machen u in hier betrachteten Entwicklungen: wird auf Möglichkeiten der Datenbeschreibungs -Sprache XML (Extensible Markup Language) aufgebaut (mit HTML verwandt) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 6 -

7 4.3.2 Implementierungen von Kommunikationsmodellen Insbesondere interessant: RPC-Implementierungen Ziel: noch mehr Interoperabilität und Offenheit als bisher u Wie bisher: Kommunikation in heterogenen Anwendungssystemen u Aber jetzt: Realisierung unter extrem schwachen Voraussetzungen trotz high-level-modell Umgang mit: 1. zuvor unbekannten Kommunikationspartnern 2. zuvor unbekannter Funktionalität (Schnittstellen, Signaturen) 3. unbekannten Plattformtechnologien (Hardware, Betriebssystem, Programmiersprachen) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 7 -

8 Implementierungen von Kommunikationsmodellen Zum Vergleich: CORBA, Java greifen nicht weit genug (zu geringe Interoperabilität) Voraussetzung: gemeinsame kompatible Middleware ORB, GIOP JVM (Java Virtual Machine) Wir betrachten: XML-RPC: der Wegbereiter SOAP: universeller, die Sockets dieses Jahrzehnts Web Services: Middleware-Framework, benutzt SOAP (Universelle und offene Dienstleistungsangebote) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 8 -

9 4.3.3 Der XML-RPC Pionier und Wegbereiter eines universellen RPC-Modells Rollenmodell: entsprechend RPC: Aufrufer und Ausführer Datenmodell: Prozedursignatur Beschreibung von Aufrufen: durch XML-Dokument universell interpretierbar offen (selbstbeschreibend) groß (Text) aufwändige Interpretation Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as - 9 -

10 Entwicklung: 1998 Dave Winer XML-RPC dient zum entfernten Prozeduraufruf (RPC) nutzt XML-Nachrichten (synchron über HTTP versendet) aus heutiger Sicht: vorläufige, inoffizielle SOAP-Version nicht standardisiert (anders als SOAP) von weniger Anwendungen und Entwicklungswerkzeugen unterstützt. einfacher zu erlernende und zu benutzende Alternative zu SOAP. Erreicht durch übersichtliches Typsystem, wenige Operationen Einschränkung auf synchrone Prozeduraufrufe über HTTP-Protokoll Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

11 Anwendungs-Beispiel: gettimeofday(datetime time) XML-RPC Request: Reply: <methodcall> <methodname>gettimeofday</methodname> <params> <param> <datetime>time</datetime> </param> </params> </methodcall> <methodresponse> <params> <param> <value><datetime> t10:05:20 </datetime></value> </param> </params> </methodresponse> Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

12 XML-RPC Der XML-RPC ist (wie SOAP) unabhängig von Betriebssystemen oder Programmiersprachen. Der Aufbau des Methodennamens ist daher nicht fest vorgeschrieben, lediglich die zu verwendenden Buchstaben, Ziffern und Sonderzeichen sind definiert. Im Gegensatz zu SOAP (mit bereits >40 elementaren Datentypen) verwendet der XML-RPC nur 6 elementare und zwei komplexe Datentypen. Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

13 4.3.4 SOAP SOAP: ursprünglich Simple Object Access Protocol, seit Version 1.2 kein Acronym, da SOAP zwar ein Protokoll ist, die übrigen Bedeutungen jedoch allgemein als falsch angesehen werden können. Insbesondere für den Anfänger ist das Attribut simple nicht (immer) nachvollziehbar, und Objekte konnten noch nie direkt angesprochen werden. è Weiterentwicklung des XML-RPCs: Implementierung mehrerer Kommunikationsmodelle, nur u.a. RPC Ziel DIE universelle Kommunikationsplattform Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

14 SOAP Weg Kommunikationsframework also mehr als nur ein Protokoll Offenheit: durch Spezifikation globaler Standards Kommunikationsmodelle (u.a. Botschaften, Ereignisse, RPC) funktional mächtiger als XML-RPC flexible Rollen- und Datenmodelle nichtfunktionale Eigenschaften; z.b. IT-Sicherheit Ausfalltransparenz Verfügbarkeit Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

15 SOAP Datenmodell (Bsp. SOAP-RPC-Datenmodell) Prozedursignaturen, beschrieben durch XML-Dokumente umfangreicher Datentypvorrat Botschaftenformate: Envelopes, Header, Body Packesel: Transportprotokolle wie HTTP, SMTP, FTP SOAP HTTP SMTP TCP IP Netzhardware Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

16 4.3. Idee globale Nutzung und Integration von Diensten powered by Google Search Ziel Abbau der Hürden der Heterogenität Information Dienstbeschreibungen, Namens- und Lokalisierungsdienste Interoperabilität XML-Datenmodell Zugriffs- und Technologietransparenz Stub-Technologie NFEs Ausfalltransparenz, IT-Sicherheit, Verfügbarkeit Weg Web Services: autonome sich selbst beschreibende Anwendungskomponenten können publiziert, lokalisiert und aufgerufen werden Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

17 Web Services Beispiel: ERP-Systeme (ERP: Enterprise Resource Planning) Lieferzeitanfrage WS-Interface Lokales ERP-System lokale Ressourcen Fremdressourcen WS-Interface Lokales ERP-System WS-Interface Lokales ERP-System lokale Ressourcen lokale Ressourcen Fremdressourcen Fremdressourcen WS-Interface WS-Interface Lokales ERP-System Lokales ERP-System lokale Ressourcen lokale Ressourcen Fremdressourcen Fremdressourcen Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

18 4.3.6 Etwas mehr Übersicht: SOA (Service-oriented Architecture) Theorie XML-RPC SOAP Web-Services (verschiedene) Implementierungen Projekte Apache Software Foundation Organisationen Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

19 Etwas mehr Übersicht: SOAP Kommunikationsframework: mehr als nur Protokoll Ø beschreibt: SOAP-Nachrichtenformat (XML), Datenmodell, Transportprotokoll Web Services Axis Axis2 Middleware-Plattform (sinngemäß vergleichbar mit CORBA) Framework für Web Services (Apache extensible Interaction System) WSDL Sprache (XML-basiert) (Beschreibung von Diensten) Axis Engine entspricht dem ORB von CORBA Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

20 Finden und Benutzen von Diensten Dienst- Verzeichnis 2. Suchen (SOAP) 3. Mitteilung (WSDL) 1. Veröffentlichen (WSDL) 4. Abfrage d. Beschreibung (SOAP) Dienst- Nutzer Darstellung nach [Melzer+2010] Bild 4.1 / S Nutzung (SOAP) Dienst- Anbieter Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

21 Aufbau einer SOAP-Nachricht SOAP Envelope SOAP Header SOAP Body <soapenv:envelope xmlns:soapenv= <soapenv:header>... </soapenv:header> <soapenv:body> <GetTimeOfDay> <datetime>time</datetime> </GetTimeOfDay> </soap:body> </soapenv:envelope> Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

22 Stubgenerierung wie gehabt: auf der Grundlage von Schnittstellenbeschreibungen CORBA: Interface Definition Language (IDL) Web Services: Web Services Description Language (WSDL) Aufrufer Stub Middleware Betriebssystem Ausführer Stub Middleware Betriebssystem XML-Dokument via SOAP/HTTP Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

23 4.3.7 Das TimeWS-Beispiel Der Webservice ( /workspace/timews/src/org/km/time/timews.java) package org.km.time; import org.apache.axis2.axisfault;... public class TimeWS { public String gettimeofday() throws AxisFault{ SimpleDateFormat sdf = new SimpleDateFormat( HH:mm:ss ); String time = sdf.format(new Date()); return time; } } Servicebeschreibung und Deploymentregeln in service.xml strukturierte Packetierung in TimeWS.aar (Axis Archive) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

24 Seine WSDL-Beschreibung ( /workspace/timews/wsdl/timews.wsdl) WSDL: Web Services Description Language = XML-Derivat zur Beschreibung der Schnittstellen von Web Services <wsdl:definitions targetnamespace=" <wsdl:documentation>timews</wsdl:documentation>... <wsdl:porttype name="timewsporttype"> <wsdl:operation name="gettimeofday"> <wsdl:input message="ns0:gettimeofdayrequest" wsaw:action="urn:gettimeofday"/> <wsdl:output message="ns0:gettimeofdayresponse" wsaw:action="urn:gettimeofdayresponse"/> </wsdl:operation> </wsdl:porttype>... <wsdl:service name="timews">... <wsdl:port name="timewssoap11port_http" binding="ns0:timewssoap11binding"> <soap:address location= loacalhost:8080/axis2/services/timews"/> </wsdl:port> TimeWS-Beispiel Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

25 TimeWS-Beispiel Stubs, Skeletons, der ORB sind (im Vergleich zu CORBA) deutlich komplexer; Folge von Offenheit (z.b. XML-Parsing) Heterogenität nichtfunktionalen Eigenschaften Beispiel: Apache Axis2-Engine ein ORB für Web Services Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

26 Axis-2 Stubs Klient AxisEngine Handler 1 Handler 2 out flow Handler n Transport Sender SOAP Request (per HTTP, JMS...) SOAP Reply Stub MC req instanziiert instanziiert Koordinator OutInAxisOperation MC resp MC resp instanziiert Handler m Handler 2 Handler 1 in flow AxisEngine MC = Message Context (siehe umseitig) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

27 Axis-2 Skeletons AxisEngine SOAP Request SOAP Reply MC req Handler 1 Handler 2 in flow Handler n MC req AxisServlet HTTP/JMS Transport Utilities Message Receiver Web Service MC resp Transport Sender Handler m Handler 2 out flow Handler 1 MC resp AxisEngine Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

28 MC = Message Context (Java-)Klasseninstanz, in der Nachricht durch System fließt beschreibt z.b. Aufruf von / Antwort auf RPCs erzeugt aus XML-Dokumenten Handler bearbeiten Nachrichten Logging/Accounting WS-Dispatching Ver-/Entschlüsselung (WS-Security) realisiert als (Java-)Klasseninstanzen Flows serieller Aufruf von Handlern (Pipeline) Pipeline-Layout anwendungsspezifisch (Baukastenprinzip) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

29 TimeWS-Beispiel Im Vergleich zu CORBA: Hürden durch Heterogenität niedriger Rollenmodell fix (RMI) vs. offen (Klient/Server, RPC, Ereignisse,...) Datenmodell Methodensignaturen (CDR) vs. sich selbst beschreibendes Dokument (XML) Protokoll fix (GIOP) vs. spezifizierbar im Kommunikationsframework (häufig SOAP/ HTTP) Adressen Objektreferenzen (IOR) vs. <Protokoll, Netzadresse> Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

30 TimeWS-Beispiel Ein Klient ( /workspace/timews-client/src/org/km/time/main.java) public class Main { public static void main (String[] args) throws AxisFault, RemoteException{ String targetendpoint = ; TimeWSStub stub = new TimeWSStub(targetEndpoint); String result = stub.gettimeofday().get_return(); } } WSDL2Java Werkzeug zur Stubgenerierung (Bestandteil von Axis2) erzeugt: TimeWSCallbackHandler.java (für benutzerdefinierte Empfangsmethoden) TimeWSStub.java (Stub) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

31 TimeWS-Beispiel Der SOAP Request (durch Stub generiert) POST /axis2/services/timews HTTP/1.1 Content-Type: application/soap+xml; charset=utf-8; action="urn:gettimeofday" User-Agent: Axis2 Host: localhost:8080 Transfer-Encoding: chunked <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" <soapenv:body /> </soapenv:envelope> Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

32 TimeWS-Beispiel Die SOAP Response HTTP/ OK Server: Apache-Coyote/1.1 Content-Type: multipart/related; type="application/soap+xml"; action="urn:gettimeofdayresponse" Transfer-Encoding: chunked Date: Mon, 30 Jun :13:46 GMT <?xml version='1.0' encoding='utf-8'?> <soapenv:envelope xmlns:soapenv=" <soapenv:body> <ns:gettimeofdayresponse xmlns:ns=" <ns:return>14:13:46</ns:return> </ns:gettimeofdayresponse> </soapenv:body> </soapenv:envelope> Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

33 TimeWS-Beispiel Technik Service autonome Anwendungskomponente mit transparenter Realisierung (Technologie, Betreiber) beschrieben durch die Web Services Description Language (WSDL) publiziert in Service-Verzeichnissen Rollenmodell prinzipiell offen; häufig: Klient/Server, RPC Datenmodell XML-Dokumente Kommunikationsadressen Protokoll plus Netzadresse Kommunikationsframework SOAP Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

34 4.3.8 Web Service Security Standards für Sicherheitseigenschaften der Kommunikation Integrität (Hash-Prüfwerte) Vertraulichkeit (Verschlüsselung) Verbindlichkeit (digitale Signaturen) Sicherheitsattribute ( Tokens ) als Teil einer SOAP-Botschaft Schlüsselzertifikate (X.509) Spezifikation, wo und wie Verschlüsselungsinformationen Signaturen security tokens in eine SOAP-Botschaft eingefügt werden (Mehr ist das bisher nicht!) Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

35 Zusammenfassung Web Services Implementierungen konkreter Kommunikationsmodelle (oft RPC) Ziel hohe Interoperabilität heterogener verteilter Anwendungssysteme Weg SOAP: Kommunikationsframework mit mehreren Kommunikationsmodellen Web Services Middleware es ist noch viel zu tun: nichtfunktionale Eigenschaften Performanz Kommunikationssicherheit: Specs in WS-Security Fehlersemantiken TimeWS- Client TimeWS- Service Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as

36 5. Die Messages des Kurses Kommunikation verteilte Systeme problemspezifische Modelle Modellspektrum send/receive Blackboards ereignisbasierte Tupelräume RPC (und RMI) Speicherbasierte Kommunikation: DSM, transaktionaler Speicher Einsatzszenarien serviceorientierte Architekturen (Klient/Server, RPC/RMI) Webshops (Blackboards / Tupelräume) I-Graphoscope, Börsen (ereignisbasierte Tupelräume) Fallstudien Übung: Sockets, SUN RPC (CORBA) Web Services (Axis 2 Framework) ENDE Kommunikationsmodelle, SS 2010 wk, SS 2011/12/13/14/15: as