Seminararbeit. Vergleichende Analyse von Webservices für die Kommunikation mit einem AixBOMS-Server

Transkript

1 Seminararbeit Vergleichende Analyse von Webservices für die Kommunikation mit einem AixBOMS-Server von, ComConsult Kommunikationstechnik GmbH 1. Betreuer: Prof. Ulrich Stegelmann 2. Betreuer: Michael Nieberg Seite 1 von 25

2 1. Einleitung Aufgabenstellung und Motivation Begriffserklärungen Webservices AixBOMS Beschreibung der Architektur Begriffe Analyse der Webservice-Technologien SOAP/WSDL Beschreibung Aufbau Vorteile Nachteile REST Beschreibung Aufbau Vorteile Nachteile Ergebnis und Auswahl Ergebnis der Analyse Auswahl der Technologie Ausblick Anhang Eigenständigkeitserklärung Literaturverzeichnis Seite 2 von 25

3 1. Einleitung 1.1 Aufgabenstellung und Motivation Zur die Entwicklung von Applikationen für mobile Endgeräte soll eine einheitliche Schnittstelle zu einem AixBOMS-Server entwickelt werden. Aus dieser Anforderung ist die Idee entstanden einen Applikationsserver einzurichten, der mit definierten Schnittstellen und einer einheitlichen Datenstruktur die Kommunikation des Endgerätes mit dem AixBOMS-Server gewährleisten soll. In dieser Arbeit sollen nun Webservice- Technologien untersucht und verglichen werden, um eine Basis für die Entwicklung einer Schnittstelle vom Endgerät zum Applikationsserver zu bieten. Seite 3 von 25

4 2. Begriffserklärungen 2.1 Webservices Ein Webservice ist ein Software-System, welches dazu dient, Maschine-zu-Maschine-Interaktion über ein Netzwerk zu unterstützen. Ein Webservice hat eine für Maschinen zu verarbeitende Schnittstelle 1. Webservices können zur einfachen Datenübermittlung verwendet werden, finden aber auch Anwendung im Bereich der Remote Procedure Calls (RPC). Dabei wird von einem externen System über den Aufruf eines Webservices eine Funktion auf dem Server aufgerufen, die auch Parameter und Rückgabewerte enthalten kann. Diese zusätzlichen Daten werden mit übertragen und im Fall der Rückgabewerte wieder an das externe System übertragen. Im Zuge dieser Arbeit wird der Begriff Webservice als Schnittstelle zwischen der mobilen Endanwendung und dem Mobil-Server verwendet. Webservices werden verwendet, da sie meist Technologien wie http und die damit verbundenen Ports (80 oder 443) verwenden und somit weniger Probleme im Zusammenhang mit Firewalls auftreten, als bei einem komplexen System, in dem zuerst ein Port zur Kommunikation ausgehandelt wird. 1 Vgl. (W3C, Web Service Architecture, 2004) Seite 4 von 25

5 2.2 AixBOMS AixBOMS (Aix la Chapelle Business Object Management System) ist eine Configuration Management Database (CMDB) Suite des Software-Unternehmens AixpertSoft. Diese CMDB ist aus verschiedenen Applikationen aufgebaut, die einzelne Teilbereiche der IT-Dokumentation und des Prozessmanagements abdecken. Zum Beispiel können in der CMDB Applikation verschiedene Arten von Configuration Items (CI) dokumentiert werden. Hier können unter anderem ein Server und seine verschiedenen Eigenschaften beschrieben werden. Daten, wie zum Beispiel der Standort, das Betriebssystem, verbaute Komponenten (exemplarisch Netzkarte), werden somit an einer zentralen Stelle zusammengetragen und verarbeitet. Weiterhin kann man Verbindungen zu anderen CIs oder Stammdaten, wie Personen oder Firmen, dokumentieren. Weitere Möglichkeiten der Anwendung beinhalten die Dokumentation von Rechenzentren, Serverracks und Verteilerschränken, sowie die enthaltenen Verbindungen und die Dokumentation von Services. Die Applikationen, die Anzahl der CIs und die Anzahl der User werden vom Hersteller als Lizenzen behandelt und es gibt somit auch gewissen Einschränkungen. Die Daten werden in einer Oracle-Datenbank gespeichert und von dem AixBOMS-Server für die Visualisierung und Bearbeitung aufbereitet. Der Applikationsserver gewährleistet in Zusammenarbeit mit der Datenbank die Konsistenz sowie die syntaktische Seite 5 von 25

6 und logische Korrektheit der Daten soweit diese definiert und maschinell überprüfbar sind (konfigurierbare Businessrules). AixBOMS bietet Webservices an, welche jedoch nicht geeignet erscheinen, die Kommunikation mit einem mobilen Endgerät zu gewährleisten. Diese vorhandenen Webservices arbeiten auch mit serialisierten Java-Objekten. Dafür müsste sichergestellt sein, dass das Endgerät Java-fähig ist. Weiterhin müssten weitere Bibliotheken in der mobilen Applikation enthalten sein, was wiederum den Speicherbedarf vergrößert, wobei zu beachten ist, dass Speicherplatz auch bei modernen, mobilen Endgeräten eine knapp bemessene Ressource ist. Seite 6 von 25

7 Abb. 1: AixBOMS-Architektur mit Mobil-Planung Es gibt verschiedene Möglichkeiten mit dem AixBOMS-Server zu arbeiten. Es ist möglich über eine Weboberfläche im Browser einige der Applikationen zu nutzen. Für den vollen Funktionsumfang ist eine Client-Software nötig (Navigator). Seite 7 von 25

8 In Kundenumgebungen werden zusätzlich automatisierte Schnittstellen verwendet. Diese dienen dem Import oder Export von Daten und erstellen teilweise auch Differenzen oder führen komplexe Datenmanipulationen in AixBOMS durch. Bei der Entwicklung von eigenen Schnittstellen für AixBOMS ist die Verwendung der XClient-API entscheidend. Diese ist die einzige vom Hersteller unterstützte und dokumentierte Schnittstelle zum AixBOMS-Server. Die XClient-API basiert auf dem vorhandenen Datenmodell und ist dementsprechend komplex in der Benutzung. Sie ist eine Bibliothek für Java und Java-basierte Sprachen wie zum Beispiel Groovy und stellt Methoden und Klassen zur Verfügung, die SOAP-Nachrichten erzeugen und so die angebotenen Webservices des AixBOMS- Servers nutzen. Dabei ist für den Anwender die Kenntnis des Aufbaus und der Struktur der Webservices nicht erforderlich. Die Erzeugung und das Auslesen der SOAP-Nachrichten erfolgt durch die Verwendung der XClient-API automatisch. Seite 8 von 25

9 2.3 Beschreibung der Architektur Durch die sehr speziellen Anforderungen und Anwendungsfälle des Mobil-Servers ist eine eigene Entwicklung erforderlich. Diese würde alle Voraussicht nach in Groovy erfolgen. Dadurch soll gewährleistet werden, dass durch Benutzung der XClient-API für die Kommunikation mit dem AixBOMS-Server die Daten unter Einhaltung der gegebenen Geschäftsregeln verarbeitet werden. Dem Mobil-Client sollen wiederum einfach aufzurufende Funktionen zur Verfügung gestellt werden, die ohne Kenntnis des internen Datenmodells Änderungen durchführen oder Informationen zurückgeben. Durch die Entwicklung eines Mobil-Servers, der diese Aufgaben übernimmt, können auch zusätzliche Anforderungen und Erweiterungen vergleichsweise einfach übernommen werden. Neue Versionen oder Funktionalitäten auf der Seite des AixBOMS- Servers müssen somit in erster Linie im Mobil-Server realisiert werden. Dies ist in diesem Zusammenhang gewünscht, da so eine versionsstabile Schnittstelle entstehen soll. Hiermit soll eine ständige Aktualisierung einer Vielzahl von Mobil-Clients vermieden werden. Dies lässt sich nur in dem Maße verhindern, wie die Funktionalität des Mobil-Clients auf dem gleichen Stand bleiben soll. Zusätzlich soll das mobile Endgerät möglichst geringen Rechen- und Speicheraufwand leisten müssen, während diese Aufgaben der Mobil- Server wahrnimmt. Außerdem soll eine Funktionalität eingerichtet werden, die es dem Mobil-Client ermöglicht, die geänderten Daten nicht immer direkt an den Mobil-Server weiterleiten zu müssen, sondern zu einem späteren Zeitpunkt die gesammelten Änderungen zu übermitteln. Für den AixBOMS-Server ist die Zuordnung einer Transaktion zu einem User wichtig, da ein entsprechender Eintrag in Seite 9 von 25

10 die History des Datensatzes erfolgt. Zudem können Seiteneffekte unter anderem dadurch auftreten, dass verschiedene User denselben Datensatz bearbeiten. Da die Funktionen des Mobil-Clients eingeschränkt sein werden, um kein Konkurrenzprodukt zu den vom Hersteller gelieferten Clients zu bilden, bietet sich eine Realisierung in HTML und JavaScript an. Mit geeigneten Entwicklungswerkzeugen (Phonegap) ist es somit möglich bei nur einmaliger Entwicklung mehrere Formen von Endgeräten zu bedienen (ios, Android). Ebenfalls gibt es mit jquery und jquery Mobile Bibliotheken, die viele grundsätzliche Funktionalitäten bieten und es ermöglichen bei der Entwicklung des Mobil-Clients den Fokus auf die speziellen Anforderungen zu legen. Ebenfalls ist es so möglich den Speicher- und Rechenaufwand in einem für das mobile Endgerät zu bewältigenden Rahmen zu halten. Die direkte Verwendung der XClient-API auf dem Mobil-Client bietet sich nicht an, da es keine für mobile Endgeräte gedachte Version dieser Bibliothek gibt und die Implementierung der entsprechenden Klassen auf dem Endgerät auch erheblichen Speicher- und Rechenaufwand bedeuten würde. Um die Sicherheit der Daten zu gewährleisten, die Dokumentation der Änderungen in der History des CI, sowie die Einhaltung der Lizenzen, muss die Realisierung einer Authentifizierung gegeben sein. Eine angebotene Funktion kann beispielsweise die Übermittlung einer Liste von Standorten sein. Um nicht immer den kompletten Bestand an Daten übermitteln zu müssen, sollte der Nutzer bereits vor der Abfrage der Daten einen Filter setzen. Aufgrund des hierarchischen Aufbaus dieser Art von Daten in AixBOMS kann aber auch dies bereits eine größere Menge an Daten sein. Seite 10 von 25

11 Abb. 2: Beispiel einer Standorthierarchie Das Beispiel soll verdeutlichen, dass eine Suche nach der Stadt Aachen auch alle darunter liegenden Standorte liefern würde. Eine weitere Funktion könnte die Abfrage der Daten zu einem bestimmten CI sein. Dies umfasst zwar nur einen Datensatz, der jedoch eine Vielzahl von Attributen enthält. Der Umfang der Daten sollte auch beachtet werden, da aus der Praxis bekannt ist, dass die Anzahl der Daten eines Typs große Ausmaße annehmen kann. Ein Beispiel dafür sind folgende Zahlen: 3000 Standorte, Komponenten, 5000 Personen und zusätzliche Objekte im Datenbestand eines Kunden. Seite 11 von 25

12 2.4 Begriffe Im Folgenden soll der Begriff Client allgemein für das System stehen, welches die Webservices aufrufen möchte. Dementsprechend bezeichnet Server das Webservice anbietende System, welches die Daten verarbeiten und weitervermitteln soll. Mobil-Server bezeichnet das Programm welches die eigentlichen Daten verarbeitet und entsprechend der existierenden Richtlinien mit dem AixBOMS-Server kommuniziert. Der Mobil-Server muss auch eventuelle Fehler behandeln und in geeigneter Form an den Mobil-Client, welcher die Applikation auf dem mobilen Endgerät beschreibt, weitergeben lassen. Seite 12 von 25

13 3. Analyse der Webservice-Technologien Im Folgenden werden nun die Technologien SOAP/WSDL und REST betrachtet. Dabei sollen die Vor- und Nachteile der jeweiligen Technologien im Bezug auf Architektur-Entwurf betrachtet werden. Sowohl bei SOAP/WSDL als auch bei REST erfolgt die Kommunikation über http was die Integration in Firmennetzwerke vereinfacht. 3.1 SOAP/WSDL Beschreibung SOAP ist eine Architektur zur Bereitstellung von Webservices, die bereits 1999 eine erste genaue Beschreibung erfuhr. SOAP stand ursprünglich für Simple Object Access Protokoll. Jedoch ist durch weitere Entwicklungen eine größere Komplexität entstanden, was gegen die Eigenschaft Simple spricht. Es wurden auch zusätzliche Funktionalitäten hinzugefügt worden, die über den Zugriff auf Objekte hinausgeht. Dadurch wird SOAP heute als feststehender Ausdruck und nicht mehr als Abkürzung angesehen. SOAP beschreibt ein Protokoll zum Austausch von XML-basierten Nachrichten zur Kommunikation zwischen Applikationen. SOAP beschreibt dabei den Aufbau der ausgetauschten Nachrichten und dient der Vereinheitlichung der Informationsübertragung. WSDL steht für Web Service Description Language und ist eine Beschreibungssprache für Webservices, die in ihrer ersten Version 2001 beschrieben wurde. Aktuell ist Version 2, welche 2007 Seite 13 von 25

14 veröffentlicht wurde. WSDL beschreibt welche Funktionen von außen aufgerufen werden und kann zudem verwendet werden, um eine genaue Beschreibung der benötigten Parameter, möglicher Rückgabewerte und zusätzlicher Informationen zu liefern. Zusätzliche Informationen können beispielsweise das verwendete Protokoll (z.b. SOAP) aber auch das Format der erwarteten Nachricht zum Aufruf der Funktion sein Aufbau SOAP-Nachrichten, die auch als SOAP Envelope bezeichnet werden, sind in XML geschrieben und enthalten einen optionalen Header und einen Body. Im Header sind Metainformationen gespeichert, die den allgemeinen Aufbau der Nachricht, sowie einige zusätzliche Attribute beschreiben. Dort können Details wie zum Beispiel Namespace- Informationen oder Encodierungs-Informationen enthalten sein. Im Body der SOAP-Nachricht werden die Daten der Nachricht beschrieben. Dabei kann der Body sowohl Daten enthalten, als auch beispielsweise Befehle zum Aufruf einer Funktion oder eines Befehls auf dem Server. Ruft nun das aufrufende System das WSDL-Dokument ab, kann der Entwickler nun sehen welche Funktionen und damit Webservices angeboten werden, welche Parameter er übergeben muss und welche Rückgabewerte er erwarten kann. Zusätzlich kann er nun die abstrakte Beschreibung nutzen um die Objekte unter Zuhilfenahme von XML zu generieren, die zum Server übertragen werden sollen. 2 (W3C, Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, 2007) Seite 14 von 25

15 Allgemein können alle Datentypen verwendet werden, die ein entsprechend verwendetes XML-Schema anbietet. In der Praxis wird meist für die Client-Anwendung eine entsprechende Bibliothek erstellt, die die Komplexität der Nachrichten-Generierung kapselt. Abb. 3: Übermittelter SOAP-Nachrichtenverkehr in AixBOMS: Informationsgehalt: eine SessionID Vorteile Durch die Verwendung von XML sowohl für den Aufbau der Nachrichten als auch für die Struktur der übermittelten Objekte ist die Einheitlichkeit, abgesehen von etwaigen Kodierungsproblemen, gegeben. Es existiert eine Vielzahl an Erweiterungen für SOAP/WSDL basierte Webservices WS-* genannt. Als Beispiel sei hier WS-Security genannt. Diese Erweiterung ermöglicht unter Anderem die Übermittlung von Seite 15 von 25

16 Securitytokens in SOAP-Nachrichten, was für die Sicherung des Mobil- Clients genutzt werden könnte. Auch ist die serverseitige Integration der Webservices durch die Verwendung etablierter Produkte (z.b. Apache Axis) einfach zu realisieren Nachteile Durch den sehr formalen Aufbau der Nachrichten wird bereits die Übertragung eines sehr einfachen Datums (wie zum Beispiel eines Wahrheitswertes, repräsentiert als 0 für falsch oder 1 für wahr) zu einem großen und im Gegensatz zu dem eigentlichen Informationsgehalt der Nachricht komplexen Konstrukt. Dies führt zu einem sehr hohen Aufwand für die Übertragung eines vergleichsweise einfachen Datums. Durch diesen sehr großen Anteil an beschreibenden Inhalten in den Nachrichten entsteht ein sehr großer Speicherbedarf bereits für einfache Nachrichten. Ebenfalls ist ein sehr großer Umfang der Nachricht nötig falls komplexere Datentypen verwendet werden. Eine Liste von Attributen ist noch vergleichsweise einfach abzubilden. Eine umfassende Liste von Objekten, die wiederum eine Vielzahl an Attributen enthalten, erhöht die Größe der Nachricht auch bereits erheblich. Zudem ist es bei jeder Nachricht erforderlich, dass der Sender die Daten kodiert und der Empfänger die Nachricht wieder dekodiert um die enthaltenen Daten zu verarbeiten. Dies erzeugt wiederum Rechenaufwand, da diese Nachrichten XML-kodiert sind. Weiterhin wird die Verwendung von SOAP/WSDL weder von JavaScript noch von etablierten Bibliotheken wie zum Beispiel jquery Seite 16 von 25

17 unterstützt. Für die effektive Nutzung ist somit ein hoher Programmieraufwand erforderlich, der wiederum die Komplexität und den Speicherbedarf des Mobil-Clients vergrößern würde. Seite 17 von 25

18 3.2 REST Beschreibung REST ist eine Abkürzung und steht für Representational State Transfer. REST beschreibt keine genaue Konvention oder ein spezielles Schema sondern ist eher als Richtlinie zu verstehen, wie Webservices realisiert werden können. REST erfuhr seine erste Beschreibung in der Dissertation aus dem Jahr 2000 von Roy Thomas Fielding, welche den Titel Architectural Styles and the Design of Network-based Software Architectures trägt. REST beschränkt sich hierbei auf bereits durch das HTTP- Protokoll beschriebene Funktionen und erweitert die bereits bestehenden Methoden Aufbau Da REST keine festgelegte Norm ist, werden nur Empfehlungen formuliert, die beschreiben wie ein REST-konformer (oder RESTful ) Webservice aufgebaut werden soll. Kernpunkte dieser Empfehlungen sind Zustandslosigkeit, die Verwendung von http-methoden sowie die Adressierung der Webservices über eine URI. 3 Die Zustandslosigkeit beschreibt hierbei eine in sich geschlossene Kommunikation zwischen Client und Server bei jeder Abfrage. Das bedeutet, dass jede Antwort des Servers alle Informationen enthalten soll, die zum Verständnis der Nachricht notwendig sind. 3 Vgl. (Fielding, 2000) Seite 18 von 25

19 Die Verwendung von HTTP-Methoden zur Übertragung von Informationen manifestiert sich in der Verwendung der Methoden GET, POST, PUT und DELETE. Der Client kann mittels GET Informationen vom Server anfragen. Er kann POST nutzen um neue Daten auf dem Server anzulegen. PUT wird genutzt um bestehende Daten zu ändern oder neue Daten ohne Bezug zu einem bereits bestehenden Datum anzulegen während DELETE dazu genutzt wird, Daten zu löschen. Die entsprechende Implementierung der Methoden muss serverseitig gewährleistet sein. Die Änderungen an Attributen oder neue Objekte werden dabei im BODY der http-nachricht übertragen. Dabei können Technologien wie zum Beispiel JSON (JavaScript Object Notation) oder XML zum Einsatz kommen. JSON bietet die elementaren Datentypen Number, String, Boolean und Array. Weiterhin können Objekte deklariert werden, die wiederum eine Sammlung von Schlüssel-Wert-Paaren sind. Seite 19 von 25

20 { } vorname : Max, nachname : Mustermann, alter :37, rabatt :5.25, bestellungen : { gekauft : [ { id :47, preis :19.99 }, { id :11, preis :8.15 } bestellt :[] ] } Beispiel Objektes eines JSON- Die Adressierung der Webservices und Daten über die URI und einen verzeichnisstrukturartigen Aufbau soll ein besseres Verständnis für die Funktion des Webservices liefern Vorteile Im Falle der Verwendung von JSON als Format für die Datenübertragung wird dieses vom Mobil-Client bereits unterstützt. Funktionen für dieses Format sind auch in Groovy als der serverseitig genutzten Technologie vorhanden. Dadurch kann dieses Format sowohl vom Mobil-Client als auch vom Mobil-Server schnell und ohne viele Übersetzungsschritte verarbeitet werden. Die Größe eines JSON Objektes ist in der Regel auch geringer, da Metainformationen und Auszeichnungen entfallen oder auf wenige Zeichen reduziert werden. Seite 20 von 25

21 Dadurch verringert sich auch der Zeit- und Rechenaufwand, der für die Kodierung und Dekodierung der Objekte nötig ist. Der Verzeichnisbaum-artige Aufbau der URI über die der Mobil-Server angesprochen würde, böte die Möglichkeit sich an der bestehenden Applikations- und Datenstruktur zu orientieren Nachteile Da REST kein Standard ist, wird keine festgelegte Definition des Aufbaus von Nachrichten oder den enthaltenen Daten erzeugt. Die flexible Interpretation der Beschreibung von REST Diese kann jedoch durch WADL (Web Application Description Language), einen Vorschlag zur Beschreibung von Webapplikationen im Allgemeinen, oder die Nutzung von WSDL erreicht werden. Seite 21 von 25

22 4. Ergebnis und Auswahl 4.1 Ergebnis der Analyse Nach der Analyse wird deutlich, dass die Realisierung des beschriebenen Szenarios mittels Webservices möglich erscheint. Beide Technologien bieten Mittel und Werkzeuge um Daten zu vermitteln und mittels eines Applikationsservers zu verarbeiten. Die Komplexität einer solchen Entwicklung kann als hoch eingeschätzt werden, da in beiden Fällen eine ausführliche Dokumentation der Schnittstellen und des Datenformats nötig ist. Diese ist notwendig um eventuelle zukünftige Erweiterungen der Mobil-Client-Applikation zu ermöglichen. Diese soll auch von anderen Entwicklern, die nicht unbedingt an der ursprünglichen Entwicklung beteiligt waren, geleistet werden können. 4.2 Auswahl der Technologie Für den Verfasser erscheint die Verwendung von REST in Kombination mit JSON lohnender. Die native Verarbeitung von JSON-Objekten in JavaScript verringert die vom Mobil-Client zu verrichtenden Aufwand. Zusätzlich ist der Umfang der Nachrichten die übermittelt werden müssen bei der Verwendung von JSON geringer. Dies ist der Kernpunkt, der gegen die Verwendung von SOAP/WSDL spricht, da hierbei die Verwendung einer erstellten Bibliothek auf dem Mobil- Client oder die Erstellung der Nachrichten im Quellcode nötig wäre. Dadurch entsteht ein erhöhter Speicherplatzbedarf und unabhängig Seite 22 von 25

23 von der gewählten Herangehensweise ist auch der Rechenaufwand für die Erstellung und das Auslesen der Nachrichten höher. Dies widerspricht jedoch der Idee die Last vom Mobil-Client auf den Mobil- Server zu verlagern. 4.3 Ausblick Es ist in Betracht zu ziehen, ein erstes Testsystem aufzusetzen mit dem die Funktionalität des Client-Server-Systems überprüft werden kann. Im Falle eines erfolgreichen Tests und einer entsprechenden Nachfrage kann die Entwicklung eines solchen Systems begonnen werden. Dazu sollte ein ausführliches Konzept und eine Beschreibung der Schnittstellen sowie der Datenmodelle angelegt werden. Weiterhin können nach der anfänglichen Entwicklung des Systems zusätzliche Funktionalitäten oder Anwendungsbereiche hinzugefügt werden. Seite 23 von 25

24

25 6. Literaturverzeichnis Fielding, T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Abgerufen am 10. Dezember 2012 von SOAP. (kein Datum). Abgerufen am 10. Dezember 2012 von Wikipedia: W3C. (27. April 2007). SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). Abgerufen am 10. Dezember 2012 von World Wide Web Consortium (W3C): W3C. (02. November 2004). Web Service Architecture. Abgerufen am 10. Dezember 2012 von World Wide Web Consortium (W3C): W3C. (26. Juni 2007). Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. Abgerufen am 10. Dezember 2012 von World Wide Web Consortium (W3C): Seite 25 von 25