Realisierung von online Applikationen als Cross-Domain Web Service mit ausgelagerter Datenhaltung

Transkript

1 Realisierung von online Applikationen als Cross-Domain Web Service mit ausgelagerter Datenhaltung Ingrid Stürmer D I P L O M A R B E I T eingereicht am Fachhochschul-Masterstudiengang Digitale Medien in Hagenberg im Juni 2010

2 Copyright 2010 Ingrid Stürmer Alle Rechte vorbehalten ii

3 Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen Stellen als solche gekennzeichnet habe. Hagenberg, am 25. Juni 2010 Ingrid Stürmer iii

4 Inhaltsverzeichnis Erklärung Kurzfassung Abstract iii vi vii 1 Einleitung Motivation Zielsetzung Aufbau der Arbeit Allgemeines AJAX vs. Ajax Cross-Domain Ajax Cloud Computing Alles in der Wolke State of the art Cloud Applikationen mit Datenhaltung Cloud Applikationen ohne Datenhaltung Mashups Zusammenfassung Cross-Domain Ajax Technische Realisierungsmöglichkeiten Bibliotheken Der WebApplicationService Die Idee Aufbau Ablauf Der Ursprung Pixelina Datenübertragung Sicherheitsaspekte Quellcode codieren iv

5 Inhaltsverzeichnis v 5.8 Web Services Implementierung Verwendete Technologien Aufbau Sicherheit Aufbau Pixelina Herausforderungen bei der Umsetzung Evaluierung Entwicklungsspezifische Aspekte Kundenspezifische Aspekte Sicherheitsspezifische Aspekte Zusammenfassung Schlussbemerkungen 92 A Inhalt der CD-ROM 94 A.1 Masterarbeit A.2 Onlinequellen A.3 CMS Prototyp A.4 Pixelina Literaturverzeichnis 100

6 Kurzfassung In Zeiten von Cloud Computing werden stetig mehr Applikationen auf fremde Server ausgelagert und über einen Webbrowser zugänglich gemacht. Dies hat den großen Vorteil, dass die Software nicht mehr auf eigenen Systemen installiert werden muss und somit der Aufwand für lokale Aktualisierungen entfällt. Das Problem bei diesem Trend liegt jedoch darin, dass nicht nur die Anwendungen selbst ausgelagert werden, sondern auch die gesamte Datenhaltung. Anwendungen und Daten sind nur mehr über den Server des Softwareanbieters zugänglich, was gewissermaßen die Kontrolle der Daten für den Kunden einschränkt. Dies ist ein kritischer Punkt, warum viele Kunden vor allem Firmenkunden dem Thema Cloud Computing skeptisch gegenüber stehen, da die Auslagerung der Daten auf fremde Server und die Angst vor Kontrollverlust von der Nutzung von Software as a Service -Produkten abhält. Im Zuge dieser Arbeit wurde ein Konzept entwickelt, dessen Umsetzung es möglich macht, online Applikationen ohne aufwändige Installation am eigenen Server zu nutzen. Ein großer Vorteil liegt darin, dass die Applikation bei jedem Aufruf als Service von einem fremden Server geladen wird und somit stets die aktuelle Version der Anwendung zum Einsatz kommt. Der wichtigste Punkt besteht allerdings darin, dass die Daten in der Datenbank und im Dateisystem auf einem eigenen Server bzw. gemietetem Websapce gehalten werden können und erst zur Laufzeit an die Applikation übergeben werden. Applikationen, die auf diesem im Rahmen der vorliegenden Arbeit als WebApplicationService bezeichneten Konzept basieren, können grundsätzlich für alle Arten von Webanwendungen umgesetzt werden. Dieses Prinzip, nur die Anwendung auszulagern, die Daten aber auf eigenen Servern zu halten, könnte sich als wichtige Variante des Cloud Computing herausstellen. vi

7 Abstract In times of cloud computing, more and more applications are being stored on remote servers and made accessible through a web browser. This has the great advantage that software no longer needs to be installed on a dedicated server. The problems that arise from this trend however are that outsourcing of applications is accompanied by outsourcing of sensitive data. This master thesis describes a concept for using online applications within its own domain without the requirement to install software on the server. The advantage of this is, that the application is called via a service hosted on a remote server, therefore the software version is always up to date. The most important point is that the data stored within the database and on the file system can be managed directly on your own locally managed server. Applications based on this concept in this master thesis called Web- ApplicationService can be implemented for any kind of web application. The benefit of inhouse data management and selective access to the applications, as well as the software as an all-encompassing service is an important step towards the concept of successful computing in the cloud. vii

8 Kapitel 1 Einleitung 1.1 Motivation Eines der zukunftsträchtigen Prinzipien in der IT-Welt der jüngsten Zeit ist das Cloud Computing eine genaue Beschreibung findet sich in Kapitel 2. Es werden immer mehr Applikationen entwickelt, die über die Cloud verfügbar sind und auch ihre Daten in der Cloud verwalten. Das in dieser Arbeit beschriebene Konzept WebApplicationService verfolgt einen Ansatz, der es Benutzern ermöglicht, Applikationen von fremden Servern auf einem eigenen Server oder Webspace zu integrieren und so Zugriff auf lokale Daten zu verschaffen. Dies bietet Vorteile in vielerlei Hinsicht wie beispielsweise geringeren Wartungsaufwand, da die Applikation jedes Mal erneut vom Fremdserver geladen wird und somit immer eine aktuelle Instanz der Anwendung im Einsatz ist. Dies ist gerade im schnelllebigen Web ein enormer Gewinn. Ein weiterer Vorteil dieses Lösungsansatzes liegt darin, dass beinahe die gesamte Rechenleistung auf den Fremdserver ausgelagert wird, da die Applikation zur Gänze auf diesem läuft. Somit wird der eigene Server entlastet, der unter Umständen auch nicht auf bestimmte Arten von Anwendungen ausgerichtet ist. Einen besonders interessanten Punkt stellt die Datenhaltung dar. Diese erfolgt komplett getrennt von der Applikation auf dem eigenen Server, was bei Cloud Applikationen wie z.b. Google Docs 1 nicht der Fall ist. 1.2 Zielsetzung Es gibt eine große Anzahl an Applikationen, die online für Benutzer zur Verfügung stehen, z.b. Google Maps, Google Docs etc. Einige davon eignen sich auch für die Integration auf eigenen Websites. Besonders oft werden diese kleinen Tools in Content Management Systemen (CMS) eingesetzt und werden in Form von Extensions eingebunden. Diese kleinen Applikationen 1 1

9 1. Einleitung 2 besitzen jedoch alle eine Gemeinsamkeit: Ein Ablaufdatum. Es muss in regelmäßigen Abständen überprüft werden, ob stets eine aktuelle Version der Applikation in Verwendung ist. Aufgrund des schnelllebigen Webs kann es einerseits oft zu Design- oder JavaScript-Problemen kommen, die z.b. mit Browserupdates einhergehen, und andererseits können die Applikationen aufgrund des technischen Fortschritts schnell veraltern. Weiters kann es z.b. bei CMS vorkommen, dass mit einem Versionsupdate bestimmte Extensions nicht mehr kompatibel sind. Ein Ansatz, den auch Google mit Google Maps 2 verfolgt ist jener, dass eine gesamte Applikation mittels JavaScript direkt in eine bestehende Seite eingebunden und so zur Gänze von einem fremden Server geladen wird. Aufgrund der clientseitigen Einbindung per JavaScript und dem Laden der Anwendungen von einem Drittserver, ist es notwendig, auf Cross-Domain Ajax zurückzugreifen. Cross-Domain Ajax greift im Gegensatz zu normalem Ajax auf fremde Server, die unter einer anderen Domain erreichbar sind, zu. Kurz gesagt erfolgt ein Server-Request von JavaScript aus auf eine andere Domain. Eine detaillierte Beschreibung zu Ajax und Cross-Domain Ajax findet sich in Kapitel 2. Das Ziel dieser Arbeit liegt nun darin, ein Konzept zu beschreiben, welches es ermöglicht, komplette Applikationen per JavaScript von fremden Servern zu laden und dabei mit den lokalen Daten am Server zu arbeiten. Ein wichtiger Punkt dabei ist, herauszufinden, in welchem Umfeld solche Anwendungen Sinn machen, wo man auf Grenzen stößt und welche Probleme bzw. Herausforderungen bei der Umsetzung von Projekten nach diesem Konzept entstehen können. 1.3 Aufbau der Arbeit In Kapitel 2 werden zuerst die notwendigen Grundlagen, die für das Verständnis des WebApplicationService-Konzeptes wichtig sind, behandelt. Hier werden die Themen Ajax und Cross-Domain Ajax, sowie die damit verbundenen Probleme näher unter die Lupe genommen. Weiters wird auf Cloud Computing eingegangen und die dabei auftretenden Schwierigkeiten diskutiert. In Kapitel 3 werden unterschiedliche Webapplikationen vorgestellt, die entweder Ähnlichkeiten mit dem WebApplicationService-Konzept aufweisen, die Konzepterstellung und Implementierung wesentlich beeinflusst haben oder generell interessant im Bezug auf Cloud Computing sind. Da Cross-Domain Ajax beim WebApplicationService-Konzept eine große Rolle spielt, werden in Kapitel 4 einerseits unterschiedliche Methoden für die Nutzung von Cross-Domain Kommunikation vorgestellt und andererseits 2

10 1. Einleitung 3 wird auf den Einsatz von unterschiedlichen Bibliotheken für Cross-Domain Ajax eingegangen. In Kapitel 5 wird das entwickelte WebApplicationService-Prinzip erklärt und beschrieben, wie dieses entstanden ist. Weiters wird hier auf wichtige Punkte, die man bei der Entwicklung einer Applikation nach diesem Konzept berücksichtigen sollte, wie z.b. Sicherheit und Codeverschlüsselung, eingegangen. In Kapitel 6 werden Aufbau und Umsetzung der beiden Projekte nach dem WebApplicationService-Konzept das CMS und Pixelina beschrieben. Zusätzlich wird hier auf Herausforderungen und Probleme bei der Entwicklung eingegangen, sowie Lösungswege diskutiert. Das Kapitel 7 dreht sich um die schlussendliche Bewertung der Applikation aus unterschiedlichen Sichtweisen. Hier wird versucht Applikationen zu definieren, für die sich die Umsetzung nach diesem Konzept am besten eignet. In Kapitel 8 findet sich die Schlussfolgerung, die sich aufgrund der einzelnen Kapitel ergeben hat.

11 Kapitel 2 Allgemeines In diesem Kapitel werden Begriffe und Technologien vorgestellt, die notwendig für das Verständnis der Zusammenhänge in dieser Arbeit sind. 2.1 AJAX vs. Ajax Um zu verstehen wie das Laden der Applikation mittels Cross-Domain Ajax funktioniert, ist es zunächst unumgänglich zu wissen, was Ajax eigentlich bedeutet. Ajax ist keine Technologie, sondern vielmehr ein Marketingbegriff, der von Jesse J. Garrett im Februar 2005 ins Leben gerufen wurde. AJAX steht also für Asynchronous JavaScript and XML, wobei AJAX nicht immer asynchron ablaufen muss und nicht zwingend XML als Kommunikationsformat verwenden muss. Deswegen ist AJAX als Akronym nicht mehr wirklich passend und wurde somit zu einem eigenständigen Wort Ajax (vgl. [3] und [33, S. 391]). Dieses ist auch gleichbedeutend mit sämtlichen Ajax-Abwandlungen wie z.b. SJAX (Synchronous JavaScript and XML) oder AJAJ (Asynchronous Java-Script and JSON) oder AHAH (Asynchronous HTML and HTTP), bei dem über einen XMLHttpRequest 1 direkt HTML angefordert und eingebunden wird. Ajax steht nun nur mehr für die Kommunikationsweise mit dem Server, unabhängig davon welches Datenformat zum Einsatz kommt Was ist Ajax? Ajax kann im Grunde genommen als modernes DHTML beschrieben werden, also eine Kombination von mehreren, schon lange vor Ajax bekannten Technologien. Die typischen Technologien stellen folgende bekannte Werkzeuge dar (vgl. [22]): Cascading Style Sheets (CSS) JavaScript (mit dem XMLHttpRequest) 1 4

12 2. Allgemeines 5 Document Object Model (DOM) 2 XML oder andere Formate wie HTML und JSON (JavaScript Object Notation) Wie funktioniert Ajax? Wie alle anderen auf HTML basierenden Webapplikationen, verwendet eine Ajax-Applikation HTML oder XHTML zur Darstellung der Webseiten im Browser (Client) oder hat serverseitige Scripte (z.b. JSP oder PHP) zur dynamischen Generierung der einzelnen Seiten im Einsatz. Bei der Anwendung von Ajax wird mit JavaScript ein Objekt das XMLHttpRequest-Objekt erzeugt, mit dem es möglich ist, eine HTTP- Anfrage über die HTTP-Methoden GET oder POST vom Client zum Webserver zu schicken. Der Server bearbeitet die Anfrage (Request), erzeugt eine Anwort (Response) und sendet diese in einem beliebigen Format (XML, JSON, HTML etc.) zurück zum Client. Auf dem Client wird eine JavaScript-Callback Funktion ausgeführt, welche die erhaltenen Daten vom Server verarbeitet und per DOM-Manipulation in die aktuelle Seite einbaut. Ajax ermöglicht also das Ausführen von HTTP-Anfragen im Hintergrund über JavaScript und somit das Aktualisieren von Teilbereichen auf Websites, ohne die gesamte Seite neu zu laden Welches Kommunikationsformat? Obwohl XML zu Beginn das X in AJAX darstellte, hat es sich gerade bei Ajax sehr schnell als ziemlicher Overhead aufgrund der zwar übersichtlichen, aber zeichenintensiven Tag-Struktur herausgestellt. Abgesehen davon kann JavaScript in den meisten Browsern nicht nativ mit XML umgehen, da ECMA-Script für XML (E4X) 4 oft nicht unterstützt wird [9, Kap. 4]. Als Kommunikationsformat für Ajax hat sich JSON bewährt. Einerseits aufgrund seiner schlanken Datenstruktur, mit der trotzdem komplexe Daten repräsentiert werden können, andererseits weil es von den meisten Browsern in ihren JavaScript-Implementierungen unterstützt wird und so der Zugriff auf die Daten sehr einfach ist. 2.2 Cross-Domain Ajax Hinter Cross-Domain Ajax XJAX oder Xjax steckt grundsätzlich die gleiche Funktionalität wie bei normalem Ajax. Der einzige Unterschied besteht darin, dass wie der Name bereits beinhaltet die HTTP-Anfragen

13 2. Allgemeines 6 auf einen fremden Server, der unter einer anderen Domain erreichbar ist, erfolgen. Mittels Cross-Domain Ajax ist es möglich, vollständige Applikationen auf externe Server auszulagern, aber trotzdem gezielten Zugriff auf das System und die Daten über zur Verfügung gestellte Schnittstellen zu gewähren. Eines der besten Beispiele ist Facebook 5 mit den zahlreichen Facebook- Applikationen, die allesamt von fremden Servern geladen werden, jedoch problemlos mit dem Facebook-Server über eine API 6 kommunizieren und so mit sämtlichen Benutzerdaten arbeiten können. Die Besonderheit an dieser Form von Ajax ist die, dass diese Art von Kommunikation via JavaScript von aktuellen Browsern standardmäßig nicht erlaubt ist, da diese ein großes Sicherheitsrisiko darstellen kann. Aufgrund der Same Origin Policy ist Cross-Domain Ajax eigentlich nicht möglich Same Origin Policy Die Same Origin Policy (SOP) stellt ein Sicherheitselement dar, welches im Jahr 1996 von Netscape eingeführt wurde und mittlerweile in allen modernen Browsern implementiert ist. Ziel der SOP ist es, Webanwendungen vor Angriffen zu schützen. Dieser Schutzmechanismus funktioniert, indem Java- Script und ActionScript nur dann auf Objekte einer Website zugreifen dürfen, wenn diese aus derselben Quelle (Origin) stammen. Dies stellt sicher, dass unterschiedliche Websites, die z.b. in verschiedenen Frames geladen werden, nicht miteinander kommunizieren können. Die Anwendungen in den verschiedenen Frames werden vom Browser als unabhängige Teile betrachtet und quasi voneinander isoliert (vgl. [19]). Früher wurden Benutzer oft hinters Licht geführt und auf präparierte Seiten gelockt, auf denen dem Benutzer vertraute Seiten in Iframes geladen wurden. Wenn sich der Benutzer dort einloggte, konnten über den Iframe hinweg sämtliche Daten (Login-Daten, Cookies etc.) ausspioniert werden. Seit der Einführung der SOP ist dies nicht mehr so einfach möglich. Cross-Domain JavaScript Trotz Same Origin Policy ist es möglich, JavaScript-Dateien von fremden Servern einzubinden und das Script auf der eigenen Seite auszuführen. Funktionen aus der externen JavaScript-Datei haben aber trotzdem nicht die Möglichkeit, per Ajax-Request eine Anfrage auf den Server ihres Ursprungs (dem fremden Server) durchzuführen, da das JavaScript nur noch Requests auf die Domain absetzen darf, unter der es geladen wurde Application Programming Interface Programmierschnittstelle

14 2. Allgemeines 7 Überprüfung der Origin Die Same Origin Überprüfung erfolgt per Stringvergleich (vgl. [19]). Das bedeutet, dass der Browser keine Domains in IP-Adressen auflösen kann keine Anfrage an einen DNS-Server stellt und somit auch nicht die Möglichkeit hat, den Zusammenhang zwischen Domain und zugehöriger IP-Adresse zu erkennen. Eine Anfrage von z.b. auf wird nicht als gleiche Quelle interpretiert und blockiert, obwohl der gleiche Server angesprochen wird. Weiters müssen auch Port und Protokoll übereinstimmen, damit der Request zugelassen wird (vgl. [26, Kap. 3]). Es darf z.b. nicht https statt http oder Port 81 statt 80 verwendet werden, wenn die SOP nicht verletzt werden soll Cross-Origin Resource Sharing Aufgrund der neuen Möglichkeiten, die sich durch den Einsatz von Cross- Domain Ajax ergeben, wird die Anwendung bei Entwicklern immer beliebter. Da ständig neue Wege gefunden werden, die SOP zu umgehen, arbeitet die W3C Web Applications Working Group 7 bereits an Cross-Origin Resource Sharing (CORS). Mittels CORS soll es möglich werden, Cross-Domain Requests durchzuführen. Dies funktioniert über die Erweiterung des HTTP Response-Headers des Servers mit der Eigenschaft Access-Control-Allow- Origin. Diese Eigenschaft beinhaltet entweder eine bestimmte Domain, der somit explizit der Zugriff gewährt wird oder das Attribut *, womit die Erlaubnis für alle Domains erteilt wird [32]. Wenn nun ein Cross-Domain Request per Ajax an einen Server erfolgt und dieser Server im HTTP Response- Header die Eigenschaft Access-Control-Origin aufweist, die als Wert entweder die Domain des Request-Servers oder eine Wildcard mit * beinhaltet, wird diese vom Browser interpretiert und der Request wird zugelassen. Dies ermöglicht, dass der Webserver, an den der Cross-Domain Request abgesetzt wird, den Zugriff nur für bestimmte Domains erlaubt oder generell für alle Requests offen ist. Näheres zum Thema CORS ist in Abschnitt zu finden Sicherheit Die erste Hürde stellt bereits die Anwendung von Cross-Domain Ajax selbst dar. Hier müssen Möglichkeiten und Wege gefunden werden, die SOP zu umgehen, um so Requests an fremde Server absetzen zu können. Ist dies geschafft, tritt bereits das nächste Problem auf: die Sicherheit. Gerade wenn Zugriffe von anderen Domains zugelassen werden, ist ein besonderer Schutz vor Angriffen, die eigentlich aufgrund der Schutzfunktionen im Browser gar nicht möglich wären, notwendig. Google und Facebook lösen dieses Problem 7

15 2. Allgemeines 8 beispielsweise über eine Domain-Registrierung, die Vergabe eines API-Keys und eventuell zusätzliche Passwörter um die Benutzer zu identifizieren. Ein weiteres Problem, welches sich nicht ausschließlich auf Cross-Domain Ajax bezieht, sondern jede Ajax-Anwendung betrifft, stellt der JavaScript- Code selbst dar. Dieser wird in Klartext zum Client übertragen und kann von jedem Benutzer eingesehen werden. Der Quellcode kann einfach interpretiert und auch manipuliert werden. Näheres zum Thema Sicherheit und Codeverschlüsselung ist in Kapitel 5 zu finden. 2.3 Cloud Computing Alles in der Wolke Der Begriff Cloud Computing stammt von dem Wolkensymbol, welches in Strukturplänen für das Internet steht (vgl. [1]) und ist mittlerweile aus der IT-Welt nicht mehr wegzudenken. Beinahe alles liegt und findet sich in der Cloud. Was genau Cloud Computing jedoch bedeutet, wird in [1] gut definiert: Beim Cloud Computing werden Soft- und Hardware ausgelagert. Es werden, weitergehend als bei Software as a Service, Soft- und Hardware über das Internet bereitgestellt, sodass der Anwender sowohl Hardwarekosten, sogar ganze Rechenzentren, sowie Softwarekosten einsparen kann. Anwendungen und Daten befinden sich in der Wolke. Laut [8] liegt der große Vorteil des Cloud Computings in der Kostenersparnis, da hier nur die Ressourcen und Services bezahlt werden, die auch tatsächlich genutzt werden Private vs. Public Cloud Cloud Computing kann in unterschiedliche Arten eingeteilt werden. Unterschieden wird zwischen der Private Cloud und der Public Cloud, wobei die Private Cloud ein abgegrenztes Rechenzentrum eines Unternehmens darstellt, auf das nur firmeninterne Rechner Zugriff erhalten. Hierbei werden auch sämtliche Applikationen, die über die Private Cloud genutzt werden sollen, auf den Servern im Rechenzentrum installiert. Die Public Cloud hingegen ist eine öffentliche Cloud, auf die von allen Personen im gesamten Netzwerk zugegriffen werden kann [8]. Die Public Cloud ist im Zusammenhang mit dieser Arbeit die Interessantere von den beiden, da es sich hier um Applikationen handelt, die von jeder beliebigen Person genutzt werden können.

16 2. Allgemeines Web Services Bei einem Web Service 8 werden serverseitige Daten über eine Schnittstelle (API) zur Verfügung gestellt und können so per HTTP-Request von jedem Client (Browser) und auch Server abgerufen werden. Diese Dienste stellen einen sehr wichtigen Punkt im Bereich Cloud Computing dar. Was genau ein Web Service ist und was ihn ausmacht hat Mario Jeckle in [12] mit gesammelten Definitionen in Erfahrung gebracht. Ein Web Service kann sehr vielfältig sein und reicht von einer einfachen Suchabfrage über die Google API bis hin zu kompletten Applikationen, die als Service im Web angeboten, und als so genannte Software as a Service- Anwendungen bezeichnet werden Software as a Service (SaaS) Als Software as a Service bereits in den 90er Jahren als Application Software Providing (ASP) bekannt werden Softwaremodelle bezeichnet, die es Benutzern ermöglichen, Software als Dienstleistung, basierend auf Internettechniken, bereitzustellen. Das bedeutet, dass diese Applikationen meist über einen Webbrowser aufgerufen werden können, was den Vorteil hat, dass Software nicht mehr auf lokalen Rechnern installiert werden muss und sich der Benutzer so nicht mehr um Installation, Berechtigungen, Kompatibilität, Rechnerleistung etc. kümmern muss [28, Kap. 1] Problem Datenhaltung und Sicherheit Die Entwicklung von ASP bzw. SaaS wird bereits seit seiner Entstehung im Jahr 1999 beobachtet und auch regelmäßig in aktuelle Marktforschungen miteinbezogen. Obwohl es eine große Anzahl an Anwendungsbereichen gibt, ging die Entwicklung von ASP nicht so rasch vonstatten wie dies prognostiziert wurde (vgl. [18]). Die Gründe, die Firmen gegen ASP entscheiden ließen, waren im Jahr 2000 bereits Sicherheitsaspekte, Angst vor Kontrollverlust und die Integration der ausgelagerten Applikationen mit den intern betriebenen Applikationen [28, S. 10]. Weniger problematisch ist die Anwendung von SaaS-Modellen in Private Clouds, da hier wenig Probleme im Bezug auf Zugriffsberechtigung, Sicherheit, Kontrolle und Datentransfer entstehen. Komplizierter sind solche Systeme in der Public Cloud, da mit dem Einsatz einer solchen Applikation meist auch die gesamte Datenhaltung an einen fremden Server übergeben wird. Das bedeutet, dass sämtliche Daten dem Server der SaaS-Applikation zur Verfügung gestellt werden. Ein bekanntes Beispiel ist Google Docs, welches seinen Benutzern die Möglichkeit bietet, unabhängig von Ort und Zeit, Dokumente zu speichern und zu bearbeiten. Dies ist interessant für private, 8

17 2. Allgemeines 10 nicht sensible Daten, es entstehen allerdings Bedenken bei der Nutzung in Verbindung mit geheimen Firmendaten. Ein Lösungsansatz für dieses Datenhaltungsproblem ist das Hosten der Daten auf einem eigenen Server und die gezielte Zugriffserlaubnis für die gewünschten Anwendungen, die auf einem fremden Server laufen. Ob und wie das möglich ist und was bei solch einer Applikation beachtet werden muss, wird im Konzept in Kapitel 5 beschrieben.

18 Kapitel 3 State of the art Dieses Kapitel stellt unterschiedliche online Anwendungen vor, die entweder verstärkt auf dem Einsatz von Cross-Domain Ajax basieren, ähnlich dem WebApplicationService-Konzept, welches in Kapitel 5 erläutert ist, funktionieren oder die Konzepterstellung und Implementierung wesentlich beeinflusst haben. 3.1 Cloud Applikationen mit Datenhaltung Bei dieser Kategorie handelt es sich um Webapplikationen, die auf einem fremden Server installiert sind, deren Funktionalität zur Gänze online über einen Browser ausführbar ist, und bei denen die gesamte Datenhaltung auf dem Applikations-Server erfolgt Google Maps Google Maps 1 kann über eine API auf jeder beliebigen Website eingebunden werden und ist im weiteren Sinne ähnlich zu dem WebApplicationService- Konzept. Der einzige Unterschied besteht darin, dass keine Daten vom Server des Benutzers geladen werden müssen und somit keine Schnittstelle notwendig ist. Die Applikation lässt sich lediglich mit ein paar Zeilen JavaScript integrieren und die benötigten Daten werden per Cross-Domain Ajax-Requests vom Google-Server geladen. Google Maps ist eine der Anwendungen, die diese Arbeit und das zugehörige Projekt sehr stark beeinflusst haben. Besonders beeindruckend ist die einfache Einbindung in bestehende Seiten per JavaScript. Deshalb wurde versucht, die Einbindung der Projekte, die auf dem WebApplicationService- Konzept basieren, wie Kapitel 6 zu entnehmen ist, ähnlich zu gestalten

19 3. State of the art 12 Funktionsweise Untersuchungen haben ergeben, dass die in eigene Webseiten integrierte Google Maps Applikation mit der Dynamic Script-Tag Methode, deren Funktionsweise in Abschnitt beschrieben ist, arbeitet. Bei Anfragen Mausinteraktionen in der Map werden dynamische script-tags erstellt, die als src-attribut einen Pfad zu einer JavaScript-Datei am Google-Server beinhalten. Diesem Script werden die benötigten Parameter über die HTTP- Methode GET übergeben, damit am Google-Server der dementsprechende Response erstellt und zum Client zurückgeschickt werden kann. Dieser besteht aus einer Reihe von JavaScript-Aufrufen, die in das Script-Tag eingefügt und sofort nach dem Laden ausgeführt werden, woraufhin die Karte aktualisiert wird Google Docs Google Docs 2 ermöglicht es seinen Benutzern, bestimmte Arten von Dokumenten online zu erstellen, sowie alle Arten von Dateien per Upload hinzuzufügen. Microsoft Office-Dokumente (und auch Open Office-Dokumente) wie Word-, Excel- und Powerpoint-Dateien können hier online über den Browser bearbeitet, abgespeichert, mit anderen Benutzern geteilt und exportiert werden. Die Dateien werden am Google-Server gespeichert, auf dem einerseits gratis Webspace (1024 MB) zur Verfügung gestellt wird, andererseits Webspace hinzu gemietet werden kann. Wichtig hierbei ist, dass nur die hochgeladenen Dateien nicht die im Google Docs-Format Speicherplatz verbrauchen. Google stellt für die Applikation eine API 3 für unterschiedliche Programmiersprachen (Java, Python, PHP,...) zur Verfügung. Diese ermöglicht es, von extern auf Dokumente und Funktionalitäten von Google Docs zuzugreifen. Diese SaaS ist zwar ähnlich zum WebApplicationService-Konzept, unterscheidet sich aber dadurch, dass die Datenhaltung hierbei nicht auf einem eigenen Servern erfolgen kann Oracle CRM On Demand Oracle CRM On Demand 4 ist ein CRM-System 5, welches komplett als SaaS- Lösung implementiert ist und so von den Benutzern via Browser erreichbar ist. Es werden zahlreiche Möglichkeiten geboten, Kundendaten zu beund verarbeiten, weiters wurde besonders auf die Integration von bekannten APIs wie Youtube, Google, Yahoo etc. Wert gelegt. Das CRM bietet eine vorgefertigte Integration in Oracle Unternehmensanwendungen und andere

20 3. State of the art 13 Anwendungen, womit eine vollständige Integration des CRM in die gesamte Unternehmensstruktur einfach zu realisieren ist. Das CRM-System, sowie sämtliche Daten, werden hierbei im Oracle Rechenzentrum in Austin gehostet. Es besteht die Möglichkeit, lokale Daten mit den bei Oracle verwalteten Daten zu synchronisieren, z.b. über ein Outlook-Plugin mit dem s per Mausklick in das entfernte System übernommen werden können. Da Oracle sehr viel Wert auf Sicherheit legt, werden die Daten ausschließlich per SSL übertragen, des Weiteren wird von Seiten Oracle die Aussage gewagt, dass ihr preisgekröntes Rechenzentrum hackersicher sei. CRM-Systeme eignen sich für kleinere Unternehmen generell besonders gut um als SaaS-Lösungen realisiert werden, da hier bei gemieteten IT- Services einerseits Kosten eingespart werden können und andererseits der Datenzugriff von überall aus möglich ist, was vor allem für Mitarbeiter im Außendienst einen großen Vorteil bietet (vgl. [25]). 3.2 Cloud Applikationen ohne Datenhaltung Bei dieser Art von Anwendungen handelt es sich um Webapplikationen, deren gesamte Funktionalität online ausführbar ist, die aber zusätzlich erlauben, die gesamte Datenhaltung auszulagern bzw. von fremden Quellen zu beziehen Facebook-Applikationen Facebook 6 boomt und damit auch die Angebote, die von Facebook zur Verfügung gestellt werden. Egal ob Benutzer oder Entwickler, für beide Seiten eröffnen sich immer mehr Möglichkeiten. Derzeit existieren unterschiedliche APIs für Facebook, je nachdem ob selbst Applikationen entwickelt werden, die direkt in Facebook eingebunden werden oder ob Facebook-Daten in einer eigenen Anwendung verwendet werden möchten. Der interessantere und auch relevantere Punkt für diese Arbeit liegt allerdings in der Erstellung von Facebook-Applikationen, da bei dieser Vorgehensweise grundsätzlich genau das Gleiche passiert wie bei dem WebApplicationService-Konzept. Diese Applikationen werden von fremden Servern direkt in die Facebook Plattform integriert, wobei die Möglichkeit geboten wird, mit dem Facebook-Server zu kommunizieren und Daten wie z.b. Namen und Profilfoto der Benutzer zu verwenden. Der Unterschied zu Applikationen, die auf dem WebApplicationService- Konzept basieren, liegt darin, dass bei der Entwicklung von Facebook-Applikationen darauf geachtet werden muss, dass diese so umgesetzt werden, damit diese auf dem Facebook-Server eingebunden werden können, während- 6