TECHNISCHE UNIVERSITÄT DRESDEN
FAKULTÄT INFORMATIK INSTITUTFÜR SYSTEMARCHITEKTUR PROFESSUR RECHNERNETZE PROF.DR. RER. NAT. HABIL.DR. H. C.ALEXANDER SCHILL
Diplomarbeit
zur Erlangung des akademischen Grades Diplom-Medieninformatikerin
Analyse, Design und prototypische Implementierung eines Backends zur dynamischen Konfiguration im Adobe Flash Player
Gergana Stoyanova (Geboren am 12. August 1981 in Varna, Bulgarien) (Mat.-Nr.: 2897709)
Betreuer TU Dresden: Dipl. Medieninf. Matthias Wauer Betreuer RTT AG: Peter Schultz
Dresden, 26. Februar 2009
Aufgabenstellung
Die Online-Konfiguration von Produkten im Internet stellt neue Anforderungen an den dynamischen Transport der Daten vom Server. Als Szenario dient ein Konfigurator für Autos. Ein Flash-Client bietet verschiedene Optionen zur Konfiguration des Exterieurs und Interieurs eines Wagens sowie an den Kontext angepasste Videoelemente als Hilfe- stellung für den Nutzer und für weitere Informationen. Ziel dieser Arbeit ist vorerst die existierenden Lösungen zum Laden der Daten im Kon- figurationsprozess zu untersuchen und zu vergleichen. Des Weiteren ist eine optimier- te Architektur des Backends zu entwickeln, eine interaktive, konfigurierbare Demo für das Frontend zu implementieren sowie eine geeignete Server-Client Kommunikation zu schaffen. Zum Schluss sollen die vorliegenden Ergebnisse evaluiert werden. Schwerpunkte:
• Untersuchung der Technologien für serverseitige Kommunikation bezüglich der festgestellten Anforderungen und “State of the art“.
1. HTTP-Transfer – REST und RESTful Web Services 2. RemoteObject – AMF, OpenAMF, AMFPHP, SabreAMF, WebORB 3. Web Service – XML-RPC, Web Services • Analyse der Anforderungen der verschiedene Konfigurationstypen (Web3D, Video, Bilder). • Design einer Backend-Lösung mit der bestgeeigneten Technologie. • Prototypische Implementierung eines Backend-Konzeptes und eines Frontend-Client für den Adobe R Flash R Player sowie deren Kommunikation. • Bewertung der Ergebnisse.
Selbstständigkeitserklärung
Hiermit erkläre ich, dass ich die von mir am heutigen Tag dem Prüfungsausschuss der Fakultät Informatik eingereichte Diplomarbeit zum Thema:
Analyse, Design und prototypische Implementierung eines Backends zur dynamischen Konfiguration im Adobe Flash Player vollkommen selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Dresden, den 26. Februar 2009
Gergana Stoyanova
Kurzfassung Die Online-Konfiguration von Produkten im Internet stellt neue Anforderungen an die dynamische Beschaffung der Daten des Servers. Ziel der vorliegenden Arbeit ist die Mög- lichkeiten zur Übertragung von Datenobjekten, Bildmaterial und Videoclips zwischen Client und Server zu untersuchen und zu evaluieren. Aufbauend auf den Ergebnissen der Analyse wird ein Prototyp für das Backend, Frontend sowie deren Kommunikation konzipiert, implementiert und bewertet. Die ganze Anwendung wird nach den Kriterien einer Rich Internet Application entwickelt. Abschließend werden Empfehlungen zu der Erweiterung der vorgestellten Lösung gegeben.
1
Inhaltsverzeichnis
1 Einführung 3
2 Grundlagen 5 2.1 Rich Internet Application (RIA) ...... 5 2.2 Adobe Flash Player ...... 7 2.3 Adobe Flex ...... 9 2.4 Representational State Transfer (REST) ...... 10 2.5 Action Message Format (AMF) ...... 13 2.6 Web Services ...... 14 2.7 Zusammenfassung ...... 16
3 Datenübertragung 17 3.1 HTTP Service ...... 18 3.1.1 RESTful Services ...... 19 3.2 RemoteObject – AMF ...... 20 3.3 Web Service ...... 25 3.4 Zusammenfassung ...... 26
4 Analyse 27 4.1 Konfigurator ...... 27 4.2 Szenario ...... 28 4.3 Anforderungen an die eigene Lösung ...... 28 4.3.1 Anforderungen ans Frontend ...... 29 4.3.2 Anforderungen an den Server ...... 29 4.3.3 Anforderungen an die Datenbank ...... 30 4.3.4 Anforderungen an die Kommunikation Frontend-Backend . . . . 30 4.3.5 Technische Anforderungen ...... 30 4.4 Aufbau der Anwendung ...... 31 4.5 Bewertung der Übertragungstechniken ...... 31 4.5.1 Bildmaterial ...... 31 4.5.2 Datenobjekte ...... 33 4.5.3 Video ...... 35 4.6 Zusammenfassung ...... 37
5 Konzeption 39 5.1 Client-Server Kommunikation ...... 39 5.1.1 OpenAMF-Gateway ...... 40 5.1.2 Granite Data Services ...... 40 5.1.3 RED5 ...... 41 5.1.4 WebORB für Java ...... 41 5.1.5 LiveCycle DS ...... 45 2
5.1.6 BlazeDS ...... 45 5.1.7 Bewertung der AMF-Gateways ...... 46 5.2 Architektur ...... 48 5.3 Datenbank ...... 50 5.4 Server ...... 53 5.5 Frontend ...... 54 5.6 Zusammenfassung ...... 57
6 Implementierung 59 6.1 Datenbank ...... 59 6.2 Server ...... 60 6.3 Frontend ...... 65 6.4 Zusammenfassung ...... 68
7 Bewertung 69 7.1 Leistungstest Szenario ...... 70 7.2 Bewertung des Frontends ...... 72 7.3 Bewertung des Servers ...... 72 7.4 Bewertung der Datenbank ...... 73 7.5 Bewertung der Kommunikation Frontend-Backend ...... 74 7.6 Bewertung der technischen Anforderungen ...... 74 7.7 Erweiterungsmöglichkeiten ...... 75
8 Zusammenfassung und Ausblick 77
Literaturverzeichnis 79
Abbildungsverzeichnis 87
Tabellenverzeichnis 89 3
1 Einführung
Die Konfiguration und Individualisierung von Produkten im Internet ist ein entscheiden- der Wettbewerbsvorteil für ein Unternehmen. Die Konfigurationsoptionen ergeben sich aus den Selektions-, Kombinations- und Parameterisierungsmöglichkeiten eines Artikels eingeschränkt durch die Konfigurationsregeln [Sch08]. Der Kunde möchte über das Stan- dardangebot hinaus maßgeschneiderte Produkte bestellen. So fordert der Markt eine intui- tive, einfache und reaktionsfreudige 1 Anwendung für das Internet wie im traditionellen Desktop-Bereich, die zugleich aber reich an Inhalt wie das Web ist. Im Jahr 2002 prägte Macromedia2 den Begriff “Rich Internet Application“, der eine neue Generation von Anwendungen definiert. Das Konzept von so einem Programm ist dem Thin-Client-Konzept entgegengesetzt, bei welchem die Webseiten auf HTML-Basis dy- namisch auf dem Server erstellt und an den Browser ausgeliefert werden. Das neue Modell behebt vor allem den Nachteil, dass die Webseite nach jeder Interaktion immer neu ge- laden werden muss und integriert in einer Umgebung verschiedene Inhaltstypen (Audio, Video) und grafische Interface-Elemente. Die Logik des Programms kann sich wie bei den Thin-Clients auf dem Server befinden, orientiert sich aber mehr an wieder-verwendbaren Softwarekomponenten, die als Services über das Netz mehrere Anwendungen und End- geräte bedienen können. Weitere Anforderungen an die Rich Client-Technologie sind ein erweiterbares Objektmodell für Interaktion, sowie Unterstützung von grafischen Kompo- nenten und ihre Wiederverwendung für eine schnelle Applikationsentwicklung. Als Anwendungsszenario für diese Arbeit dient ein Produktkonfigurator für Autos. Ein Flash-Client bietet verschiedene Optionen zur Konfiguration des Exterieurs und Interieurs eines Wagens sowie an den Kontext angepasste Videoelemente als Hilfestellung für den Nutzer und für weitere Informationen. Ziel dieser Arbeit ist, den Produktkonfigurator für Autos als eine Rich Internet Applica- tion zu entwickeln. Besonderer Schwerpunkt liegt bei der Backend-Architektur mit ei- ner geeigneten Client-Server-Kommunikation. Auch das Frontend für den Adobe Flash Player ist zu erstellen und mit dem Backend zu verbinden. Diese Arbeit ist wie folgt aufgebaut: Was genau eine Rich Internet Application ist und welche Technologien diese einsetzt, wird im 2. Kapitel beschrieben. Es wird auch auf den Adobe Flash Player, der für das An- zeigen der Clientseite dient, und die Entwicklungsumgebung Flex Builder eingegangen. Erläuterungen zu der REST-Technologie, dem binären Format AMF und Web Services sind ebenda zu finden. In Kapitel 3 werden die existierenden Technologien zur Datenübertragung im Flex Buil- der vorgestellt und verglichen. Dazu gehören HTTPServices sowie RESTful-Services, die AMF-basierten Methodenfernaufrufe mittels RemoteObject und Web Services.
1Englisch: responsivness 2heute Adobe Systems Inc. 4 1. EINFÜHRUNG
Wie der Konfigurator funktionieren soll und ein Test-Szenario wird in Kapitel 4 beschrie- ben. Es werden auch Leistungstests mit einem existierenden Konfigurator für das gleiche Produkt durchgeführt und anhand der Ergebnisse Anforderungen an die eigene Lösung aufgestellt. Der Aufbau der Anwendung sowie die Bewertung der Übertragungstechniken werden auch in diesem Kapitel vorgestellt. Basierend auf den festgelegten Kriterien ist eine optimale Architektur des Backends zu entwickeln. Wie in Kapitel 4 festgestellt eignet sich die AMF-Technologie am besten für die Übertragung von Datenobjekten. So werden in Kapitel 5 zuerst die existierenden AMF-Gateways analysiert und bewertet. Nach der Auswahl eines Gateways wird die Ar- chitektur der Anwendung vorgestellt, die auch den Transfer von Bild- und Videodaten einschließt. Die Datenbank, die serverseitige Logik sowie das Frontend werden konzi- piert. Kapitel 6 betrachtet die Implementierung der vorgestellten Anwendungs-Komponenten. Es wird auf die verwendeten Entwicklungswerkzeuge sowie auf einige Auszüge des Quell- codes eingegangen. In Kapitel 7 werden die erzielten Ergebnisse evaluiert. Abschließend folgt in Kapitel 8 eine Zusammenfassung und Betrachtung zu weiterführenden Aspekten. 5
2 Grundlagen
In diesem Kapitel werden Technologien und Begriffe erläutert, die weiter in der Arbeit benutzt werden. Am Anfang wird ein kurzer Überblick über eine neue Art Anwendungen gegeben, die Rich Internet Applications. Es folgt der Adobe Flash Player, der eine Mög- lichkeit zum Anzeigen dieser Anwendungen ist, sowie die Produktfamilie Adobe Flex für die Entwicklung von RIAs. Die Technologien zur Beschaffung der Daten vom Ser- ver für eine Rich Internet Application können auf dem Architekturstil “Representational State Transfer“ (Kapitel 2.4), dem Adobe-eigenen Format zur Serialisierung von Objek- ten “Action Message Format“ (Kapitel 2.5) oder den serviceorientierten Komponenten Web Services (Kapitel 2.6) basieren.
2.1 Rich Internet Application (RIA)
Rich Internet Application (RIA) definiert eine neue Generation Software-Anwendungen, die die Vorteile von Web- und Desktop-Programmen vereinigt – sie laufen im normalen Web Browser, benötigen aber keine Aktualisierung der Seite und reagieren sofort auf Be- nutzereingaben. Der Begriff “RIA“ ist sehr vage und es gibt keine genaue Definition. In diesem Kapitel werden verschiedene Meinungen und Systematisierungsversuche vorge- stellt. Ein Vergleich zwischen einer Desktop-, einer normalen HTML [RHJ99] - und HTTP [FGM+99] - basierten Web- und einer Rich-Internet-Anwendung ist in der Tabelle 2.1 zu finden. Dabei werden die Vorteile einer RIA deutlich, die auf dem Modell eines verteilten Systems basierend eine verbesserte Benutzeroberfläche bietet und den Kommunikations- overhead reduziert [BCFC06]. Merkmale Desktop Web RIA Client (Browser) nein ja ja Installation auf dem Client komplex einfach einfach Benutzerinteraktion reichhaltig begrenzt reichhaltig Serverseitige Business-Logik ja ja ja Clientseitige Business-Logik ja begrenzt ja Ganzseitiges Refresh erforderlich nein ja nein Häufige Server round-trips nein ja nein Client-Server Kommunikation nein ja ja Funktioniert getrennt vom Internet ja nein ja
Tabelle 2.1: Vergleich einer Desktop- , Web- und Rich Internet Application [BCFC06].
Um einer Definition von RIA näher zu kommen, hat die Seite “InsideRIA“ [O’R08] des O’Reilly Verlags Anfang 2008 die Frage “Was ist RIA?“ an Entwickler gestellt, die in diesem Bereich tätig sind. 6 2. GRUNDLAGEN
Einige Experten haben ihren Fokus bei der Definition auf das Wort “reichhaltig“ gesetzt. Ihrer Ansicht nach muss zunächst geklärt werden, in welchem Kontext “reichhaltig“ steht – reichhaltig an Benutzererlebnis oder an Technologien wie Ajax [Aja09], Adobe Flash, Adobe Flex, OpenLaszlo [LS08], XAML [Cor09g], Microsoft Silverlight [Cor09e] und ihrer Kombination [Cru08]. Andere setzen ihren Augenmerk auf das Wort “Internet“ und machen den Unterschied zwischen Anwendungen, die eine entfernte API aufrufen und andere, die es nicht tun. Demzufolge ist RIA eine Applikation, deren Daten per Inter- netverbindung zugestellt werden. Sie hat ein modernes Interaktionsmodell, sieht wie ei- ne Desktop-Anwendung aus und funktioniert auch so, wird aber im Browser angezeigt [Mac08]. Der Arbeitsablauf mit einem Programm verlagert sich zunehmend demzufolge vom Desktop aufs Netz. RIA ist gleich in Echtzeit kollaborativ, asynchron und unterstützt Streaming-Video und -Audio. Die Daten werden immer in einem Kontext gespeichert und auch in diesem gesucht. RIA gibt auch keine Funktionalität oder Usability vor. Neu sind aber die User Interfaces für neue Interaktionsarten mit Daten und Prozessen – es werden Elemente wie ComboBox, Links und Forms für die Interaktion mit Seiten benutzt, die schon von den Internet-Anwendungen bekannt sind [Tri08]. Alle obengenannten Eigenschaften haben zwar viele Rich Internet Applications, sie defi- nieren aber diese Anwendung nicht, meint [Tri08]. Wichtig ist seiner Ansicht nach, wie und wofür die Anwendung genutzt wird. Folgende Technologien sind nicht erforderlich, aber üblich bei der Erstellung von RIAs:
• Zustandsbehaftete Clients und asynchroner Datentransfer – Der Zustand der Anwendung wird auf der Clientseite gehalten, was eine vereinfachte serviceori- entierte und asynchrone Backend-Logik erlaubt. So können die Backend-Services spezifische Operationen ausführen ganz gleich von wem sie aufgerufen werden. Durch den asynchronen Datentransfer bleibt das Interface während der Backend- Operationen erreichbar und der Nutzer kann weiter mit dem Programm arbeiten. So wird das Gefühl einer Desktop-Anwendung vermittelt, da der Nutzer nicht be- merkt, dass ein entfernter Service aufgerufen wird. • Drag and Drop UI Paradigma – Der Nutzer wird durch Drag and Drop z.B. von Elementen in einen Warenkorb oder Daten auf einer Geokarte unterstützt. Es ist die intuitivste Form der Interaktion mit einem gewöhnlichen PC [Dra08]. • Tools zum Zeichnen und Analysieren – Viele RIAs bieten die Möglichkeit Grafi- ken zu bearbeiten oder große Datenmengen zu analysieren und Diagramme davon zu erstellen. Unter Umständen wird auch 3D-Modellieren unterstützt. • Frontend-Technologien – Es gibt mehrere Technologien mit denen RIAs erstellt werden können. Die Auswahl eines Frameworks hängt vom Entwickler und vom Nutzungsfeld der Anwendung ab. Einige Frameworks dafür sind: Adobe Flex, Ajax Frameworks wie Dojo Toolkit [Fou09d] oder JQuery [RT09], Microsoft Silverlight, Java FX [SM09g] und andere. • Backend-Technologen – Die serverseitige Technologie ist nicht an einen bestimm- ten Applikationsserver oder eine Sprache gebunden. Es stehen unter anderem Adobe ColdFusion [Inc09f], Sun Java/JEE [SM09d], Microsoft .NET [Cor09d] oder PHP [Gro09b] zur Verfügung. Die Entscheidung für eine bestimmte Backend- Technologie hängt vom Bedarf der Anwendung, den Ressourcen und der Infrastruk- tur ab. Wichtige Fragen bei dieser Entscheidung sind: 2.2. ADOBE FLASH PLAYER 7
– Werden die Daten dynamisch geliefert? – Werden Streaming-Medien genutzt? – Wird Real-Time Messaging eingesetzt? – Wird ein bestehendes System nachgerüstet oder ein neues von Grund auf ein- gerichtet? – Wird die Verwendung von Open-Source-Software unterstützt? – Wird ein bestimmtes kommerzielles Produkt bevorzugt, welches auch einen technischen Support anbietet? – Wie hoch ist das Budget für die Technologie? RIA ist an keine Technologie gebunden und daher müssen viele Fragen in Bezug auf die Auswahl bestimmter Technologie beantwortet werden. Obwohl sich die RIAs in vielen Aspekten voneinander unterscheiden, können sie in vier Kategorien unterteilt werden [BCFC06]:
1. Skript-basierte – Die Client-Seite ist in Skriptsprachen wie JavaScript [Cen09] implementiert und das Interface ist eine Mischung aus HTML und CSS [LB08]. 2. Plug-in-basierte – Bei diesen Anwendungen wird das Rendern und die Bearbei- tung von Ereignissen durch ein Web-Browser-Plug-in übernommen - Adobe Flash Player, OpenLaszlo, Xamlon [Wol06], Microsoft Silverlight. 3. Browser-basierte – Die Interaktion wird nativ von einigen Browsern unterstützt, die deklarative Interface-Beschreibungssprachen interpretieren – XUL [XUL06]. 4. Web-basierte Desktop-Technologien – Hierbei werden die Anwendungen vom Web heruntergeladen, aber außerhalb des Browsers ausgeführt – Adobe AIR [Inc09b], Java Web Start [SM09f], Windows Presentation Foundation [Cor09f]. RIAs haben den Vorteil, im Vergleich zu herkömmlichen Anwendungen, dass sie nicht installiert werden müssen. Außerdem sind Rich Internet Applications für das Internet optimiert – stellen weniger Anfragen an den Server zur Laufzeit und aktualisieren nicht die Seite nach jeder Interaktion mit dem Nutzer. RIAs sind eine neue Generation von Anwendungen, die das Internet relevanter und nützlicher für Business und Konsumenten macht. Eine Möglichkeit Rich Internet Applications anzuzeigen wird im nächsten Kapitel vorgestellt.
2.2 Adobe Flash Player
Heutzutage ist es üblich, dass Webseiten ihre Inhalte in Flash, Silverlight oder Java App- lets [SM09a] präsentieren, um eine reichhaltige und interaktive Anwendung anzubieten. In diesem Kapitel wird ein kurzer Überblick über die Flash-Technologie gegeben, die weiter in dieser Arbeit eingesetzt wird. Eine Flash-Anwendung, auch Flash-Film genannt, ist im SWF-Format verfügbar und beinhaltet Vektor- und Rastergraphik, Audio und Video sowie Bytecode, welcher aus der Skriptsprache ActionScript kompiliert wird [Inc08e]. Im Web sind Flash-Programme ak- 8 2. GRUNDLAGEN tive Objekte, die in einer Seite ähnlich zu Java Applets oder Silverlight eingebettet sind. Flash ist der am meisten verbreitete Player für multimediale Inhalte [Inc08d]. Flash-Programme werden mit einer IDE erstellt, die Web- und Multimedia- Anwendungsentwicklung besser als herkömmliche Softwareentwicklungstools unterstüt- zen – Adobe Flash CS4 Professional (Authorentool) oder Adobe Flex (siehe Kapitel 2.3). Die IDEs kompilieren das Flash Programm in einer SWF-Datei, die Medienob- jekte, UI-Elemente und Bytecode des Programms enthält. Die SWF-Datei wird von der ActionScript Virtual Machine geparst (aktuell in Version 2 - AVM2) und ausgeführt. Der Adobe Flash Player (aktuell in der Version 10.0.12.36) kann als Browser-Plug-in oder Standalone benutzt werden, Webanwendungen werden mit der Plug-in-Variante wieder- gegeben. Der Adobe Flash Player definiert zusätzlich zu der Virtual-Machine-Architektur auch built-in Klassen (flash.*), die vom Bytecode, also vom ActionScript, aufgerufen wer- den können (beispielsweise MovieClip, Camera und LoadVars). Diese Klassen vereinfachen die Manipulation von Grafiken, UI-Elemente und Events. Andere Klassen erlauben den Zugriff auf System- und HTTP-Operationen. Weitere JavaScript-Operationen werden auch von den built-in Klassen unterstützt. Eine Übersicht über die Architektur ei- ner Flash-Applikation ist in Abbildung 2.1 zu finden.
Abbildung 2.1: Architektur einer Flash-Anwendung [BCFC06].
Der Vorteil der Benutzung des Flash-Formats für eine Anwendung ist, dass mit der glei- chen Version des Players bei jedem Client die gleiche Darstellung angezeigt wird unab- hängig vom Betriebssystem. Außerdem wird eine SWF-Datei beim Abrufen vom Server nicht neu kompiliert, es werden nur neue Komponente der Anwendung heruntergeladen. Es ist kein Refresh der Seite erforderlich wenn der Nutzer mit der Anwendung intera- giert, die Engine übernimmt die Verantwortung für das Rendern des Interfaces und die Serverkommunikation. Obwohl mit Adobe Flash Professional und Adobe Flex SWF-Files kompiliert und vom Adobe Flash Player abgespielt werden, unterscheiden sich die Datenmanagement-Archi- tekturen der beiden IDEs. Flash CS4 wurde primär für Designer als Authorentool für Animationen entwickelt. Benutzeroberflächen und größere Anwendungen sind mühsam mit diesem Werkzeug zu erstellen. Deswegen brachte Adobe 2004 die Produktfamilie 2.3. ADOBE FLEX 9
Adobe Flex auf den Markt, die im nächsten Kapitel vorgestellt wird.
2.3 Adobe Flex
Adobe Flex ist eine Produktfamilie von Adobe Systems zum Erstellen von RIAs (siehe Kapitel 2.1). Das Framework besteht aus dem Software Development Kit (SDK, aktu- ell in der Version 3.2), dem Flex Builder (in der Version 3.0.2), dem LiveCycle Data Services (LiveCycle DS) und den Flex Charting Komponenten. Seit Februar 2008 steht die Flex SDK unter einer Open-Source Mozilla Public License (MPL) [Moz06]. Flex- Anwendungen werden mit dem Flex Builder erstellt, einer Entwicklungsumgebung, die auf der Eclipse-Plattform [Fou09e] aufbaut. Die Anwendungen können im Browser mit Flash Player (siehe Kapitel 2.2) oder auf dem Desktop mit Adobe AIR ausgeführt werden. Eine Flex-Anwendung besteht aus Code in zwei verschiedenen Sprachen: ActionScript und MXML. ActionScript, aktuell in der Version 3.0, hat sich von einer prototyp-basierten Skriptsprache zu einer objekt-orientierten, strikt typisierten ECMA-Skriptsprache ent- wickelt. MXML ist eine deklarative Markup-Sprache zur Erstellung von Komponenten und basiert auf XML. Nach der Kompilierung entsteht eine SWF-Datei. MXML kann ActionScript-Code enthalten, während in ActionScript-Dateien kein MXML auftreten darf. Meistens wird MXML für die Beschreibung der Anwendung und ihrer Komponen- ten benutzt, während ActionScript für die Behandlung von Events und die Logik verwen- det wird. Die beiden Sprachen beschreiben die gleichen Objekte mit einer anderen Syn- tax, wobei nur in ActionScript Schleifen, Funktionen und bedingte Anweisungen mög- lich sind. Abbildung 2.2 zeigt den Aufbau des Flex Builders mit den beiden unterstützten Sprachen MXML und ActionScript.
Abbildung 2.2: Aufbau des Flex Builders [Bri08].
Das Flex SDK bietet User-Interface-Komponenten wie Buttons, Listen, Text Controls, Data Grid, LayoutContainers und andere an. Außerdem werden unter anderem Drag&Drop, Animationseffekte und Validierung von Formularen unterstützt. 10 2. GRUNDLAGEN
Die Flex Produktfamilie wird auf der Serverseite mit LiveCycle Data Services (früher Flex Data Servies) ergänzt. Über diesen Dienst kann eine Flex-Anwendung andere Server- Anwendungen (z.B. Java-Anwendungen) ansprechen (siehe Kapitel 5.1.5). Flex und Flash haben unterschiedliche vorgefertigte Klassen für die Datenkomponenten, obwohl sich einige Funktionalitäten von diesen überschneiden – Komponenten von Flash sind auch in Flex verfügbar, bauen aber auf einer anderen Architektur auf. Das Binden von Daten erfolgt in beiden Programmen auf grundlegend verschiedene Art und Weise [Ado08]. Deshalb muss die Entscheidung getroffen werden mit welchem Programm eine Anwendung erstellt wird. Für diese Arbeit wurde Adobe Flex ausgewählt, da sich das Framework für das Erstellen von RIAs (siehe Kapitel 2.1) besser eignet. Außerdem wird das Anbinden am Backend mit verschiedener Technologien ermöglicht, auf die in den nächsten Kapiteln eingegangen wird.
2.4 Representational State Transfer (REST)
REpresentational State Transfer (REST) ist ein Architekturstil, der Richtlinien gibt, wie Daten zwischen einem Client und einem Server ausgetauscht werden sollen [Gro07]. REST beschreibt, wie verteilte Daten definiert und adressiert werden können. Diese ver- teilten Informationen werden Ressourcen genannt und können eindeutig mit Bezeichnern wie der Uniform Resource Locator (URL) [BLFM05] für das Web identifiziert werden. Die Ressourcen können auch manipuliert werden – eine Ressource kann verändert oder gelöscht werden.
Abbildung 2.3: Beispiel einer Kundenbestellung im Online-Shop und Navigation über Links und HTTP-GET [Bay02].
Am Beispiel eines Onlineshops in Abbildung 2.3 wird eine REST-konforme Anwendung vorgestellt. Jedes Objekt der Anwendung wie Bestellung, Kunde oder Artikel stellt ei- ne Ressource dar, die extern über eine URL erreicht werden kann. Die Ressource Kun- de, z.B der erste Kunde, kann über www.example.com/customers/1 erreicht werden und www.example.com/products/4598 referenziert ein bestimmtes Produkt. Jede Ressource unterstützt den gleichen Satz von Methoden, mit denen die Ressourcen manipuliert wer- den. Diese sind: GET, POST, PUT, DELETE, HEAD und OPTIONS. Die Bedeutung die- 2.4. REPRESENTATIONAL STATE TRANSFER (REST) 11 ser Methoden ist in der HTTP-Spezifikation [FGM+99] definiert. In einer REST-konformen Anwendung werden folgende Aktionen von den Methoden ausgelöst [RR07]:
• GET – Gibt eine Übersicht über die Ressourcen oder die Details zu einer bestimm- ten Ressource. • POST – Erzeugt eine neue Ressource zu einer existierenden URL. • PUT – Erzeugt eine neue Ressource zu einer neuen URL oder modifiziert eine existierende Ressource zu einer existierenden URL. • DELETE – Löscht eine existierende Ressource. Die HTTP-Spezifikation gibt auch Garantien über das Verhalten der einzelnen Methoden – beispielsweise ist die Anfrage mit GET sicher, da diese Methode nur Daten vom Server liest, diese aber nicht verändert. Egal ob die Anfrage mehrmals gestellt wird, die Antwort bleibt gleich, da nur die Repräsentation der Ressource abgefragt wird. Es kann aber vor- kommen, dass GET Seiteneffekte verursacht, z.B. wenn die Ressourcen auch Zähler sind, die ihren Wert jedes Mal erhöhen, wenn der Client sie aufruft. Die meisten Web Server loggen alle ankommenden Anfragen und das sind die Seiteneffekte – der Zustand des Ser- vers und sogar die Ressource selbst verändert sich als Folge der GET-Anfrage. Aber ein Client sollte niemals GET-Anfragen wegen der Seiteneffekte stellen [RR07]. Außerdem sind PUT und DELETE idempotent, d.h. im Fall einer ausbleibenden Antwort kann die Anfrage noch mal geschickt werden, unabhängig davon, ob die erste Anfrage angekommen ist oder nicht. Wenn eine neue Ressource mit PUT erstellt wird und danach PUT noch mal gesendet wird, ist die Ressource immer noch auf dem Server und zwar mit den gleichen Eigenschaften wie beim ersten Mal des Aufrufs. Das Gleiche funktioniert auch beim Ändern des Zustandes einer Ressource. Wenn aber die Ressource einen nume- rischen Wert als Teil ihres Zustandes enthält, wird mit PUT nur dann eine idempotente Operation ausgelöst, wenn immer der gleiche Wert gesendet wird, beispielsweise 3. Wird aber bei jedem PUT der Wert inkrementiert, z.B. um 1, wird bei einem Startwert 0 der Wert nach zwei Anfragen 2 sein. Bei so einer inkrementellen Operation ist PUT nicht mehr idempotent [RR07]. Von allen HTTP-Methoden ist nur POST weder sicher noch idempotent. Bei zwei Aus- führungen der Anfrage mit POST werden zwei gleichen Ressourcen erstellt [Til08]. Was für Auswirkung die einzelnen Methoden auf die Ressourcen des Online-Shop-Beispiels haben, wird in Abbildung 2.4 dargestellt. Die Antwort des Servers auf die Anfrage “GET/orders/5173“ wird in Listing 2.1 gezeigt. Wie das Ergebnis einer Anfrage dargestellt wird, ist bei REST nicht spezifiziert. Zwischen Client und Server muss ein gemeinsames Verständnis über die Bedeutung der Repräsen- tation vorhanden sein [Bay02]. Es wird meistens XML [TSMG08] benutzt sowie andere kompatible Standards zur Weiterverarbeitung oder Verlinken von Ressourcen. Der Client kann einen Link verfolgen, z.B. den Hersteller, um weitere Produkte von ihm zu sehen. So wird von einem Zustand (Ergebnis der Anfrage) in einen anderen (Produkte des glei- chen Herstellers) gewechselt. Auf diese Weise kann in der Anwendung von Ressource zu Ressource navigiert werden. REST basiert auf Prinzipien des World Wide Webs und das Web stellt auch die größte REST-Anwendung dar, die HTTP für den Transport und URLs für die Adressierung nutzt. 12 2. GRUNDLAGEN
Abbildung 2.4: Manipulation der Ressourcen mit den HTTP-Methoden im Online-Shop- Beispiel [Til08].
Listing 2.1: Repräsentation einer Bestellung im Online-Shop, Antwort auf die Anfrage GET/orders/5173 [Bay02]
1 HTTP/1.1 200 OK Content-Type: text/xml 2 3
Der REST-Stil abstrahiert die architektonischen Elemente in einem verteilten Hypermedia- System und ignoriert die Details der Komponenten-Implementierung sowie die Protokoll- syntax. Der Fokus liegt auf den Rollen der Komponenten, den Bedingungen für deren In- teraktion sowie der Interpretation von wichtigen Daten [Til08]. Im Mittelpunkt von REST stehen folgende Konzepte:
• Data Elements – Ressourcen, Resource Identifiers (URL, URN) und die Repräsen- tation der Ressourcen (HTML-Dokumente, JPEG-Bilder) werden durch ein stan- dardisiertes Interface wie HTTP erreicht. Die Ressourcen und ihre Repräsentation werden getrennt. Es ist möglich mehrere Repräsentationen pro Ressource zu defi- nieren, z.B. HTML und XML für unterschiedliche Anforderungen. Eine Ressource wird referenziert während eine Repräsentation manipuliert wird. Ressourcen und 2.5. ACTION MESSAGE FORMAT (AMF) 13
ihre zugehörigen Repräsentationen werden mit den HTTP-Methoden GET, POST, PUT, DELETE manipuliert [Fie00]. Für Ressourcen und Repräsentationen können zusätzlich Metadaten und Kontrolldaten definiert werden. • Connectors – Verschiedene Connector-Typen kapseln die Aktivitäten für den Zu- griff auf die Ressourcen und die Übertragung ihrer Repräsentationen. Dazu gehö- ren Clients, Servers, Caches, aber auch Tunnels wie SOCKS [LGL+96] und SSL [(IE96] sowie Resolver. Die Connectoren bilden ein abstraktes Interface für die Kommunikation und verdecken Implementierungsdetails und Kommunikationsme- chanismen. • Components – User Agent (Web Browser), Origin Server (Apache httpd [Fou09a], Microsoft IIS [Cor09b]) sowie die dazwischenliegenden Komponenten Proxy und Gateway zählen zu den Komponenten einer REST-Architektur. Ein wichtiges Merkmal von REST ist, dass die Interaktion zwischen Client und Server zustandslos ist, jede Operation steht für sich. Der Client ist dafür verantwortlich, welcher Zustand manipuliert wird. Es ist ein Gegensatz zum Web, wo mit Cookies und URL Re- writing auf das zustandslose HTTP-Protokoll künstlich Sessions aufgesetzt werden , die zustandsbehaftet sind [Bay02]. Diese Eigenschaft einer REST-Anwendung erlaubt nicht nur Skalierbarkeit, sondern verringert auch die Kopplung des Clients an den Server - zwei aufeinander folgende Anfragen müssen nicht von der gleichen Server-Instanz bearbeitet werden. REST bietet eine Möglichkeit für die Kommunikation zwischen Anwendungen im he- terogenen Umfeld. Es ist ein abstrakter Architekturstil, der mit vielen Technologien in eine konkrete Architektur umgesetzt werden kann. Ein Umdenken des Programmierstils ist notwendig um die Prinzipien von REST umsetzen zu können.
2.5 Action Message Format (AMF)
Action Message Format (AMF) ist ein kompaktes binäres Format für das Serialisieren und Deserialisieren von ActionScript Objekten und entfernten Methodenaufrufen (Remo- te Method Invocations). Der Adobe Flash Player nutzt AMF für eine effiziente Kommu- nikation zwischen Flash/Flex-Anwendungen und einem entfernten Server. AMF kann auf Basis von HTTP oder andere Real-Time-Netzwerkprotokolle wie Real Time Messaging Protocol (RTMP) [Inc09j] transportiert werden. AMF wurde mit Flash Player 6 im Jahr 2001 eingeführt und blieb unverändert in den darauf folgenden Versionen des Players 7 und 8. Diese erste Version von AMF wird als AMF0 bezeichnet. Mit der Einführung von ActionScript 3.0 und der neuen ActionScript Virtual Machine (AVM2) im Flash Player 9 wurde auch AMF an die neuen Datentypen und Besonderheiten der Sprache angepasst [Ado07]. Adobe Flash Player 9 unterstützt beide Messaging-Formate – AMF0 für Acti- onScript 1.0 und 2.0 und das neue AMF3 Format. Adobe Systems hat die Spezifikation des Protokolls AMF Ende 2007 publiziert. Mit AMF0 können Referenzen auf komplexe Objekte gesendet und somit die Redundanz im Objektgraphen verringert werden. Die erste Version erlaubt den Endpunkten das Wie- derherstellen von Objektbeziehungen. Auch zyklische Referenzen werden korrekt verar- 14 2. GRUNDLAGEN
beitet1, da die Probleme wie beispielsweise unendliche Rekursion in der Serialisierungs- phase behandelt werden. Die Verbesserungen in der neuen Version AMF3 werden im Folgenden aufgelistet [Ado07]:
• Zusätzlich zu den Objektinstanzen können Referenzen auf Strings, komplexe Ob- jekte (anonyme Objekte, typisierte Objekte, Array, Date, XMLDocument, XML und ByteArray) und Objekteigenschaften 2 gesendet werden. • Int/uint und flash.utils.IExternalizable3 Typ wird unterstützt. • Variable Länge für integer-Werte zur Reduzierung des Datenvolumens, wird auch bei der Übertragung der Länge von UTF-8 Strings, XMLDocument UTF-8, XML UTF-8 und ByteArray benutzt. In AMF3 werden für die Referenzierung von Objekten drei verschiedene virtuelle Ta- bellen eingesetzt – für Strings, Objekte und Objekteigenschaften. Diese Tabellen werden implizit bei der Serialisierung und Deserialisierung geprüft, aber nicht als Einheit im For- mat mitkodiert. Jeder Objekttyp, welcher als Referenz gesendet werden kann, kann auch mit einem Index auf die Tabelle verweisen und so kodiert werden. Einige der Vorteile bei der Nutzung von AMF sind [AAB+08]:
• Filegröße – Die AMF-Objekte sind sehr klein und mit zlib [GA09] komprimiert. • Schnelles Serialisieren/Deserialisieren – AMF nutzt nativen C-Code für die Trans- formation der Datenobjekte und wurde entwickelt um mit wenig virtuellen Speicher und langsamen Prozessoren zu arbeiten. Die Daten werden direkt in Objekte ge- parst. • Native Typen und eigene Klassen unterstützt – Alle Objekte außer flash.display.DisplayObject können serialisiert werden. Außerdem kön- nen serialisierte Objekte zurück in die eigenen Datentypen überführt werden. Die Datenübertragung mit AMF verbessert die Leistung durch das Verringern des Daten- volumens und das Parsen von binären Daten in Objekten, welches effizienter ist als das Parsen von XML.
2.6 Web Services
Die Service-orientierte Architektur (SOA) ist keine technische, sondern die geschäftliche Sicht auf die Internet-Technologie. Es ist nicht wichtig bestehende Programme und deren Gesamtleistung zu betrachten, sondern wie sich Teilprozesse unter Nutzung vieler verfüg- barer Komponenten realisieren lassen. Web Services stellen eine technische Realisierung von Diensten im Sinne der SOA dar. Sie sind keine Architektur, sondern eine Infrastruktur für die Kommunikation und den Datenaustausch [Wöh04]. Ein Web Service setzt sich aus einer Implementierung und einer Beschreibung zusam- men. Die Implementierung soll über ein Netzwerk nutzbar sein. Die Beschreibung besteht
1zwei oder mehrere voneinander abhängige Objekte referenzieren sich gegenseitig. 2Objekteigenschaften sind der Klassenname und die public Variablen. 3wenn IExternalizable implementiert wird, können auch private, internal und protected Variablen seriali- siert werden [Ado08]. 2.6. WEB SERVICES 15 aus Schnittstellen, verfügbaren Operationen und der Netzwerkadresse des Services. Die Adresse wird als Endpunkt bezeichnet. In einer serviceorientierten Architektur sind die Rollen der Beteiligten wie folgt definiert:
• Service Provider – Implementiert einen Web Services und macht diesen verfügbar. Es gibt keine Vorgaben über das verwendete Protokoll (z.B. HTTP, SMTP [Kle01]). • Service Requester – Ist eine Person, oder im automatisierten Fall ein Software- Client, der den Service benutzt (beispielsweise Anwendung, Applet, Servlet [SM04] oder anderer Web Service). • Service Registry – Ist ein zentraler Verzeichnisdienst mit Daten über das Unterneh- men, den Web Service, den Leistungsumfang und mit Verweisen auf Information zur konkreten Nutzung. Die typischen Interaktionen unter den Beteiligten sind das Publizieren, das Auffinden und das Binden. Abbildung 2.5 zeigt den Zusammenhang zwischen den Rollen und den Interaktionen.
Abbildung 2.5: Web-Service-Rollen und Interaktionen [Wöh04].
Die Standards für die Interaktion mit Web Services sind:
• SOAP [LM07] – Ist ein Protokoll für den Nachrichtenaustausch basierend auf XML. SOAP-Nachrichten sind plattform- und Programmiersprachen unabhängig. Das Transportprotokoll wird durch SOAP nicht festgelegt, in der Regel wird jedoch HTTP verwendet. • WSDL [MWCR07] – Ist eine standardisierte Grammatik für die Beschreibung der öffentlichen Schnittstellen und basiert ebenfalls auf XML. WSDL stellt einen Kon- trakt zwischen Service-Anbieter und Nutzer dar und umfasst öffentlich verfügbare Methoden und deren Signaturen, Information über unterstütze Transportprotokolle, die Typ-Schemata für den Datenaustausch sowie die Adresse des Web Services. • UDDI [CHRR09] – Ist ein Standard für den Aufbau eines verteilten Web-Service- Verzeichnisdienstes und beinhaltet APIs zum Publizieren (Description) und Auffin- den (Discovery) von Diensten. Während WSDL die technische Schnittstelle be- schreibt, enthält UDDI globalere Informationen über den Service, z.B. das Un- ternehmen, die Klassifizierung (Taxonomie) und einen Verweis auf die technische Spezifikation (meistens die URL des WSDL-Dokumentes). 16 2. GRUNDLAGEN
Nachdem die Standards für die Nutzung von Web Services kurz dargestellt worden sind, wird die Beziehung zwischen Service Requester und Provider erläutert. Diese durchläuft im Allgemeinen vier Phasen:
• Modellierungsphase – Bei der ersten Phase wird aus der Sicht eines Providers ein Webdienst erstellt, entwickelt und beschrieben. Die Beschreibung kann auch semantisch sein. Der Client definiert in dieser Phase die Anforderungen an den gesuchten Web Services. • Publication/Discovery Phase – Angebotene Dienste werden mit den Daten aus der ersten Phase vom Provider veröffentlicht. Anhand der Anforderung des Clients werden passende Dienste gesucht (matching). • Kompositionsphase – Nachdem eine Liste mit einem oder mehreren Diensten von der Suche zurückgegeben worden ist, werden beim dritten Schritt die Parame- ter zwischen Requester und Provider ausgehandelt. Es können auch verschiedene Dienste kombiniert und aggregiert werden um die gewünschte Funktionalität zu erhalten. • Ausführungsphase – Orchestrierung, tatsächlicher Aufruf des Web Services. Web Services sind wiederverwendbare Komponenten, die in einem heterogenen Um- feld eingesetzt werden oder dann, wenn die Funktionalität als Service angeboten werden soll. So wird der Zugriff von unterschiedlichen Frontend-Clients auf Funktionalitäten im Backend-Bereich über eine definierte Adresse ermöglicht.
2.7 Zusammenfassung
In diesem Kapitel wurden Grundlagenkenntnisse über die relevanten Technologien für diese Arbeit vermittelt. In Kapitel 2.1 wurde eine neue Generation von Anwendungen - Rich Internet Applications vorgestellt, die zugleich reichhaltig an Benutzererlebnis sind, kein Refresh der Web-Seite bei Interaktion mit dem User brauchen und weniger Anfra- gen als herkömmliche Webanwendungen an den Server stellen. Eine Technologie für das Anzeigen und das Erstellen vom Frontend solcher Anwendungen wurde in den darauf folgenden Kapiteln 2.2 bzw. 2.3 beschrieben. Da für diese Arbeit Adobe Flex für die Er- stellung des Frontends benutzt wird, wird aus diesem Framework ausgegangen und nach Möglichkeiten für die Kommunikation mit dem Backend gesucht. Eine Variante dafür ist den Architekturstil REST zu nutzen, der angibt wie Daten definiert und adressiert werden sollen und wurde in Kapitel 2.4 vorgestellt. Weitere Möglichkeit bietet das binäre Format AMF, der in Kapitel 2.5 erläutert wurde. Informationen können in und aus diesem Format automatisch serialisiert und deserialisiert werden und auf Basis von HTTP oder RTMP zum Server und zurück transportiert werden. Web Services sind auch eine relevante Tech- nologie für das Anbinden an dem Backend und bieten vordefinierte Funktionalitäten, auf die mittels eines Interfaces zugegegriffen werden kann. Wie Web Services funktionie- ren und welche Phasen die Kommunikation zwischen Requester und Provider durchläuft wurde in Kapitel 2.6 betrachtet. 17
3 Datenübertragung
Einer der wichtigsten Aspekte für eine Rich Internet Application (siehe Kapitel 2.1) ist die Beschaffung der Daten für die Anwendung. Adobe Flex arbeitet mit so genanten Daten- quellen, anders als andere Web Technologien wie JavaServer Pages (JSP) [SM06], Active Server Pages (ASP) [Cor09a] oder Adobe ColdFusion. Die Dateien in Adobe Flex werden im binären SWF-Format bereitgestellt, zum Client gesendet und im Adobe Flash Player angezeigt. Wenn die Flex-Anwendung eine Anfrage zum externen Service stellt, wird die SWF nicht neu kompiliert und kein Refresh der Seite ist erforderlich (Client-side pro- cessing). Vergleichsweise wird bei JSP die Anfrage auf dem Server statt auf dem Client verarbeitet, und das Ergebnis wird für die Generierung einer neuen HTML-Seite benutzt. In diesem Fall erneuert der Applikationsserver die ganze HTML-Seite (Server-side pro- cessing). Adobe Flex bietet Remote Procedure Call-basierten Kommunikation (RPC) und Real- Time Messaging an. Für diese Arbeit ist die erste Kommunikationsart von Interesse. Im Flex-Framework (siehe Kapitel 2.3) stehen drei RPC-Klassen für den Datentransfer mit dem Applikationsserver zur Verfügung. Dabei ist zu beachten, dass diese Klassen unter- schiedliche Implementierung in MXML und ActionScript3 haben: die MXML-Versionen sind Subklassen der ActionScript3-Klassen. Eine Übersicht über die Struktur der einzel- nen Klassen ist im Anhang zu finden (siehe Abbildung 8.1 und 8.2). Abhängig vom Typ des Interfaces für eine bestimmte serverseitige Anwendung kann in Flex unter den folgenden Komponenten zur Kommunikation mit dem Backend ausge- wählt werden [Ado08]:
• HTTP GET und POST mittels der HTTPService-Komponente – Diese Komponente nutzt HTTP für die Übertragung und seine GET- und POST-Methoden für die An- frage an den Server und bearbeitet XML oder Zeichenketten, die als Antwort vom Server kommen. Mit dem HTTPService kann u.a. mit PHP-, ColdFusion-, JSP- und ASP-Seiten sowie einem Ruby on Rails-Backend [Han09] kommuniziert werden. • SOAP-konforme Web Services mittels der WebService-Komponente – Für Web Ser- vices, die ihr Interface mit der WSDL definiert und SOAP-basiertes XML oder nur XML für die Übertragung nutzen. • AMF Remoting Services mit RemoteObject – Alle Daten werden im binären AMF- Format umgewandelt und über HTTP zum Server transportiert. Auf dem Server muss sich ein Remoting-Gateway befinden, welcher die ActionScript-Objekte in den Datentypen der serverseitigen Sprache umwandelt. Es existieren Adobe-eigene und Drittsoftware für diese Datentransformation. In diesem Kapitel werden die aufgelisteten Möglichkeiten zum Datenaustausch betrach- tet. 18 3. DATENÜBERTRAGUNG
3.1 HTTP Service
Mit HTTP(S) Anfragen (meist GET oder POST) können von einfachen URL-kodierten Variablen bis zu komplexen Datenstrukturen wie XML transportiert werden. Auf diesem Prinzip beruht auch die Kommunikation mit REST-basierten Anwendungen (siehe Kapi- tel 2.4). Die Information wird als Klartext gesendet und empfangen. Die Daten müssen an die ent- sprechenden Datentypen in ActionScript auf der Clientseite und an die Datentypen der serverseitigen Technologie gemappt werden. Dieser Vorgang wird nicht vom Framework unterstützt und muss vom Entwickler implementiert werden. Der Ablauf eines Daten- austausches mittels HTTPService ist in Abbildung 3.1 dargestellt. Es ist auch möglich ein spezielles Datenaustauschformat wie JSON [Int99] zu nutzen. ActionScript und viele serverseitigen Sprachen bieten eine Schnittstelle für dieses Format an.
Abbildung 3.1: Ablauf eines HTTPService-Aufrufs in Flex [Der08].
Um die Funktionsweise des HTTPServices zu veranschaulichen wird ein einfacher Ser- vice in PHP erstellt, der als Eingabe die ID eines Produkts hat und als Ergebnis den Namen und den Preis des Selben im XML-Format liefert. Das Produkt-Beispiel wird für alle drei RPC-Komponenten benutzt. Der Service ist in Listing 3.1 dargestellt. In diesem Code werden die Informationen zum Artikel direkt geschrieben, sie können aber aus dem Ergebnis einer SQL-Anfrage zu einer Datenbank generiert werden. Auch das Einfügen von Daten in die Datenbank auf diese Weise ist möglich. Listing 3.1: Die Service-Klasse productRequest.php gibt zu einer ID den Namen und den Preis des Produktes im XML-Format zurück. 1 ‘.$id_number.‘
Auf der Clientseite wird in MXML die HTTPService-Komponente erstellt, wie in Listing 3.2 abgebildet. Der HTTPService (Zeile 5-15) hat eine URL (Zeile 6), nutzt die HTTP- Methode GET (Zeile 9) und hat kein Proxy (Zeile 10) definiert. Das Ergebnis wird im For- mat ECMAScript for XML (E4X) (Zeile 11) erwartet, welches vordefinierte Konstrukte zum Bearbeiten von XML anbietet. Wenn die Anfrage erfolgreich abläuft, wird das Er- gebnis in der Funktion serviceResult (Zeile 7,29) behandelt und als Text angezeigt (Zeile 38,39). Im Fehlerfall wird die Funktion serviceFault (Zeile 8,32) aufgerufen. 3.1. HTTP SERVICE 19
Parameter können in der Anfrage in
1 2
Komplexe Datenstrukturen, die als Antwort vom Server in XML-Format kommen, kön- nen auch bearbeitet werden. Es ist noch möglich die PUT- und DELETE-Methode von HTTP zu nutzen, um Ressourcen mittels RESTful Services zu manipulieren. Dieser An- satz wird im nächsten Unterkapitel vorgestellt.
3.1.1 RESTful Services
Eine Flex-Anwendung kann auch REST (siehe Kapitel 2.4) für die Kommunikation zu ei- nem Server nutzen. Ein RESTful Service bietet vier mögliche HTTP-Header für die Ma- nipulation der Ressourcen: PUT, POST, DELETE und GET, die auf die vier Datenzugriff- Operationen: Erstellen (Create), Lesen (Read), Aktualisieren (Update) und Löschen (Delete, zusammen auch CRUD genannt) gemappt sind. Eine Ressource kann eine einfa- che Ressource, eine Tabelle in einer Datenbank oder ein komplexes Objekt sein. Der Flash Player ist beschränkt auf die Nutzung von GET- und POST-Methoden, so dass 20 3. DATENÜBERTRAGUNG
die Methoden DELETE und PUT an einer GET oder POST-Nachricht angehangen werden müssen. In Listing 3.3 ist ein Beispiel eines HTTPServices dargestellt, der ein Produkt mit einer vorgegebenen ID (Zeile 5) löscht. Auf der Serverseite wird Ruby on Rails genutzt. Da die URL des Services sich abhängig von der manipulierten Ressource ändert, wird diese erst in der Funktion (Zeile 6) und nicht im Service festgelegt. Der Methodenname DELETE wird als Parameter in der Variable _method mitgeschickt (Zeile 7). Listing 3.3: Definition der Methode DELETE bei HTTPService für Ruby on Rails.
1
Das Problem der fehlenden Behandlung der PUT- und DELETE-Methode kann auch umgegangen werden, wenn BlazeDS (siehe Kapitel 5.1.6) oder Adobe LiveCycle Ser- ver (siehe Kapitel 5.1.5) eingesetzt werden. Dann muss beim HTTPService useProxy auf true gesetzt werden. So kommuniziert der Flash Player nur mit dem Server, der in der Konfigurationsdatei service-config.xml (siehe Listing 3.4) in Flex definiert ist. In diesem Fall wird die Anfrage erst zum Proxy-Server – beispielsweise Adobe LiveCycle oder BlazeDS geschickt und erst dort wird die korrekte HTTP-Anfrage mit der gewünsch- ten Methode erstellt. Der Proxy bearbeitet auch fehlerhafte HTTP-Antworten im Bereich vom Statuscode 500, so dass diese für den Flash Player als HTTPService Antworten ver- ständlich sind. Eine andere Möglichkeit bietet die Bibliothek as3httpclient [Qab09], welche einen bi- nären Flash-Socket nutzt, um den HTTP-Stream zu lesen, und kümmert sich um die Ko- dierung und Dekodierung der Antwort. Mit dieser Bibliothek kann mit POST, PUT, DE- LETE und GET-Methoden gearbeitet werden. Voraussetzung für die erfolgreiche Kom- munikation ist aber eine corssdomain.xml-Datei, in der dem Flash Player erlaubt wird sich mit dem Server über Port 80 zu verbinden. Adobe bietet auch ein eigenes binäres Format (AMF) für die Übertragung von Daten und entfernte Methodenaufrufe. Diese Technik wird in dem nächsten Kapitel erläutert.
3.2 RemoteObject – AMF
Mit RemoteObject-Services kann die Business-Logik direkt in ihrem nativen Format er- reicht werden, statt die Objekte aus dem empfangenen XML zu erzeugen wie dies bei den REST-style Services mit Ruby on Rails oder Web Services der Fall ist. Die verfügbaren Methoden einer RemoteObject-Komponente sind im Anhang zu finden (siehe Abbildung 8.2). Die Kommunikation über RemoteObject kann auf zwei Arten erfolgen: direkt, über Adobe- eigene Produkte, oder indirekt, über Gateways von Drittanbietern. Im ersten Fall ist das Gateway, das für das Mappen von ActionScript- auf serverseitige Objekte zuständig ist, im Produkt mit integriert. Die direkte Variante meint die Nutzung von Adobe LiveCycle Data Services (siehe Ka- pitel 5.1.5), BlazeDS (siehe Kapitel 5.1.6) oder ColdFusion. Die Flex-Anwendung kann 3.2. REMOTEOBJECT – AMF 21 die Java-Objekte oder ColdFusion-Komponenten unmittelbar mit einem entfernten Me- thodenaufruf erreichen. Das Objekt auf dem Server kann dann mit den nativen Daten- typen der Argumente interagieren, die Datenbank mit diesen Argumenten abfragen und die nativen Datentypen als Werte zurückgeben. Ein Vorteil der Remote-Services ist die Geschwindigkeit der Kommunikation. Der Austausch der Daten erfolgt über HTTP oder HTTPS, die Daten werden binär kodiert. Als Ergebnis wird weniger Information übertra- gen und die Speicher- sowie Prozessorzeit-Nutzung sinkt. Eine andere Möglichkeit ist Drittsoftware zu benutzen, die als Gateway zwischen der Flash-Player-basierten Anwendung und der Serverseite fungiert. Beispiele dafür sind die Open-Source-Software wie AMFPHP oder die Tools von Midnight Coders WebORB für PHP, .NET, Rails und Java. Eine Übersicht der existierenden Gateways ist im Anhang in der Tabelle 8.1 zu finden. Anwendungen mit RemoteObject und einem Gateway beruhen auf dem Schichtenmodell. Abbildung 3.2 stellt eine Drei-Schichten-Architektur dar, die wie folgt aufgeteilt ist:
• Präsentationsschicht – Der Flash Player als Standalone oder Browser-Plug-in tauscht mit dem Gateway die Information in Form von ActionScript-Objekten aus. • Logikschicht – Das Gateway hat die Aufgabe die ActionScript-Objekte auf die Datentypen der serverseitigen Sprache zu mappen. Ein Remote-Gateway wird für jeweils eine Sprache angeboten. Die serverseitigen Objekte rufen weitere Funktio- nen auf oder verbinden sich mit den Diensten der Datenschicht. • Datenschicht – In dieser Schicht werden die Daten von einer Datenbank, SOAP- Services oder anderen Datendiensten ausgelesen.
Abbildung 3.2: Drei-Schichten-Architektur bei Benutzung eines Gateways. 22 3. DATENÜBERTRAGUNG
Da das AMF-Format benutzt wird, erfolgt auf der Clientseite keine zusätzliche Aufbe- reitung der Datenobjekte, wenn diese zum Server gesendet respektive davon empfangen werden. Das Gateway mappt die Daten – beispielsweise von ActionScript-Datenobjekten auf PHP-Objekte für ankommende Nachrichten (von Flash zu PHP) und umgekehrt für die Rückgabe zum Client. Damit Flex entfernte Methoden aufrufen kann, muss eine Konfigurations-Datei namens service-config.xml für die Services definiert werden, die im Gateway zur Verfügung ste- hen. Die Struktur von so einer Datei ist in Listing 3.4 dargestellt. Für einen entfernten Dienst (Zeile 4-6) wird ein Ziel unter destination (Zeile 7) und ein Kanal (Zeile 9) definiert. Vom Ziel wird der Endpunkt als URL festgelegt (Zeile 20). Listing 3.4: services-config.xml von Flex für RemoteObject.
1 2
Abhängig vom Gateway werden die Services, die zur Verfügung stehen, in der jeweiligen Serversprache definiert. Als Beispiel wird AMFPHP mit einem Product-Service benutzt. Das Objekt Product ist ein Datentransferobjekt [GHJV05] und wird in PHP in der Klasse ProductVO.php (siehe Listing 3.5) und in ActionSctipt im File ProduktVO.as (sie- he Listing 3.7) definiert. Das Wichtigste für das serverseitige Objekt im ProductVO.php ist die Variable $_explicitType, die dem Gateway, in diesem Fall AMFPHP, sagt, dass diese Klasse eine Äquivalenz, ProductVO, im Flash Player hat. Die beiden Klas- sen müssen die gleiche Struktur haben, sonst kann Flex das RemoteObject nicht korrekt casten. Listing 3.5: Die Klasse ProductVO.php.
1
Im Gateway befindet sich die Serviceklasse, die beispielsweise mit der Datenbank eine Verbindung aufbaut und die Produkt-Objekte erstellt. Ein Beispiel dafür ist in Listing 3.2. REMOTEOBJECT – AMF 23
3.6 vorgestellt. Am Anfang der Service-Klasse wird die Definition von ProductVO.php angebunden (Zeile 2) und nach einer erfolgreichen Datenbankverbindung in der Methode getProductVO() (Zeile 5-17) wird für jede Zeile des Datenbankergebnis (Zeile 10) ein ProductVO-Objekt mit den nötigen Parametern erstellt (Zeile 11-13). Es wird ein Array als Halter für alle Objekte definiert (Zeile 6) und schließlich von der Methode zurückgegeben (Zeile 16). Listing 3.6: Die Klasse ProductService.php.
1 productId = $row[’PRODUCT_ID’]; 13 $product->name = $row[’NAME’]; 14 $myProducts[] = $product; 15 } 16 return $myProducts; 17 } 18 ?>
Nachdem die Klasse ProductVO.php und der zugehörige Service auf dem Server erstellt worden ist, wird eine gleichnamige Klasse in ActionScript benötigt, damit das Server- Objekt darauf gemappt wird. Diese Klasse hat die Struktur wie in Listing 3.7 und ist genau wie die Klasse in PHP aufgebaut (siehe Listing 3.5). Das Metatag Bindable (Zeile 3) erlaubt, Werte zu einer Variable zu binden und diese automatisch bei einer Veränderung zu erneuern. Das RemoteClass-Metatag (Zeile 4) definiert, welches das entfernte Objekt auf dem Server ist. Es ist vorgeschrieben, dass dieses Metatag und der $_explicitType in PHP gleich sein sollen. Listing 3.7: Die Klasse ProductVO.as.
1 package 2 { 3 [Bindable] 4 [RemoteClass(alias="ProductVO")] 5 6 public class ProductVO 7 { 8 public var productId:int; 9 public var name:String; 10 11 public function ProductVO(){} 12 } 13 }
Der Aufruf des RemoteObjects ist dem Listing 3.8 zu entnehmen. Wie bei der Verwen- dung HTTPService werden die Methoden für den Fehlerfall (Zeile 2,7) und das erfolg- reiche Ergebnis definiert (Zeile 6). Im source (Zeile 3) steht der Name des entfern- ten Dienstes auf dem Server, in diesem Fall ProductService (siehe Listing 3.6). Destination hat den gleichen Wert wie das destination-Tag im services-config.xml (siehe Listing 3.4). Das destination-Tag des RemoteObjects verbindet sich mit dem servi- ces-config.xml-File, so dass RemoteObject dessen Endpoint laden kann. Die Methode des RemoteObjects (Zeile 5) ruft die Funktion getProductVO() auf. Das Ergebnis wird 24 3. DATENÜBERTRAGUNG
weiterverarbeitet und die ProductVO-Objekte werden erstellt. Listing 3.8: RemoteObject-Aufruf in Flex.
1
Der Ablauf einer kompletten Anfrage wird abstrahiert in der Abbildung 3.3 dargestellt. In diesem Fall wird auch ein Datentransferobjekt zum Server gesendet. Wenn ein Remo- teObject definiert und aufgerufen wird, wird der Service vom Gateway aufgerufen und das Datentransferobjekt (ProductVO.as) weitergereicht. Im AMF-Gateway wird das Da- tentransferobjekt deserialisiert und auf ein serverseitiges Objekt (beispielsweise Product- VO.php) gemappt. Die Funktion ProductService.getProductVO() bekommt das serverseitige Objekt, arbeitet mit diesem und gibt es als Ergebnis dem Gateway zurück. Im Gateway wird das serverseitige Datentransferobjekt in ein ActionScript-Objekt umge- wandelt und serialisiert. Dieses Objekt wird der Methode in Flex weitergeleitet, die das erfolgreiche Ergebnis bearbeitet.
Abbildung 3.3: Abstrakter Ablauf des Remotings [Der08].
RemoteObject-Kommunikation ist nicht nur auf PHP und Java-Objekte beschränkt, es können verschiedene Sprachen auf der Serverseite und Server benutzt werden sobald ein Remote-Gateway für diese Sprache zur Verfügung steht. Tabelle 8.1 gibt eine Übersicht über die verfügbaren Gateways. Einige Vorteile bei der Nutzung von AMF-Gateways werden im Folgenden aufgelistet 3.3. WEB SERVICE 25
[AAB+08]:
• Konvertierung von Datentypen zwischen ActionScript und eine ausgewählte Pro- grammiersprache. • Mapping von benutzerdefinierten Objekten. • Direkter Aufruf serverseitiger Methoden. • AMF Serialisierung ist Teil des Flash Players, so wird der Code-Footprint minimiert und die Kommunikation mit dem Server optimiert.
3.3 Web Service
Die WebService-Komponente sendet und empfängt SOAP Nachrichten über HTTP. Der Ablauf des Datentransfers mit einem Web Service in Flex wird in der Abbildung 3.4 ge- zeigt. Die WebService-Klasse des Flex-Clients übernimmt das Serialisieren und Deseria- lisieren von allen ActionScript primitiven und manchen komplexen Typen von und nach SOAP/XML. Das ist eine Verbesserung zu der auf der HTTPService-Komponente basier- ten Kommunikation, wo das Mapping der Daten vom Entwickler durchgeführt werden muss.
Abbildung 3.4: Ablauf eines Web-Service-Aufrufs in Flex [Der08].
Wie ein Web Service von Flex aufgerufen wird ist in Listing 3.9 dargestellt. In diesem Beispiel wird auch wie bei den Beispielen aus den Kapiteln 3.1 und 3.2 ein Produkt- Service aufgerufen. Es wird eine WebService-Komponente definiert (Zeile 1) und die Adresse des WSDL-Files gesetzt (Zeile 2). Die aufzurufenden Operationen sowie das Format der Antwort und Funktionen zu weiteren Behandlung der Ergebnisse werden mit dem Tag
Listing 3.9: Web-Service-Aufruf in Flex.
1
Die WebService-Komponente bietet auch die Möglichkeit SOAP-Header zu definieren, in denen Namespaces und Benutzerdaten kodiert werden können, um diese mit dem Service zu übertragen. Über diese Vorgehensweise kann in [NA08] nachgelesen werden.
3.4 Zusammenfassung
In diesem Kapitel wurden existierenden Lösungen zur Kommunikation von einem Flex- Client zu einem Server vorgestellt. Ausgehend vom Flex-Framework wurde in Kapitel 3.1 der HTTP-Transfer der HTTPService-Komponente erläutert, ebenso wie die Mög- lichkeit einen RESTful Service aufzurufen. Da der Flash Player nur die HTTP-Methoden GET und POST zulässt, wurde eine Variante vorgestellt, wie zusätzlich die Methoden PUT und DELETE benutzt werden können, wenn das Backend in Ruby on Rails imple- mentiert ist. In Kapitel 3.2 wurde die Übertragung von Daten mit dem Adobe-eigenen Format AMF erläutert. Bei dieser Technik wird das Mapping von ActionScript-Objekte auf Objekte der Serversprache vom Gateway durchgeführt. Dies wurde an einem Beispiel mit PHP vorgestellt. Eine Übersicht über die existierenden Gateways und die unterstützen Sprachen ist im Anhang 8.1 zu finden. Im letzten Kapitel 3.3 wurde auf die WebService- Kommunikation eingegangen. Die existierenden Lösungen werden im nächsten Kapitel 4 bewertet sowie Anforderungen an die eigene Arbeit aufgestellt. 27
4 Analyse
In diesem Kapitel wird zuerst die Funktionsweise des Konfigurators der Aufgabenstellung beschrieben (Kapitel 4.1) und ein Test-Szenario aufgestellt (Kapitel 4.2). In dieser Arbeit geht es darum eine passende Kommunikation zwischen dem Backend und dem Frontend zu finden, so dass die Daten bei der Konfiguration mit minimalen Ladezeiten transfe- riert werden. Im Konfigurator gibt es mehrere Optionen zur Auswahl, deswegen wird im Test-Szenario die Reihenfolge der Selektierung von Optionen definiert. Im bestehenden Konfigurator werden dann anhand dieses Szenarios die Payloads und die Dauer der Über- tragung vom Client zum Server gemessen (Kapitel 4.2). Basierend auf diese Erkenntnisse werden die Anforderungen an die eigene Lösung definiert (Kapitel 4.3) und die Übertra- gungstechniken des Kapitels 3 analysiert. Anhand dieser Bewertung (Kpaitel 4.5) werden anschließend die geeigneten Technologien für die Datenübertragung zwischen Server und Client ausgewählt.
4.1 Konfigurator
Der Konfigurator für diese Arbeit soll dem Nutzer die Möglichkeit bieten, Autos online zu konfigurieren und dabei jede Änderung visuell sofort zu sehen. Eine Automarke hat mehrere Serien, jede Serie mehrere Modelle. Zu jedem Modell gibt es mögliche Optionen für die Konfiguration im Exterieur und Interieur. Für das Exterieur können vordefinierte und benutzerdefinierte Farben anhand eines Reglers eingestellt werden. Ebenda können auch die Felgen des Wagens konfiguriert werden. Im Interieur gibt es mehrere Optionen zur Einstellung, die in Gruppen zusammengefasst sind (z.B. Mittelkonsole und Lenkrad). Jede Option (z.B. Griff Handbremshebel) kann aus verschiedenen Materialien sein (z.B. Leder, Aluminium) und hat dementsprechend die Farben zur Konfiguration. Jede Option gehört außerdem zu einem Teil des Wagens (z.B. Mittelkonsole) und hat einen Preis. Die Autoteile sind nötig, da sie in einer bestimmten Ebenenstruktur bei der Visualisierung an- geordnet sind. Die ausgewählte Option wird dann den Platz des Teils einnehmen, welches verändert wurde. Der Preis des Autos wird nach jeder ausgewählten Option erneut be- rechnet. Manche Optionen können nicht in Kombination mit anderen ausgewählt werden oder brauchen zusätzliche Optionen. In diesem Fall wird eine Warnung ausgegeben. Au- ßerdem kann ein Nutzer den konfigurierten Wagen in seinem Benutzerkonto speichern. Dafür ist eine Registrierung erforderlich. Der existierende Autokonfigurator besteht im Frontend aus zwei Teilen: einer JSP-Seite, die die GUI-Elemente enthält, und einem Adobe Shockwave-Film [Inc09e]. Der Konfigu- rator wurde für Shockwave entwickelt, da sich die Anwendung so außer im Web auch von CD- oder DVD starten lässt. Eine Shockwave-Datei enthält komplexe Geometriedaten in 3D, die in Echtzeit mit Hilfe der Grafikkarte des Clients gerendert werden. So können Farben und Texturen online verändert werden. Wenn sich die Geometrien der ausgewähl- ten Option von den Serienausführung unterschieden (z.B. anderes Lenkrad), müssen diese 28 4. ANALYSE
Daten zusätzlich nachgeladen werden. Auf der Backend-Seite wird ein Apache Tomcat Server verwendet, über die Datenbank liegen keine Informationen vor. Im folgenden Kapitel wird ein Szenario aufgestellt auf dessen Basis Zeit- und Datenwerte bei der Übertragung vom Client zum Server gemessen werden.
4.2 Szenario
Folgender Beispielablauf dient zur Validierung der Anwendung:
• A1 – Anwendung starten, Exterieur in Studio-Ansicht des Autos wird geladen. • A2 – Die Farbe des Wagens wird geändert. • A3 – Die Ansicht wird von Studio in Surround geändert. • A4 – Es wird von Exterieur- zur Interieur-Ansicht gewechselt. • A5 – Eine Kategorie Sitze wird ausgewählt und die Farbe davon verändert. • A6 – Es wird zurück ins Exterieur gewechselt. • A7 – Es wird von Front zur Heck-Ansicht gewechselt. Die Dauer und die Payloads bei der Übertragung vom Client zum Server im bestehenden Konfigurator sind in der Tabelle 4.1 unter dem Namen „Datenübertragung“ zu finden. Für die Werte wurden jeweils zehn Messungen mit dem Tool Charles Proxy [Ran09] für HTTP-Transfer durchgeführt und daraus der Mittelwert gebildet. Da das Rendern auch gewisse Zeit in Anspruch nimmt, also das Zusammenfügen und Darstellen der aktuellen Konfiguration, wurde auch die Gesamtdauer der Übertragung und des Renderns mit einer Stoppuhr ermittelt. Diese Werte wurden fünf Mal gemessen und daraus der Mittelwert ge- bildet. Zum Kriterium A3 liegen keine Daten vor, da im bestehenden Konfigurator diese Funktion nicht angeboten wird. Die größten Datenmengen werden zum Initialisierungs- zeitpunkt übertragen und wenn z.B. die Interieur-Daten zum ersten Mal geladen werden. Wenn die Informationen einmal vom Server zu dem Client transferiert worden sind, be- finden sich diese im Browser-Cache und werden von dort bei erneuerten Aufrufen geholt. Bei den Ladezeiten geht es um primäre Ladezeiten, also wenn Ansichten oder Optionen das erste Mal geladen werden. Beim Starten der Anwendung vergehen ca. 40 Sekunden bis das Auto konfiguriert werden kann. Zwar wird ein Bild des Wagens sofort nachdem das Laden beendet ist angezeigt, es ist aber eine Animation, die ca. 8 Sekunden dau- ert. Der Übergang von Front- zur Heck-ansicht ist auch animiert und dauert ungefähr 8 Sekunden. Es ist zu bemerken, dass bei jeder Interaktion Daten vom Server angefordert werden.
4.3 Anforderungen an die eigene Lösung
Die zu erstellenden Anwendung hat eine Drei-Schichten-Architektur, deswegen werden die Anforderungen für die Bereiche Frontend, Server und Datenbank aufgestellt. Dazu kommen die Anforderungen an die Datenübertragung sowie die technischen Anforderun- gen für die Belastung des Clients. 4.3. ANFORDERUNGEN AN DIE EIGENE LÖSUNG 29
Schritt Art Zeit/Sekunden übertragene Datenmenge/210 Byte A1 Anwendung starten Datenübertragung 33,76 6872,53 Übertragung + Rendern 40,31 A2 Farbe Exterieur ändern Datenübertragung 0,87 0,38 Übertragung + Rendern 1,69 A3 Studio -> Surround Datenübertragung - - Übertragung + Rendern - A4 Exterieur -> Interieur Datenübertragung 10,11 0,26 Übertragung + Rendern 13,04 A5 Sitze Farbe ändern Datenübertragung 0,61 0,50 Rendern 1,8 A6 Interieur -> Exterieur Datenübertragung 0,16 0,34 Rendern 2,87 A7 Front -> Heck-Ansicht Datenübertragung 0,93 91,65 Rendern animiert 8,61
Tabelle 4.1: Dauer und Datenmengen der Übertragung vom Server zum Client im beste- henden Konfigurator beim ersten Laden.
4.3.1 Anforderungen ans Frontend
Für die eigene Lösung wird vom vorgegebenen Client ausgegangen, deswegen werden erst die Anforderungen am Frontend definiert. Diese beziehen sich nicht auf die Funktion des Konfigurators („was“ gemacht werden soll), sondern auf die nicht-funktionalen Ei- genschaften („wie“ es funktionieren soll).
• F1 – Die Anwendung wird in einer Plug-in basierten Version des Flash-Players ausgeführt. • F2 – Die gleiche Technologie soll für die Visualisierung des Autos und die GUI- Elemente benutzt werden. • F3 – Der Zustand der Anwendung wird auf dem Client gehalten. • F4 – Beim Anfordern von neuen Daten wird nicht die gesamte Seite neu geladen. • F5 – Asynchroner Datenaustausch mit dem Server. • F6 – Die erhaltenen Daten vom Server können möglichst schnell bearbeitet werden. • F7 – Das Frontend ist modular konzipiert, so dass es einfach erweitert werden kann.
4.3.2 Anforderungen an den Server
Die Anforderungen des Servers beziehen sich auf die Funktionsweise der zu entwickeln- den Logik.
• S1 – Aufbau einer Verbindung zur Datenbank. 30 4. ANALYSE
• S2 – Datenaufbereitung für das Frontend. • S3 – Empfangen und Bearbeiten asynchroner Aufrufe vom Frontend. • S4 – Service-orientierte Logik, spezifische Operationen erlauben CRUD auf der Datenbank. • S5 – Konkurrenter Zugriff mehrerer Clients soll gewährleistet werden. • S6 – Skalierbarkeit der Logik, Hinzufügen von neuen Services. • S7 – Konzeption der Logik für Apache Tomcat Server [Fou09b]. • S8 – Haltung des Bildmaterials.
4.3.3 Anforderungen an die Datenbank
Für die persistente Haltung der Daten der Anwendung sind folgende Kriterien definiert:
• DB1 – Konsistente Haltung der Datenobjekte. • DB2 – Objekte haben eine Referenz auf das benötigte Bildmaterial. • DB3 – Hinzufügen und Entfernen von neuen Datenobjekte, dabei soll die Konsi- stenz der Daten nicht verletzt werden. • DB4 – Lese- und Schreibzugriff nach Rechten auf die Datenbank. • DB5 – Die Datenbank kann mit dem ausgewählten Server kommunizieren.
4.3.4 Anforderungen an die Kommunikation Frontend-Backend
Die Anforderungen für die Kommunikation beziehen sich zum Einen auf die ausgewählte Frontend-Technologie, zum Anderen auf die gemessenen Werte bei der Datenübertragung beim existierenden Konfigurator.
• K1 – Effiziente Übertragung von Bildmaterial über HTTP. • K2 – Übertragung von Objekten und XML-Files mittels einer der ausgewählten Komponenten: Web Service, HTTP Service und RemoteObject. • K3 – Transfer-Techniken von Video-Daten. • K4 – Die Ladezeit beim Starten der Anwendung sollen um etwa 30% verglichen mit der existierenden Applikation reduziert werden (Kriterium A1). • K5 – Das erste Laden der Daten beim Wechsel vom Exterieur- ins Interieur-Ansicht soll um etwa 30% reduziert werden (A4). • K6 – Bei der Auswahl der Technologie soll die Übertragung und die Aufbereitung der Daten auf der Clientseite beachtet werden.
4.3.5 Technische Anforderungen
Die Anwendung wird für die Leistungstests auf einem Rechner mit Windows Vista be- trieben, der einen Prozessor Intel R CoreTM2 Duo mit einer Frequenz von 1.8 GHz und 4.4. AUFBAU DER ANWENDUNG 31 einen Speicher von 3 GB hat. Von diesem Rechner ausgegangen werden Anforderungen definiert bis zu welchem Punkt die Anwendung der Rechner belasten soll.
• T1 – Die Prozessorlast des Rechners soll nicht mehr als 60% bei Berechnungen überschreiten, wenn keine Interaktion ausgeführt wird weniger als 15%. • T2 – Die Speicherbelegung der Anwendung soll 253 MB nicht überschreiten (der Wert des existierenden Konfigurators). Dieser Wert soll möglichst minimiert wer- den.
4.4 Aufbau der Anwendung
Die Daten im Konfigurator können in drei Gruppen geteilt werden:
• Bildmaterial – Dieses Material liegt im SWF-Format vor. Es sind mehrere Da- teien, die zu einer Ansicht oder Option gehören. Die Dateien werden in Ordnern zusammengefasst. Alle Optionen zu einer Kategorie (Exterieur, Interieur) werden bei der Initialisierung dieser Kategorie geladen; einerseits um die Anzahl der Ser- veranfragen zu minimieren, anderseits um die Interaktion mit der Anwendung zu beschleunigen. • Datenobjekte – Diese Daten kommen aus der Datenbank und müssen auf Objekte der Serverseite gemappt werden. Mit Hilfe dieser Daten werden auch Operationen auf der Datenbank ausgeführt. Die gleichen Objekte gibt es auch im Konfigurator auf Clientseite. Manche Daten beinhalten langen Text zur Beschreibung der Optio- nen, andere haben Zahlen für die Farbwerte und die Preise. • Video-Daten – Zu bestimmten Zeitpunkten wird Videomaterial im FLV-Format ab- gespielt.
4.5 Bewertung der Übertragungstechniken
Im vorangegangenen Kapitel wurden der Aufbau der Anwendung sowie die Daten im Konfigurator vorgestellt. In diesem Kapitel werden die Übertragungstechniken für die verschiedenen Datentypen bewertet. Die Zeit, die für die Ausführung einer Interaktion, Aufbereitung der Daten auf dem Server, Transport vom Server zum Client und Bearbei- tung der Datenergebnisse im Frontend benötigt wird, wurde im Adobe Flex mittels einem Timer gemessen. Für jeden Wert wurden fünf Messungen durchgeführt und daraus der Mittelwert gebildet. Die vollständigen Zahlen der Messreihen sind im Anhang zu finden.
4.5.1 Bildmaterial
Der größte Teil der Anwendungsdaten im gewählten Szenario basiert auf Bildern. Bei Auswahl einer neuen Option wird neues Bildmaterial geladen. Zu den Anforderungen dieser Arbeit gehört eine effiziente Übertragung von Bildern über HTTP. Eine Besonder- heit der Benutzerfreundlichkeit im Frontend ist, dass ein Ladebalken den Fortschritt eines Ladeprozesses zeigt falls mehrere Dateien vom Server geladen werden sollen. Da jedes 32 4. ANALYSE
Objekt einzeln geladen wird, wird erstmal jedes Objekt nur kurz geladen, damit seine Größe ermittelt werden kann. Daraus wird das gesamte Datenvolumen ermittelt und der Transfer beginnt. Nun kann ein Ladebalken angezeigt werden, der prozentual den Wert des geladenen Materials visualisiert. Mit dieser Anforderung entstand die Idee einer Datenkompresion der Bilddaten auf dem Server. Das Bildmaterial liegt in SWF-Files vor und wird nach Optionen und Kategori- en in Ordner verteilt. Die Ordner werden mit dem offenen Format ZIP [Gro96] archi- viert und komprimiert. Es wird viel mehr den Vorteil ausgenutzt, dass eine archivierte Datei schneller übertragen wird, die Kompression der Dateigröße ist eher unbedeutend (ungefähr 1% der Datenvolumens). Die Bibliothek FZip [WH08] unterstützt die Über- tragung zum Flash-Client progressiv während der Ladezeit. Im ersten Schritt wird eine Verbindung zum ZIP-File aufgebaut und die Gesamtgröße der Datei ermittelt. Im zweiten Schirtt werden die Files geladen. Der Vorteil dieser Technologie ist, dass der Inhalt der im ZIP-File beinhaltete Dateien im binären ByteArray-Format [Ado08] vorliegt. Das er- laubt eine schnelle Übertragung der Daten zum Client und erfordert keine Dekompression des ZIP-Files. Ein weriterer Vorteil ist, dass für die Ermittlung der Gesamtgröße nur eine einzige Verbindung zum Server genügt. Bei dem normalen Ladeprozess würde eine Ver- bindung zu jedem File aufgebaut, die Dateigröße ermittelt, akkumuliert, die Verbindung abgebrochen und eine neue für das Laden aufgebaut. Listing 4.1 zeigt in Pseudocode die beschriebenen Abläufe. Listing 4.1: Pseudocode des Ladens eines SWFs ohne und mit ZIP-Kopression.
1 program Laden ohne Kompression 2 3 for every file in PayloadImageTest{ 4 file.loadFile(); 5 dataSize += file.getSize(); 6 file.unload(); 7 } 8 for every file in PayloadImageTest{ 9 load(file); 10 } 11 12 end Laden ohne Kompression 13 14 program Laden mit ZIP-Kompression 15 16 Fzip.load(PayloadImageTest.zip) 17 for every file in Fzip { 18 dataSize += file.getSize(); 19 } 20 for every file in PayloadImageTest{ 21 loadBytes(file.content); 22 } 23 end Laden mit ZIP-Kompression
Um die Effizienz des komprimierten Transfers zu zeigen, wurden Messungen mit unter- schiedlichen Filegrößen durchgeführt. Es wurden Ordner erstellt, die SWF-Files der Grö- ße 8KB, 101KB und 251KB beinhalten. Dabei wird am Anfang des Ladeprozesses die Gesamtgröße der Bilddaten ermittelt. Das Diagramm in Abbildung 4.1 zeigt die Ergeb- nisse der Messungen, die Tabelle 8.2 mit den genauen Zahlen befindet sich im Anhang. Aus diesem Diagramm wird deutlich, dass die Übertragung einer Datei der Größe 1MB mit der ZIP-Kompression etwa zwei Mal schneller als die Übertragung ohne Kompression ist. Ab diesem Wert ist die komprimierten Übertragung immer dreifach schneller als der normale Datentransfer, was einen Zeitertrag von ca. 60% bedeutet. Die Bearbeitungsdauer 4.5. BEWERTUNG DER ÜBERTRAGUNGSTECHNIKEN 33
Abbildung 4.1: Dauer der Übertragung vom Bildmaterial vom Client zum Server ohne und mit Kompression des Ordners, in dem sich die Daten befinden (siehe auch Tabelle 8.2). des Bildmaterials im Frontend bleibt gleich – die geladenen Dateien liegen nun im SFW- Format vor.
4.5.2 Datenobjekte
In Kapitel 3 wurden Ansätze zur Übertragung von Informationen zwischen einem Server und einem Flex-Client vorgestellt. Diese Ansätze sind nur für die Datenobjekte relevant. Es stehen drei Möglichkeiten zum Transfer dieser Information zur Verfügung: HTTPSer- vice, RemoteObject und WebService. Das Format der Antwort, welches für diese Arbeit relevant ist, ist XML eines RESTful Services oder eines Web Services und AMF eines RemoteObjects. Als Testbeispiel wurde eine Datenzeile mit acht Einträgen erstellt, die sowohl Text als auch Integer-Werte enthält und eine Größe von 0,43 KB hat. Ein PHP- Skript generiert eine bestimmte Anzahl Datenzeilen auf dem Server und sendet diese zum Flex-Client. Zusätzlich zu der Übertragung wurden auch die Dauer für einige Prozesse ge- messen, die hintereinander ausgeführt werden und für eine Anwendung, z.B. beim ersten Laden der Applikation, üblich sind – Datenaufforderung mit einer bestimmten Zeilenan- zahl, Generierung der Daten auf dem Server sowie Übertragung, und die Verarbeitung auf Clientseite. Grafik 4.2 zeigt das Ergebnis der Übertragung der Nutzdaten vom Client zum Server ge- messen in Sekunden. Bis 1 000 Datenzeilen ist die Übertragung im XML-Format etwa drei bis sechs Mal schneller als im AMF-Format (vergleiche Tabelle 8.3). Ab 1 000 Zei- len ist XML nur noch 1,3 Mal schneller als AMF. Aus diesem Diagramm ist ersichtlich, dass XML um einige Male schneller bei niedrigen Datenmengen (bis 1 000 Zeilen) und nur etwas besser bei einem höheren Datenvolumen ist. Da das AMF-Format für den Da- tentransfer zwischen Adobe Flash Player und einen Server entwickelt und optimiert ist, ist eine Datenzeile im AMF-Format um ca. 140 Mal kleiner (0,003 KB) als die Zeile in XML, die eine Größe von 0,43 KB aufweist. Die genauen Werte des übertragenen Daten- volumens sind in der Tabelle 8.5 im Anhang zu finden. XML-Daten werden als Text übertragen und auf der Clientseite geparst. Deswegen wur- de eine zweite Messungen durchgeführt, die für einen ganzen Zyklus der Client-Server- Kommunikation steht – Aufforderung des Clients, Generierung und Übertragung der Da- ten und Parsen für das Anzeigen im Flex. Folgende Abbildung 4.3 zeigt die Ergebnisse als Diagramm und Tabelle 8.4 beinhaltet die genauen Werte dazu. Bei 100 Zeilen erfolgt 34 4. ANALYSE
Abbildung 4.2: Dauer der Datenübertragung vom Server zum Client von Datenzeilen in Sekunden im Format AMF und XML (siehe auch Tabelle 8.3). die Arbeit mit XML zwei mal schneller, jedoch ab diesem Wert hat AMF den Vorteil und bleibt stets eineinhalb Mal schneller als XML. Obwohl Flex das Format EX4 für schnel- leres Parsen der XML-Daten anbietet, werden diese Informationen etwas langsamer als das binäre AMF-Format bearbeitet.
Abbildung 4.3: Dauer der Datenaufforderung, Übertragung vom Server zum Client und Verarbeitung im Frontend von Datenzeilen in Sekunden im Format AMF und XML (siehe auch Tabelle 8.4).
Bis jetzt wurde der Datentransfer und - parsen auf der Clientseite betrachtet. Es ist aber auch nötig den Fall der weiteren Nutzung im Frontend zu betrachten. Bei einer Anwen- dung, die z.B. CRUD unterstützt, wird die gleiche Struktur der Datenobjekte auf dem Client und dem Server vorausgesetzt, damit die einzelnen Dateneinträge der Datenbank manipuliert werden können. Wenn für diese Aufgabe ein RESTful- oder Web Service gewählt wird, kann keine genaue Aussage anhand der Übertragungsdauer der Daten ge- macht werden, welcher Service sich besser eignet, da das Ergebnis in beiden Fällen im XML-Format vorliegt. Ein Grund für die Wahl der WebService-Komponente wäre, dass Flex das Mapping der Objekte übernimmt. Ein weiterer Vorteil des Web Services ist, dass dieser direkt mit dem Client kommunizieren kann, während der RESTful Service einen Proxy für die HTTP-Methoden PUT und DELETE sowie das Anzeigen der Hea- der im Fehlerfall braucht. Da für den RESTful Service die Clientseite vom Entwickler geschrieben werden muss, besteht die Gefahr, dass Zyklen bei den Datenanfrage entste- hen können – eine Ressource ruft alle Kinder-Ressourcen auf, die haben wiederum eine Link auf die Eltern-Ressource und rufen diese erneuert auf. Für eine große Anwendung eignet sich ein RESTful Service nicht, da es noch keine Tools gibt, die Teile vom Code für die Clientseite generieren. Außerdem ist die gesamte Anwendung ab 100 Datenzeilen etwas langsamer, verglichen mit der Kommunikation über RemoteObject und deren Be- arbeitung. So ist das RemoteObject für eine CRUD-Anwendung vorzuziehen – die Daten werden schneller auf der Clientseite bearbeitet und das Format wird nativ unterstützt. Es 4.5. BEWERTUNG DER ÜBERTRAGUNGSTECHNIKEN 35 existieren viele AMF-Gateways (siehe Tabelle 8.1), die die Kommunikation mit Backend- Implementierung in unterschiedlichen Sprachen erlauben. Dem Entwickler werden au- ßerdem bei der Implementierung Tools zur automatischen Codegenerierung angeboten. Es bleibt die etwas langsamere reine Datenübertragung, dafür ist die Entwicklung und Bearbeitung im Frontend schneller. Tabelle 4.2 zeigt eine Übersicht über die Bewertung der verfügbaren Übertragungsmöglichkeiten.
Merkmale HTTP Service RemoteObject Web Service Übertragungsformat XML, Text AMF XML Proxy erforderlich nein, für RESTful ja nein Service ja Mapping der Daten auf nein ja ja der Clientseite Datenvolumen groß gering groß Übertragungsdauer klein mittel klein Bearbeitung auf Cleitn- aufwendig gering gering seite Tools zur Codegenerie- nein ja nein rung der Clientseite Tools zur Codegenie- ja ja ja rung der Serverseite Tabelle 4.2: Bewertung der existierenden Technologien zur Datenübertragung vom Server zum Client anhand Kriterien der Datenübertragung und Anwendungsentwicklung.
4.5.3 Video
Adobe Flash hat ein eigenes Standardformat für Video, FLV [Inc08f], welches als Con- tainer für verschiedene Video- und Audio-Codecs dient. Dieses Format ist heute de facto Standard für Web-Videos und sein Vorteil ist, dass es im Flash Player abgespielt wird und somit auf allen Plattformen und Betriebssystemen zugänglich ist: 84% aller online ge- stellten Videoclips werden mit Hilfe der Adobe Flash-Technology gesehen [Rei08]. Flash Videos unterstützen das reichhaltige Erlebnis einer Rich Internet Application, da sie so wie Objekte in einem SWF-File behandelt werden – so können sie in Ebenen positioniert oder mit ActionScript kontrolliert werden. Außerdem muss ein Video nicht ein rechtecki- ges Bild haben, es können Elemente von einem Video ausgeschnitten (maskiert) und als Teile in einem SWF Inhalt positioniert werden. Der Autokonfigurator soll auch Videoelemente enthalten, die kontextbezogen als Hilfe- stellung für den Nutzer und für weitere Informationen dienen. Für diese Daten liegt der Schwerpunkt auf einer effizienten Übertragung und einer niedrigen Belastung des Clients bezüglich seines Speichers. Es gibt drei Möglichkeiten wie die Videodaten dem Client ausgeliefert werden [Inc08b]:
• Eingebettetes Video im SWF-File – Ein Video kann im Flash Authoring-Tool auf der Timeline positioniert und innerhalb des SWF-Files publiziert werden. So kann das Video von einem normalen Web Server geliefert werden. Ein Nachteil dieser 36 4. ANALYSE
Lösung ist, dass das Video bei jeder Änderung neu zum SFW-File kompiliert wer- den muss. Außerdem wird der gesamte Videoclip im RAM vom Client geladen und bei einer Länge ab 120 Sekunden treten Synchronisationsprobleme auf. Deswegen ist diese Technik nur für Clients empfehlenswert, die den Flash Player 5 oder nied- riger nutzen sowie für Inhalte, die kürzer als fünf Sekunden sind. • Progressives Laden – In diesem Fall wird das Video getrennt von dem restlichen Flash-Inhalt und Kontrollelementen zur Wiedergabe gehalten. So kann das Video unabhängig von den anderen Daten verändert werden. Die Technik des progressiven Ladens wird seit der Version 7 des Flash Players unterstützt. Das Video wird mit den Klassen flash.net.netConnection und flash.net.netStream von Ac- tionScript geladen [Ado08]. Vom Quellcode des SWF-Files, der die Kontrollele- mente enthält, kann das Abspielen, die Pause und das Suchen kontrolliert werden. Wenn das Video mittels HTTP übertragen wird, wird es immer progressiv gela- den und wie jedes andere Dokument behandelt. Wenn genug von der Datei geladen ist, kann diese abgespielt werden. Dieses Verhalten kann mit ActionScript geändert werden. Zur Laufzeit wird das Video aus dem Browser-Cache, wohin es zuerst ge- laden worden ist, abgespielt. Es gibt keine Begrenzung bezüglich der Größe oder Länge des Videoclips. Außerdem treten keine Synchronisationsprobleme auf. • Streaming-Video – Die dritte Möglichkeit zur Auslieferung ist das Streamen von Video- und Audio-Files von einem Server, der diese Übertragung unterstützt. In diesem Vorgang hat der Client eine persistente Verbindung zum Server, so dass un- ter anderem die Bandbreite und weitere Dienstgütemetriken berücksichtigt werden können. Wie beim progressiven Laden wird der Video-Inhalt getrennt von den an- deren Elementen gehalten. Der Vorteil dieser Lösung zur Übertragung von Video ist, dass es nicht im Browser-Cache geladen wird und nur Teile, die der Client sehen möchte, ihm auch geliefert werden. Eine Verbindung zu streamenden Medien wird mittels dem Protokoll RTMP von Adobe über den Port 1935 aufgebaut. Einen Ausweg für Clients, die nur über Port 80 mit Internet kommunizieren können, ist das Protokoll RTMP „tunneled“ (RTMPT) [LK08]. In diesem Fall wird das HTTP-Protokoll als Transportmittel für die Informationen benutzt. Die wichtigsten Eigenschaften für den Vergleich der drei Möglichkeiten zum Laden von Videos sind in der Tabelle 4.3 vorgestellt. Das streamende Video eignet sich am besten für den Konfigurator, weil es weder im Spei- cher noch im Cache bleibt. Das Bildmaterial hat das größte Datenvolumen von allen be- nutzen Datentypen. Diese Daten werden erst im Browser-Cache geladen, beim Anzeigen befinden sie sich im Speicher. Da die Größe des Bildmaterials nicht minimiert werden kann, wird beim Video eine Variante gesucht, mit der der Client am wenigsten belastet wird. Das streamende Video entspricht diesen Anforderungen. Die Datenrate eines Videoclips kann mit dem Flash Video Datenrate-Kalkulator berech- net werden [Inc08b]. Es gibt vier Einstellungsoptionen: Art des Inhalts, Audio, Player Version und Art der Auslieferung (HTTP oder RTMP). Für den Inhalt wurde „redender Kopf“ ausgewählt, da die Idee des Videoelements ist, dass ein Helfer den Kunden durch die Anwendung leitet. Der Soundtrack ist „Erzählung“, die Version des Players ab Flash Player 9 und die Art der Auslieferung ist RTMP. Die Berechnung ermittelt für ein Bild von 320 x 240 und 15 fps 84 Kbps Video mit dem Video Codec AVC/H.264 und 16 Kbps 4.6. ZUSAMMENFASSUNG 37
Eigenschaft eingebettetes Video progressives Laden Streaming Auslieferung SWF-File progressiv Video progressiv gela- Das Video wird ge- geladen. den, gecached und ab- streamt, abgespielt und gespielt. Der gesamte dann vom Speicher ver- Videoclip muss nicht worfen. Kein Cachen. im Speicher passen. Performance limitiert durch RAM limitiert durch Cache optimal, Bildqualität ist von der Datenrate limi- tiert. Nutzung Länge < 1 Minute, Bild Bild < 720 x 480 Pixel, unbegrenzt < 320 x 240 Pixel, fps= fps <= 30 12 ) Tabelle 4.3: Vergleich der existierenden Ladetechniken für Flash-Video. Die Bildgröße ist in Pixel gekennzeichnet. Die Bildfrequenz wird in Bilder pro Sekunde – fps (Frames per Second) gemessen [Inc08b].
Audio mit dem AAC Audio Codec bei einer Rate von 11.025 kHz und mittlere Qualität. Insgesamt beträgt die Datenrate des Videos 100 Kbps und wird für eine Verbindung von 120 Kbps empfohlen.
4.6 Zusammenfassung
In diesem Kapitel wurde die Funktionsweise des Autokonfigurators und die Technolo- gie der existierenden Anwendung vorgestellt. Es wurde einen Beispielablauf definiert und anhand diesem die existierende Anwendung bewertet. Eine Anforderungsanalyse der eigenen Lösung für die Bereiche Front- und Backend sowie deren Kommunikation und technische Anforderungen wurde durchgeführt. Die existierenden Technologien zur Übertragung von Daten vom Kapitel 3 wurden nach ihrer Relevanz bewertet. Auch die Übertragung von Bild- und Videomaterial wurde analysiert. Die ausgewählten Technologien für die prototypischen Implementierung sind in Tabelle 4.4 aufgelistet. Es folgt eine Begründung für jede einzelne Technologie. Ausgegangen von der existierenden Anwendung beträgt das gesamte Datenvolumen, wel- ches beim Starten des Konfigurators übertragen werden soll, ca. 7 MB und wurde bis jetzt für 33,76 Sekunden transferiert (siehe Tabelle 4.1). Wenn davon ausgegangen wird, dass das Bildmaterial den größten Teil davon ausmacht, wird die Übertragung mit der ZIP-Kompression einen Ertrag von ca. 56% bringen, da die gleiche Datenmege in 14,82 Sekunden transferiert wird (siehe Tabelle 8.2). Nach diesen Ergebnissen wird die Art der Übertragung für das Bildmaterial komprimierte ZIP-Files über HTTP sein. Bei der Übertragung der Datenobjekte sollte nicht nur die reine Übertragungsdauer, son- dern auch die Bearbeitung auf der Clientseite betrachtet werden. Obwohl XML deutlich schneller transferiert wird, ist die Aufbereitung der Daten auf dem Client etwas langsamer (siehe Kapitel 4.5.2). Es wird davon ausgegangen, dass die Daten im realen Einsatz eher größer sind. Mit der Steigerung der Datenzeilen ist AMF um ca. 30% schneller bei der Übertraung und Bearbeitung der Daten. Der Vorteil von AMF liegt aber auch darin, dass 38 4. ANALYSE viel weniger Daten übertragen und im Cache gespeichert werden. Für die Videoelemente eignet sich am besten die Übertragung mittels RTMP von strea- menden Videos, da diese nicht im Browser-Cache gespeichert werden.
Art der Daten Technologie Bildmaterial ZIP-Kompression über HTTP Datenobjekte AMF Video RTMP Tabelle 4.4: Auswahl der Technologie der Datenübertragung für die prototypische Implementierung. 39
5 Konzeption
In diesem Kapitel wird die Konzeption der eigenen Lösung vorgestellt. In Kapitel 4.3 wurden Anforderungen an die Funktionsweise des Systems gestellt. Nach der Bewertung der existierenden Technologien zur Übertragung der erforderlichen Daten wurden AMF für die Übertragung von Datenobjekten, ZIP über HTTP für den Transfer von Bildmaterial und RMTP für das Streamen von Videoclips ausgewählt. Wie in Kapitel 3.2 beschrieben, erfordert die AMF-Technologie eine drei Schichten Architektur. Zuerst wird ein passendes Gateway für die Client-Server-Kommunikation ausgewählt (Kapitel 5.1). Darauf aufbauend wird die gesamte Architektur der eigenen Lösung und die Rollen der einzelnen Komponenten betrachtet (Kapitel 5.2). Es folgt die Konzepti- on der Datenbank (Kapitel 5.3) und der serverseitigen Logik (Kapitel 5.4). Abschließend wird der Entwurf des Frontends erläutert (Kapitel 5.5).
5.1 Client-Server Kommunikation
In Kapitel 3 wurden die Möglichkeiten zur Übertragung von Datenobjekten zwischen Cli- ent und Server analysiert und in Kapitel 4 wurde für diese Arbeit die Technologie AMF ausgewählt. Eine der Anforderungen an die Serverseite ist, dass als Applikationsserver Apache Tomcat genutzt werden soll. Unter den verfügbaren AMF-Gateways (siehe Ta- belle 8.1) soll in diesem Kapitel ein passendes Gateway für Java ausgewählt werden. Zu- nächst werden die existierenden Gateways für diese Sprache kurz vorgestellt und bezüg- lich ihrer Relevanz nach bestimmten Kriterien bewertet. Die Ergebnisse des Vergleichs sind in der Tabelle 4.4 zu finden. Folgende Aspekte eines Gateways wurden betrachtet: SOLL-Kriterien AMF-Gateway
• G1 – AMF3 soll unterstützt werden. • G2 – Java als Serversprache soll benutzt werden. • G3 – Möglichkeit zur Integration im Apache Tomcat Server. • G4 – Automatische Generierung des Codes für den Server. • G5 – Freie Auswahl der Datenbank. • G6 – Veränderung des generierten Codes bei Änderungen in der Datenbank. • G7 – Services für Datenmanagement. • G8 – Kostenlose Nutzung des Gateways. KANN-Kriterien AMF-Gateway
• G9 – Automatisches Deployment der Server-Anwendung. • G10 – Automatische Generierung des Codes für den Client. 40 5. KONZEPTION
• G11 – Zusätzliche Unterstützung vom RTMP. • G12 – Monitoring des Servers. • G13 – Verfügbare Dokumentation. • G14 – Bestehendes Supportforum für Entwicklerfragen.
5.1.1 OpenAMF-Gateway
Das OpenAMF-Gateway [Bak06] wurde für Flash MX entwickelt und unterstützt somit nur AMF0. Nach der Dokumentation auf der Seite von OpenAMF wurde das Projekt seit 2006 nicht mehr weiterentwickelt. Da für diese Arbeit nur die letzte Version des Messaging-Formats (AMF3) interessant ist, wird diese Lösung nicht betrachtet.
5.1.2 Granite Data Services
Das Granite Data Services Projekt (GDS) [Sys09] ist eine kostenlose Alternative zu Ad- obe LiveCycle Data Services und ist auf JEE Technologien zugeschnitten. Es unterstützt Java EE Persistenz wie Enterprise Java Beans (EJB3) [SM09b], Hibernate [RHM09a] und TopLink [Cor09i] mit lazy-loading 1. Ein weiterer Vorteil dieser Lösung ist, dass alle Objekteigenschaften (auch private, protected und internal) ohne zusätzliche Implementie- rung serialisiert werden können (siehe Kapitel 2.5). GDS kann mit verschiedenen Frameworks benutzt werden – Spring [Spr09a], Seam [RHM09b] und Google Guice [Goo08] mit Persistenz von Wrap [Gro08]. Auch mit POJO 2-Services kann gearbeitet werden. Das Projekt hat eine offene Adapter-Architekur, so dass Adapter für weitere Frameworks geschrieben werden können. Die Architektur von GDS ist in Abbildung 5.1 vorgestellt. Auf der untersten Ebene befinden sich die Schnitt- stellen zu den Persistenzobjekten und zu Java Message Service (JMS) [SM09e]. Es folgen die Objekte der verschiedenen Frameworks, die von GDS unterstützt werden. Tide ist der mitgelieferte Datenmanagement-Service, der in seinem Dienstangebot etwa den LiveCy- cle Data Services (siehe 5.1.5) entspricht. Darunter sind Client entity caching, Collection paging und Transparent lazy loading. Das Datenmanagement wird nicht für POJOs und Guice angeboten. Auf der nächsten Schicht erfolgt die AMF3-Serialisierung. GDS kann mit den Servern Tomcat [Fou09c], Jetty [Con08], JBoss [Inc09a] und GlassFish [SM09c] eingesetzt werden. Das GDS-Projekt unterstützt Data Push, Gravity genannt, welches als Comet-ähnlicher 3 Service mit AMF3 über HTTP implementiert ist. Es gibt auch einen ActionScript 3.0 Generator, Gas3, der aus JavaBeans Client-Code generiert. Gas3 kann Standalone als Ant-Task oder als Eclipse-Builder Plug-in laufen. Ein Servlet dient als Web-Compiler und kompiliert den MXML/ActionScript 3.0 Code zur Laufzeit. Der Vorteil vom Granite Data Services ist, dass diese Lösungen viele Applikationsserver und Frameworks unterstützt. Es ist aber eher für die Adaption von existierenden server-
1Design Pattern, das die Initialisierung eines Objektes verzögert, bis dieses gebraucht wird. 2Plain Old Java Object – einfache Java Objekte. 3Ein Oberbegriff für viele Techniken, die Daten vom Web Server im Browser pushen, ohne dass der Browser explizit nach diesen Daten gefragt hat. 5.1. CLIENT-SERVER KOMMUNIKATION 41
Abbildung 5.1: Granite-Data-Services-Architektur für Java-Applikationsserver [Sys09]. seitige Anwendungen gedacht, die eine AMF-Kommunikation brauchen. Eine komplette Backend-Lösung nur mit diesem Tool zu entwickeln ist nicht möglich, denn zuerst muss die Logik mit einem der oben genannten Frameworks vorliegen. Weiterhin wird die Er- zeugung des Server-Codes nicht unterstützt.
5.1.3 RED5
RED5 [RED08] ist ein Open-Source-Server, der für die Arbeit mit Adobe Flash Player entwickelt worden ist. Er unterstützt das TCP-Socket-basierte RTMP und die HTTP- basierte AMF Übertragung sowie XML-RPC. RED5 kann Video und Audio streamen und auch clientseitige Streams aufnehmen und wiedergeben, und wird daher meistens für Video-Chat-Anwendungen oder Mehrbenutzer-Spiele eingesetzt. Der Vorteil gegenüber dem Flash Media Server [Inc09c] ist, dass er kostenlos ist und eine starke Community an seiner Entwicklung arbeitet. RED5 kann als AMF-Gateway benutzt werden, er bietet aber keine Tools für die Entwicklung und Deployment an. RED5 kann mit allen Datenbanken arbeiten, die eine Java Database Connectivity (JDBC) Schnittstelle besitzen und lässt sich auf Tomcat aufspielen [Gre07]. Außerdem werden mehrere Skriptsprachen unterstützt. Wie bei GDS muss die Backend-Lösung mit anderen Tools vorher entwickelt und danach auf RED5 deployt werden. Es wird keine Codegenerierung unterstützt.
5.1.4 WebORB für Java
WebORB für Java ist eine Entwicklungs- und Laufzeitumgebung, die Flex-, Flash und Ajax-Clients mit Java Objekten, Spring Beans, EJB oder XML Web Services verbindet. WebORB gibt es auch noch für die Plattformen PHP, Rails und .NET. Für PHP und .NET gibt es eine Silverlight-API. Das Produkt WebORB für Java existiert in drei verschiede- nen Ausführungen. Die Community Edition ist kostenlos und bietet unbegrenzte Anzahl von Verbindungen zum Server. Die Developer Edition ist auch kostenlos, aber auf fünf Verbindungen begrenzt. Diese Version bietet Möglichkeiten des Monitoring, außerdem gibt sie Performance- und Skalierungs-Garantien. Die Enterprise Edition kostet zwischen 750$ und 4999$ pro Jahr und Server je nach Support-Stufe des Produktes. WebORB generiert serverseitigen Code mit CRUD-Services von einer vorgegebenen Da- 42 5. KONZEPTION tenbank. Zur Auswahl stehen MySQL [SM09h], PostgreSQL [Gro09a], Oracle [Cor09h] und MicrosoftSQLServer [Cor09c]. Die erstellten Services können dann automatisch auf dem Server aufgespielt werden. Clientseitiger Code kann für ActionScript 2.0 und ActionScript 3.0 sowie für die Frameworks Caringrom [Inc08a], PureMVC [Fut09] und Ajax-Clients generiert werden. Alle Tools zur Codegenerierung und Monitoring sind Browser-basiert und befinden sich unter der localhost-Adresse. Der Code kann dann von dort als ZIP-File heruntergeladen werden. Seit Februar 2009 mit der Version 3.0.2 un- terstützt WebORB auch Video-Streaming und Client-Stream-Recording. Die Architektur von WebORB ist in Abbildung 5.2 dargestellt.
Abbildung 5.2: WebORB-Architektur und Bearbeitungsschritte einer Anfrage vom Client [Cod09].
WebORB hat eine erweiterbare, skalierbare und mehrschichtige Architektur, die aus fol- genden Komponenten besteht: 5.1. CLIENT-SERVER KOMMUNIKATION 43
• Protocol Handlers – Als Multiprotokoll-Server unterstützt WebORB verschiedene Client-Server Messaging Formate, unter anderem AMF und ein eigenes Format für Ajax-Clients. • Dispatchers – Ein Top-level Mechanismus, der die Anfragen nach Methoden- und Kontroll-Aufrufe unterteilt. Es kann auch zusätzliche Logik für einen Dispatcher implementiert werden, z.B Filterfunktion. • Handlers – Eine Kette von Handlers bearbeitet die Methoden- oder die Kontroll- Aufrufe. Jeder Handler ist für eine spezielle Kategorie von Objekten zuständig: Java-Objekte, .NET-Objekte, SOAP-Web-Services und EJBs. Es können auch be- nutzerdefinierte Handlers registriert werden. • Sicherheit – Das Sicherheitsmodul begrenzt oder erlaubt den Zugriff auf Systemres- sourcen oder Kontroll- und Aufruf-Objekte. Bevor eine Anfrage zu der nächsten Komponente weitergeleitet wird, überprüft das Sicherheitsmodul ob dies erlaubt ist. Es wird Sicherheit auf der Service-Ebene unterstützt – entweder für bestimmte Services oder für die ganze Anwendung. Die Sicherheit kann für Rollen (Admi- nistrator, Datenbanknutzer oder Beispielnutzer), Host, einzelne IP-Adressen oder einen IP-Bereich im Browser-basierten Tool für Sicherheit eingestellt werden. • Activators – Diese Komponente wirkt bei der Konstruktion von neuen Objekten und deren Instanziierung mit. • Object Factories – WebORB nutzt einen Konstruktor ohne Argumente für das Er- zeugen der Instanzen für Java- und .NET-Objekte. Wenn dieser Konstruktor nicht verfügbar ist, kann eine benutzerdefinierte Factoty, die eine bestimmte Schnittstelle implementiert, eingesetzt werden. • Type Adaption – Vor jedem Aufruf werden die Daten, die vom Client empfangen worden sind, analysiert und in den erwarteten Datentyp der Methode konvertiert. • Argument Factories – Diese Factories erzeugen Instanzen von Methodenargumen- ten. All diese Komponenten der Architektur haben eine Aufgabe und werden zu bestimmtem Zeitpunkt der Bearbeitung einer Client-Anfrage gebraucht. Die einzelnen Schritte des Ab- laufs eines Aufrufs wird im Folgenden erläutert. Die Zahlen sind der Abbildung 5.2 zu entnehmen.
1. Ein Aufruf kommt über ein WebORB Servlet in den WebORB Presentation-Server. 2. WebORB ist ein Multiprotokoll-Server, daher wird die Anfrage an mehrere Hand- lers geschickt. 3. Der passende Protocol Handler wird ausgewählt. 4. Der Handler deserialisiert die empfangenen Daten und erzeugt ein Objekt, das die Protokolldetails abstrahiert und nur eine Sicht des Objektes in der ganzen Prozes- skette definiert. 5. Die Anfrage wird an die Dispatchers weitergeleitet und ein Aufruf- oder Kontroll- Dispatcher ausgewählt. 6. WebORB unterstützt mehrere Kategorien von Objekten, so wird der passende Typ ausgewählt. 44 5. KONZEPTION
7. Jeder Handler hat seine eigene Logik für die Bearbeitung der Anfrage. Beispiels- weise nutzt der Local Object Handler ein Object Construction Mechanismus für das Erzeugen oder Zugriff auf die Instanz eines Objektes. Der Web Service Handler erzeugt einen Proxy für den Web Service mit dem SOAP Proxy Generator. 8. Object Construction instantiiert oder fragt die Klasseninstanz ab, die im Aufruf benutzt wird. 9. Wenn das Objekt verfügbar ist, wird es für den Aufruf der Methode zum Invocation System weitergeleitet. 10. Das Inovocation System ist für das Finden der Methode mit den gefragten Argu- menten verantwortlich. WebORB implementiert ein TypeAdaption System, welches Daten vom Client in formale Argumenttypen für die Methoden umwandelt. 11. Wenn alle Argumente erfolgreich adaptiert werden, wird die Methode aufgerufen. 12. Die Ergebnisse oder die Fehler werden zu dem Protocol Handler, der im Schritt 3 ausgewählt wurde, zurückgesendet. 13. Der Serialisierer formatiert die Antwort für den Client. 14. Der WebORB Servlet schickt dem Client das Ergebnis. WebORB bietet auch Data paging an — es wird nur ein Teil der Daten zum Client über- tragen, die dann z.B. in einem UI-Element wie dem DataGrid angezeigt werden. Der Rest der Information wird gecached und bei der weiteren Interaktion mit dem UI-Element, bei- spielsweise wenn der Ausschnitt des DataGrids durch scrollen verändert wird, zum Client geschickt. So wird die Menge an transferierten Daten reduziert, aber da der Server die Da- ten aus der Datenbank vorhält wird der Speicher des Servers bei großen Datenvolumen belastet. Auf der Clientseite wurde für die Datenbankabfragen die Klasse ActiveRecord definiert, die die besten Ideen von Ruby on Rails eigenem ActiveRecord und Hibernate vereint. Es ist ein Interface für alle CRUD Operationen und bietet zusätzlich dynamische Generie- rung von benutzerdefinierten Abfragen an. WebORB kann als neue Anwendung auf den Servern Tomcat, JBoss, IBM WebSphere [Cor08] und BEA WebLogic[IBM09] aufge- spielt werden. Es kann aber auch in einer existierenden Web Anwendung, beispielsweise in Spring Framework integriert werden. Insgesamt bietet das Produkt WebORB eine komplette Palette an Tools für Entwicklung und Deployment von CRUD-Services in Java. Alle diese Tools sind Browser-basiert, so bedarf es keiner zusätzlichen Installation außer dem WebORB Presenation Server selbst, der mit Jetty Server als Standalone angeboten wird. Es ist zur gleichen Zeit ein AMF- Gateway mit Service-Browser und Monitoring-Modul. Eine Anwendung kann komplett mit WebORB entwickelt werden, dafür muss eine existierende Datenbank ausgewählt werden. Von dieser Datenbank wird ein Datenmodell, die serverseitigen Services für die CRUD-Operationen und der clientseitige Code generiert. Außerdem unterstützt WebORB seit Version 3.0.2 streamende Medien. 5.1. CLIENT-SERVER KOMMUNIKATION 45
5.1.5 LiveCycle DS
LiveCycle Data Services (DS) ist das Adobe-eigene Produkt für serverseitige Lösungen eines Flex-Frontendes. LiveCycle DS kann eigenständig installiert oder in den Servern JBoss, BEA WebLogic, IBM WebSphere und Apache Tomcat integriert werden. Die Da- tenbanken IBM DB2, Microsoft SQL Server, MySQL und Oracle werden unterstützt. Es bietet eigene Tools wie das Eclipse-basierte LiveCycle Workbench für die Entwicklung und Deployment von serverseitiger Logik. Die Entwicklung einer Backend-Anwendung wird zum Teil unterstützt, zuerst muss die Persistenzschicht z.B. in Form von EJBs vor- liegen und daraus werden Services generiert. LiveCycle DS kann kostenlos als Developer Version heruntergeladen werden, Preise für den Einsatz werden auf der Web Seite des Produktes nicht genannt. LiveCycle DS bietet folgendes Dienste an [Inc08c]:
• Remoting – Methoden von Java Server Objekten können direkt aufgerufen werden. Ähnlich zum Java Remote Method Invocation (RMI), erfolgt Marshalling der Daten automatisch und es wird ein binäres Format für den Transfer genutzt. • Messaging – Der Flash-Client kann verschiedene Events zu einem Thema auf dem Server publizieren und sich für broadcast-Events einschreiben. Ein Beispiel für die Verwendung von Messaging ist Real-Time Streaming von Finanzdaten oder von Systeminformationen. • Data Management Services – Automatisches Management von Datensätzen, die in dem Flex-Client geladen sind. Wenn einmal die Daten vom Server verfügbar sind, werden Veränderungen automatisch verfolgt und mit dem Server synchroni- siert wenn die Anwendung nachfragt. Clients können auch benachrichtigt werden, wenn sich die Daten auf dem Server verändert haben. • PDF-Generierung – Client-Daten und Templates auf dem Server werden zusam- mengefügt und und daraus ein PDF-Dokument generiert. Insgesamt bietet LiveCycle DS Tools zur Entwicklung und Ausführen von serverseitigen Anwendungen. Es ist aber nicht genau einzuschätzen, wie teuer der Einsatz von diesem Produkt ist. Die Optionen für Real-Time Messaging sind zwar interessant, werden aber im vorliegenden Fall für die zu implementierende Anwendung nicht gebraucht.
5.1.6 BlazeDS
Teile von LiveCycle DS sind als BlazeDS Open-Source seit Ende 2007 verfügbar. Gleich- zeitig wurde auch die Spezifikation des binären Protokolls AMF publiziert und somit den Entwicklern die Möglichkeit gegeben eigene Gateways zu schreiben. Bis zu diesem Zeitpunkt setzten die existierenden Gateways auf Reverse Engineering. BlazeDS ist die serverseitige Java-Remoting- und Web Messaging-Technologie, die eine einfache Verbin- dung zum Backend ermöglicht. Abbildung 5.3 zeigt die angebotenen Dienste dieser kostenlosen Komponente im Ver- gleich zu der vollen Palette von LiveCycle DS. Zahlreiche Beispiele sind im Installati- onsordner von BlazeDS vorhanden, so dass ein schnelles Einarbeiten ermöglicht wird. BlazeDS ist ein einfaches AMF-Gateway wie OpenAMF. Es ist jedoch eher auf die Er- 46 5. KONZEPTION weiterung bereits existierender Lösungen ausgerichtet. Ende 2008 wurde die erste Version der Integration des Spring-Frameworks und BlazeDS verkündet [Spr09b]. Somit wird die Entwicklung von Enterprise-RIA-Anwendungen ver- einfacht.
Abbildung 5.3: Die angebotenen Dienste von BlazeDS werden farbig dargestellt, die ver- fügbaren in LiveCycle DS sind grau markiert [unb08].
5.1.7 Bewertung der AMF-Gateways
In diesem Kapitel wurden sechs AMF-Gateways vorgestellt, die die Kommunikation mit einem Java-Backend ermöglichen. In jedem Abschnitt wurde die eigene Einschätzung eingebracht, ob sich das Gateway und die dazu angebotenen Tools für die Entwicklung einer kompletten Backend-Lösung eignet oder eine existierende serverseitige Lösung er- forderlich ist. Die Kriterien zur Bewertung der beschriebenen Gateways wurden in 5.1 definiert und in zwei Gruppen nach Soll- und Kann-Kriterien unterteilt. Für die Erfüllung jeder Anforde- rung wird ein Punkt vergeben. Die ersten drei Kriterien – AMF3 als binäres Protokoll für die Datenübertragung (G1), Java als Serversprache (G2) und Apache Tomcat als Server (G3) sollen unterstützt werden – wird von allen Gateways erfüllt außer vom OpenAMF, der nur für AMF0 angeboten wird. Das Generieren von serverseitigen Diensten (G4), die den Zugriff auf die Business Ser- vices und die Datenbank ermöglichen, wird von WebORB für Java und LiveCycle DS zur Verfügung gestellt. Dabei ist hier der Unterschied zwischen beiden Verfahren zu verdeut- lichen – WebORB kann aus einer vorhandenen Datenbank den Code generieren, während LiveCylce DS für diesen Schritt auf eine Persistenzschicht zugreifen muss. Die Datenbank ist bei allen Lösungen frei wählbar (G5). Wenn aber eine Änderung im Datenbankmodell vorgenommen wird, wird diese nur im LiveCycle DS automatisch be- handelt (G6). Bei WebORB muss beispielsweise die ganze Serverseite neu generiert und als Service aufgespielt werden. 5.1. CLIENT-SERVER KOMMUNIKATION 47
Datenmanagement (G7) wird von der Hälfte der Gateways angeboten – GDS, WebORB und LiveCycle DS. Mit diesem Service können die Daten auf der Serverseite visuell an- gezeigt und die Dienste getestet werden. Bei WebORB werden in diesem Service auch die Rechte für die Zugriffe auf Service-Ebene vergeben. Da in der eigenen Lösung die Sicherheit kaum eine Rolle spielt, wird dieser Punkt nicht extra betrachtet. Alle Gateways außer LiveCycle DS und WebORB haben eine kostenlose Version (G8) für den Einsatz. Diese Beiden werden nur als Entwickler-Version unentgeltlich angeboten. Das automatische Deployment für die Services (G9) wird von WebORB und LiveCycle DS angeboten. Bei allen anderen Lösungen werden die Dienste von Hand in den dafür vorgesehen Ordner kopiert und ,falls erforderlich, den Server neu gestartet. Zwei Werkzeuge unterstützen die Generierung der Clientseite (G10) – GDS und WebORB. Das zweite Tool kann sogar für verschiedene ActionScript-Frameworks im Frontend Code erstellen oder für einen Ajax-Client. Die Übertragung von Audio- und Video-Daten (G11) mittels RTMP ist mit RED5, WebORB und LiveCycle DS möglich. RED5 wurde primär als kostenlose Alternative zum Flash Media Server mit diesem Ziel entwickelt. Die Überwachung des Servers (G12) ist nur mit WebORB möglich. Eine Dokumentation mit Anweisungen und Tutorials (G13) gibt es für alle Gateways außer OpenAMF. Ein betreutes Forum existiert für GDS, RED5, BlazeDS und WebORB (G14). Beim Letzten ist die Dokumentation nicht immer auf dem neuesten Stand, da am Produkt ständig neuen Funktionalitäten hinzugefügt werden, die aber für diese Arbeit nicht von Interesse sind. Kriterien OpenAMF GDS RED5 WebORB Java LiveCycle DS BlazeDS G1 - + + + + + G2 + + + + + + G3 + + + + + + G4 - - - + + - G5 + + + + + + G6 - - - - + - G7 - + - + + - G8 + + + - - + G9 - - - + + - G10 - + - + - - G11 - - + + + - G12 - - - + - - G13 - + + + + + G14 - + + + - + Gesamt 4 9 8 12 10 7 Tabelle 5.1: Bewertung der AMF-Gateways für Java nach den in Kapitel 5.1 aufgestellten Kriterien. Die erfüllten Anforderungen werden mit einem Plus markiert, die nicht erfüllten mit einem Minus.
Nach den gestellten Kriterien und der Bewertung erzielt WebORB für Java die beste Ge- samtbewertung. Außerdem bietet dieses Tool die Möglichkeit eine komplette Backend- 48 5. KONZEPTION
Logik von einer existierenden Datenbank zu entwickeln. Für die Implementierung der eigenen Lösung wird somit die Entwicklungs- und Laufzeitumgebung WebORB für Java genutzt.
5.2 Architektur
Die meisten Webanwendungen haben eine Drei-Schichten-Architektur und sind nach dem Model-View-Controller [SM02b] Architekturmuster aufgebaut. In diesem Muster wird die Applikation in drei Teilen untergliedert – das Modell repräsentiert die Daten, die Präsentationsschicht ist für die Darstellung zuständig und die Steuerung nimmt die Be- nutzerinteraktionen entgegen und entscheidet welche Daten im Modell geändert werden müssen. Ohne auf mehr Details der genauen Zuständigkeit einzelner Komponenten des MVC-Musters einzugehen, wird die Struktur einer Flex-RIA wie folgt definiert – die Steuerung befindet sich in Form von Business-Logik oder Services auf dem Applikati- onsserver und aktualisiert die Datenbank (das Modell) wenn Benutzerinteraktionen vom Flex-Client kommen. Der Flex-Client zeigt die Datensätze dem Benutzer an. Das MVC- Diagramm einer Flex-RIA ist in Abbildung 5.4 dargestellt.
Abbildung 5.4: Model-View-Controller-Architekturmuster einer Rich Internet Application.
Jede Schicht hat folgende Aufgaben:
• Präsentationsschicht – In dieser Schicht befindet sich der Flash Player Client. Das Frontend hat zwei Ansichten, eine für den Web-Benutzer, der mit der Anwendung interagiert, und eine für den Administrator, der Daten in der Datenbank manipuliert. Der Client kommuniziert über ein AMF-Gateway mit den Diensten auf dem Server, die ihrerseits eine Verbindung zu der Datenbank aufbauen und die nötigen Opera- tionen auf den Daten ausführen. Ein weiterer Transfer von Bilddaten erfolgt über HTTP. Das Bildmaterial befinden sich auf einem Server in ZIP-Ordnern kompri- miert, zu denen der Client eine Verbindung aufbaut und diese nach Bedarf lädt. Der dritte Kommunikationskanal ist zum Streaming-Server, der die Videodaten über RTMP zum Client transferiert. • Steuerung – In dieser Lösung hat die Steuerung eine Form von Business Services, die sich auf dem Applikationsserver befinden. Da sich bei einer Rich Internet Appli- cation die Logik auf dem Client befinden kann, haben die Services auf dem Backend meist die Aufgabe CRUD-Operationen auszuführen. Wenn eine Anfrage vom Cli- ent kommt, wird diese in Java Objekten deserialisiert. Danach wird die Anfrage bearbeitet – JDBC-Treiber geladen, die Verbindung zu der Datenbank aufgebaut 5.2. ARCHITEKTUR 49
und das Statement in Form von SQL gesendet. Nach dem Empfang der Ergebnisse werden die Daten serialisiert, die Verbindung zur Datenbank wird geschlossen. Auf der Serverseite als AMF-Gateway wird WebORB eingesetzt. • Modell – In dieser Schicht werden alle Datenobjekte gehalten. Der Client kommu- niziert nicht direkt mit der Datenbank, sondern über die Steuerung, die die Daten für die Übertragung serialisiert. Auf der Datenbank können alle Daten vom Admi- nistrator manipuliert werden und nur einige vom normalen Benutzer. Die Überprü- fung der Rechte wird auf der Clientseite behandelt. Die Datenquelle für das Bildmaterial ist ein Web Server, auf dem die Dateien ab- gelegt sind. Es kann auch der gleiche Server sein, auf dem sich die Business Logik befindet. Das Frontend baut bei Bedarf eine Verbindung über HTTP und lädt die nötigen Dateien. Die Videodaten müssen sich auf einem Streaming-fähigen Server befinden. Dieser kann der Adobe-eigene Flash Media Server sein, oder aber auch die kostenlose Variante RED5 (siehe Kapitel 5.1.3). Da die Version 3.0.2 von WebORB auch diese Funktion unterstützt, wird dieses Programm in der vorgestellten Lösung nicht nur als AMF-Gateway dienen, sondern kann auch zum Streamen von Videos eingesetzt werden. Die beschriebenen Komponenten und ihre Aufgaben sind in der Abbildung 5.5 dargestellt.
Abbildung 5.5: Drei-Schichten-Architektur und Übertragungsprotokolle der eigenen Lösung. 50 5. KONZEPTION
5.3 Datenbank
Die Datenbank hat die Aufgabe Informationen, die im Frontend gezeigt werden, persistent zu halten. Ein Objektdiagramm der Daten für die eigene Lösung ist in Abbildung 5.6 zu sehen. Nach Analyse der funktionalen Anforderungen der Anwendung wurde festgestellt, dass auf die Daten sowohl Lese- als auch Schreibzugriff ermöglicht werden soll. Außerdem ha- ben zwei Gruppen verschiedene Rechte auf die Operationen der Datenbank – ein normaler Nutzer hat einen lesenden Zugriff auf alle Daten und einen schreibenden nur wenn er sich anmeldet, also in der Tabelle Account existiert. Nachdem der Nutzer einmal registriert ist, darf er eigene Konfigurationen in der Tabelle Configuration persistent speichern. Beim erneuerten Besuch des Konfigurators kann der Nutzer seine gespeicherte Konfiguration laden und weiter damit arbeiten. Ein Administrator kann neue Datensätze hinzufügen, existierende Daten lesen, aktualisieren oder löschen. Die Zugriffsrechte des Nutzers wer- den durch den Client überprüft.
Abbildung 5.6: Abstraktes Datenbankdiagramm in UML-Notation.
Das verfeinerte Design des Datenbankdiagramms ist in der Abbildung 5.7 veranschau- licht. Zwischen den Objekten, die eine Viele-zu-Viele-Beziehung haben (beispielsweise Model - Part), wird eine neue Tabelle hinzugefügt (Model_Part), die auf die je- weiligen Entitäten mit einem Fremdschlüssel verweist (Code_Part und Name_Model). Zusätzlich wurden die Tabellen Onlywith_Option und Conflict_Option, die auf die Tabelle Options verweisen, hinzugefügt, um Zusammenhänge von Optionen zu repräsentieren. Neu ist auch die Tabelle Recommender_Color, die zwei passende Far- 5.3. DATENBANK 51 ben enthält. Die Tabelle Color hat einen Verweis auf sich selbst. Auf dieser Weise wird eine zweifarbige Farbgebung repräsentiert. Alle Namen der Tabellen sind im Singular mit Ausnahme von Options, da Option ein reserviertes Wort der in der Implementierungsphase benutzen Datenbank ist (siehe Kapi- tel 6.1). Der Autokonfigurator wird auf einer Web-Seite mit internationalem Zugriff präsentiert. Eine Möglichkeit zur Internationalisierung auf Datenbankebene wird nicht implementiert, aber kurz erläutert. Nur einige Tabellen enthalten Informationen, die dem Benutzer prä- sentiert werden und deren Namen sich in anderen Sprachen ändern. Diese sind Model, Options, Area, Material_Group, Material und Color. Alle anderen Tabellen werden für den internen Gebrauch benutzt. Zur Veranschaulichung der Vorgehensweise bei der Internationalisierung wird die Tabelle Material herangezogen. Diese wird nur ein Feld enthalten – den Primärschlüssel ID. Eine neue Tabelle, z.B. mit dem Namen Language, enthält zwei Felder – ID der Sprache und Name der Sprache. Primärschlüssel dieser Tabelle ist die ID. Eine weitere Tabelle, z.B. Model_Language_Attribute, verbindet die beiden Entitäten mittels Fremdschlüs- sel – ID_Language verweist auf die Sprache und ID_Model hat eine Referenz aufs Modell. Ein weiteres Feld dieser Verknüpfungstabelle ist der Name des Materials. Es ist der gleiche Ansatz wie bei einer Viele-zu-Viele-Beziehung mit der Besonderheit, dass die Tabelle, deren Felder übersetzt werden sollen, nur eine ID enthält. Alle anderen Attribute werden in der dazwischengeschalteten Tabelle gehalten. 52 5. KONZEPTION
Abbildung 5.7: Datenbankdiagramm mit Primär- und Fremdschlüssel-Beziehungen. 5.4. SERVER 53
5.4 Server
Die Business Services, die sich auf dem Server befinden, haben zwei Aufgaben – die An- fragen des Clients zu deserialisieren und die Daten der Datenbank zu manipulieren. Diese Services sind nur für CRUD-Operationen gedacht, sie enthalten keine zusätzliche Logik. Die Sessions eines Nutzers werden auf der Clientseite gehalten, auch seine Zugriffsrechte werden im Frontend überprüft. Auf der Serverseite wird das AMF-Gateway von WebORB genutzt. Dieses Gateway bietet auch ein Tool zur Entwicklung der Service-Logik aus einer vorhandenen Datenbank. In dieser Arbeit wird mit dem Tool zur Generierung des Codes für die Serverseite gearbeitet, deshalb wird hier die Funktion der erzeugten Services vorgestellt. Abbildung 5.8 zeigt ein abstraktes Schema der Serverobjekte und ihre Funktionen. Zwei Entwurfsmuster [SM02a] sind grundlegend für die Logik: das Datentransferobjekt (Value Object, VO) und das Datenzugriffsobjekt (Data Access Object, DAO).
Abbildung 5.8: Das Datenzugriffs- und Datentransferobjekt-Muster in einer Rich Internet Application.
Das Datenzugriffsobjekt kapselt die Mechanismen für die Arbeit mit der Datenbank und isoliert diese völlig von seinem Client, dem Service. Das Interface des Datenzugriffsob- jekts ändert sich nicht, wenn die Implementierung des Datenzugriffs oder die Quelle (die Datenbank) sich ändert. Das DAO ist eine Art Adapter zwischen dem Service und der Datenquelle und versteckt die eigentlichen technischen Details vor dem Client. In die- ser Lösung wird die Verbindung zur Datenbank mittels JDBC realisiert. Mit dem Einsatz des Datenzugriffsobjekts wird die Migration zu anderen Datenbanken erleichtert und der Datenzugriff in einer eigenen Schicht definiert. Das Datentransferobjekt wird für die Kapselung der Daten in einem Objekt für den Trans- fer eingesetzt. Somit können mehrere Informationen durch einen einzigen Programm- aufruf übertragen werden. Sonst wäre für jedes Attribut eines Objektes ein entfernter Aufruf nötig. Das Datentransferobjekt wird sowohl für die Übertragung zum Client als auch zurück zum Server benutzt. Im zweiten Fall erfolgt das, wenn eine Operation zum 54 5. KONZEPTION
Erzeugen, Ändern oder Löschen eines Datenbankeintrags aufgerufen wird. So wird das ActionScript-Objekt, welches im Frontend manipuliert wird, zum Server gesendet. Vom Gateway wird das ActionScript-Objekt in ein Java-Objekt umgewandelt und vom Daten- zugriffsobjekt weiter bearbeitet. Beim Erzeugen oder Ändern wird das neue oder verän- derte Objekt zurück zum Client gesendet. Vorher wird es vom Gateway wieder in ein ActionScript-Objekt transformiert. Der Vorteil bei der Nutzung dieses Musters ist die Re- duktion des Netzwerktraffics. Abbildung 5.8 zeigt den Einsatz der zwei Entwurfsmuster in einer RIA-Umgebung. Im konkreten Fall mit WebORB für Java wird weborb.ActiveRecord aufgerufen. Das ist das entfernte Objekt auf dem Server. Diese Komponente erzeugt ein Datenzu- griffsobjekt, das ClassNameDataMaper, wobei ClassName der Name des Objektes ist, welches gemappt wird. Das Datenzugriffsobjekt liest die Daten von einer bestimmten Ta- belle der Datenbank aus. Mit diesen Informationen definiert das DataMaper-Objekt dann ein Datentransferobjekt mit dem Namen der ausgelesenen Tabelle – ClassNameVO. Nun wird dieses Transferobjekt zum Client übertragen. Abbildung 5.9 zeigt die Struktur der Komponenten auf der Serverseite im WebORB und ihre Namen.
Abbildung 5.9: Das Datenzugriffs- und Datentransferobjekt-Muster mit WebORB für Java.
Für jedes Datentransferobjekt muss ein gleichnamiges Objekt mit der gleichen Struktur auf der Clientseite definiert sein (siehe Kapitel 3.2). Auf dieses Objekt wird das Server- objekt gemappt.
5.5 Frontend
Das Frontend des Konfigurators hat zwei Ansichten: eine für den Benutzer, der mit dem Konfigurator ein Produkt konfiguriert, und eine für den Administrator, der Daten in der Datenbank manipuliert. Wenn der Konfigurator gestartet wird, soll die Ansicht zum Kon- figurieren erscheinen. Die schematische Darstellung des Interfaces ist der Abbildung 5.10 5.5. FRONTEND 55 zu entnehmen. Den größten Teil der Benutzeroberfläche des Konfigurators nimmt die Anzeige des Autos ein. Es ist eine vorgefertigte Komponente in ActionScript 3.0, die über ihre Schnittstelle vom Flex Builder angesprochen wird. Für den Wagen sind verschiedene Ansichten defi- niert und zwischen diesen kann mit den Buttons, die oberhalb der Bildfläche positioniert sind, gewechselt werden. Die genaue Funktion des Konfigurators und die angebotenen Ansichten wurden in 4.1 erklärt.
Abbildung 5.10: Frontend Benutzer.
Die Ansicht des Administrators wird vom Benutzeransicht über einen Button in der obe- ren rechten Ecke erreicht. Dieser Nutzer kann die Daten in der Datenbank manipulieren. Sein Interface ist in Abbildung 5.11 dargestellt.
Abbildung 5.11: Frontend Administrator. 56 5. KONZEPTION
Der Aufbau der Anwendung ist in vier Paketen aufgeteilt, die in Abbildung 5.12 zu sehen sind. Die Funktion der Pakete ist wie folgt definiert:
• Controls – In diesem Paket befinden sich alle MXML-Komponenten, die das Be- nutzerinterface gestalten und Funktionen zur Bearbeitung von Ereignissen haben. Im Flex-Builder wird ein Interface aus MXML-Elementen aufgebaut, die ihrerseits Container für weitere Elemente sind. Beispielsweise enthält ein TabNavigator meh- rere Registerkarten. Die Tabs sind aus horizontalen und vertikalen Boxen, Data- Grids und Buttons aufgebaut. Auf dieser Weise werden mehrere Elemente ineinan- der verschachtelt. Das Login-Paket enthält die Ansichten für das Login und, im Falle eines neuen Nut- zers, für die Registrierung. Im Ordner Administrator sind die Komponenten zum Hinzufügen, Bearbeiten oder Löschen von bestehenden Datensätze der Datenbank zu finden. Das Paket ConfigurationList enthält den Quellcode für den Bereich der Liste mit den ausgewählten Optionen für einen Wagen. Die Registerkarten im Kon- figurator sind in einem Ordner unter dem Namen ConfigTabNavigator zusammen- gestellt. Jeder Tab wird zusätzlich in einem einzelnen Paket gespeichert, da auch noch die UI-Elemente dazukommen, aus denen der Inhalt eines Tabs aufgebaut ist. • Events – Es werden mehrere eigene Events definiert. Auf dieser Weise kann nicht nur ein Ereignis ausgelöst werden, sondern auch Daten mit diesem übertragen wer- den. Beispielsweise soll bei der Auswahl eines bestimmten Modells dieses an die Hauptdatei übergeben, damit im nächsten Schritt die Informationen für diesen Wa- gen geladen werden können. Auf diesen Ablauf wird in Kapitel 6.5 eingegangen. In jeder Registerkarte werden Ereignisse ausgelöst und nach diesen Tabs sind die Events in Ordnern zusammengestellt. • Vo – In diesem Paket befinden sich alle Datentransferobjekte auf Clientseite. • Rtt – Die zur Verfügung gestellte Komponente zur Visualisierung des Wagens ist im Paket rtt zu finden. Im Ordner loader befindet sich die Loader-Klasse, deren Aufgabe das Laden von ZIP-Dateien ist. Im states-Ordner sind alle Zustände der Komponente gespeichert. Im util ist eine Sorter-Klasse definiert, die alle in der ZIP- Datei enthaltenen Dateien nach Anzeige-Ebenen sortiert. Dies erfolgt nach dem Dateinamen, welcher nach dem Laden zur Verfügung steht. Auch ein XML-Loader und -Handler sind in diesem Ordner zu finden. Der Ordner visual enthält die Logik der visuellen Anzeige des Wagens und bietet eine API, über die die Komponente angesprochen werden kann. Bis jetzt wurde auf die Struktur der Anwendung eingegangen und wie die Datenobjekte und Bilddaten visualisiert werden. Die Ansicht und das Anbinden der Videodaten wird im Frontend nicht betrachtet. Wie die Daten in die Anwendung geladen werden, wird zunächst erläutert. Die Bilddaten des Autos werden in einer ZIP-Datei gehalten. Für jede der drei Regi- sterkarten Exterieur, Interieur und Individualisierung gibt es jeweils ein ZIP-File. Dazu kommen noch die Ansichten für die Umgebung. Im ZIP-Ordner befinden sich außerdem die Daten, die bei der Auswahl einer Option auf den Wagen angezeigt werden sollen. Um die Wartezeit des Benutzers und die Abfragen zum Server zu minimieren, werden alle Da- ten, die zu einer Registerkarte gehören, in einem Paket gespeichert. So wird das gesamte Datenvolumen mit einem Mal übertragen und bei der Auswahl einer Option werden nun 5.6. ZUSAMMENFASSUNG 57 die Daten aus dem Browser-Cache geholt. Die Datenobjekte, die in der Datenbank gespeichert sind, werden asynchron je nach Be- darf aufgerufen. Beispielsweise werden bei der Initialisierung der Anwendung nur die Informationen aus der Tabelle Series übertragen. Nach Auswahl einer Serie werden die Daten über die Modelle geladen. Nachdem ein bestimmtes Modell ausgewählt wird, werden zum Einen aus der Datenbank die Datensätze zu den Optionen dieses Wagens gefordert, zum Anderen wird eine Verbindung zur Web-Adresse aufgebaut, wo sich die ZIP-Datei mit dem Bildmaterial zu diesem Auto befindet und über HTTP geladen. Die Session des Clients – die Sicht des Autos und die ausgewählten Optionen der Re- gisterkarten, wird im Frontend gehalten. Die Komponente zum Anzeigen des Wagens ist mit dem Zustand-Entwurfsmuster [GHJV05] implementiert und weiß zu jeder Zeit in welchem Zustand sich ihre Ansicht befindet. Die ausgewählten Optionen in einer Regi- sterkarte z.B. werden von dieser Komponente selbst gehalten. Das erledigt Flex-Builder selbst und muss nicht zusätzlich implementiert werden.
Abbildung 5.12: Pakete, die das Frontend aufbauen.
5.6 Zusammenfassung
In diesem Kapitel wurde die Konzeption der eigenen Lösung vorgestellt. Ausgegangen von der AMF-Technologie für die Kommunikation zwischen Client und Server wurden die existierenden Gateways für Java nach bestimmten Kriterien analysiert und bewertet. Nach der Auswahl des Tools WebORB für Java, welches auch Code für den Server und 58 5. KONZEPTION
Client generieren kann, wurde die Drei-Schichten-Architektur der Anwendung und die Rollen der einzelnen Komponenten vorgestellt. Darauf aufbauend sind die Datenbank, die serverseitige Logik und das Frontend konzipiert worden. Im nächsten Kapitel wird auf die Implementierung eingegangen. 59
6 Implementierung
Im vorangegangenen Kapitel 5 wurde die Architektur der Anwendung vorgestellt. Die einzelnen Bestandteile des Konfigurators, Datenbank, Server und Frontend wurden kon- zipiert. In diesem Kapitel wird die Implementierung der eigenen Lösung präsentiert. Zu- erst wird die Herangehensweise bei der Datenbank erläutert (Kapitel 6.1). Es folgt die Implementierung der Serverseite mit WebORB für Java (Kapitel 6.2). Zum Schluss wird auf den Code der Clientseite eingegangen (Kapitel 6.3).
6.1 Datenbank
Für die Implementierung wird die Datenbank Oracle Database 10g Express Edition (XE) [Cor09h] eingesetzt, weil sie im Gegensatz zur kommerziellen Version nur 1 GB RAM benötigt. Oracle XE ist eine auf 4GB Nutzerdaten beschränkte, vereinfachte und kosten- lose Version der Oracle Database 10g Release 2 [Ora09a] und bietet ein Browser-basiertes Datenbank-Frontend, in dem neue Nutzer erzeugt und Rechte vergeben werden können. Als grafisches Frontend für das Anlegen und Bearbeiten von Tabellen und Indices wird SQL Developer [Ora09b], ein kostenloses Entwicklungswerkzeug von Oracle, benutzt. Oracle XE ist für prototypische Implementierung gedacht, hat eine einfache Installation, braucht wenig Speicher-Kapazität im Vergleich zu den vollständigen Versionen einer Da- tenbank und hat ein gutes Tool wie SQL Developer für die Entwicklung. So konnte die in der Konzeptionsphase erarbeitete Struktur der Datenbank schnell überprüft werden. Im Konfigurator gibt es drei Datentypen – Zeichenketten für IDs, Namen und Beschrei- bungen, natürliche Zahlen für Bezeichnungen und Preise, und Gleitkommazahlen für Farbton, Sättigung und Helligkeit einer Farbe. Diese Daten werden wie folgt implemen- tiert:
• Zeichenketten – Eine Folge von Zeichen wird als VARCHAR2(n), ein String va- riabler Länge, implementiert, wobei n die maximale Länge der Zeichen angibt. VARCHAR2 ist ein Oracle-Format, in SQL wird der entsprechende Datentyp VAR- CHAR genannt. • Natürliche Zahlen – Zahlen werden im NUMBER-Format gespeichert. • Gleitkommazahlen – Eine Besonderheit sind die Attribute der Color-Tabelle, die auch negative Gleitkommazahlen enthalten. In Oracle können positive und ne- gative Gleitkommazahlen im NUMBER-Datenformat mit Präzision gespeichert wer- den. Bei der Erzeugung des serverseitigen Codes mit WebORB kam es zum Feh- ler bei der Typumwandlung dieses Datenformats nach Java. Eine Lösung war das BINARY_FLOAT, was eine von Oracle angebotene Variante zum FLOAT nach dem IEEE 754 Standard für Gleitkommazahlen [ANS85] ist. Bei der Auswahl dieses 60 6. IMPLEMENTIERUNG
Formats kam es auf der Clientseite zum Unterlauf-Problem 1. Die Zahlen wurden nicht genau und mit wiederholten Dezimal stellen präsentiert. Der Ausweg war die Werte für die Farben im VARCHAR2-Format zu speichern. Auf der Clientseite werden die Zeichenketten dann in Numbers bei der Benutzung umgewandelt und korrekt dargestellt. Abbildung 6.1 zeigt einen Teil des Quellcodes der Datenbank in SQL. Um Inkonsisten- zen der Daten zu vermeiden wurden für jeden Fremdschlüssel Regeln angegeben, wie abhängige Daten beim Löschen behandelt werden sollen. In Zeile 11 wird die Regel ON DELETE CASCADE definiert, mit der durch Kaskadierung beim Löschen einer Serie alle abhängigen Modelle gelöscht werden. In Zeile 20 wird der Wert des Fremdschlüssels auf NULL mit ON DELETE SET NULL gesetzt, wenn ein Area gelöscht wird. Der Eintrag in der Tabelle Part bleibt erhalten. Es wurden auch für alle Tabellen, deren Primär- schlüssel aus zwei Fremdschlüsseln bestehen, ein Datenbankindex zur Beschleunigung der Datensuche erstellt.
Abbildung 6.1: SQL-Quellcode für die Erstellung der Tabellen Series, Model und Part.
Wenn alle Änderungen in der Datenbank beendet sind, muss eine Bestätigung der Trans- aktion mittels COMMIT erfolgen. Zwar zeigt SQL Developer alle Datensätze in den Tabel- len, diese sind aber nicht festgeschrieben und in diesem Moment erfolgt ein „dirty read“. Falls kein COMMIT aufgerufen wird, fehlen die Änderungen, wenn SQL Developer neu gestartet wird.
6.2 Server
Die serverseitige Logik wird mit dem Tool WebORB für Java generiert. Es wird mit der Developer-Version 3.0 gearbeitet (siehe Kapitel 5.1.4). Abbildung 6.2 zeigt die nötigen Daten beim Anbinden einer Datenbank, welche als Datenquelle für das Entwicklungs- werkzeug dient. Es wird nach dem Typ des Servers, seiner Adresse und dem Port gefragt.
1Englisch: gradual underflow 6.2. SERVER 61
Des Weiteren werden auch ein Benutzername und Kennwort des Datenbanknutzers sowie im Fall von Oracle zusätzlich die Oracle System ID (SID), die eine Datenbank auf einem System identifiziert, gefordert. Im nächsten Schritt wird das Datenbankschema ausge- wählt. Bei der Arbeit mit WebORB wurde festgestellt, dass in Oracle XE nur ein Da- tenbankschema existiert und kein weiteres erzeugt werden kann. Jeder Nutzer legt seine Tabellen innerhalb dieses Schemas an. So kommt im WebORB nur das Standardschema von Oracle XE zur Auswahl.
Abbildung 6.2: Geforderte Informationen bei der Datenbankverbindung des Tools Web- ORB für Java.
Nachdem die Datenbank erfolgreich ausgewählt und importiert worden ist, sind alle ent- haltenen Tabellen sichtbar. Abbildung 6.3 zeigt die Datenmanagement-Ansicht von WebORB für Java. In der linken unteren Ecke befinden sich die Namen der importierten Datenbankschemata, wobei „xe“ ausgewählt ist. Im Fenster Table Data Preview unten rechts kann die Struktur der einzelnen Tabellen sowie der darin gespeicherten Daten ein- gesehen werden. Wenn mit Oracle und SQL Developer gearbeitet wird, muss ein COMMIT der Daten vor dem Anzeigen im WebORB erfolgen. Andernfalls werden die Datensätze nicht angezeigt, da sie noch nicht in der Datenbank persistent geschrieben sind. Für das Erstellen des Codes wird zunächst ein Datenmodell, in dieser Lösung mit dem Namen „demoConfigurator“, erzeugt. Es werden auch die Namensräume der Server- und Clientseite definiert. Dem Datenmodell können bestimmte oder alle Tabellen eines Sche- mas hinzugefügt werden. Nun werden diese Tabellen im oberen rechten Teil des Datenmanagement-Fensters angezeigt (siehe Abbildung 6.3). Wenn eine Tabelle ausge- wählt wird, werden die Daten für das Mapping angezeigt. Abbildung 6.4 zeigt den Na- men der Tabelle in der Datenbank Model_Part und des Java-Objektes ModelPart. Auch die Spalten einer Tabelle sind in diesem Fenster zu sehen. Namen der Datenbank, die einen Bindestrich enthalten, werden in Java mit großer Buchstabe nach dem Binde- strich dargestellt. Die Eins-zu-Viele-Beziehung wird auch angezeigt. In dieser Beziehung wird als „Parent“ eine Entität bezeichnet, die viele „Child“-Entitäten enthält. Z.B. hat ei- ne Serie mehrere Modelle, so ist die „Parent“-Entität die Serie und die „Child“-Entität das Modell. Im Fall der Tabelle Model_Part sind die „Parents“ die Tabellen Model und Part. Mit diesen Beziehungen können auf der Clientseite per Variablennamen wie RelatedModel und RelatedPart die „Parent“-Entitäten aufgerufen werden. Auch für die „Child“-Entitäten werden solche Variablen definiert. 62 6. IMPLEMENTIERUNG
Abbildung 6.3: Datenmanagement-Ansicht von WebORB für Java.
Abbildung 6.4: Mapping der Tabelle Model_Part auf Java-Objekt ModelPart und Fremdschlüsselbezihungen.
Nachdem alle Tabellen und Beziehungen überprüft werden, kann der Quellcode automa- tisch aus den vorhandenen Informationen generiert werden. Die erstellten Dateien be- finden sich in zwei Ordner – dem übergeordneten mit dem vorgegebenen Namespace „de.configServer“ und dem darin enthaltenen Ordner „codegen“. Im „de.configServer“ befinden sich Transfer- und Datenzugriffsobjekte (siehe Kapitel 5.4), die mit dem Ent- wurfsmuster Fassade [GHJV05] als abstrakte Klassen implementiert sind. Sie bieten eine einheitliche Schnittstelle zur tatsächlichen Implementierung im Ordner „codegen“. Zu- sätzlich gibt es noch eine Konfigurationsdatei für den JDBC-Driver mit der Adresse der Datenbank und eine Klasse, die die Verbindung zur Datenbank sowie die Erzeugung der Transfer- und Datenzugriffsobjekte implementiert. Ein Ausschnitt dieser Klasse mit dem Namen XeDb ist in Listing 6.1 zu sehen. 6.2. SERVER 63
Listing 6.1: Ausschnitt der Klasse XeDb.java, die Datenzugriffs- und Datentransferobjek- te erzeugt.
1 package de.configServer; 2 3 import weborb.data.management.*; 4 5 public class XeDb extends Database { 6 7 public XeDb() throws Exception 8 { 9 InitConnectionString( "xe" ); 10 } 11 //... 12 public Account create(Account account) throws Exception 13 { 14 AccountDataMapper dataMapper = new AccountDataMapper((Database)this); 15 16 return (Account)dataMapper.create(account); 17 } 18 19 public Account update(Account account) throws Exception 20 { 21 AccountDataMapper dataMapper = new AccountDataMapper((Database)this); 22 23 return (Account)dataMapper.update(account); 24 } 25 26 public Account remove(Account account, boolean cascade) throws Exception 27 { 28 AccountDataMapper dataMapper = new AccountDataMapper((Database)this); 29 30 return (Account)dataMapper.remove(account, cascade); 31 } 32 //... 33 }
Nachdem der Client eine Methode des RemoteObjects weborb.ActiveRecord auf- ruft, dessen Code nicht eingesehen werden kann, wird eine Instanz der Klasse XeDb.java erstellt. In Zeile 1 der Klasse XeDb.java ist der Namensraum definiert, der bei der Er- stellung des Datenmodells bestimmt worden ist. Des Weiteren werden mehrere Klassen importiert, die das Datenmanagement in WebORB regeln. Da es sich bei WebORB um ein Produkt und kein Open-Source-Projekt handelt, gibt es weder eine API noch Möglichkeit die Implementierung dieser Komponenten zu sehen. Nach dem Konstruktor (Zeile 7-10) folgen drei Methoden – create (Zeile 12), die eine neue Instanz von Account er- zeugt, update (Zeile 19), die ein Account erneuert und remove (Zeile 26), die ein Account löscht. Es ist zu beachten, dass jede dieser Methoden als Eingabeparameter ein Objekt vom Typ Account hat. Es handelt sich um das Datentransferobjekt, welches die nötigen Attribute des Objektes der Clientseite transferiert hat. Vom Gateway selbst wird das ActionScript-Objekt in ein Java-Objekt umgewandelt (siehe Kapitel 5.1.4). In jeder dieser drei Methoden wird zuerst die Klasse AccountDataMapper aufgerufen (Zeile 14), die ein Datenzugriffsobjekt auf die Datenbank darstellt. Das Datenzugriffsobjekt er- zeugt nun ein neues Datentransferobjekt mit dem Namen Account (Zeile 16), welches dem Client zurückgesendet wird. Die Zusammenhänge zwischen Datenzugriffs- und Da- tentransferobjekt wurden in Kapitel 5.4 erläutert. In der Klasse XeDb.java sind für alle Tabellen der Datenbank die drei Methoden create, update und remove definiert. Der Zugriff auf die Datenbankobjkete wird mittels _ClassNameDataMapper.java ausge- führt, ClassName steht dabei für den Namen des Datentransferobjektes. Listing 6.2 zeigt einen Ausschnitt der Klasse _AccountDataMapper.java. In Zeile 11 ist der Konstruk- 64 6. IMPLEMENTIERUNG
tor, der von der Klasse XeDb.java mit der aktuellen Datenbank als Parameter aufgerufen wird. In den Zeilen 16-19 wird ein Exemplar der Klasse Account zurückgegeben. Die Methode in Zeile 21-24 gibt den Namen der Tabelle, von der das Datentransferobjekt die Information liest. Mit der nächsten Funktion (Zeile 27-36) wird ein SQL-Statement zum Hinzufügen einer Datenzeile in der Datenbank definiert. In Zeile 39 befindet sich die Methode create, die neue Datentransferobjekte erzeugt.
Listing 6.2: Die Datenzugriffsklasse _AccountDataMapper.java.
1 2 package de.configServer.codegen; 3 4 public abstract class _AccountDataMapper extends DataMapper 5 { 6 public _AccountDataMapper() throws Exception 7 { 8 super( new XeDb() ); 9 } 10 11 public _AccountDataMapper( Database database ) throws Exception 12 { 13 super( database ); 14 } 15 16 public Class getDomainObjectClass() 17 { 18 return Account.class; 19 } 20 21 public String getTableName() 22 { 23 return "\"ACCOUNT\""; 24 } 25 //... 26 27 private final String SqlCreate = "Insert Into \"ACCOUNT\" ( " 28 + " \"ID\"," 29 30 + " \"LOGIN\"," 31 32 + " \"PSW\"," 33 34 + " \"ADMIN\"" 35 36 + " ) Values ( "+ " ?, "+ " ?, "+ " ?, "+ " ? "+ " ) "; 37 38 public DomainObject create( DomainObject arg ) throws Exception 39 { 40 Account account = (Account) arg; 41 return createTyped( account ); 42 } 43 //... 44 }
Mit WebORB für Java kann auch clientseitiger Code generiert werden, der als Test für die Funktionalität auf dem Server dient. Insgesamt wurden ca. 24 000 Zeilen Code erzeugt. Nach der Erstellung der serverseitigen Logik wird die erstellte Komponente in Form einer JAR-Datei auf dem Server aufgespielt und steht zur Nutzung bereit. 6.3. FRONTEND 65
6.3 Frontend
Das Frontend wird mit dem Flex Builder Version 3.0.2 entwickelt und für die Version 9.0.124 des Flash Players veröffentlicht. Wenn der Konfigurator gestartet wird, werden zunächst die Daten für das Interface asynchron vom Server aufgerufen. Für jedes Ob- jekt wird ein Aufruf erzeugt und nachdem sich die Daten auf dem Client befinden, wer- den sie im Interface angezeigt. Diese Daten sind z.B. die Optionen der Registerkarten und der Preis des Wagens. Kleine Bilder wie die Abbildungen der jeweiligen Farbe oder Button-Assets werden in der Flex-Anwendung selbst gehalten. Das Frontend wird im Flex-Builder 3.0 implementiert Wie der asynchrone Aufruf von Datenobjekte funktioniert, wird in Listing 6.3 darge- stellt. Die Variable _seriesData vom Typ ArrayCollection wird definiert (Zeile 7) und der Tag [Bindable] wird hinzugefügt (Zeile 6). Dieser Tag signalisiert Flex, dass der Wert immer dorthin kopiert werden soll, wo die Variable _seriesData be- nutzt wird. Die Komponente, welche so eine Variable nutzt, muss diese in geschweiften Klammern setzten (Zeile 25). Auf dieser Weise wird immer der aktuelle Wert angezeigt und es bedarf beispielsweise keines Beobachters [GHJV05], der die Änderung des Wer- tes signalisiert. Die Funktion onCreationComplete (Zeile 9) wird dann aufgerufen, wenn die Komponente, in der sich diese Funktion befindet, aufgerufen wird. Der Varia- ble _seriesData wird ein Ereignis-Listener hinzugefügt (Zeile 12), der seine innere Funktion ausführt (Zeile 13), sobald die Information vom Server geladen ist. Der Daten- typ DynamicLoadEvent ist ein WebORB-eigner Typ. Wenn die Daten verfügbar sind können sie direkt beispielsweise im DataGrid angezeigt werden (Zeile 25) oder in ande- ren Flex-Komponenten, die ArrayCollection als Datenprovider unterstützen. Eine zweite Variante ist das sequentielle Auslesen der Daten in einer Schleife (Zeile 16-19), da die Informationen im Event übertragen und mittels event.data verfügbar sind (Zeile 14).
Listing 6.3: Asynchroner Aufruf der Daten aus der Tabelle Serie.
1
In Zeile 10 erfolgt der entfernte Aufruf zum Server mittels ActiveRecord. Es ist das RemoteObject, welches serverseitige Methoden aufruft (siehe Kapitel 3.2). Für ein Da- tentransferobjekt stehen einige Methoden zur Verfügung, unter Anderem findByPrimaryKey(name:String), findBySql(sqlQuery:String,...parameters) oder findFirst() und findLast(), die den ersten und letzten Eintrag einer bestimmten Tabelle liefern. Außerdem besteht es die Möglichkeit dynamische Methoden zu erstellen. Beispielsweise kann ein Account mit dem Befehl ActiveRecords.Account.findByLoginAndPsw(login:String, psw:String) überprüft werden. Login und Psw sind die Namen der Spalten der Ta- belle Account. Es ist zu beachten, dass wenn z.B. Bindestriche in den Namen der Da- tenbankelemente benutzt werden, müssen diese auf diese Art geschrieben werden und nicht die in Java transformierten Namen. Als Ergebnis wird das Objekt des existierenden Accounts kommen oder null, falls die Daten nicht existieren oder nicht korrekt sind. WebORB für Java generiert auch Test-Code für den Client, mit dem die Funktionalität der serverseitigen Dienste überprüft werden kann. Der erstellte Ordner heißt „UI“. Die- ser Code wird in der Administrator-Ansicht eingesetzt. Von WebORB wird auch eine Bibliothek-Komponente namens weborb.swc erstellt, die nötige Dateien hält. Deren In- halt kann jedoch nicht eingesehen werden. Der Versuch die Namespaces der generierten Komponenten zu ändern war erfolglos, da die Bibliothek weborb.swc Verweise auf die er- stellten Klassen hatte. So befindet sich die Ansicht für den Administrator nicht im Paket de.controls.admin wie geplant, sondern unter UI.TestDrive. Wie die Datenobjekte in der Anwendung genutzt und weitergeleitet sowie auf Ereignisse reagieren, wird in Abbildung 6.5 gezeigt. Es wird ein Teil des Konfigurators vereinfacht dargestellt, in dem ein Modell ausgewählt wird. Die einzelnen Schritten der Ausbreitung der Daten hat folgenden Ablauf:
1. Die Anwendung ruft Daten von der Datenbank mittels ActiveRecords.Models.findAll(); ab. Zu jedem Modell wird der Na- me, der Preis sowie die Leistung aus der Datenbank gelesen. 2. Das Ergebnis kommt in Form eines ArrayCollections, in dem sich die Model- Objekte befinden, zurück. Diese Objekte enthalten die in Punkt 2 genannten Infor- mationen. 3. Die Variable _modelList wird an der Komponente TabContentModel ange- bunden. Diese Komponente hat als Schnittstelle modelList definiert. Mit modelList werden die Getter- und Setter-Funktionen 2 einer privaten Variable benannt. 4. Im TabContentModel wird die Liste mit den Modellen an die nächste benut- zerdefinierte Komponente ModelList über die Schnittstelle modelListData übergeben. 5. ModelList enthält die Flex-Komponente DataGrid, welche die Daten in Form einer Liste anzeigt. An dieser Stelle wird auch ein Listener definiert, der auf das Ereignis itemClick reagiert. Dieses Event wird ausgelöst, wenn ein Element aus
2In ActionScript 3.0 werden die Getter- und Setter-Funktionen mittels get modelList():Typ und set modelList(t:Typ) definiert. 6.3. FRONTEND 67
Abbildung 6.5: Bearbeitung der Datenobjekte in Flex.
der Liste mit den verfügbaren Modellen ausgewählt wird. Die Funktion clickEventHandler, die in Listing 6.4 zu sehen ist, wird aufgerufen. 6. Die Funktion clickEventHandler ist vom Typ ListEvent. Das ausgewähl- te Modell kann mittels event.itemRenderer.data ausgelesen werden (Zei- le 4). Es wird eine Instanz der benutzerdefinierten Klasse ModelChosenEvent erzeugt (Zeile 5-6). Nun wird das Datentransferobjekt Model mit dem Ereignis propagiert (Zeile 7). Der String “modelChosen“ der eigenen Event-Klasse definiert den Namen des Events, für den ein Listener definiert werden soll. 7. Das Event-Objekt wird in der Anwendung propagiert. Es können sich ein oder meh- rere Listener in verschiedenen Komponenten für dieses Ereignis mittels addEventListener(“modelChosen“, modelChosenHandler) registrieren. 8. Die Hauptdatei der Anwendung hat einen Listener für das Ereignis definiert, wenn ein Modell ausgewählt wird. Die Funktion modelChosenHandler hat als Ein- 68 6. IMPLEMENTIERUNG
gabeparameter ein Event vom Typ ModelChosenEvent, dem benutzerdefinier- ten Event. In dieser Funktion wird die nächste Registerkarte mittels configurationTabNavigator ausgewählt, da alle Tabs in dieser Kompo- nente verschachtelt sind. Die Variable selectedModel liest den Wert des Trans- ferobjektes mittels event.model aus und wird danach an eine weitere benutzer- definierte Komponente übergeben, was hier nicht mehr angezeigt wird. Listing 6.4: Die Funktion clickEventHandler der benutzerdefinierten Komponente ModelList, die beim Auswählen eines Modells der DataGrid-Komponente aufgerufen wird. 1 2 private function clickEventHandler(event:ListEvent):void{ 3 var selectedItem:Model; 4 selectedItem = event.itemRenderer.data as Model; 5 var modelSelectEvent:ModelChosenEvent = 6 new ModelChosenEvent("modelChosen",selectedItem); 7 dispatchEvent(modelSelectEvent); 8 }
Nachdem das Modell ausgewählt worden ist, wird nun die ZIP-Datei für die Visualisie- rung des Wagens geladen. Parallel dazu werden die Farben aus der Datenbank und die Op- tionen zu dem Modell angefordert. Es finden insgesamt sechs Requests statt: einer für das Laden des ZIP-Files, einer für die Information der Assets (Anzeige-Ebenen, ob gefärbt wird oder nicht), einer für die Optionen des Wagens und drei für die verfügbaren Farb- gruppen, die nach MaterialGroup aufgeteilt sind. Nachdem alle Farben mit einem Aufruf ausgelesen werden, müssen sie im Frontend sortiert werden. Diese Sortierung wird in diesem Fall durch den Aufruf der Methode findById_MaterialGroup(..) auf dem Datentransferobjekt ActiveRecords.Color vorgenommen. Das Laden und das Anzeigen des Wagens nimmt ca. 7 Sekunden in Anspruch, so können zeitlich parallel da- zu drei Anfragen statt einer ausgeführt werden, da es nicht so wichtig ist wie schnell die Farben erscheinen. Optionen und Farben für die Konfiguration des Wagens können erst dann ausgewählt werden, wenn das Auto visualisiert wird.
6.4 Zusammenfassung
In diesem Kapitel wurden Teile der Implementierung des Konzeptes erläutert. Die Da- tenbank wurde in SQL für Oracle XE geschrieben, wobei mit kleinen Änderungen der Code für jede Datenbank benutzt werden kann. Die serverseitige Logik wurde mit der Developer-Edition Version 3.0 des Tools WebORB für Java generiert und auf dem Jet- ty Server aufgespielt, der als Container für das WebORB-Gateway dient. Dieses AMF- Gateway kann auch mit Tomcat eingesetzt werden. Das Frontend wurde im Flex-Builder 3.0 implementiert. Im nächsten Kapitel wird die vorgeschlagene Lösung bewertet. 69
7 Bewertung
In dieser Arbeit wurden die existierenden Technologien zur Datenübertragung vom Ser- ver zum Client in einer Rich Internet Application untersucht. Als Test-Szenario diente ein Konfigurationsprogramm für Autos, das drei Datentypen enthält: Datenobjekte, Bildma- terial und Videoclips. Die Anwendung sollte für einen Flash Player konzipiert sein, so wurde für die Entwicklung Flex Builder 3.0 benutzt. Von diesem Entwicklungswerkzeug ausgehend wurden die Varianten zur Kommunikation mit dem Server untersucht. Da- zu zählt die RPC-Kommunikation mittels HTTPService und RESTful Service, entfernte Methodenaufrufe mittels RemoteObject und Web Services. Es wurde die Dauer und die Größe der übertragenen Datenmengen analysiert und die Eignung der einzelnen Möglich- keiten für die Client-Server-Kommunikation bewertet. Dazu wurde auch der Transfer von Bildmaterial mit und ohne ZIP-Kompression evaluiert. Auch die Optionen zur Übertra- gung von Videodaten wurden betrachtet. Es wurde festgestellt, dass sich das binäre Format AMF am besten für den Transport von Datenobjekten eignet. Der Grund dafür war nicht nur das kleine Datenvolumen, sondern auch die Bearbeitungsgeschwindigkeit auf der Clientseite der empfangenen Informati- on. Für die Übertragung des Bildmaterials erzielte der Transfer von ZIP-komprimierten Dateien über HTTP bessere Ergebnisse als die Variante ohne Kompression. Videoclips lassen sich am besten streamen, da sie so nicht im Browser-Cache gespeichert werden. Anhand dieser Erkenntnisse wurde eine Architektur konzipiert, die einen Applikations- server für das Remote-Gateway und die Business Logik enthält. Die Aufgaben des Ga- teways sind die Informationen vom Client zu deserialisieren und diese auf Java-Objekte zu mappen. Wenn eine Antwort zum Frontend geschickt wird, erfolgt das Mapping auf ActionScript-Objekte und deren Serialisierung. Auf diesem Server befinden sich auch Dienste, die eine Verbindung zur Datenbank aufbauen und die Daten darin manipulie- ren. Für die Serverseite wurde das AMF-Gateway von WebORB für Java eingesetzt. Der Server-Container ist ein Jetty-Server. Das Programm lässt sich aber auch auf einem Tomcat Server ausführen. WebORB bietet auch gleichzeitig ein Tool zum Generieren der Business Logik an. Es sind Dienste, die CRUD-Operationen auf der Datenbank ermögli- chen. Auf dem Server befindet sich keine zusätzliche Logik wie beispielsweise Session- Haltung. Es werden nur Anfragen zur Datenbank und die Bearbeitung derer Ergebnisse ausgeführt. So ist eine Backend-Lösung entstanden, die auch von anderen Clients ange- sprochen werden kann. Bei der Nutzung von WebORB für Java kann auch ein Ajax-Client mit dem gleichen Backend kommunizieren. Das Tool WebORB generiert außerdem auch Code für das Frontend. In dieser Arbeit wurde der Code für die Administrator-Ansicht mit diesem Werkzeug erstellt. Das Bildmaterial befindet sich in ZIP-komprimierten Ordnern auf dem gleichen Applika- tionsserver wie das Remote-Gateway. Für die Leistungstests wurden die Daten auf dem Universitäts-Server der TU Dresden gespeichert damit die Messungen in einem realen Einsatz durchgeführt werden können. Auf der Clientseite wurde eine Klasse definiert, welche die ZIP-Files lädt und in einer bestimmten Form an die MXML-Komponenten 70 7. BEWERTUNG zur Anzeige weitergibt. Der Einsatz von Videodaten wurde nur konzipiert, aber nicht implementiert. Die Versi- on 3.0.2 von WebORB für Java unterstützt auch das Streamen von Videos über RTMP. So können sich auf dem gleichen Server die Business Logik, das Bildmaterial und die Videoclips befinden.
7.1 Leistungstest Szenario
Nachdem die Funktion des Systems betrachtet wurde, werden die Ergebnisse des Test- Szenarios aus Kapitel 4.2 vorgestellt. In der eigenen Lösung wird das Bildmaterial pro Registerkarte geladen (Exterieur, Interieur). Wenn der Nutzer beispielsweise von der Ex- terieur- in die Interieur-Ansicht wechselt, werden alle Daten, die für das Anzeigen bei der Auswahl einer Option nötig sind, geladen. Eine weitere Besonderheit ist, dass wenn eine andere Farbe ausgewählt wird, muss diese nicht neu vom Server geladen werden. Der Wagen wird mittels Filter neu gefärbt. Das gilt für Exterieur und Interieur. Der Flash Player cached die geladenen Dateien im Browser. So wird der Wechsel zu einer Ansicht, die schon einmal gezeigt worden ist, schneller erfolgen, weil die Informationen lokal vor- liegen und nicht noch mal vom Server geladen werden müssen. Die einzelnen Schritte beim Test-Szenario und die erzielten Werte sind der Tabelle 7.1 zu entnehmen. Bei der Messung der Daten wurde getrennt die Übertragungsdauer und die Datenmenge mit dem Tool Charles Proxy gemessen. Zusätzlich wurde die Übertragung und das Rendern des Bildmaterials im Frontend mittels eines Timers im Flex Builder ermittelt. Für alle Werte wurden jeweils fünf Messungen durchgeführt und daraus der Mittelwert gebildet. Man- che Schritte im Testprozess verwenden nur Daten für das Rendern, welche schon lokal vorliegen. Das sind A2, A5, A6 und A7. Beim Starten der Anwendung braucht das Laden und Anzeigen des Wagens im Durch- schnitt 6,87 Sekunden (A1). Beim existierenden Konfigurator liegt dieser Wert bei 40,31 Sekunden. Somit ist die Dauer bis zum Anzeigen des Wagens im Prototyp ca. 6 Mal schneller. Die Übertragung der Information (1,58 Sekunden) erfolgt ungefähr zwanzig Mal schneller als in der existierenden Anwendung (33,76 Sekunden). Das benötigte Bild- material hat ein kleineres Volumen. Es wurden aber Messungen in Kapitel 4.5.1 durchge- führt und anhand diesen in Kapitel 4.6 festgestellt, dass für die gleiche Datenmenge wie im existierenden Konfigurator (ca. 7 MB) mit der ZIP-komprimierten Übertragung ein Ertrag von ungefähr 56% erzielt werden kann. So bezieht sich die Reduzierung der Über- tragung nicht nur auf die Grösse der Datei, sondern auch auf die benutzte Technologie. Beim Wechseln von der Exterieur- in die Interieur-Ansicht erfolgt in 5,52 Sekunden. In der existierenden Anwendung ist dieser Wert 13,04. Somit wurde ein Ertrag von ungefähr 55% erzielt. Interessant ist auch der Vergleich beim Ändern einer Farbe. Wenn man im bestehenden Konfigurator die Zeit des Datentransfers abzieht bleibt nur die Dauer des Renderns. Im Exterieur ist dieser Wert ungefähr 0,8 Sekunden, in der vorgeschlagenen Lösung 0,55. Im Interieur erfolgt der Farbwechsel der existierenden Anwendung in 1,2 Sekunden und im neuen Konfigurator in 0,26 Sekunden. Der Übergang von Front- zur Heck-Ansicht dauert jetzt 0,11 Sekunden. Im bestehenden 7.1. LEISTUNGSTEST SZENARIO 71
Schritt Art Zeit/Sekunden übertragene Datenmenge/210 Byte A1 Anwendung starten Datenübertragung 1,58 450,38 Übertragung + Rendern 6,87 A2 Farbe Exterieur ändern Datenübertragung - - Rendern 0,55 A3 Studio -> Surround Datenübertragung 2,54 691,39 Übertragung + Rendern 3,86 A4 Exterieur -> Interieur Datenübertragung 3,38 1001 Übertragung + Rendern 5,52 A5 Sitze Farbe ändern Datenübertragung - - Rendern 0,26 A6 Interieur -> Exterieur Datenübertragung - - Rendern 1,30 A7 Front -> Heck-Ansicht Datenübertragung - - Rendern 0,11
Tabelle 7.1: Dauer und Datenmengen der Übertragung sowie des Renderns vom Server zum Client im neuen Konfigurator beim ersten Laden.
Konfigurator ist der Wert der Datenübertragung 0,93. Der Wert des Renderns kann aber nicht genau ermittelt werden, da der Wechsel beider Ansichten animiert ist und ungefähr 8 Sekunden dauert. Insgesamt wurde die Übertragungsdauer bei allen Schritten um mindestens 50% reduziert, wie in Tabelle noch einmal zusammengefasst wird. Es ist aber hervorzuheben, dass nicht nur für die Datenübertragung, sondern auch für das Rendern eine andere Technologie benutzt wird.
Schritt Zeit/Sekunden Zeit/Sekunden Verbesserung % existierender eigene Lösung Konfigurator A1 Anwendung starten 40,31 6,87 ≈ 83 % A2 Farbe Exterieur ändern 1,69 0,55 ≈ 67 % A3 Studio -> Surround - 3,86 - A4 Exterieur -> Interieur 13,04 5,52 ≈ 58 % A5 Sitze Farbe ändern 1,8 0,26 ≈ 85 % A6 Interieur -> Exterieur 2,87 1,30 ≈ 55% A7 Front -> Heck-Ansicht 8,61 0,11 - Tabelle 7.2: Vergleich der Dauer bei Auswahl einer Option im bestehenden und ent- wickelten Konfigurator und der Ertrag in Prozent. Die Zeitwerte beziehen sich auf die Gesamtzeit von Datenübertragung und Rendern.
Bis jetzt wurden die Ergebnisse des Test-Szenarios betrachtet. Es folgt eine Bewertung der einzelnen Architektur-Komponenten nach den in Kapitel 4.3 gestellten Anforderungen. 72 7. BEWERTUNG
Für jedes Teil des Systems wird eine Tabelle die Erfüllung der Kriterien mit einem Plus markieren und die Nicht-Erfüllung mit einem Minus.
7.2 Bewertung des Frontends
Die Anforderungen ans Frontend werden noch einmal in der Tabelle 7.3 in Stichpunk- ten aufgelistet. Als Werkzeug für die Entwicklung des Clients wurde Adobe Flex ausge- wählt, da sich dieses besser für die Erstellung von Rich Internet Applications eignet als ein reines Flash Authoring-Tool. Somit wurde eine Anwendung erstellt, die im Browser mit der Plug-in basierten Version des Flash Players angesehen werden kann (F1). Die UI-Elemente sowie die Komponenten zum Anzeigen des Wagens wurden in MXML und ActionScript realisiert und zu einem SWF-File kompiliert. So wurde die gleiche Tech- nologie für das Anzeigen verschiedener Interaktionselemente verwendet (F2). Eine Flex- Anwendung hält die Session des Clients, der Zustand der Ansicht des Wagens wurde mit dem State-Entwurfsmuster realisiert (F3). Ein SWF-File wird nicht bei jeder Inter- aktion mit dem Client neu erstellt wie beispielsweise bei einer JSP-Seite der Fall ist. Es werden asynchron nur bestimmte Teile vom Server geladen (F5) und es erfolgt kein Refresh der ganzen Seite (F4). In der vorgestellten Lösung erfolgt ein schnelles Bear- beiten der Datenobjekte, da das AMF-Format schneller als XML im Frontend bearbeitet wird. Das Bildmaterial wird als ByteArray übertragen und bedarf keiner besonderen Aufbereitung. Beim Anbinden von Videoclips werden diese in einer Video-Komponente abgespielt und somit sind auch dafür keine besonderen Vorkehrungen erforderlich (F6). Das Frontend wurde in MXML-Komponenten mit Schnittstellen implementiert. Dadurch lassen sich neue Elemente hinzufügen oder die bestehenden in anderen Anwendungen einsetzen (F7).
Anforderung/Beschreibung erfüllt F1 Entwickelt für Plug-in Version vom Flash Player + F2 Eine Technologie zum Anzeigen von Autos und UI-Elemente + F3 Session auf dem Client + F4 Kein Refresh der ganzen Seite + F5 Asynchroner Datenaustausch + F6 Schnelle Bearbeitung der empfangenen Daten + F7 Frontend erweiterbar +
Tabelle 7.3: Anforderungen ans Frontend und deren Erfüllung.
7.3 Bewertung des Servers
Auf der Serverseite befindet sich ein Applikationsserver, der auch ein AMF-Gateway enthält. Die Business Logik ist in Form von Diensten definiert, die eine Datenbankver- bindung aufbauen (S1) und die Daten für den Client in Form von ActionScript-Objekte aufbereiten (S2). Es können die asynchronen Aufrufe des Clients bearbeitet (S3) und CRUD-Operationen auf der Datenbank mittels Datenzugriffsobjekten ausgeführt werden 7.4. BEWERTUNG DER DATENBANK 73
(S4). Ein konkurrenter Zugriff von mehreren Clients ist möglich (S5). Da das Tool von WebORB für die Erstellung der serverseitigen Logik benutzt wurde, wurden die Business Services anhand des Datenmodells der Datenbank generiert. Wenn sich aber das Daten- bankmodell ändert, müssen die Dienste noch einmal generiert und als JAR-File auf dem Server aufgespielt werden. Die neue JAR-Datei überschreibt die existierende. Der Cli- ent ist auch unverändert lauffähig mit dem serverseitigen Code. In diesem Sinne ist das Hinzufügen von neuen Services in einer bestehenden Anwendung teilweise erfüllt (S6). WebORB für Java lässt sich auch auf einem Tomcat Server deployen (S7). Das Bildma- terial befindet sich auf dem gleichen Server wie das Gateway (S8). Tabelle 7.4 fasst die Anforderungen und ihre Erfüllung zusammen.
Anforderung/Beschreibung erfüllt S1 Datenbankverbindung + S2 Datenaufbereitung Frontend + S3 Bearbeiten asynchroner Aufrufe + S4 CRUD + S5 Konkurrenter Zugriff + S6 Hinzufügen neuer Services +- S7 Apache Tomcat + S8 Haltung Bildmaterial +
Tabelle 7.4: Anforderungen an den Server und deren Erfüllung.
7.4 Bewertung der Datenbank
Die Kriterien und Evaluation der Lösung für die Datenbank ist in der Tabelle 7.5 dar- gestellt. Es wurden Integritätsbedingungen festgelegt, welche die Datenbank konsistent halten (DB1). In der Tabelle Asset wird die Adresse zu jedem Bild gespeichert (DB2). Beim Einfügen, Löschen oder Ändern von Datensätzen werden die Integritätsbedingun- gen geprüft, damit keine widersprüchlichen Daten vorliegen (DB3). Die Rechte im ent- wickelten Prototypen werden nicht auf Datenbank-Ebene, sondern im Frontend vergli- chen (DB4). Der Server kann mit der Datenbank mittels der JDBC-API kommunizieren (DB5).
Anforderung/Beschreibung erfüllt DB1 Konsistenz + DB2 Referenz auf Bildmaterial + DB3 Konsistenz bei Datenmanipulation + DB4 Lese- und Schreibzugriffe nach Rechten + DB5 Datenbank-Server-Kommunikation +
Tabelle 7.5: Anforderungen an die Datenbank und deren Erfüllung 74 7. BEWERTUNG
7.5 Bewertung der Kommunikation Frontend-Backend
In der vorgestellten Lösung wird ein Transfer des Bildmaterials mittels ZIP-Files über HTTP benutzt. Auf dieser Weise werden die Daten schneller als ohne Kompression über- tragen (K1). Die Datenobjekte werden in das AMF-Format serialisiert und auf dem Client wieder deserialisiert. Damit werden nicht nur sehr kleine Datenmengen transferiert, son- dern auch schneller im Frontend bearbeitet (K2). Für die Videodaten eignet sich am besten Streaming. Dieses Verfahren wurde nur im Vergleich zu anderen bewertet, aber nicht im- plementiert. Deswegen gilt dieses Kriterium als nicht erfüllt (K3). Die neue Lösung soll die Ladezeiten beim Starten der Anwendung um etwa 30% im Vergleich zum bestehen- den Konfigurator reduzieren. Zum Einen wurde die Übertragung von Bilddaten verbessert (siehe K1), zum Anderen wurde eine neue Technologie für das Anzeigen des Autos einge- setzt. Die Übertragungsdauer konnte um das zwanzigfache reduziert werden (K4) (siehe auch 7.1). Wenn von der Exterier- in die Interieur-Ansicht gewecheselt wird, werden neue Daten geladen. Der Transfer geschieht drei Mal schneller. Wie bei K4 konnte die Übertra- gungsdauer minimiert werden und damit ein Ertrag von ca. 60% erzielt werden (K5). Die ausgewählten Technologien berücksichtigen immer die Bearbeitung der Daten im Fron- tend (K6). Die Übersicht aller Anforderungen und deren Erfüllung sind der Tabelle 7.6 zu entnehmen.
Anforderung/Beschreibung erfüllt K1 Effiziente Übertragung vom Bildmaterial + K2 Effiziente Übertragung von Datenobjekten + K3 Effiziente Übertragung von Videodaten - K4 Ladezeit beim Starten der Anwendung um 30% reduziren + K5 Exterieur-Interieur um 30% reduziren + K6 Ausgewählte Technologie berücksichtigt Bearbeitung der Daten +
Tabelle 7.6: Anforderungen an die Datenbank und deren Erfüllung.
7.6 Bewertung der technischen Anforderungen
Für die Anwendung spielen nicht nur die Übertragungsmetriken eine Rolle, sondern auch die technischen Kriterien. Da es für den Konfigurator das Wichtigste ist seine Produkte zu visualisieren, sind die meisten Daten Bilder. Das Bildmaterial wird beim Starten der Anwendung im Browser-Cache geladen und während des Anzeigens befinden sich die Daten im RAM. Das Datenvolumen im RAM konnte reduziert werden. Im Durchschnitt belegt aktuell eine Anwendung ca. 100 MB RAM (T1). Die Komponente, die das Auto anzeigt, wurde darauf optimiert, dass wenn keine Interaktion mit dem Produkt ausgeführt wird, der Speicherbedarf der Anwendung etwa zwischen 90 und 100 MB liegt. Bei Be- rechnungen übersteigt die Prozessorauslastung den Wert von 60% nicht, ohne Interaktion liegt diese zwischen 4% und 10% (T2). Die Anforderungen und deren Erfüllung sind in der Tabelle 7.7 zu sehen. 7.7. ERWEITERUNGSMÖGLICHKEITEN 75
Anforderung/Beschreibung erfüllt T1 Prozessorlast < 60%, ohne Interaktion < 15% + T2 RAM < 253 MB +
Tabelle 7.7: Technische Anforderungen und deren Erfüllung.
7.7 Erweiterungsmöglichkeiten
In den vorangegangenen Kapiteln wurde die eigene Lösung evaluiert. Nun werden einige Punkte vorgestellt, in denen die Anwendung erweitert werden kann.
• Das nicht-erfüllte Kriterium des Anzeigen von Videoclips kann umgesetzt werden. WebORB für Java unterstützt das Streaming, so müssen die Videodaten auf dem Server gespeichert werden. Der Flash-Client soll nach Bedarf eine Verbindung zu diesen Informationen aufbauen. Eine Video-Komponente soll die empfangenen Vi- deodaten anzeigen. • Internationalisierung auf Datenbank- und Frontend-Ebene. In Kapitel 5.3 wurde er- läutert, wie die Datenbank-Tabellen konzipiert werden können, um mehrere Spra- chen zu unterstützen. Dieses Vorgehen ist für die Datenbank umzusetzen. Wie das Umschalten der Sprache von statten gehen soll, ob automatische Erkennung im Browser oder Umschalten durch den Benutzern, könnte untersucht werden. Auch das Anzeigen der lokalisierten Beschriftung der UI-Elemente muss im Flex umge- setzt werden. 76 7. BEWERTUNG 77
8 Zusammenfassung und Ausblick
In dieser Arbeit ist eine Backend-Lösung entstanden, die den Anforderungen einer Rich Internet Application entspricht. Die Business Services führen nur CRUD-Operationen auf der Datenbank aus und können auch von mehreren Clients angesprochen werden. Die Session des Nutzers wird im Frontend gehalten und es bedarf keines Neuladens der Browseransicht nach jeder Interaktion mit dem Client. Für die Backend-Lösung wurde WebORB für Java eingesetzt. Es ist sowohl eine Entwicklungs- als auch eine Laufzeit- umgebung, die die serverseitige Business Logik aus einem Datenbank-Modell erstellt. Außerdem bietet dieses Werkzeug auch ein Remote-Gateway an, welches die Daten für die Client-Kommunikation aufbereitet. Dieselbe Plattform unterstützt auch das Streamen von Videodaten, was aber in dieser Arbeit nicht implementiert worden ist. Das konzipierte und umgesetzte Backend und Frontend sowie deren Kommunikation erfüllen die gestell- ten Anforderungen an den Konfigurator und bieten eine Verbesserung im Vergleich zur existierenden Anwendung. Welche Möglichkeiten es zu weiteren Untersuchungen gibt, wird im Folgenden vorgestellt. Bei den Recherchen für diese Arbeit in Entwicklerforen ist aufgefallen, dass sich viele Entwickler eine bessere Unterstützung des Flash-Players für die Kommunikation mit ei- nem Ruby-on-Rails-Backend wünschen. Ein Punkt zur Untersuchung wäre in wie weit der neue Flash Player Version 10 [Inc09d] die vorgestellten Probleme in Kapitel 3.1.1 löst. Ein weiterer Aspekt könnte sein, wie AMF als Repräsentation von REST-Ressourcen implementiert werden kann und ob das sinnvoll ist. Der Konfigurator wurde für die Version 9.0.124 des Flash-Players entwickelt ohne die Funktionen der neuen Version 10 zu berücksichtigen. Es wäre interessant zu untersuchen, ob die neuen 3D-Effekte und die erweiterte Grafikhardware-Unterstützung die Dauer ver- kürzen können. Adobe verkündet, dass im ersten Quartal 2009 das Protokoll RTMP frei gegeben wird [Inc09i]. Dieses Protokoll wird für das Streaming von Audio- und Videodaten sowie zur Datenübertragung für das Real-Time Messaging eingesetzt. Es existieren auch Comet- ähnliche Technologien, die das Pushen von Nachrichten im Browser ermöglichen. Da der Flash Player als Browser Plug-in läuft, wäre es sinnvoll zu untersuchen, in wie weit sich diese Technologien des Messaging unterscheiden und wie sie in einem Szenario für kolla- borative Systeme eingesetzt werden können. In dieser Arbeit wurden die Diagramme zum Teil mithilfe des Werkzeugs „Lovely Charts“ [Cha09] erstellt, welches im Frontend mit Flex entwickelt worden ist. Wie kann man beispielsweise mit so einem Tool kollaborativ unter Verwendung von Real-Time-Messaging arbeiten, lässt sich das mit den untersuchten Technologien entwickeln? Es gibt eine plattformunabhängige Laufzeitumgebung für den Desktop von Adobe – Adobe Integrated Runtime (AIR). Rich Internet Applications lassen sich auch für AIR ent- wickeln und haben somit Zugriff auf das Dateisystem des Nutzers, können eine TCP/IP- Verbindung aufbauen und nutzen Binary Sockets. Welche Vorteile bringt die Nutzung 78 8. ZUSAMMENFASSUNG UND AUSBLICK von AIR als Laufzeitumgebung bezüglich der Real-Time-Messaging-Kommunikation mit sich? Welche Ergebnisse erzielt das Programm verglichen mit den erwähnten Comet- ähnlichen Technologien oder der Browser-basierten Version des Flash-Players? Der Konfigurator wurde nur für das Internet konzipiert. Die mobile Kommunikation ent- wickelt sich immer mehr in Richtung Unterhaltung und die neuen Geräte haben größere Displays. Adobe Flash Lite [Inc09g] ist der Player für mobile Geräte und wurde 800 Millionen Mal installiert [Inc09h]. Die Anwendungen für mobile Geräte haben andere Anforderungen an die Daten und Übertragungsdauer als die Internet-basierten Applika- tionen. Lässt sich ein Konfigurator für ein mobiles Telefon entwickeln? Welche sind die Möglichkeiten zum Anzeigen des Bildmaterials und wie wäre die Performance? Mit wel- chen Ladezeiten muss gerechnet werden? Können alle Datentypen wie in der vorgestellten Lösung eingesetzt werden? Das sind einige der Aspekte, die im Bereich Rich Internet Application und Client-Server- Kommunikation für Internet- und mobile Anwendungen als Ideen für weitere Untersu- chungen aus dieser Arbeit hervorgegangen sind. 79
Literaturverzeichnis
[AAB+08]A LLEN, Chris ; ARNOLD, Wade ; BALKAN, Aral ; CANNASSE, Nicolas ; GRDEN, John ; GUNESCH, Moses ; HUGHES, Marc ; MACDONALD, R. J. ; ZUPKO, Andy: The Essential Guide to Open Source Flash Development. 1. Friends of Ed, 2008. – ISBN 1430209933, 9781430209935 [Ado07] Adobe Systems Incorporated: Action Message Format - AMF 3. 1. 2007 [Ado08] Adobe Systems Incorporated: Adobe R Flex R 3 Language Reference. 1. 2008 [Aja09]A JAXPATTERNS.ORG. AjaxPatterns. http://ajaxpatterns.org/On-Demand_Javascript. 2009 [ANS85]ANSI/IEEE. IEEE Standard for Binary Floating-Point Arithmetic. http://754r.ucbtest.org/standards/754.pdf. 1985 [Bak06]B AKER, Kevin. Open AMF ::: Java Flash Remoting. http://www.openamf.com/index.html. 2006 [Bay02]B AYER, Thomas. REST Web Services, Eine Einführung. http://www.oio.de/public/xml/rest-webservices.pdf. 2002 [BCFC06]B OZZON, Alessandro ; COMAI, Sara ; FRATERNALI, Piero ; CARUGHI, Gio- vanni T.: Conceptual modeling and code generation for rich internet applica- tions. In: ICWE ’06: Proceedings of the 6th international conference on Web engineering. New York, NY, USA : ACM, 2006. – ISBN 1–59593–352–2, S. 353–360 [BLFM05]B ERNERS-LEE, T. ; FIELDING, R. ; MASINTER, L. Uniform Resource Iden- tifier (URI): Generic Syntax. RFC 3986 (Standard). Januar 2005 [Bri08]B RIMELOW, Lee. Adobe Flex & AIR Overview. http://www.aicc.org/docs/meetings/28jan2008/flex. pdf. 2008 [Cen09]C ENTER, Mozilla D. New in JavaScript 1.8. https://developer.mozilla.org/en/New_in_ JavaScript_1.8. 2009 [Cha09]C HARTS, Lovely. Lovely Charts. http://www.lovelycharts.com/. 2009 [CHRR09]C LEMENT, Luc ; HATELY, Andrew ; VON RIEGEN, Claus ; ROGERS, Tony. Universal Description, Discovery and Integration v3.0.2 (UDDI). http://uddi.org/pubs/uddi_v3.htm. 2009 [Cod09]C ODERS, The M. WebORB Presentation Server Documentation. http://www.themidnightcoders.com/fileadmin/docs/ java/guide/index.htm. 2009 80 Literaturverzeichnis
[Con08]C ONSULTING, Mort B. Jetty. http://www.mortbay.org/jetty/. 2008 [Cor08]C ORPORATION, Oracle. BEA WebLogic Server. http://www.bea.com/framework.jsp?CNT=index.htm&FP= /content/products/weblogic/server/. 2008 [Cor09a]C ORPORATION, Microsoft. ASP.NET. http://www.asp.net/. 2009 [Cor09b]C ORPORATION, Microsoft. Internet Information Services. http://www.iis.net/. 2009 [Cor09c]C ORPORATION, Microsoft. Microsoft SQL Server. http://www.microsoft.com/germany/sql/2008/default. mspx. 2009 [Cor09d]C ORPORATION, Microsoft. .NET Framework Developer Center. http://msdn.microsoft.com/en-us/netframework/ default.aspx. 2009 [Cor09e]C ORPORATION, Microsoft. Silverlight. http://silverlight.net/. 2009 [Cor09f]C ORPORATION, Microsoft. Windows Presentation Foundation (Avalon). http://msdn.microsoft.com/en-us/netframework/ aa663321.aspx. 2009 [Cor09g]C ORPORATION, Microsoft. XAML Overview. http://msdn.microsoft.com/en-us/library/ms752059. aspx. 2009 [Cor09h]C ORPORATION, Oracle. Oracle Database 11g. http://www.oracle.com/lang/de/database/index.html. 2009 [Cor09i]C ORPORATION, Oracle. TopLink JPA. http://www.oracle.com/technology/products/ias/ toplink/jpa/index.html. 2009 [Cru08]C RUMLISH, Christian. InsideRIA. http://www.insideria.com/2008/01/what-is-ria-1. html. 2008 [Der08]D ERAEDT, David. Flex Architecture Fundamentals Part 2 : Main Means Of Communication Between Flex And The Application Server. http://www.dehats.com/drupal/?q=node/33. 2008 [Dra08]D RAG&DROP, Wikipedia. Drag&Drop. http://de.wikipedia.org/wiki/Drag_and_Drop. 2008 [FGM+99]F IELDING, R. ; GETTYS, J. ; MOGUL, J. ; FRYSTYK, H. ; MASINTER, L. ; LEACH, P. ; BERNERS-LEE, T.: Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (Draft Standard). Juni 1999 (Request for Comments). – Updated by RFC 2817 [Fie00]F IELDING, Roy T.: Architectural styles and the design of network-based Literaturverzeichnis 81
software architectures, University of California, Irvine, Diss., 2000. – Chair- Richard N. Taylor [Fou09a]F OUNDATION, The Apache S. Apache HTTP Server Project. http://httpd.apache.org/. 2009 [Fou09b]F OUNDATION, The Apache S. Apache Tomcat. http://tomcat.apache.org/. 2009 [Fou09c]F OUNDATION, The Apache S. Apache Tomcat. http://tomcat.apache.org/. 2009 [Fou09d]F OUNDATION, The D. The Dojo Toolkit. http://dojotoolkit.org/. 2009 [Fou09e]F OUNDATION., The E. Eclipse. http://www.eclipse.org/. 2009 [Fut09]F UTURESCALE. PureMVC framework. http://puremvc.org/. 2009 [GA09] LOUP GAILLY, Jean ; ADLER, Mark. Zlib Compression Library. http://zlib.net/. 2009 [GHJV05]G AMMA, Erich ; HELM, Richard ; JOHNSON, Ralph ; VLISSIDES, John M.: Design Patterns: Elements of Reusable Object-Oriented Software. 32. Addison-Wesley, 2005. – ISBN 0–201–63361–2 [Goo08]G OOGLE. Google-guice. http://code.google.com/p/google-guice/. 2008 [Gre07]G REGOIRE, Paul. Deploying Red5 to Tomcat. http://dl.fancycode.com/red5/0.6.3/war/Red520War. pdf. 2007 [Gro96]G ROUP, Network W. ZLIB Compressed Data Format Specification version 3.3. http://tools.ietf.org/html/rfc1950. 1996 [Gro07]G ROSS, Christian: Ajax Design Patterns und Best Practices. 1. mitp, 2007 [Gro08]G ROUP, Wideplay I. Warp::Persist. http://www.wideplay.com/home. 2008 [Gro09a]G ROUP, PostgreSQL Global D. PostgreSQL. http://www.postgresql.org/. 2009 [Gro09b]G ROUP, The P. PHP. http://de.php.net/. 2009 [Han09]H ANSSON, David H. Ruby on Rails. http://rubyonrails.org/documentation. 2009 [IBM09]IBM. IBM WebSphere. http://www-01.ibm.com/software/de/websphere/. 2009 [(IE96] (IETF), Internet Engineering Task F. SSL 3.0 Specification. http://www.freesoft.org/CIE/Topics/ssl-draft/ 3-SPEC.HTM. 1996 82 Literaturverzeichnis
[Inc08a]I NCORPORATED, Adobe S. Caringrom. http://opensource.adobe.com/wiki/display/ cairngorm/Cairngorm. 2008 [Inc08b]I NCORPORATED, Adobe S. Flash video learning guide. http://www.adobe.com/devnet/flash/articles/video_ guide.html. 2008 [Inc08c]I NCORPORATED, Adobe S. Adobe LiveCycle Data Services ES. http://www.adobe.com/products/livecycle/ dataservices/. 2008 [Inc08d]I NCORPORATED, Adobe S. Flash Player Penetration. http://www.adobe.com/products/player_census/ flashplayer/. 2008 [Inc08e]I NCORPORATED, Adobe S. SWF File Format Specification Version 9). 2008 [Inc08f]I NCORPORATED, Adobe S. Video File Format Specification Version 10. http://www.adobe.com/devnet/flv/pdf/video_file_ format_spec_v10.pdf. 2008 [Inc09a]I NC, JBoss. JBoss. http://jboss.org/. 2009 [Inc09b]I NCORPORATED, Adobe S. Adobe AIR. http://www.adobe.com/products/air/. 2009 [Inc09c]I NCORPORATED, Adobe S. Adobe Flash Media Interactive Server 3.5. http://www.adobe.com/de/products/ flashmediainteractive/. 2009 [Inc09d]I NCORPORATED, Adobe S. Adobe Flash Player 10. http://www.adobe.com/de/products/flashplayer/ features/. 2009 [Inc09e]I NCORPORATED, Adobe S. Adobe Shockwave Player. http://www.adobe.com/de/products/shockwaveplayer/. 2009 [Inc09f]I NCORPORATED, Adobe S. ColdFusion. http://www.adobe.com/products/coldfusion/. 2009 [Inc09g]I NCORPORATED, Adobe S. Flash Lite. http://www.adobe.com/products/flashlite/. 2009 [Inc09h]I NCORPORATED, Adobe S. Forecasted Installed Base of Flash Lite Devices Worldwide - Grouped by Country and Flash Lite Version. http://www.adobe.com/mobile/pdfs/flash_lite_ forecast_installed_base_jan09.pdf. 2009 [Inc09i]I NCORPORATED, Adobe S. Publishing RTMP Advances Open Screen Project. http://www.adobe.com/aboutadobe/pressroom/ pressreleases/200901/012009RTMP.html. 2009 [Inc09j]I NCORPORATED, Adobe S. Real-Time Messaging Protocol (RTMP) specifi- Literaturverzeichnis 83
cation. http://www.adobe.com/devnet/rtmp/. 2009 [Int99]I NTERNATIONAL, ECMA. Standard ECMA-262. http://www.ecma-international.org/publications/ files/ECMA-ST/Ecma-262.pdf. 1999 [Kle01]K LENSIN, J.: Simple Mail Transfer Protocol. RFC 2821 (Proposed Stan- dard). apr 2001 (Request for Comments). – Obsoleted by RFC 5321, updated by RFC 5336 [LB08]L IE, Håkon W. ; BOS, Bert: Cascading Style Sheets (CSS1) Le- vel 1 Specification / W3C. 2008. – W3C Recommendation. http://www.w3.org/TR/2008/REC-CSS1-20080411/ [LGL+96]L EECH, M. ; GANIS, M. ; LEE, Y. ; KURIS, R. ; KOBLAS, D. ; JONES, L. SOCKS Protocol Version 5. RFC 1928 (Proposed Standard). März 1996 [LK08]L ARSON-KELLEY, Lisa. Overview of streaming with Flash Media Server 3. http://www.adobe.com/devnet/flashmediaserver/ articles/overview_streaming_fms3_02.html. 2008 [LM07]L AFON, Yves ; MITRA, Nilo: SOAP Version 1.2 Part 0: Primer (Second Edi- tion) / W3C. 2007. – Forschungsbericht. http://www.w3.org/TR/2007/REC- soap12-part0-20070427/ [LS08]L ASZLO SYSTEMS, Inc. Open Laszlo. http://www.openlaszlo.org/. 2008 [Mac08]M ACDONELL, Tony. InsideRIA. http://www.insideria.com/2008/01/what-is-ria-1. html. 2008 [Moz06]M OZILLA.ORG. Mozilla Public License Version 1.1. http://www.mozilla.org/MPL/MPL-1.1.html. 2006 [MWCR07]M OREAU, Jean-Jacques ; WEERAWARANA, Sanjiva ; CHINNICI, Roberto ;RYMAN, Arthur: Web Services Description Language (WSDL) Versi- on 2.0 Part 1: Core Language / W3C. 2007. – W3C Recommendation. http://www.w3.org/TR/2007/REC-wsdl20-20070626 [NA08]N OBLE, Joshua ; ANDERSON, Todd: Flex 3 Cookbook: Code-Recipes, Tips, and Tricks for RIA Developers (Adobe Developer Library). 1. Sebasto- pol, CA : Adobe Dev Library - Imprint of: O’Reilly Media, 2008. – ISBN 9780596529857 [O’R08]O’R EILLY. InsideRIA. http://www.insideria.com/2008/01/what-is-ria-1. html. 2008 [Ora09a]O RACLE. Oracle Database 10g Release 2. http://www.oracle.com/technology/software/ products/database/index.html. 2009 [Ora09b]O RACLE. Oracle SQL Developer. 84 Literaturverzeichnis
http://www.oracle.com/technology/products/ database/sql_developer/index.html. 2009 [Qab09]Q ABIZ, Abdul. as3httpclient. http://code.google.com/p/as3httpclient/downloads/ list. 2009 [Ran09] VON RANDOW, Karl. Charles Web Debugging Proxy. http://www.charlesproxy.com/. 2009 [RED08] RED5. Red5 : Open Source Flash Server. http://osflash.org/red5. 2008 [Rei08]R EITMAN, Laurel. Understanding the video encoding ecosystem for Flash. http://www.adobe.com/devnet/video/articles/video_ encoding_ecosystem.html. 2008 [RHJ99]R AGGETT, David ; HORS, Arnaud L. ; JACOBS, Ian: HTML 4.01 Specification / W3C. 1999. – W3C Recommendation. http://www.w3.org/TR/1999/REC-html401-19991224 [RHM09a]R ED HAT MIDDLEWARE, LLC. Hibernate. http://www.hibernate.org/. 2009 [RHM09b]R ED HAT MIDDLEWARE, LLC. Seam Framework. http://www.seamframework.org/. 2009 [RR07]R ICHARDSON, Leonard ; RUBY, Sam: Restful web services. 1. O’Reilly, 2007. – ISBN 9780596529260 [RT09]R ESIG, John ; JQUERY TEAM. jQuery. http://jquery.com/. 2009 [Sch08]S CHEER, Christian. Produktkonfigurator. http://de.wikipedia.org/wiki/Produktkonfigurator. 2008 [SM02a]S UN MICROSYSTEMS, Inc. Core J2EE Patterns: Patterns index page. http://java.sun.com/blueprints/corej2eepatterns/ Patterns/. 2002 [SM02b]S UN MICROSYSTEMS, Inc. Java BluePrints Model-View-Controller. http://java.sun.com/blueprints/patterns/ MVC-detailed.html. 2002 [SM04]S UN MICROSYSTEMS, Inc. JSR-000154 JavaTM Servlet 2.5 Specification. http://jcp.org/aboutJava/communityprocess/mrel/ jsr154/index.html. 2004 [SM06]S UN MICROSYSTEMS, Inc. JSR-000245 JavaServer PagesTM 2.1 (Final Release). http://jcp.org/aboutJava/communityprocess/final/ jsr245/index.html. 2006 [SM09a]S UN MICROSYSTEMS, Inc. Applets. http://java.sun.com/applets/. 2009 Literaturverzeichnis 85
[SM09b]S UN MICROSYSTEMS, Inc. Enterprise JavaBeans 3.0 Specifikation. http://java.sun.com/products/ejb/docs.html. 2009 [SM09c]S UN MICROSYSTEMS, Inc. GlassFish. https://glassfish.dev.java.net/. 2009 [SM09d]S UN MICROSYSTEMS, Inc. Java EE Technologies. http://java.sun.com/javaee/technologies/. 2009 [SM09e]S UN MICROSYSTEMS, Inc. Java Message Service (JMS) API. http://java.sun.com/products/jms/. 2009 [SM09f]S UN MICROSYSTEMS, Inc. Java Web Start. http://www.java.com/de/download/faq/java_webstart. xml. 2009 [SM09g]S UN MICROSYSTEMS, Inc. javaFX. http://javafx.com/. 2009 [SM09h]S UN MICROSYSTEMS, Inc. MySQL. http://www.mysql.de/. 2009 [Spr09a]S PRINGSOURCE. Spring. http://www.springsource.org/. 2009 [Spr09b]S PRINGSOURCE. Spring BlazeDS Integration Resources. http://www.springsource.org/spring-flex. 2009 [Sys09]S YSTEMS, Adequate. Granite Data Services. http://www.graniteds.org/confluence/pages/ viewpage.action?pageId=229378. 2009 [Til08]T ILKOV, Stefan: Eine kurze Einführung in REST. In: JavaSPEKTRUM (2008), Nr. 3, S. 52–55 [Tri08]T RICE, Andrew. InsideRIA. http://www.insideria.com/2008/01/what-is-ria-1. html. 2008 [TSMG08]T HOMPSON, Henry S. ; SPERBERG-MCQUEEN, C. M. ; GAO, Shudi: W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures / W3C. 2008. – a WD in Last Call. http://www.w3.org/TR/2008/WD-xmlschema11- 1-20080620/ [unb08] UNBEKANNT. BlazeDS Abbildung. http://res.sys-con.com/story/dec07/474563/BlazeDS. JPG. 2008 [Wöh04]W ÖHR, Heiko: Web-Technologien. 1. dpunkt.verlag, 2004 [WH08]W AHLERS, Claus ; HERKENDER, Max. FZip ActionScript3 Library. http://codeazur.com.br/lab/fzip/. 2008 [Wol06]W OLFF, Bill. The Xamlon Story. http://www.sys-con.com/node/121826. 2006 [XUL06]XULP LANET.COM. XULPlanet. http://www.xulplanet.com/. 2006 86 Literaturverzeichnis 87
Abbildungsverzeichnis
2.1 Architektur einer Flash-Anwendung [BCFC06]...... 8 2.2 Aufbau des Flex Builders [Bri08]...... 9 2.3 Beispiel einer Kundenbestellung im Online-Shop und Navigation über Links und HTTP-GET [Bay02]...... 10 2.4 Manipulation der Ressourcen mit den HTTP-Methoden im Online-Shop- Beispiel [Til08]...... 12 2.5 Web-Service-Rollen und Interaktionen [Wöh04]...... 15
3.1 Ablauf eines HTTPService-Aufrufs in Flex [Der08]...... 18 3.2 Drei-Schichten-Architektur bei Benutzung eines Gateways...... 21 3.3 Abstrakter Ablauf des Remotings [Der08]...... 24 3.4 Ablauf eines Web-Service-Aufrufs in Flex [Der08]...... 25
4.1 Dauer der Übertragung vom Bildmaterial vom Client zum Server ohne und mit Kompression des Ordners, in dem sich die Daten befinden (siehe auch Tabelle 8.2)...... 33 4.2 Dauer der Datenübertragung vom Server zum Client von Datenzeilen in Sekunden im Format AMF und XML (siehe auch Tabelle 8.3)...... 34 4.3 Dauer der Datenaufforderung, Übertragung vom Server zum Client und Verarbeitung im Frontend von Datenzeilen in Sekunden im Format AMF und XML (siehe auch Tabelle 8.4)...... 34
5.1 Granite-Data-Services-Architektur für Java-Applikationsserver [Sys09]. . 41 5.2 WebORB-Architektur und Bearbeitungsschritte einer Anfrage vom Client [Cod09]...... 42 5.3 Die angebotenen Dienste von BlazeDS werden farbig dargestellt, die ver- fügbaren in LiveCycle DS sind grau markiert [unb08]...... 46 5.4 Model-View-Controller-Architekturmuster einer Rich Internet Application. 48 5.5 Drei-Schichten-Architektur und Übertragungsprotokolle der eigenen Lö- sung...... 49 5.6 Abstraktes Datenbankdiagramm in UML-Notation...... 50 5.7 Datenbankdiagramm mit Primär- und Fremdschlüssel-Beziehungen. . . . 52 5.8 Das Datenzugriffs- und Datentransferobjekt-Muster in einer Rich Internet Application...... 53 5.9 Das Datenzugriffs- und Datentransferobjekt-Muster mit WebORB für Java. 54 5.10 Frontend Benutzer...... 55 5.11 Frontend Administrator...... 55 5.12 Pakete, die das Frontend aufbauen...... 57
6.1 SQL-Quellcode für die Erstellung der Tabellen Series, Model und Part...... 60 88 Abbildungsverzeichnis
6.2 Geforderte Informationen bei der Datenbankverbindung des Tools Web- ORB für Java...... 61 6.3 Datenmanagement-Ansicht von WebORB für Java...... 62 6.4 Mapping der Tabelle Model_Part auf Java-Objekt ModelPart und Fremdschlüsselbezihungen...... 62 6.5 Bearbeitung der Datenobjekte in Flex...... 67
8.1 Attribute und Methoden der Klassen AbstractWebService und WebService von Adobe Flex 3.0...... 91 8.2 Attribute und Methoden der Klassen AbstractService, RemoteObject, Ab- stractInvoker, AbstractOperation und HTTPService von Adobe Flex 3.0. . 92 89
Tabellenverzeichnis
2.1 Vergleich einer Desktop- , Web- und Rich Internet Application [BCFC06].5
4.1 Dauer und Datenmengen der Übertragung vom Server zum Client im be- stehenden Konfigurator beim ersten Laden...... 29 4.2 Bewertung der existierenden Technologien zur Datenübertragung vom Server zum Client anhand Kriterien der Datenübertragung und Anwen- dungsentwicklung...... 35 4.3 Vergleich der existierenden Ladetechniken für Flash-Video. Die Bildgrö- ße ist in Pixel gekennzeichnet. Die Bildfrequenz wird in Bilder pro Se- kunde – fps (Frames per Second) gemessen [Inc08b]...... 37 4.4 Auswahl der Technologie der Datenübertragung für die prototypische Im- plementierung...... 38
5.1 Bewertung der AMF-Gateways für Java nach den in Kapitel 5.1 aufge- stellten Kriterien. Die erfüllten Anforderungen werden mit einem Plus markiert, die nicht erfüllten mit einem Minus...... 47
7.1 Dauer und Datenmengen der Übertragung sowie des Renderns vom Ser- ver zum Client im neuen Konfigurator beim ersten Laden...... 71 7.2 Vergleich der Dauer bei Auswahl einer Option im bestehenden und ent- wickelten Konfigurator und der Ertrag in Prozent. Die Zeitwerte beziehen sich auf die Gesamtzeit von Datenübertragung und Rendern...... 71 7.3 Anforderungen ans Frontend und deren Erfüllung...... 72 7.4 Anforderungen an den Server und deren Erfüllung...... 73 7.5 Anforderungen an die Datenbank und deren Erfüllung ...... 73 7.6 Anforderungen an die Datenbank und deren Erfüllung...... 74 7.7 Technische Anforderungen und deren Erfüllung...... 75
8.1 Existierende AMF-Gateways [Der08]...... 93 8.2 Datenvolumen des übertragenen Bildmaterials ohne und mit Kompression des Ordners, in dem sich die Daten befinden...... 94 8.3 Dauer der Datenübertragung vom Server zum Client in Sekunden im For- mat AMF und XML...... 94 8.4 Dauer der Datenaufforderung, Übertragung vom Server zum Client und Verarbeitung im Frontend in Sekunden im Format AMF und XML. . . . . 94 8.5 Übertragene Nutzdaten in Kilobyte vom Server zum Client im Format AMF und XML...... 94 90 Tabellenverzeichnis 91
Anhang
Abbildung 8.1: Attribute und Methoden der Klassen AbstractWebService und WebService von Adobe Flex 3.0. 92 Anhang
Abbildung 8.2: Attribute und Methoden der Klassen AbstractService, RemoteObject, Ab- stractInvoker, AbstractOperation und HTTPService von Adobe Flex 3.0. 93
Name Technologie Entwickler kostenlos Open- Bemerkung Source AMFPHP PHP AMFPHP ja ja Das bekannteste PHP- Team Gateway für AMF0/3. Zend PHP Wade ja ja Das PHP-Framework unter- Framework Arnold stützt auch AMF0/3. WebORB PHP The mid- nein nein AMF0/3-Gateway, Service- PHP night Browser, Code-Generator, coders auch für Silverlight- und AJAX-Clients. SabreAMF PHP Evert Pot ja ja AMF0/3-Gateway, kein Service-Browser. FLUORINE .NET ja ja AMF0/3-Gateway, Real- Time Messaging, Video- Streaming, auch für Silverlight-Clients. WebORB .NET The mid- nein nein AMF0/3-Gateway, Real- .NET night Time Messaging, Audio- coders und Video-Streaming, Datenmanagement für CRUD-Operationen, Code- Generator. Open AMF Java/JEE OpenAMF ja ja AMF0-Gateway. team Granite Java/JEE GDS Team ja ja AMF3-Gateway, Framework Data für Flex 2+/EJB 3/Se- Services am/Spring/Guice/POJO, (GDS) Code-Generator für Eclipse. RED5 Java/ Ruby/ RED5 ja ja AMF3-Gateway, kostenlose Python Team Alternative zu Flash Media Server, Audio- und Video- Streaming, Aufnehmen von Client-Streams. WebORB Java/JEE The mid- nein nein AMF0/3-Gateway, EJBs, JAVA night Spring Beans, auch AJAX- coders Clients, Datenmanagement, Real-Time Messaging, Audio- und Video-Streaming, Code-Generator. LiveCycle Java/JEE Adobe nein nein AMF0/3-Gateway, Real- DS (LCDS) Time Messaging, Datenma- nagement, PDF-Generierung. BlazeDS Java/JEE Adobe ja ja AMF0/3-Gateway, Real- Time Messaging, auch AJAX-Clients. AMF::Perl Perl/Python AMF::Perl ja ja AMF0-Gateway. Team PyAMF Python PyAMF ja ja AMF0/3-Gateway. Team
Tabelle 8.1: Existierende AMF-Gateways [Der08]. 94 Anhang
Datenmenge Anzahl der SWF-Loader ZIP-Loader in 220 Byte Dateien Zeit/Sekunden Zeit/Sekunden 1 10 6,98 3,516 3 37 22,268 7,476 5 45 31,15 10,716 7 75 44,308 14,82 10 57 60,25 20,354 20 176 116,83 41,298 Tabelle 8.2: Datenvolumen des übertragenen Bildmaterials ohne und mit Kompression des Ordners, in dem sich die Daten befinden.
Datenzeilen AMF – Zeit/Sekunden XML – Zeit/Sekunden 100 0,059 0,016 1 000 0,286 0,095 10 000 3,14 0,492 50 000 15,986 11,846 Tabelle 8.3: Dauer der Datenübertragung vom Server zum Client in Sekunden im Format AMF und XML.
Datenzeilen AMF – Zeit/Sekunden XML – Zeit/Sekunden 100 0,162 0,087 1 000 0,437 0,643 10 000 4,058 5,955 50 000 25,297 36,474
Tabelle 8.4: Dauer der Datenaufforderung, Übertragung vom Server zum Client und Ver- arbeitung im Frontend in Sekunden im Format AMF und XML.
Datenzeilen AMF – Datenmenge in 210 Byte XML – Datenmenge in 210 Byte 100 1,022 43,41 1 000 4,03 434,87 10 000 33,14 4 260 50 000 162,04 21 320
Tabelle 8.5: Übertragene Nutzdaten in Kilobyte vom Server zum Client im Format AMF und XML. 95
Erklärungen zum Urheberrecht
Adobe, the Adobe logo, are trademarks of Adobe Systems Incorporated, ColdFusion, Flash, Flash Lite, Flex, Flex Builder, Adobe and MXML are either registered trademarks or trademarks of Adobe Systems Incorporated and may be registered in the United States or in other jurisdictions including internationally. Other product names, logos, designs, titles, words, or phrases mentioned within this publication may be trademarks, service marks, or trade names of Adobe Systems Incorporated or other entities and may be regi- stered in certain jurisdictions including internationally. 96 Erklärungen zum Urheberrecht