Development of a client-server communication via Flash Remoting and PHP in connection with a project information system for students

Größe: px
Ab Seite anzeigen:

Download "Development of a client-server communication via Flash Remoting and PHP in connection with a project information system for students"

Transkript

1 BACHELORARBEIT B A C H E L O R O F S C I E N C E I N MEDIA INFOR M A T I C S Entwicklung einer Client-Server Kommunikation mit Hilfe von Flash Remoting und PHP am Beispiel eines Projektinformationssystems im studentischen Kontext Development of a client-server communication via Flash Remoting and PHP in connection with a project information system for students ausgearbeitet von: Andy Bucksch Enriko Podehl vorgelegt am: 21. Februar 2007 Erster Prüfer: Prof. Dr. rer. nat. Dipl.-Inform. Kristian Fischer Zweiter Prüfer: Prof. Dr. Erich Ehses

2 Anfragen an: Fachhochschule Köln Fakultät für Informatik und Ingenieurwissenschaften Institut für Informatik Am Sandberg 1 D Gummersbach Hinweise zum Dokument: Dieses Dokument ist urheberrechtlich geschützt. Nachdruck oder Vervielfältigung und die Weitergabe ist nur mit Genehmigung des Urhebers gestattet. ii

3 Danksagung An dieser Stelle möchten wir all jenen danken, die durch ihre fachliche und persönliche Unterstützung zum Gelingen dieser Bachelorarbeit beigetragen haben. Besonderer Dank gebührt unseren Eltern und Großeltern, die uns dieses Studium durch ihre Unterstützung ermöglicht haben. Des Weiteren bedanken wir uns bei Dipl. Inform. Frauke Voss, für die Betreuung unserer Bachelorarbeit und die zahlreichen Ratschläge, welche stets zur Verbesserung der Arbeit beigetragen haben. iii

4 Zusammenfassung Als Grundlage für die Bachelorarbeit dient eine, im Laufe des Studiums von uns implementierte Client-Server-Anwendung. Sie soll es verschiedenen Benutzergruppen ermöglichen, sich über, an der Fachhochschule angebotene und durchgeführte, Projekte zu informieren, um diese gegebenenfalls weiterführen zu können. Dabei liegt der Schwerpunkt der Bachelorarbeit auf der Implementierung der Kommunikation zwischen der in Flash entwickelten Client-Anwendungen und den in amfphp realisierten Server-Funktionen. Um diese Neuentwicklung besser bewerten zu können, haben wir uns dazu entschlossen, Hypothesen aufzustellen. Sie behandeln die Dauer des Datenaustauschs zwischen Client und Server, die Sicherheit der Kommunikation in Bezug auf Integrität, Authentizität und Vertraulichkeit sowie die Datenintegration in Flash. Weiterhin behandeln die Hypothesen die Plattformunabhängigkeit der eingesetzten Technologien sowie die Unterstützung von amfphp bei der Fehleranalyse. Nach Abschluss der Implementierung werden diese Hypothesen diskutiert und evaluiert. Im nächsten Schritt findet eine Abgrenzung unserer Umsetzung von alternativen Anwendungen statt. Dabei werden diese Alternativen, wie Content Management Systeme, aufgeführt und ihre Merkmale angesprochen. Zudem findet ein Vergleich mit den Funktionen unserer eigenen Implementierung statt. Nach der Positionierung unseres Projekts gehen wir näher auf die verwendeten Technologien ein. Dazu werden die Haupttechnologien amfphp, Flash Remoting und das Kommunikationsprotokoll AMF im Detail beschrieben. Des Weiteren wird mit Schaubildern und Erklärungen die Kommunikation der Anwendung aufgezeigt. Nach einer Beschreibung, der im Projektinformationssystem verwendeten Technologien, findet eine Auflistung und Erklärung alternativer Technologien statt. Dabei geht es um Technologien wie.net oder JAVA, die amfphp oder Flash ersetzen könnten. In diesem Bereich wird auf zwei unterschiedliche Punkte eingegangen. Zum Einen betrachten wir Technologien, die auf der Client-Seite eingesetzt werden können und zum Anderen behandeln wir jene, die auf dem Server betrieben werden. Im Anschluss an diese Betrachtungen wird, unter Anderem auf die momentan populäre Technologie AJAX eingegangen, mit der es prinzipiell möglich ist, ein Projekt wie das Unsere umzusetzen. Bei dem Nächsten großen Block handelt es sich um die Dokumentation der Implementierung, welche einen Großteil der Arbeit eingenommen hat. Zu Beginn dieses Bereichs wird zunächst allgemeines, wie die Beschreibung des Singelton Konzepts, das Sessionmanagement oder die Verzeichnisstruktur der Anwendung behandelt. Anschließend werden beispielhaft Funktionen und Abläufe sowie ihr Quellcode erläutert, welche in der Anwendung mehrfach auftauchen. Eine dieser Funktionen ist eine Liste zum Anzeigen der verschiedenen Daten. Dabei ändert sich nur der Inhalt der Liste, der Aufbau ist jedoch immer der gleiche. Nach den allgemeinen Betrachtungen wenden wir uns konkreten iv

5 Anwendungsfällen des Projektinformationssystem zu, deren Funktion ebenfalls anhand ihres Quellcodes erklärt wird. Dies sind unter anderem das Einstellen eines Projekts in das Projektinformationssystem oder das Betrachten eines Solchen. Ziel der Arbeit ist es, die für wichtig befundenen Funktionen zu implementieren und diese zu dokumentieren. Außerdem soll anhand der Hypothesen die Arbeit bewertet werden. v

6 Abstract A Client-Server-Application, implemented by us during our studies, is the basis of this Bachelor thesis. Its goal is to enable different user groups to gather information about projects offered and executed at the technical college and, if applicable, continue with them. The focus lies on the reimplementation of the communication between the client (developed under Flash) and the server (developed under amfphp). In order to evaluate this new application, we decided to make assumptions. These assumptions deal with the duration of the data transfer between client and server, security of the communication with respect to integrity, authenticity, data confidentiality, as well as integration of data in Flash. Furthermore, they cover the platform independency of the technologies used, as well as the support of amfphp with regard to error analysis. The assumptions are discussed and evaluated after finishing the implementation. The next step shows the difference between our and other possible applications. The alternatives and their characteristics are presented and compared with our implementation. After describing the applicable areas of use for our project we focus on the used technologies. We describe main technologies such as amfphp, Flash Remoting and the communication protocol AMF in detail. Diagrams and explanations demonstrate the communication part of the application. In the next part, we list and describe possible technologies which could be used alternatively. That is, technologies which work on the one hand on client-side and on the other hand on server-side. To be more precise,.net or Java which could substitute amfphp or Flash, respectively. Furthermore, we consider, amongst others, AJAX, with which our project could have been implemented as well. The next part deals with the documentation of the implementation. It represents the biggest part of the thesis. We start by talking about basics, such as the Singleton Concept, session management or directory structure of the application. Afterwards, particular functions and procedures are demonstrated on the basis of their source codes. One of these functions is a list that displays different data. The underlying architecture of the list remains the same, only the content changes. Concrete applications, such as the creation or examination of a project within the Project Information System, are explained again with their source codes. The goal was to implement the most important functions and their documentation. Furthermore, hypotheses are used to evaluate the work. vi

7 Inhaltsverzeichnis Abkürzungsverzeichnis Einführung Motivation Thema der Bachelorarbeit Schwerpunkt der Arbeit Aufbau der Arbeit Zielgruppe Vorherige Umsetzung Vorzug für amfphp Zeitplanung Hypothesen Konzeption Abgrenzung des eigenen Produkts Content Management Systeme Digital Asset Management-Systeme Redaktionssysteme Die Kommunikationstechnologien unseres Projektinformationssystems Flash Remoting AMF Kommunikation Amfphp Alternative Technologien Serverseitige Umsetzung Gänzlich andere Umsetzungen Netzwerk der Metadaten Tagging Implementierung Refactoring...66 Beschreibung...66 Anwendung Remote Procedure Call (RPC) Sessionmanagement Singleton Design Pattern...70 Problembeschreibung...70 Problemlösung...70 Singelton Implementierung...70 vii

8 Bewertung...72 Weiterführende Links zu dem Thema Verzeichnis- und Dateistruktur Aufteilung der Bereiche Außenbereich Interner Bereich Implementierung in Flash und PHP Allgemeine Betrachtungen Konkrete Anwendungsfälle Serverseitige Probleme mit MySQL und PHP Verwendete Technologien und Hardware Software der Entwickler Hard Software des Servers Thesendiskussion Hypothese Hypothese Hypothese Hypothese Hypothese Hypothese Erweiterbarkeit und Ausblick Aufgabenverteilung Erklärung Literaturverzeichnis Glossar Anhang A UML-Diagramme A.1. Sequenzdiagramm A.2. Anwendungsfalldiagramm A.3. Klassendiagramm B. Gantt-Diagramm mit Meilensteinplanung C. Persönliches Nachwort Andy Bucksch Enriko Podehl D. Programmdateien des Projektinformationssystems Notizen viii

9 Abkürzungsverzeichnis Abkürzungsverzeichnis AGB Allgemeine Geschäftsbedingungen AJAX Asynchronous JavaScript and XML AMF Action(Script) Message Format API Application Programming Interface ASP Active Server Pages AWT Abstract Window Toolkit BCL Base Class Library bspw. beispielsweise bzgl. bezüglich CF ColdFusion CFC ColdFusion Components CFML ColdFusion Markup Language CGI Common Gateway Interface CLI Common Language Infrastructure CLR Common Language Runtime CLS Common Language Specification CMS Content Management Systeme COM Component Object Model CORBA Common Object Request Broker Architecture CPAN Comprehensive Perl Archive Network CSS Cascading Style Sheets DAM Digital Asset Management DBI Database Integration Interface DOM Document Object Model EJB Enterprise Java Beans engl. englisch FH Fachhochschule FTP File Transfer Protocol ggf. gegebenenfalls GUI Graphical User Interface HTML Hypertext Markup Language IB Institutsbericht ID Identifikation IDE Interactive Development Environment IIS Internet Information Services J2EE Java 2 Enterprise Edition 1

10 Abkürzungsverzeichnis JRE Java Runtime Environment JSP Java Server Pages JSON JavaScript Object Notation LDAP Lightweight Directory Access Protocol MD5 Message Digest Algorithm 5 MP3 (Moving Picture Experts Group)-1 Audio Layer 3 MVC Model View Controller OOP Objektorientierte Programmierung PDF Portable Document Format PHP Akronym für "PHP: Hypertext Preprocessor" PDO PHP Data Objects RPC Remote Procedure Call SDK Software Developement Kit SOAP Simple Object Access Protocol SQL Structured Query Language SSAS Server-Side ActionScript SSL Secure Sockets Layer u.a. unter anderem URL Uniform Resource Locator usw. und so weiter XML Extensible Markup Language z.b. zum Beispiel 2

11 1. Einführung 1. Einführung Dieses Kapitel stellt unsere grundlegenden Gedanken zum Thema vor. Zuerst wird anhand der Problemstellung unsere Motivation für diese Arbeit erläutert. Dem schließt sich die Betrachtung unseres Themas, mit der Vertiefung auf dessen Schwerpunkt, an. Daraufhin wird der Aufbau der Arbeit und unsere Zielgruppe näher definiert. Diese Abschnitte werden von einem Verweis auf die vorherige Umsetzung und der Erläuterung, warum wir uns für amfphp entschieden, ergänzt. Anschließend wird unsere Zeitplanung dargestellt Motivation Die Durchführung von Projekten gehört zum täglichen Brot eines Informatikstudenten. Jedoch ist es für die Studenten nicht immer leicht ein Projekt zu finden, welches sie z. B. in einem Praktikum bearbeiten können. Dabei stellt nicht nur die Wahl eines geeigneten Themas eine Schwierigkeit für sie dar. Häufig fehlt es den Studenten an einer Vorstellung über den Umfang eines solchen Projekts, sowie über den Erwartungshorizont der Dozenten bzw. der Betreuer. Schnell fühlen sie sich allein gelassen und geraten unter Druck, wenn die zündende Idee ausbleibt. In dieser Situation wächst der Wunsch nach einer zentralen Übersicht, in der sie bereits absolvierte Projekte mit einem ähnlichen Schwerpunkt finden, sich Anregungen holen und von den Erfahrungen der Projektmitglieder profitieren können. Diese Übersicht sollte auch Projekte enthalten, die weitergeführt werden können, um auf den ersten Ideen oder Umsetzungen anderer Studenten aufzubauen und diese möglicherweise zu einem Abschluss zu bringen. In der Fachhochschule findet sich keine umfassende Projektübersicht, die jenes zu leisten vermag. Deswegen kommen die Studenten nicht umhin, zu den jeweiligen Dozenten oder Betreuern zu gehen, um sich dort nach entsprechenden Projekten zu erkundigen. Dies bedeutet sowohl für die Studenten, als auch für die Dozenten und Betreuer einen großen Aufwand, da die Einen von den verfügbaren Sprechstunden abhängig sind und die Anderen für jeden Studenten in ihr Archiv sehen müssen. An dieser Stelle soll unser Projektinformationssystem ansetzen Thema der Bachelorarbeit Ziel unserer Arbeit ist es, ein Projektinformationssystem zu entwickeln, welches diesem organisatorischen Missstand begegnet und umfangreiche Daten zu den beschriebenen Projekten aus einer Hand liefert. Der Begriff "Projektinformationssystem" bezeichnet hierbei ein System zur Darstellung von projektspezifischen Daten und Medien, sowie zur Auflistung 3

12 1.2. Thema der Bachelorarbeit von Projekten nach unterschiedlichen Kriterien. Die enthaltenen Projekte können den Zustand ausgeschrieben, in Bearbeitung, abgeschlossen oder weiterführbar annehmen. Hierfür entwickeln wir eine Client-Server Anwendung, welche frei aus dem Internet zugänglich sein soll, damit die Studenten jederzeit auf diese Übersicht zugreifen können. Die Clientseite wird mit Flash entwickelt, um einerseits dynamisch Inhalte anzeigen und animieren zu können und andererseits die Metapher "Fachhochschule" aufzugreifen. Hierbei soll ein typisch statisches und grafisch armes Auftreten vermieden werden. Der Schwerpunkt unserer Arbeit liegt auf der Entwicklung der Client-Server Kommunikation mit Hilfe von Flash Remoting MX (im folgenden nur noch Flash Remoting genannt) und amfphp Schwerpunkt der Arbeit Mit dem Begriff "Kommunikation" bezeichnen wir in unserer Arbeit den vollständigen Datenaustauschprozess zwischen Client und Server. Dies beinhaltet den Aufruf des Remote Services im Client, das Senden des Requests, die Ausführung des Remote Services auf dem Server, das Senden einer Rückgabe und die Verarbeitung dieser Rückgabe im Client. (Abb. 1) Abbildung 1: Kommunikation des Projektinformationssystems Diese Kommunikation stellt die Kernfunktionalität in unserem System dar. Deswegen ist es besonders wichtig, dass jener Prozess so effektiv und effizient wie möglich abläuft. In unserem System werden häufig Daten zwischen dem Client und dem Server ausgetauscht, wodurch lange Wartezeiten für den Benutzer entstehen könnten, wenn der Kommunikationsprozess nicht flüssig durchgeführt wird. Aus diesem Grund ist es unerlässlich, dass wir prüfen, ob Flash Remoting in Verbindung mit amfphp einen Vorteil gegenüber der vorherigen Umsetzung mit XML darstellt. Die Evaluation unserer Kommunikationstechnologien soll zeigen, in wie weit Flash Remoting in unserer Anwendung sinnvoll ist und uns die Implementierung erleichtert. 4

13 1.4. Aufbau der Arbeit 1.4. Aufbau der Arbeit Nachdem das 1. Kapitel in die Bachelorarbeit einführte und unser Thema vertiefte, stellen wir im 2. Kapitel Hypothesen auf, die unsere Erwartungen an die Entwicklung der Client-Server Kommunikation mit Flash Remoting und amfphp darstellen. Der konzeptionelle Teil unserer Arbeit befindet sich in Kapitel 3 und umfasst neben der Abgrenzung unseres Produkts, auch die Vorstellung der verwendeten Kommunikationstechnologien, die Untersuchung von alternativen Technologien, sowie einen Einblick in das Netzwerk der Metadaten. Das 4. Kapitel steht ganz im Zeichen der Implementierung. Nach allgemeinen Betrachtungen zu Themen wie "Refactoring" oder "Session Management" widmen wir uns der konkreten Implementierung in Flash und PHP. An ausgewählten Beispielen werden dann die Möglichkeiten und Abläufe der Kommunikationsprozesse zwischen Flash und amfphp erläutert. Die vorgestellten Beispiele bilden eine wichtige Grundlage für die spätere Evaluation der Hypothesen in Kapitel 5. An dieser Stelle prüfen wir, in wie fern unsere Erwartungen an die neue Umsetzung erfüllt wurden und wo sich Schwachstellen offenbarten. Kapitel 6 nennt abschließend mögliche Erweiterungen für unser Projektverwaltungssystem und gibt darüber hinaus einen Ausblick auf denkbare Weiterentwicklungen Zielgruppe Unser System richtet sich in erster Linie an die Studenten der Fachhochschule Köln, Fakultät 10. Ihnen soll es erleichtert werden, sich über angebotene (ausstehende, weiterführbare) Projekte semesterübergreifend und zentral zu informieren. Hierzu können registrierte Benutzer (Informatikstudenten des Campus Gummersbach, Dozenten, wissenschaftliche Mitarbeiter, aber auch externe Personen) Projekte in das System einstellen. Darüber hinaus bietet das Projektinformationssystem studieninteressierten Menschen die Möglichkeit, sich einen Überblick über die geleisteten Arbeiten zu verschaffen, um so einen Eindruck über die Qualität und den Standard der Lehreinrichtung zu erhalten. In Zeiten von konkurrierenden Hochschulen stellt die repräsentative Eigenschaft unseres Systems einen nicht zu vernachlässigenden Faktor dar Vorherige Umsetzung Bei der Entwicklung des Projektinformationssystems fangen wir nicht bei null an. In früheren Semestern erarbeiteten wir die Grundlage für das aktuelle System und dokumentierten es in einem Institutsbericht (IB) [8]. 5

14 1.6. Vorherige Umsetzung Zu diesen Grundlagen zählen die "functional" und "non-functional Requirements", welche in Kapitel des IB zu finden sind und die Basis für die Funktionen und grundlegenden Eigenschaften unseres Systems darstellen. Ansonsten beschäftigt sich der Institutsbericht mit der Entwicklung der Benutzeroberfläche. Hierfür wurde der Nutzungskontext ermittelt (siehe Kapitel 4 im IB), Prototypen entwickelt (siehe u. a. Kapitel 5 im IB) und evaluiert (siehe Kapitel 6 im IB). Der Schwerpunkt dieser Arbeit liegt auf der Kommunikation zwischen Flash Remoting und amfphp, weswegen weder ein erneutes Requirements Engineering durchgeführt, noch das visuelle Design getestet und überarbeitet wurde. Dennoch erweiterten wir den Funktionsumfang um ein Nachrichtensystem und das visuelle Design einiger Bereiche wurde an die erweiterten Funktionen und deren Anforderungen angepasst. Im Institutsbericht wurde auch eine Implementierung dokumentiert, welche uns nur noch als Orientierung für unser aktuelles System diente, da nahezu der gesamte Quellcode durch ein Refactoring (siehe Kapitel 4.1.) überarbeitet und teilweise neu geschrieben wurde Vorzug für amfphp Zu Beginn der Bachelorarbeit war es wichtig, die Anforderungen an die Technologie, welche zum Einsatz kommen sollte, festzulegen. In der vorherigen Umsetzung fand bereits eine Evaluation auf benötigte Funktionen statt, wodurch uns diese Anforderungen vorlagen und nur noch überarbeitet werden mussten. Wir konnten bereits Erfahrung mit amfphp und PHP sammeln. Außerdem steht diese Technologie kostenlos unter einer Open Source Lizenz zur Verfügung. Vergleichbare Umsetzungen (z. B. mit Microsoft.NET oder mit Java) benötigen dagegen eine kostenpflichtige Erweiterung (Macromedia Flash Remoting MX) und konnten nicht weiter berücksichtigt werden, da der Fachhochschule zu hohe Kosten entstanden wären. Nachdem wir die Anforderungen überprüft hatten und amfphp diesen gerecht wurde, konnten wir uns tiefer in die Technologie einarbeiten. Da die Entwickler von amfphp großen Wert auf einen leichten und schnellen Einstieg legen, stehen auf der offiziellen Webseite 1 umfangreiche Dokumentationen und Anleitungen für die Inbetriebnahme und die ersten Schritte bereit. Nachdem erste allgemeine Tests mit amfphp erfolgreich verliefen und wir zudem in der Dokumentation auf einen externen Bericht2 über eine schnellere Performance von amfphp gegenüber XML basierter Kommunikation gestoßen waren, entschlossen wir uns endgültig unsere Umsetzung mit amfphp durchzuführen. Es muss noch erwähnt werden, dass amfphp die einzige kostenlose Flash Remoting Umsetzung ist, die aktiv und professionell weiterentwickelt wird. Dies war natürlich eine weitere Voraussetzung, um auch zukünftig aktuelle Programmversionen beziehen zu können. Für eine genau Beschreibung der Funktion von amfphp existiert ein eigenes Kapitel. 1 2 Vgl. Vgl. 6

15 1.8. Zeitplanung 1.8. Zeitplanung Bevor wir mit der Bachelorarbeit begannen, entwickelten wir einen Zeitplan, um unsere umfangreichen Aufgaben zu organisieren. An ihm konnten wir uns zu jeder Zeit orientieren und uns aufeinander abstimmen, was die Bearbeitung der einzelnen Aufgaben anbelangt. Wir teilten unser Projekt in die Phasen "Konzeption", "Implementierung" und "Auswertung und Bearbeitung" ein. Danach legten wir Aktivitäten fest, die in der jeweiligen Phase abgearbeitet werden mußten. Zusätzlich bestimmten wir Meilensteine, die als Teilziele fungierten und das Ende jeder Phase markierten. Das zugehörige Gantt-Diagramm befindet sich im Anhang B. In ihm sind die einzelnen Aktivitäten mit der geplanten Bearbeitungsdauer aufgelistet. 7

16 2. Hypothesen 2. Hypothesen Wir entschieden uns, wie zuvor beschrieben, die Kommunikation zwischen dem Flash Client und dem Server mit Hilfe von Flash Remoting MX und amfphp zu implementieren. An diese Entscheidung sind einige Erwartungen geknüpft, die wir, besonders im Bezug auf die vorige Umsetzung, an Flash Remoting und amfphp stellen. Die daraus resultierenden Hypothesen werden später evaluiert, um die Zweckmäßigkeit der verwendeten Technologien für unsere Anwendung zu prüfen. 1. Schnellerer Ablauf der Kommunikation, gegenüber der Umsetzung mit Flash, PHP und XML. 2. Die Kommunikation ist sicher, in Bezug auf Integrität, Authentizität und Vertraulichkeit. 3. Die Technologien der Kommunikationspartner sind plattformunabhängig. 4. Leichtere Datenintegration in Flash, gegenüber der Umsetzung mit XML. 5. Das Risiko bei der Programmierung Fehler zu erzeugen, ist in der neuen Umsetzung geringer. 6. Unterstützung bei der Analyse von Fehlern in der Kommunikation. Wir werden diese Hypothesen anhand unserer Erfahrungen mit der vorigen Umsetzung und unseren Erfahrungen mit der neuen Umsetzung evaluieren. Des Weiteren ziehen wir bei den Thesen 2, 3 und 6 (literarische) Quellen zu Rate. Für die erste These sollen uns außerdem Ablauftests als Vergleichsgrundlage dienen, welche wir sowohl mit der vorigen, als auch mit der neuen Umsetzung durchführten. 8

17 3. Konzeption 3. Konzeption 3. Konzeption Abgrenzung des eigenen Produkts Content Management Systeme Digital Asset Management-Systeme Redaktionssysteme Die Kommunikationstechnologien unseres Projektinformationssystems Flash Remoting...14 Flash Remoting Components...14 Flash Remoting Gateway...15 Vorteile von Flash Remoting...15 Anwendungsgebiete...16 MVC-Modell AMF Kommunikation Architektur...21 Presentation Tier...22 Middle Tier...22 Data Tier...22 N-Tier Ablauf der Kommunikation (Workflow) Amfphp...25 PHP...25 PHP Zend Engine Vorzüge von amfphp Alternative Technologien Serverseitige Umsetzung ColdFusion MX...29 ColdFusion Pages...31 ColdFusion Components...31 ColdFusion Pages versus ColdFusion Components...32 Vorzüge von ColdFusion...33 Nachteile von ColdFusion Server-Side ActionScript...34 Wann kann man Server-Side ActionScript verwenden?

18 3. Konzeption Nachteile von Server-Side ActionScript NET...36 Was wird benötigt?...36 Welche Möglichkeiten werden geboten?...37 Verschiedene Programmiersprachen in.net...38 Vorzüge von.net...39 Nachteile von.net Java EE...41 Funktionsweise von Java EE...41 Ablauf und Infrastruktur...41 Vorzüge von Java EE...42 Nachteile von Java EE...43 OpenAMF AMF::Perl...44 Funktionsweise von Perl...44 Einsatzgebiete von Perl...44 Vorzüge von Perl...45 Nachteile von Perl Gänzlich andere Umsetzungen AJAX...47 Funktionsweise von AJAX...47 Bei AJAX eingesetzte Technologien...48 Ablauf einer AJAX-Anwendung...48 Die Kommunikation im Detail...50 Vorzüge von AJAX...50 Nachteile von AJAX JAVA-Applets...53 Funktionsweise eines Applets...53 Aufbau eines Java-Applets...54 Verschiedene Möglichkeiten der Kommunikation...55 Vorzüge eines Applets...56 Nachteile eines Applets PHPObject...58 Vorzüge von PHPObject...58 Nachteile von PHPObject Netzwerk der Metadaten Tagging

19 Das Kapitel Konzeption beschäftigt sich zunächst mit der Positionierung des Projektinformationssystems, dazu werden Vergleiche zu anderen Anwendungen mit ähnlichen Funktionen gezogen. Anschließend werden die Technologien vorgestellt, mit denen die Kommunikation in unserer Umsetzung statt findet, um danach Alternativen aufzuführen. Dabei geht es zum Einen um Technologien die nur die Serverseite ersetzen und zum Anderen um solche, die Server- und Clientseite ersetzen können. Zuletzt beschäftigt sich das Kapitel mit dem Netzwerk der Metadaten, durch das die Daten in unserem System verknüpft werden Abgrenzung des eigenen Produkts Bei unserem Produkt handelt es sich um eine Anwendung zur Bereitstellung von Daten zu Projektarbeiten, die im studentischen Kontext entstanden sind und gegebenenfalls noch bearbeitet werden können. Es soll eine Kommunikationsplattform angeboten werden, die das Arbeiten mit Projekten vereinfacht und die Weiterführung dieser erlaubt. Des Weiteren bietet es die Möglichkeit mit den Projektverantwortlichen in Verbindung zu treten. Eine genauere Positionierung des eigenen Produkts ist dennoch schwierig Content Management Systeme Unser System siedelt sich als eine Unterform der Content Management Systeme (CMS) an, bei denen es sich um Anwendungen handelt, die das (gemeinschaftliche) Arbeiten und Organisieren am Inhalt von Text- und Multimedia-Dokumenten erlauben. Der Inhalt (Content) kann dabei in unterschiedlichen Formen vorliegen. So kann er aus einzelnen Dateien bestehen, an denen gearbeitet wird oder aus zusammenhängenden, komplexen Dateistrukturen, wie sie zum Beispiel bei Webseiten auftreten. Dort wird oft der Inhalt in Hypertext Markup Language (HTML) gespeichert und die Formatierung durch Cascading Style Sheets (CSS) vorgenommen. Das Ziel solcher Systeme ist es, die Aufgaben an verschiedene Benutzer zu verteilen. Es wäre möglich, einer Benutzergruppe das Gestalten der Webseite zu gestatten und einer anderen den inhaltlichen, textuellen Teil zu überlassen. Vorteil hierbei ist es, dass sich einzelne Benutzergruppen nur mit den für ihren Bereich wichtigen Fähigkeiten auskennen müssen. (Abb. 2) Ein Benutzer, der beispielsweise für die Texte einer Webseite zuständig ist, muss keine Kenntnisse von der Programmierung dieser Seite haben. Ein weiterer Vorteil der Aufteilung in verschiedenen Benutzergruppen ist die Sicherheit. Es wird garantiert, dass die Benutzer nur die Arbeiten erledigen für die sie qualifiziert sind. 11

20 Content Management Systeme Damit ein CMS die Ausgabe in gängige und relevante Publikationsformate, wie beispielsweise das Portable Document Format (PDF)3 unterstützen kann, ist eine medienneutrale Datenhaltung erforderlich. Das bedeutet, dass der Inhalt unabhängig vom Datenformat gespeichert und erst bei Bedarf an die gewünschte Ausgabe angepasst wird. Zur Datenhaltung werden heute in der Regel Datenbanken eingesetzt. Um die Einsatzgebiete heutiger CMS weitestgehend offen zu halten, zeichnen sich diese durch ein sehr hohes Maß an Flexibilität und Erweiterbarkeit aus. Die meisten CMS lassen sich durch Zusatzprogramme erweitern und somit an die eigenen Bedürfnisse anpassen. Ein bekanntes und sehr umfangreiches CMS, welches in der Wirtschaft oft eingesetzt wird und die genannten Funktionen unterstützt ist TYPO34. Abbildung 2: Aufbau eines CMS Digital Asset Management-Systeme Einen ähnlichen Funktionsumfang liefern die so genannten Digital Asset ManagementSysteme (DAM), mit denen vorzugsweise Multimediadateien gespeichert und verwaltet werden können. Der Schwerpunkt bei diesen Systemen liegt auf dem Anreichern der Inhalte mit Meta-Daten zu Recherchezwecken und um sie später schnell wiederzufinden. Außerdem ist eine eindeutige Versionierung bei Änderungen des Inhalts wichtig, um diese gegebenenfalls rückgängig machen zu können. Weiterhin stellen DAM-Systeme Funktionen zur Konvertierung von verschiedenen Dateien zur Verfügung, was am Anwendungszweck unseres Produkts vorbei läuft. Typische Einsatzgebiete für diese Art der Content 3 4 Vgl. Link: 12

21 Digital Asset Management-Systeme Management Systeme liegen in der Musikindustrie, beim Umgang mit großen Bilddaten in der 3D Animation oder in Pressearchiven Redaktionssysteme Redaktionssystem ist die Bezeichnung für eine weitere Form von Content-ManagementSystem, welches sich aber im kleineren Funktionsumfang von den bisher genannten unterscheidet. Bei diesem System soll dem Benutzer das Anlegen von Internet- und Informationsseiten erleichtert werden. Er soll in der Lage sein, Inhalt, ohne Kenntnisse von der eigentlichen Programmierung, hinzuzufügen. Diesen Funktionsumfang unterstützt unser Produkt ebenfalls. Es bietet zusätzlich die Möglichkeit Medien bereitzustellen, die zum Projekt gehören. Der Schwerpunkt von Redaktionssystemen liegt dagegen mehr auf dem gemeinschaftlichen Arbeiten und der sauberen Trennung von Aussehen und Inhalt, weniger auf der strukturierten Information zu einem Produkt. Unser Produkt bringt einige der oben genannten Funktionen mit, ist aber geradlinig auf den eigentlichen Einsatzzweck, nämlich das anzeigen von Projektdaten, zugeschnitten, so dass die Funktionen, die ein CMS oder DAM mehr bietet, wegfallen. (Abb. 3) Es ist beispielsweise nicht vorgesehen, dass mehr als ein Benutzer gleichzeitig am Inhalt eines Projekts arbeitet. Es dient vielmehr dazu, Studenten zu finden, die die angebotenen Projektarbeiten weiterführen möchten. In technischer Hinsicht unterscheidet sich unser System von einem CMS wohl am deutlichsten in der Umsetzung der grafischen Oberfläche, da bei uns ein Fokus auf dem Arbeiten mit dem System liegt und nicht nur in dem Ergebnis der Arbeit. Abbildung 3: Funktionsumfang unseres Systems 13

22 3.2. Die Kommunikationstechnologien unseres Projektinformationssystems 3.2. Die Kommunikationstechnologien unseres Projektinformationssystems Flash Remoting soll uns die Entwicklung unseres Projektinformationssystems erleichtern und die Kommunikation zwischen dem Flash Client und PHP auf dem Server regeln. Doch woraus setzt sich Flash Remoting zusammen, wie läuft die Client-ServerKommunikation ab und was ist AMF sowie amfphp? Flash Remoting Flash Remoting ermöglicht einem Flash Film die Kommunikation zu serverseitigen Remote Services oder Web Services. Es sorgt für die Serialisation von Daten und die Durchführung von Remote Procedure Calls (siehe Kapitel 4.2. ) zwischen Client und Server. Mittels Flash Remoting kann der Flash Film als Interface für die unterschiedlichsten Anwendungen agieren. Hierfür können die verschiedensten Technologien verwendet werden, da Flash Remoting u. a. die Verbindung zu ColdFusion, J2EE,.NET und PHP ermöglicht und dort Datenbanken wie SQL Server, Oracle, DB2, Access, PostgreSQL und MySQL unterstützt. Der Flash Film wird also um die funktionalen Möglichkeiten einer Anwendungslogik erweitert. Zu Flash Remoting gehören: Flash Remoting Components Flash Remoting Gateway oder ein Equivalent (eine open source Umsetzung des Gateways, wie z. B. amfphp, AMF::Perl, OpenAMF) ActionScript Klassen und ein Debugger Des Weiteren ist Flash MX oder eine spätere Version nötig, um Flash Remoting zu verwenden. Flash Remoting Components Die notwendigen Komponenten können kostenlos bei Adobe heruntergeladen5 werden, um sie dann in der Entwicklungsumgebung zu installieren. Sie erweitern den Client bzw. die Entwicklungsumgebung um diverse ActionScript Klassen und Funktionen. NetServices ActionScript Funktionen werden zum Beispiel benutzt, um eine Verbindung zum Application Server oder Web Service aufzubauen. Über diese Verbindung erfolgt dann der Datenaustausch. NetDebug ActionScript Funktionen und der NetConnection Debugger helfen dabei die Flash Anwendung, den clientseitigen Code und die Server Kommunikation zu debuggen. 5 Download Link: 14

23 Flash Remoting Wie die einzelnen Klassen der Flash Remoting Components zusammenspielen, betrachten wir im Kapitel genauer. Flash Remoting Gateway Der Flash Remoting Gateway muß für J2EE oder.net als Paket "Flash Remoting MX" bei Adobe käuflich erworben werden. Man kann ihn aber auch als Testversion downloaden 6. Um diese Kosten zu sparen, könnte man ColdFusion verwenden, da der Flash Remoting Gateway hier bereits enthalten ist. Ansonsten nutzt man ein open source Equivalent. Der Gateway wird auf dem Server installiert und fungiert als Interface zwischen dem Flash Player und dem Server (Abb. 4). Die Flash Remoting Software, welche den Gateway implementiert, wird auch Adapter genannt. Der Gateway umfasst 3 Hauptaufgaben: Requests vom Flash Player an die Remote Services verarbeiten Die Remote Services können sich auf dem gleichen Server wie der Gateway, aber auch auf einem anderen Server (Web Services) befinden. Requests und Daten vom Flash Player in serverseitige Requests und Datentypen übersetzen Responses und Daten vom Server in ActionScript Datentypen übersetzen Abbildung 4: Flash Remoting Architektur Vorteile von Flash Remoting Vergleicht man Flash Remoting mit anderen Technologien, welche die Flash Anwendung mit externen Datenquellen verbinden (wie die HTTP-Funktionen geturl oder loadvariables oder die XML-Funktion XMLSocket) entdeckt man einige Vorteile. 6 Kaufen oder testen unter: 15

24 Flash Remoting Der Flash Film kann zum Beispiel durch den Flash Remoting Gateway serverseitige Methoden direkt aufrufen. Komplexe Objekte, wie RecordSets oder Arrays, können ohne zusätzliche Serialisation durch den Entwickler übertragen werden. Des Weiteren muss sich der Server nicht mehr um das Parsen oder Präsentieren von Daten kümmern. Es ist kein Session Management mehr nötig, da Flash dies clientseitig erledigt, wodurch zusätzliche Ressourcen auf dem Server frei werden. Damit sind komplexere Anwendungslogiken oder zusätzliche Benutzer möglich. Durch die binäre Datenübertragung zwischen dem Flash Film und dem Remote Service ist die Übertragungsgeschwindigkeit erheblich höher. Verglichen mit traditionellen HTML Anwendungen verfügt Flash Remoting über weitere Vorteile, wie die Entwicklung von dynamischen und hoch entwickelten Benutzerinteraktionen. Außerdem kann das User Interface (Präsentationsschicht) von der Anwendungslogik sauber getrennt werden. Dadurch können beide Seiten unabhängig voneinander und sogar durch unterschiedliche Entwickler programmiert werden, sofern die Schnittstellen klar definiert sind. Damit steht der Entwicklung von n-tier Architekturen nichts mehr im Weg. Alle Daten eines Flash Films werden zu Beginn einmal geladen. Danach ist es nicht mehr nötig die ganze Seite neu zu laden, wenn sich Teile des Inhalts ändern. Zu dem unterstützt Flash die Verwendung von Vektor Grafiken, wodurch man einen weiteren Vorteil im flüssigen Ablauf der Anwendung erreicht. Anwendungsgebiete Mit Flash Remoting ergeben sich viele neue Einsatzgebiete für Flash Filme: Es sind Anwendungen denkbar, die eine Verbindung zu einer Datenbank, zu einem Dateisystem oder anderen serverseitigen Technologien benötigen. Es wären Online Shops möglich, die über Kataloge und einen Warenkorb verfügen. Es kann alles in einem Interface untergebracht werden, ohne die Seite neu laden zu müssen. Sound- und Videoclip Bibliotheken sind unter Verwendung der Audio- /VideoFunktionen von Flash in Verbindung mit einem Flash Media Server kein Problem. Mit den Funktionen eines Application Servers kann man sogar durchsuchbare Clip Bibliotheken erstellen. Man kann neue Steuerelemente entwickeln, um sie anstatt von HTML-Elementen zu verwendet. Ein Online Auktions-Interface wäre denkbar, welches die beobachteten Artikel lokal speichert und einen Remote Web Service zum Bieten verwendet 16

25 Flash Remoting Es sind Frontends für Administratoren möglich, um Datenbanken zu bearbeiten. Somit können Tabellen und Daten vom Client aus verwaltet werden, ohne die eigentliche Datenbank zu berühren oder mit der Technologie vertraut zu sein. Nutzung von Systeminformationen und -ressourcen Senden und Empfangen von s Interaktion mit einem Application Server MVC-Modell Flash Remoting wurde für eine Integration in bekannte Entwurfsmuster und Frameworks entwickelt. Es vereinfacht die Implementierung von korrekt strukturierten Entwurfsmustern für Flash-Anwendungen7. Zu diesen Entwurfsmustern gehört das MVC-Modell (Model-View-Controller) (Abb. 5). Dieses Architekturmodell ist in der Softwareentwicklungsgemeinschaft für Benutzeroberflächen-orientierte Anwendungen verbreitet. Das MVC-Modell beschreibt die strenge Abtrennung der Daten (Model) von der Anzeige (View) und der Anwendungslogik (Controller). Abbildung 5: MVC-Modell in Flash Remoting Modell (Model) Das Modell enthält die Daten der Anwendung (Datenmodell) und verarbeitet diese. Bei einer Webanwendung besteht dieses Modell normalerweise aus dem Anwendungsserver-Programm und der Datenbank. 7 Vgl. 17

26 Flash Remoting Ansicht (View) Die Ansicht stellt die Benutzeroberfläche dar, die normalerweise aus Benutzersteuerungen und Informationsanzeigen besteht (Sicht auf die Daten). Controller Unter Controller wird die Logik verstanden, die die Benutzereingaben verarbeitet und das Modell oder die Ansicht entsprechend verändert (Steuerungsmechanismen). In Abhängigkeit vom Anwendungsdesign kann sich der Controller auf dem Client, dem Server oder beiden befinden. Um die Menge an Netzwerkverkehr zu reduzieren und die Vorteile der Flash-Laufzeit zu nutzen, empfiehlt Macromedia, den Controller in Flash zu implementieren. 18

27 AMF AMF Um Meldungen an Remote-Services senden und von ihnen empfangen zu können, verwendet Flash Remoting das Action Message Format (AMF), ein für das ActionScriptObjektmodell entwickeltes binäres Nachrichtenformat. Mithilfe von AMF kodiert Flash Remoting Datentypen zwischen der Flash-Anwendung und dem Remote-Service über HTTP in beide Richtungen, welches eine beiderseitig transparente Datenübertragung ermöglicht. Es wurde von Macromedia entwickelt, um Daten zwischen dem Flash Player und dem Flash Remoting Gateway leicht und effizient zu serialisieren, deserialisieren und zu transportieren. Die AMF-Meldungen werden mittels Standard HTTP Request gesendet (Abb. 6). Ein AMF Paket wird als binary POST übertragen. Der Body des Requests enthält die serialisierten, binären Daten und Angaben zum Remote Procedure Call. Flash Remoting benötigt einen Browser, der einen binären (binary) POST unterstützt, was Netscape 6.x oder älter Browser nicht tun. In diesem Fall bleibt der Remote Procedure Call ohne Effekt und kein Fehler wird zurückgegeben. Abbildung 6: Kommunikation mittels AMF Aufbauend auf dem Simple Object Access Protocol (SOAP) verwendet AMF ein Paketformat zum Weiterleiten von Informationen. Ein AMF-Paket besteht aus den folgenden Elementen: Paket-Header mit AMF-Versionsinformationen Anzahl der Kontext-Header Array von Kontext-Headern, die beschreibende Informationen zu dem Kontext enthalten, in dem einzelne AMF-Meldungen verarbeitet werden sollten Anzahl der Meldungen Array von Meldungen Der Content-Type von AMF ist: application/x-amf. Die AMF Daten sind größtenteils binär, jedoch sind auch lesbare Strings enthalten ( im Body des Request/Response). Die Vorteile von AMF gegenüber der traditionellen Serialisierung von Daten in Flash durch XML oder URL encoded Strings sehen wie folgt aus: AMF ist ein binäres Format und erzeugt serialisierte Daten, die kleiner sind als bei String basierten Encodings. Dadurch sind sowohl die Anforderungen an die Bandbreite geringer, als auch die Lade- und Antwortzeiten kürzer. 19

28 AMF AMF wurde für die Serialisierung von ActionScript Datentypen entwickelt. Damit kann es schnell und effizient aus ActionScript Objekten serialisieren und in ActionScript Objekte deserialisieren, was zu dem beschriebenen Performanzgewinn führt. Warum verwendet Flash Remoting AMF, anstatt von SOAP, zur Kommunikation mit dem Flash Player? SOAP wurde entwickelt, um Nachrichten in verteilten Anwendungen auszutauschen, genau wie AMF. Außerdem können Beide Remote Services aufrufen und über HTTP bzw. HTTPS arbeiten. Dennoch gibt es Gründe, warum Macromedia AMF entwickelte anstatt SOAP zu benutzen: Die mit SOAP übertragenen Daten sind in XML kodiert, wodurch die Pakete größer sind als beim binären AMF und damit die Übertragungsdauer länger. AMF wurde entwickelt, um mit den ActionScript Datentypen zu arbeiten. AMF im Flash Player zu deserialiseren ist effizienter als das Parsen und die Deserialisierung von SOAP, da AMF für die ActionScript Datentypen optimiert wurde und SOAP ein allgemeingültiges Protokoll ist. Selbst wenn SOAP-Nachrichten komprimiert wären, würde die Serialisierung mit AMF immer noch effizienter sein. 20

29 Kommunikation Kommunikation Die Kommunikation zwischen Flash Player und Flash Remoting Gateway verläuft über HTTP und bringt folgende Besonderheiten mit sich: Die Kommunikation wird durch Requests gesteuert. Der Flash Player muss die gesamte Kommunikation mit dem Gateway initiieren, da der Server keine Daten senden kann; es sei denn, der Flash Player fordert sie an. Nur über einen Umweg mit XMLSocket oder mit dem Flash Media Server8 wäre das Pushen durch den Server möglich. HTTP ist ein zustandsloses Protokoll. Der Flash Remoting Gateway erkennt den Zustand anhand von Cookies. Sollten keine Cookies beim Client verfügbar sein, entnimmt er die Zustandsinformationen dem AMF Paket Header. Die Benutzung von HTTPS sowie SSL wird unterstützt und verleiht Flash Anwendungen die gleiche Sicherheit wie HTML Anwendungen Architektur Flash Remoting Anwendungen folgen einer n-tier Architektur (Abb. 7). Diese umfasst eine Präsentationsschicht auf dem Client (der Flash Player), eine Middle Tier (Flash Remoting Gateway auf dem Server) und eine Data Tier (Datenbank, XML Datei oder andere Datenquellen). Abbildung 7: n-tier Architektur 8 Vgl. 21

30 Kommunikation Presentation Tier Sie ist verantwortlich für das User Interface der Anwendung und die nötige clientseitige Programmierlogik, wie die Validierung von Daten. Die Presentation Tier kommuniziert nur mit der Middle Tier, an die sie Daten sendet oder von ihr empfängt. Middle Tier Sie sitzt zwischen der Presentation Tier und der Data Tier. Ihre wichtigste Aufgabe besteht darin, dem Flash Player den Zugang zu den jeweiligen Daten zu ermöglichen. Des Weiteren enthält die Middle Tier den Remoting Gateway und die vollständige Anwendungslogik. Somit liegt die Aufgabe des Clients nur in der Präsentation. Der Server kümmert sich sowohl um die Kommunikation mit Datenbanken oder anderen Datenquellen, als auch um Anwendungslogik. Data Tier Sie ist verantwortlich für die Verwaltung und Speicherung von Daten. Die Datenquellen können sich auf demselben oder einem anderen Server befinden. Sie umfassen Datenbanken, XML- oder andere Dateien. N-Tier Diese n-tier Architektur ähnelt den n-tier Architekturen, die HTML verwenden und in denen der Web Browser die Presentation Tier darstellt. Es gibt jedoch wesentliche Unterschiede. Die Presentation Tier in Flash arbeitet komplett auf dem Client und kann dynamisch erzeugt werden. Wenn das User Interface erst einmal erstellt oder heruntergeladen wurde, müssen nur noch die aktualisierten Daten zwischen Client und Server ausgetauscht werden. Bei dynamischen HTML Seiten muß immer die ganze Seite neu auf dem Server erzeugt und dann an den Client gesendet werden. Dies geschieht jedes Mal, wenn sich der Status oder die Daten der Anwendung ändern. Es gibt noch einen weiteren Vorteil der n-tier Architektur mit dem Flash Player als Presentation Tier. Die Datenquelle oder das Format kann geändert werden, ohne dass es die Presentation Tier betrifft oder der Flash Film geändert werden muss. Änderungen an der Data Tier betreffen nur die Middle Tier. Somit kann jede Schicht für seine spezielle Aufgabe und Umgebung optimiert werden. Dies ist besonders wichtig für die Client Seite, da diese eine viel variablere und unbekanntere Umgebung als die des Servers sein kann. Es ist bedeutend leichter die Anwendungslogik zu ändern, wenn sie sich ausschließlich in der Middle Tier befindet und nicht über mehrere Tiers oder Technologien verteilt wurde. Die Anwendungslogik aus der Präsentationsschicht herauszuhalten, erlaubt dem Entwickler, die Anwendungslogik separat zu testen, Probleme zu isolieren, Änderungen zu entwickeln und sie in die anderen Tiers der Architektur zu integrieren. 22

31 Kommunikation Wir entschlossen uns den Vorteil unserer verteilten Anwendung zu nutzen und die Aufgaben sinnvoll zu verteilen. Ein Entwickler kümmert sich um die Präsentationslogik (ActionScript) und damit um die Presentation Tier (Flash Film). Der andere Entwickler arbeitet an der Anwendungslogik und entwickelt den serverseitigen Code. Dies schließt neben der Entwicklung der Middle Tier auch die Data Tier mit ein. Jeder Entwickler kann seinen Code unabhängig entwickeln und testen, wodurch die Entwicklung einfacher, schneller und weniger fehleranfällig ist. Dies setzt lediglich voraus, dass die Schnittstellen der jeweiligen Tiers klar definiert sind Ablauf der Kommunikation (Workflow) In Abbildung 8 wird der Ablauf der Kommunikation zwischen Flash Remoting und amfphp grob dargestellt. In diesem Fall liefert der Remote-Service ein Ergebnis (Result) zurück. Abbildung 8: Kommunikationsablauf Unter Verwendung der NetServices API innerhalb von Flash, ruft der Code (vom Entwickler geschrieben) einen Remote Service auf: Call. Die NetServices Bibliothek leitet den Remote Service Call (1) mit einigen Argumenten an das NetConnection Objekt im Flash Player weiter. Das NetConnection Objekt serialisiert den Request in AMF und sendet ihn an den Server als HTTP binary POST (2). Der Flash Remoting Gateway auf dem Server empfängt den Request, deserialisiert ihn und ermittelt den serverseitigen Service, an den der Request weitergeleitet werden soll. Der Flash Remoting Gateway ruft diesen Service auf und gibt die Argumente weiter, die mit dem Request gesendet wurden (3). Danach erhält der Remoting Gateway alle Daten vom Service (z. B. String oder RecordSet 4), serialisiert diese in AMF und sendet sie an den clientseitigen Flash Player mittels HTTP Response zurück (5). 23

32 Kommunikation Der Flash Player empfängt die AMF Daten und deserialisiert diese in entsprechende ActionScript Datentypen. Abhängig von den empfangenen Daten wird die Deserialisierung im Flash Player oder im NetServices Code durchgeführt. Zuletzt werden die ActionScript Datentypen an eine ActinScript Callback Funktion übergeben (6), die vom Entwickler für den Empfang von serverseitigen Daten geschrieben wurde. 24

33 Amfphp Amfphp Amfphp ist ein open source Flash Remoting Gateway, also eine ganzheitliche Implementierung von Flash Remoting für PHP mit zusätzlichen Funktionen, um die Entwicklung von Remoting Anwendungen einfacher zu machen. Eine dieser Funktionen ist der integrierte Service Browser9, welcher das Testen von asynchronen Anwendungen und die Entwicklung von Stub Code sehr nah zusammenbringt. Amfphp wurde mit dem Ziel der Interoperabilität entwickelt und benutzt deswegen keine Flash spezifischen Objekte oder Schlüsselwörter. Die Klassen, welche für das amfphp Framework entwickelt wurden, sind normale PHP Klassen mit einem methodtable Attribut, welches nicht stört, wenn man diese Klassen in einem anderen Zusammenhang verwendet. amfphp ist ein interoperabler Remoting Gateway, anders als sprachspezifische Lösungen wie PHPObject. Das bedeutet, dass es einfach ist, Anwendungen, die für ColdFusion, Java oder.net Remoting entwickelt wurden, zum amfphp Framework zu migrieren: das ActionScript bleibt im Grunde unverändert. Die meisten Implementierungen von Flash Remoting (mit Ausnahme von WebORB 10) benutzen Remoting spezifische Objekte und Strukturen auf der Server Seite, z.b. verwendet Macromedias.Net Implementierung ASObject um ActionScript Objekte zu wrappen und ColdFusion besitzt ein Flash Struct, um Aufgaben wie pagesize zu lösen. Dagegen kann amfphp ActionScript Objekte direkt verarbeiten. PHP PHP ist ein rekursives Akronym und steht für "PHP: Hypertext Preprocessor". Es ist eine open source Programmiersprache, dessen Syntax an Perl und Java angelehnt ist. Es eignet sich besonders für die dynamische Entwicklung von Webseiten und Webanwendungen. PHP verfügt über eine breite Datenbankunterstützung und Internet-Protokolleinbindung. Es zeichnet sich durch seine leichte Erlernbarkeit und seine umfangreichen Funktionsbibliotheken aus. PHP ist eine serverseitig interpretierte Scriptsprache. Der Quelltext wird also nicht an den Browser gesandt, sondern an einen Interpreter auf dem Webserver. Dessen Ausgabe wird dann an den Browser übermittelt. Somit bleibt der Quelltext auf dem Server und ist dem Benutzer nicht ersichtlich. Ein weiterer Vorteil der serverseitigen Ausführung ist, dass keine Inkompatibilitäten mit irgendeinem Browser auftreten können und auch keine besonderen Fähigkeiten oder Plug Ins nötig sind. 9 Vgl. 10 Vgl. 25

34 Amfphp Ein Nachteil von PHP ist jedoch, dass jede Benutzeraktion erst beim erneuten Aufruf der Seite erfasst werden kann. Des Weiteren wird bei jedem Aufruf die Seite erneut durch den Interpreter geprüft und übersetzt, wodurch die Reaktionszeit des Servers gemindert wird. PHP 5 Seit Juli 2004 ist die aktuelle Version PHP 5 mit der Zend Engine 2.0 verfügbar11. Diese Version verfügt über weitreichende Neuerungen im Vergleich zu den vorigen Versionen. So wurde unter anderem ein neues objektorientiertes Modell und weitere objektorientierte Funktionen eingeführt, sowie die Speicherverwaltung überarbeitet. Eine wichtige Weiterentwicklung stellen Objekt-Variablen dar, welche nur noch eine Referenz auf das Objekt sind und nicht mehr das Objekt selber. Wichtige Teile der Standardbibliothek sind nun auch objektorientiert. Zu den neuen objektorientierten Funktionen gehören u. a.: Festlegung der Sichtbarkeit der (Klassen-) Eigenschaften (public, private, protected) Ein Konstruktor und ein Destruktor Interfaces Der instanceof Operator Finale Klassen und Methoden Statische Klassen und Methoden Abstrakte Klassen und Methoden Konstanten Iteratoren Klonen von Objekten Exceptions mit den Schlüsselwörtern try, catch und throw In der Version 5.1 wurde mit PHP Data Objects (PDO), einer Datenbankabstraktionsschicht, eine neue objektorientierte Erweiterung aufgenommen, die einen einheitlichen Zugriff auf die verschiedenen SQL Datenbanken ermöglicht. In der Version 5.2 wurde u. a. eine objektorientierte Date Erweiterung, sowie Filter zum Verifizieren und Filtern von Benutzereingaben hinzugefügt. Des Weiteren kann PHP 5 nun mit JSON arbeiten und ZIP-Archive auslesen oder erstellen. Die neue Speicherverwaltung (Memory Manager) arbeitet schneller, effektiver und liefert eine Unterstützung von multi-thread Umgebungen. 11 Vgl. 26

35 Amfphp Dank der vielen Optimierungen und Änderungen arbeitet PHP 5 im Allgemeinen schneller als die Vorgängerversion PHP 4. Dies ergaben Benchmarktests12 durch das SourceLabs13 Certification Team mit den Versionen PHP und PHP Die Testwerte reichen im Wesentlichen von "gleich auf" bis zu 20,49% besser als PHP4. In einigen wenigen Testfällen schnitt PHP 4 sogar besser ab als PHP 5. Zend Engine 2.0 Alle Neuerungen verdankt PHP 5 der neuen Zend Engine 2.0. Ihre Änderungen haben eine neue PHP Version nach sich gezogen, da sie den Kern der Sprache darstellt. Die Zend Engine 2.0 leitet eine neue Generation ein, wobei das Hauptaugenmerk auf der Implementierung essenzieller Sprachelemente und einer verbesserten objektorientierten Verhaltensweise liegt. Diese zeichnet sich durch eine bessere, sowie schnellere objektorientierte Unterstützung aus. Sie ermöglicht eine einfachere Codepflege und Wartung von Webanwendungen in PHP 5. Die Zend Engine 2.0 übernimmt die Codeaufbereitung, wodurch nur Seiten ausgeführt werden, die keine Fehler aufweisen, nachdem sie den Code geparst, die Syntax überprüft und alles kompiliert hat. Der Interpreter wurde in Module mit klar umrissenen Aufgaben (u. a. Script parsen, Ressourcenverwaltung, Scriptausführung) aufgeteilt. Auch wenn dieser Ansatz zunächst kompliziert wirkt, eröffnet er doch neue Möglichkeiten. Code- und Speicheroptimierungen können zielgerichtet durchgeführt werden. Der Einfluss durch Seiteneffekte auf andere Programmteile ist minimiert. Diese Modularisierung macht die Pflege und Wartung erheblich leichter. Trotz der vielen objektorientierten Neuerungen in der Zend Engine, die PHP 5 um bekannte Programmiertechniken und Paradigmen erweitert und es näher an Java bzw. JSP führt, bleibt es eine leicht zu erlernende Sprache. Vorzüge von amfphp Es gibt viele Argumente, die für amfphp sprechen14: Es ist frei verfügbar und open source. Es ist schnell und zuverlässig. Das Framework ist pattern-based und die Programmierung wurde so einfach gehalten, dass es keine Schwierigkeit darstellt, es zu erweitern. Man entwickelt ausschließlich in OOP, was zu einem sauberen Programmierstil führt. 12 Vgl. 13 Vgl. 14 Vgl. 27

36 Amfphp Der Gateway und die Services sind voneinander getrennt, damit sind die Klassen auch außerhalb von amfpfp wiederverwendbar. Amfpfp ist sehr flexibel und benötigt nur eine amfpfp spezifische Variable pro Klasse, die definiert werden muss: methodtable. Dies unterstützt die problemlose Wiederverwendung der Klassen außerhalb von amfpfp. Die SQL Handler sind vollständig, d. h. man kann MySQL, postgress, adodb, sqlite, mysqli und weitere benutzen. Zudem ist es einfach neue SQL Filter zu entwickeln. Es gibt die Option, die RecordSets gleich als pageable recordset zu erhalten. amfpfp ist interoperabel mit ColdFusion,.NET, Java, Python, Perl, usw. Hinter amfpfp steht eine große Community, die an der Weiterentwicklung von amfpfp arbeitet. Durch die Kombination von PHP auf der Serverseite und Flash auf der Clientseite können ihre jeweiligen Stärken vereint werden. Neben einer dynamischen Benutzerinteraktion, die alle Aktionen des Benutzers sofort erfasst und bei der es nicht nötig ist, die Seite neu zu laden, wenn sich Inhalte ändern, findet sich eine flexible und zu vielen Seiten kompatible, serverseitige Anwendungslogik. Somit werden auch ihre jeweiligen Schwächen kompensiert. 28

37 3.3 Alternative Technologien 3.3 Alternative Technologien Dieses Kapitel teilt sich in zwei Bereiche. Der erste Bereich behandelt alternative Technologien, die nur auf der Serverseite einsetzbar sind und der zweite Bereich solche, die Server- und Clienttechnologien ersetzen können Serverseitige Umsetzung Der folgenden Abschnitt beschreibt alternative Technologien, welche die Serverseite der Anwendung umsetzen und gleichzeitig einen Flash Remoting Gateway zur Verfügung stellen. Dabei wurden nur solche Technologien berücksichtigt, die den von uns benötigten technischen Anforderungen genügen. Da unser Client in Flash realisiert wird, ist die Hauptanforderung demnach mit Flash kommunizieren zu können ColdFusion MX ColdFusion (CF) ist eine serverseitige Technologie, mit der Anwendungen erstellt werden können. Flash Remoting ist eine eingebaute Funktion von ColdFusion und muss demnach nicht extra für den Server bezogen werden. CF ist eine Sprache, die auf Tags basiert und als eine Erweiterung zu HTML entwickelt wurde. Der Entwickler kann mit Hilfe von ein paar Tags eine komplexe Anwendungslogik erstellen. ColdFusion ist so einfach, dass Flash Entwickler die Remote Services für ihre Anwendungen selber entwickeln können. Sie müssen es aber nicht, da hier die Client Seite unabhängig von der Server Seite programmiert werden kann. ColdFusion ist wegen seiner leichten Nutzung, seiner Vielseitigkeit und seiner nahtlosen Flash Integration eine gute Lösung für die Entwicklung einer Anwendungslogik (Abb 9). Man unterscheidet hierbei drei unterschiedliche, serverseitige Implementierungen: ColdFusion Markup Language pages ColdFusion Components Server-Side ActionScript (siehe Kapitel ) 29

38 3.3.1 Serverseitige Umsetzung Abbildung 9: Kommunikation zwischen Flash und ColdFusion Über folgende Funktionen und Eigenschaften verfügt ColdFusion unter anderem: Einfache Datenbankintegration Eingebaute Verarbeitung von XML Unterstützung bei "custom" Tags und JSP Tag Bibliotheken Eingebaute Sicherheitsfunktionen (Sandbox Sicherheit, rollenbasierte Sicherheit) und FTP Server Integration, um webbasierte und FTP Clients zu entwickeln Session Management Für viele Plattformen verfügbar (Windows, Linux, MacOSX) Leichte Integration in Enterprise-Systeme, mit eingebauter Unterstützung für LDAP, EJB, COM und CORBA ColdFusion Anwendungen werden mit der ColdFusion Markup Language (CFML) und CFScript entwickelt. Die Syntax von CFML ähnelt HTML, die von CFScript erinnert dagegen an JavaScript und ActionScript. ColdFusion ist in Java geschrieben und läuft als Java Servlet. Der ColdFusion Application Server besitzt einen Präprozessor. Benutzer Requests werden vom Web Server an den ColdFusion Server weitergegeben. Die Tags der jeweiligen CF Page werden sequentiell abgearbeitet. Beim ersten Aufruf der Seite wird sie in ein Java Servlet kompiliert. Jeder weitere Aufruf der Seite profitiert von dem Geschwindigkeitsvorteil des kompilierten Codes. 30

39 3.3.1 Serverseitige Umsetzung ColdFusion Pages Der Sinn von CF Pages liegt darin, serverseitige Prozesse durch eine einfach Markup Sprache (CFML) nutzbar zu machen und die Ergebnisse in einem Web Browser anzuzeigen, wodurch man dynamische Webseiten entwickeln kann. Da ColdFusion Pages Ausgaben in einem Web Browser erzeugen, sind sie nicht das typische Anwendungsgebiet für Flash Remoting. Dennoch gibt es zwei Gründe, warum es trotzdem Sinn macht, das ColdFusion Pages für Flash Remoting zugänglich sind: Viele ColdFusion Entwickler verfügen über große Kenntnisse, wie man CF Pages erzeugt und mit diesen arbeitet. Es existieren Anwendungen, die bereits CF Pages benutzen. Anstatt diese erneut zu schreiben, um ein Flash Interface zu nutzen, können die CF Pages leicht verändert werden, so dass Flash Remoting Anwendungen die existierende Anwendungslogik verwenden kann. Das Aufrufen einer ColdFusion Page mit einer Flash Anwendung via Flash Remoting lässt sich in drei wesentliche Schritte teilen: Aufrufen einer ColdFusion Page Parameter an die CF Page übergeben Werte von der CF Page entgegen nehmen (Return) ColdFusion Components ColdFusion Components (CFCs) zu benutzen ist ein angenehmer Weg, Code in wiederverwendbare Funktionen zu kapseln. Diese können sowohl von CF Pages, als auch von Flash Filmen oder Web Services aufgerufen werden. Die Kombination von ColdFusion Components Funktionen und Flash Remoting passt sehr gut zusammen. CF Pages machen nur Sinn, wenn man bereits existierende CF Anwendungen für Flash Remoting zugänglich machen will. Sie sind dennoch für die Ausgabe im Web Browser gedacht. Auf der anderen Seite sind ColdFusion Components dafür vorgesehen, spezifische Funktionalitäten zu modularisieren, so dass diese von einem Client, wie einem Flash Film, aufgerufen werden können. Folgende Anwendungen könnten für den Einsatz von CFCs sinnvoll sein: Mit Datenbanken arbeiten (insert, select, delete und update) Systeminformationen vom Server holen (z. B. time, date) Dateioperationen Benutzerverwaltung (Login...) Senden / Empfangen von s FTP Funktionen 31

40 3.3.1 Serverseitige Umsetzung Die Möglichkeiten sind nicht begrenzt. Somit lassen sich gut organisierte, effektiv eingekapselte Bibliotheken von wiederverwendbaren Funktionen erstellen, welche nicht nur von Flash Filmen, sondern auch von anderen Clients aufgerufen werden können. ColdFusion Components sind die nächstgelegene Implementierung eines objektorientierten Programmierkonzepts in ColdFusion. Mit CFCs hat man ein abgeschlossenes Objekt, welches Methoden enthält, die von einem Client aufgerufen werden können. CFCs folgen jedoch nicht dem Konzept der Instantiierung in Verbindung mit Flash. Wenn man ein CFC aufruft, spricht man mit einem statischen Objekt. Generell wird das Instantiierungskonzept unterstützt, obwohl es für Flash nicht verfügbar ist. ColdFusion Pages versus ColdFusion Components Grundsätzlich sollte man seine Entscheidung von der Aufgabe abhängig machen, die gelöst werden soll und dies so effizient wie möglich. Es gibt drei Dinge, die CFCs bieten, welche CF Pages nicht können: Dokumentation CFCs bieten eine gute und automatische Form der Dokumentation, welche man dann in der Flash oder Dreamweaver15 Entwicklungsumgebung durchgehen kann. Automatische Validierung Seit einem CFCs ermöglichen, die Argumente zu definieren, welche eine Funktion akzeptieren soll, kann der ColdFusion Server die Parameter, welche an eine Funktion übergeben werden, automatisch validieren. Für CF Pages muss man solche Validierungen selber entwickeln. Wiederverwendung ColdFusion Components Funktionen können von unterschiedlichen Clients aufgerufen werden, wie Flash Remoting, ColdFusion Pages, anderen CFCs und durch URLs. Wenn man Flash Remoting Services in CF Pages entwickelt, werden diese Pages inkompatibel zu anderen Clients als Flash. Einige Vorteile von CFCs können mit CF Pages simuliert werden, was jedoch zusätzliche Arbeit erfordert. Generell muss man sich vor Augen führen, dass CF Pages für die Ausgabe in einem Browser gedacht sind und nicht ohne Weiteres das Kapseln von Funktionen ermöglichen, damit diese auch anderen Clients als Remote Services zur Verfügung stehen können. 15 Vgl. 32

41 3.3.1 Serverseitige Umsetzung Vorzüge von ColdFusion Mit Hilfe weniger Tags können in ColdFusion komplexe Anwendungslogiken entwickelt werden. Dabei ist ColdFusion einfach genug, so dass die Remote Services selbst von den Flash Entwicklern programmiert werden können. Zu dem lässt es sich nahtlos in Flash integrieren. CF Pages besitzen einen Geschwindigkeitsvorteil gegenüber amfphp, da die Tags nur einmal, beim ersten Abrufen der CF Page, kompiliert werden und nicht, wie bei PHP üblich, bei jeder Ausführung des Scripts. Unsere Anwendung verwendet einen PHP-Cache, um unser kompiliertes PHP-Script nicht bei jedem Aufruf erneut kompilieren zu müssen. Damit fällt dieser prinzipielle Geschwindigkeitsvorteil weg. CFCs profitieren nur von ihrer automatischen Validierung, denn alle anderen Vorteile (wie Dokumentation und Wiederverwendbarkeit), die sich gegenüber den ColdFusion Pages zeigten, werden auch von amfphp abgedeckt. Nachteile von ColdFusion Der vermeintliche Vorteil, dass Flash Remoting bereits in ColdFusion integriert ist und demnach nicht extra bezogen oder gar gekauft werden muss, verschwindet leider hinter den Kosten, die für ColdFusion anfallen. In ColdFusion fehlt ein Werkzeug, wie der Service Browser von amfphp, der die Service Spezifikationen im Web Browser anzeigt. ColdFusion Pages sind lediglich für die Ausgabe in einem Web Browser geeignet und liefern einen beschränkten Funktionsumfang. Sie machen nur dann Sinn, wenn eine bereits existierende ColdFusion Anwendung für Flash Remoting zugänglich zu machen. ColdFusion Components bestechen zwar durch die Möglichkeit, spezifische Funktionalitäten zu modularisieren und eignen sich somit besonders für die Verwendung mit Flash Remoting, jedoch ist das unterstützte Instantiierungskonzept für Flash nicht verfügbar. Deswegen spricht man immer mit einem statischen Objekt, wenn man ein CFC aufruft. Sie stellen dennoch die nächstgelegene Implementierung eines objektorientierten Programmierkonzepts in ColdFusion dar. Amfphp und PHP5 unterstützen dagegen eine objektorientierte Programmierung. Zusätzlich muß ColdFusion ein Flash Struct verwenden, um Aufgaben wie pagesize zu lösen. In amfphp finden sich keine sprachspezifischen Objekte oder Konstrukte, um ActionScript Objekte zu wrappen. 33

42 3.3.1 Serverseitige Umsetzung Server-Side ActionScript Server-Side ActionScript (SSAS) ist Macromedias Weg ActionScript Entwicklern, mit ihrer Erfahrung in der ActionScript Programmierung, die Möglichkeit zu geben, serverseitige Services zu entwickeln, ohne eine neue Sprache wie ColdFusion oder Java erlernen zu müssen. SSAS ist im Grunde JavaScript. Es wurde unter Verwendung des Rhino JavaScript Parsers 16 entwickelt. Rhino ist ein JavaScript Parser (geschriebn in Java), wodurch er gut zu ColdFusion und JRun passt. Macromedia benutze die Rhino Engine für die SSAS Implementierung sowohl in ColdFusion als auch in JRun. Dies sind die beiden einzigen Plattformen, die SSAS bisher unterstützen. Eine SSAS Datei besteht aus Funktionen, welche zu den Methoden des Remote Services werden, die man dann mit Flash Remoting aufrufen kann. Man kann keine SSAS Datei für sich alleine oder durch einen anderen Mechanismus als Flash Remoting aufrufen oder ausführen. SSAS Dateien weisen folgende Beschränkungen auf: SASS Dateien können keinen inline-code ausführen, wie Variablendeklarationen. Dies ist nur Möglich, wenn eine Remote Methode aufgerufen wird. Dann wird der gesamte inline-code der Seite ausgeführt. SASS Dateien können keine anderen Dateien einfügen. Demnach ist es nicht möglich andere Klassen einzubinden oder den Quellcode anderer Dateien hinzuzufügen. Server-Side ActionScript enthält die Kern ECMAScript Sprache, jedoch ohne diverse clientseitige Funktionen, die man von ActionScript gewohnt ist. SSAS benutzt die gleichen Basis Ausdrücke, Operatoren und Objekte wie ActionScript. Es fehlt aber die Unterstützung für MovieClips, Komponenten, die LoadVars Klasse, XML und andere Flash spezifische Funktionen. Server-Side ActionScript ist nur dafür bestimmt, von Flash via Flash Remoting aufgerufen zu werden. Es kann nicht von außerhalb der Flash Umgebung aufgerufen werden. SSAS verfügt aber auch über einige neue Funktionen: Volle Nutzung von regulären Ausdrücken (RegExp Objekte) Try / Catch / Finally Konstruktion zur Fehlerbehandlung wie in JavaScript Volle Nutzung von eval(), was im clientseitigen ActionScript nur partiell unterstützt wird Fähigkeit, Zugang zu Java Klassen aus SSAS heraus zu erhalten 16 Vgl. 34

43 3.3.1 Serverseitige Umsetzung Unter Verwendung von SSAS kann man serverseitige Objekte und Methoden entwickeln, wie man es auf der Client Seite auch tun würde. Für ActionScript Entwickler, die Zugriff auf einen ColdFusion Server haben, liegt die wirkliche Stärke von Server-Side ActionScript im CF Objekt, welches speziell für Flash Remoting entwickelt wurde. Das CF Objekt umfasst zwei Methoden: CF.query() Sie ermöglicht den Zugriff auf Datenbanken. CF.http() Hiermit können HTTP Requests ausgeführt werden. Wann kann man Server-Side ActionScript verwenden? SSAS ist zwar eine Erweiterung der Entwicklungsmöglichkeiten, stellt aber nicht immer den besten Weg dar, um Flash Remoting Services zu entwickeln. Es ist vielmehr eine Erleichterung für Flash ActionScript Entwickler, um serverseitige Services zu entwickeln, ohne eine andere Sprache lernen zu müssen. Um einfache Services zu erstellen, erweist sich SSAS als die schnellere Methode, gegenüber beispielsweise der Erstellung einer Java Datei. Wenn es nötig ist, ein ActionScript Objekt an den Server zu senden, es dort verändern zu lassen und es wieder zurück zum Client zu senden, dann ist SSAS die einfachere Lösung, als bspw. die Umsetzung mit CFML. Nachteile von Server-Side ActionScript Die SSAS-Dateien können nur von Flash Remoting verwendet werden und sind somit nicht interoperabel. Dagegen kann die Service Klasse von amfphp auch von anderen PHPScripten benutzt werden, ohne den Quellcode des Remote Services zu ändern. Des Weiteren fehlt SSAS die Unterstützung von Flash spezifischen Funktionen, wie z. B. MovieClips, Kompoenenten oder XML. Generell verfügt Server-Side ActionScript über sehr eingeschränkte Funktionen. Seine wirkliche Stärke kann es erst in Verbindung mit einem ColdFusion Server zeigen. Deswegen kommen bei der Finanzierung dieser Umsetzung die Kosten für den ColdFusion Server zum an sich kostenlosen Server-Side ActionScript hinzu. Außerdem fehlt ein Werkezeug, wie der Service Browser in amfphp, mit dem man sich die Service Spezifikationen im Web Browser ansehen kann. 35

44 3.3.1 Serverseitige Umsetzung NET Die.NET Implementierung von Flash Remoting bietet die Möglichkeit Flash mit einer Microsoft.Net Anwendung zu verbinden. Man kann sie, wie die anderen Flash Remoting Gateways, bei Adobe kaufen. Das von Microsoft entwickelte.net Framework17 stellt eine Implementierung des CommonLanguage-Infrastructure Standards (CLI) für Windows dar. CLI spezifizierte Systeme ermöglichen eine programmiersprachen- und plattformneutrale Anwendungsentwicklung sowie Ausführung. Die umfangreiche Base-Class-Library (BCL) von.net und die CommonLanguage-Runtime (CLR), eine Virtuelle Maschine ähnlich der von Java, ermöglichen die Nutzung unterschiedlicher Programmiersprachen wie Visual Basic oder C#, um Anwendungen oder Webdienste zu entwickeln. Dabei kann eine.net Anwendung aus verschiedenen Komponenten bestehen, die in unterschiedlichen Programmiersprachen entwickelt wurden. Was wird benötigt? Um Flash Remoting mit.net einsetzen zu können, müssen zunächst, wie bei allen anderen Flash Remoting Gateways auch, die nötigen Komponenten in die Flashentwicklungsumgebung intergriert werden. Da.NET eine von Microsoft entwickelte Technologie ist, arbeitet sie zunächst nur mit den Internet Information Services (IIS) 18, einem Webserver von Microsoft, zusammen. Dabei ist der IIS entweder schon auf dem Windowsserver verfügbar oder kann nachinstalliert werden. Neben dem Webserver wird außerdem noch das.net Framework Software Developement Kit (SDK) benötigt. Es ist frei erhältlich und kann von Microsofts Internetseite19 bezogen werden. Um die Verbindung zwischen dem SDK und Flash herstellen zu können, wird zudem noch ein Gateway auf Seiten des Servers benötigt. Theoretisch ist.net plattformunabhängig, was in der Praxis aber daran scheitert, dass Microsoft nicht daran interessiert ist, diese Technologie für andere Betriebssysteme (außer für Windows) zur Verfügung zu stellen. Aus diesem Grund hat sich das Open-Source-Projekt Mono20 gebildet, welches eine vollständige Kompatibilität mit dem.net Framework anstrebt Vgl. Vgl. Vgl. Vgl. 36

45 3.3.1 Serverseitige Umsetzung Welche Möglichkeiten werden geboten? Flash Remoting MX bietet fünf Möglichkeiten, um mit dem.net Framework zu kommunizieren. 1. Active Server Pages.NET(ASP.NET)21 wird die serverseitige Technologie genannt, um mit dem.net Framework Internetanwendungen zu erstellen (Abb. 10). ASP.NET ist die Weiterentwicklung der Advanced Server Pages, mit denen es bis auf den Namen aber nicht mehr viel gemeinsam hat. Eine wichtige Neuerung von ASP.NET ist die Trennung der Programmlogik und den HTML Elementen. Das Code-Behind Konzept ordnet jeder HTML Datei eine kompilierte Datei zu, so dass zur Laufzeit kein Code mehr übersetzt werden muss. Daraus resultiert beim Aufruf der Internetseite ein höheres Maß an Geschwindigkeit und außerdem werden Fehler schon beim Übersetzen der Klassen festgestellt. Abbildung 10: Kommunikation von.net und ASP.NET 2. Abstract Data Objects.NET (ADO.NET)22 ist eine Sammlung von Klassen, um mit.net auf verschiedene Datenbanken zugreifen zu können. Es existieren Klassen, um eine Datenbankverbindung herzustellen oder die Daten im Arbeitsspeicher zu verwalten. 21 Vgl. 22 Vgl. 37

46 3.3.1 Serverseitige Umsetzung 3. Mit Webservices wird es möglich, Daten und Dienste rechnerübergreifend zur Verfügung zu stellen. Dabei ist das Hauptziel dieser Services, die Interaktion verschiedener Geräte und verschiedener Betriebssysteme zu ermöglichen. An dieser Stelle sei angemerkt, das amfphp auch direkt mit Webservices interagieren kann. 4. Assemblies nennt man kompilierte Programmklassen die sich aus.exe und.dll Dateien zusammensetzen. Die Kombination dieser beiden Dateitypen bilden eine logische Einheit. Bei der Übersetzung werden dieser Einheit weitere Daten hinzugefügt, welche sie näher beschreiben. Diese Daten werden auch Manifest genannt. 5. Mit Windows Forms wird die Möglichkeit bezeichnet, grafische Benutzeroberflächen unter Windows zu erstellen. Verschiedene Programmiersprachen in.net Einer der größten Unterschiede zu amfphp und somit PHP ist die Möglichkeit bei.net verschiedene Programmiersprachen für die Programmierung zu nutzen. Neben der von Microsoft für.net eingeführten Sprache C# werden außerdem offiziell noch C++, Visual Basic.NET sowie J# unterstützt. Neben den offiziell von Microsoft angebotenen Sprachen gibt es zudem noch Sprachen von Drittanbietern wie Delphi.NET von Borland oder F# einer weiteren Programmiersprache von Microsoft ähnlich OCalm. Der genaue Aufbau und das Zusammenspiel der einzelnen.net Komponenten ist in der folgenden Grafik aufgeführt (Abb. 11). Abbildung 11: Aufbau und Funktion einer.net-anwendung 38

47 3.3.1 Serverseitige Umsetzung Vorzüge von.net Bei der Entwicklung des.net Frameworks wurde von Anfang an darauf geachtet, dass Entwickler anderer Programmiersprachen sofort mit der neuen Technik zurecht kommen können. Weiterhin hat man bei Microsoft schnell erkannt, dass der Erfolg von.net zu großen Teilen vom Gewinn bestehender C++ Entwicklern abhängen wird. Deswegen wurde besonders auf die Windowsumgebung Ausführungsgeschwindigkeit stellt man aus Wert diesem gelegt. Grund In keine einer modernen nennenswerten Geschwindigkeitsunterschiede bei der Ausführung einer.net- oder C++-Anwendung fest. Generell ist die Ausführungzeit ein Vorteil, auch gegenüber unserer Umsetzung mit PHP. Bei Scriptsprachen, wozu auch PHP gehört, muss vor jeder Ausführung zunächst das auszuführende Script geparsed und anschließend übersetzt werden. Dieser Vorgang verlängert die Ausführungszeit gegenüber Sprachen wie.net. Die Sicherheit ist ein weiterer Punkt auf den besonderer Wert gelegt wurde. So sieht das Sicherheitskonzept Seitens Microsofts vor, dass die Authentizität der Anwendung gewährleistet werden kann. So kann zum Beispiel die Identität des Programmentwicklers überprüft werden oder der Ausführungsort der Anwendung in die Überprüfung mit einbezogen werden. Zudem existieren Mechanismen, die.net Programme davor schützen, dass sie von Schadprogrammen wie Viren verändert werden. Amfphp bietet ebenfalls Sicherheitsfunktionen, die dem Entwickler bei der Authentizität der Anwendung helfen sollen. In der aktuellen Version ist der Umfang von Sicherheitsfunktionen aber noch nicht mit dem von.net vergleichbar. Um die Entwickler vom eigenen Produkt zu überzeugen, bietet Microsoft mächtige Entwicklungsumgebungen23 an, die zum Teil sogar kostenlos zu bekommen sind. Bei diesen Produkten gehören intelligente Codevervollständigung oder die Einbindung einer sehr umfassenden Dokumentation zum Leistungsumfang. Nachteile von.net Wie schon angesprochen ist die Plattformunabhängigkeit zwar theoretisch gegeben, wird von Microsoft selber aber nicht verfolgt. Man ist also auf alternative Produkte angewiesen, bei denen die Sicherheit einer dauerhaften Existenz nicht gegeben ist. Es ist denkbar, dass Microsoft diese Hersteller bei größer werdender Konkurrenz verklagt und die Produkte in diesem Zug verboten werden. Dies ist auch einer der Hauptgründe warum wir uns nicht für.net entschieden. Mit amfphp (PHP) ist eine höhere Plattformunabhängigkeit gegeben. Der Vorteil, dass in.net verschiedene Sprachen eingesetzt werden dürfen, kann auch als Nachteil angesehen werden. So ist bei der Wartung und Weiterentwicklung solcher 23 Vgl. 39

48 3.3.1 Serverseitige Umsetzung Anwendungen zu bedenken, dass es Experten und Entwickler geben muss, die sich mit der jeweiligen Sprache auskennen. Macromedias.NET Implementierung benutzt ein Remoting spezifisches Objekt (ASObject) auf der Server Seite, um ActionScript Objekte zu wrappen. ASObject steht nach der Installation von Fash Remoting MX for.net auf dem Server zur Verfügung. Bei unserer Implementierung mit amfphp wird auf der Serverseite kein Wrapper benötigt, da amfphp ActionScript Objekte automatisch behandelt. Im Gegensatz zu amfphp, was den Flash Remoting Gateway für PHP darstellt, ist dieser Gateway für.net nicht kostenlos verfügbar. Man muss diesen von Adobe, kostenpflichtig, beziehen,um.net mit Flash einsetzen zu können. In.NET fehlt ebenfalls ein Werkzeug, wie der Service Browser in amfphp, mit dem man sich die Service Spezifikationen im Web Browser ansehen kann. 40

49 3.3.1 Serverseitige Umsetzung Java EE Mit "Flash Remoting for J2EE" (Java 2 Enterprise Edition) steht eine Möglichkeit zur Verfügung aus einem Flash Film heraus mit einem Java basierten Server zu kommunizieren. Java EE (ehemals J2EE)24 spezifiziert eine Softwarearchitektur, bei der die transaktionsbasierte Ausführung von Java-Anwendungen festgelegt wurde. Es geht dabei um die Spezifikation von Webanwendungen die primär in der Sprache Java geschrieben sind, dies aber nicht voraussetzen. Es soll ein allgemein gültiger Rahmen zur Verfügung gestellt werden, auf dessen Grundlage mehrschichtige und verteilte Anwendungen programmiert werden können. Damit Komponenten unterschiedlicher Hersteller einfach miteinander Kommunizieren können, werden diese durch klar definierte Schnittstellen verbunden. Funktionsweise von Java EE "Flash Remoting for J2EE" ist ein Servlet, das es erlaubt, aus Flash die Eigenschaften der Java Objekte und dessen Methoden auf der Serverseite aufzurufen. Ebenso ist es möglich Resultate zu verarbeiten, ohne dass sich der Flash-Entwickler um eine Konvertierung dieser kümmern muss. Diese Fähigkeiten werden auch Java introspection oder reflection genannt. Das Servlet und die dazugehörigen Klassen bilden den Flash Remoting Gateway. Dieser Gateway ist in seinen Kernkomponenten genauso implementiert wie der des ColdFusion Servers, da beide Technologien Java als Programmiersprache benutzen. Unterschiede sind nur die speziell vom ColdFusion Server zur Verfügung gestellten Services (siehe Kapitel ). Ablauf und Infrastruktur Um Java EE einsetzen zu können, wird ein Application Server vorausgesetzt, der Servlets ab der Versionen 2.2 unterstützt. Explizit von Adobe genannte Server sind dabei der JRun 4.0, IBM WebSphere Application Server, BEA WebLogic und Sun ONE Web Server. Bei Enterprise JavaBeans (EJB) handelt es sich um standardisierte Komponenten eines J2EE Servers, die häufig zum Einsatz kommen. Flash Remoting bietet jedoch nicht bei allen Servern die Möglichkeit EJBs anzusprechen. Ein Java EE Server, häufig auch Application Server genannt, besteht nach Spezifikation aus den folgenden Komponenten (Abb. 12): 24 Vgl. 41

50 3.3.1 Serverseitige Umsetzung Der Client Seite Dabei wird unterschieden zwischen einer Desktop-Anwendung (Container) und dem Webbrowser in dem der Flash Film läuft Web Container Ist der logische Container für die Servlets und die Java Server Pages (JSP) EJB Container Hier werden die Enterprise Java Beans aufbewahrt. Das Containermodell des Java EE Servers ermöglicht ein hohes Maß an Sicherheit, da Komponenten so besser voneinander getrennt und die Rechte auf die verschiedenen Container bezogen werden können. Abbildung 12: Aufbau und Kommunikation von Flash und J2EE Bei der Entwicklung einer Flash Anwendung in Verbindung mit einem Java EE Server ist es möglich direkt auf Methoden der Servlets zuzugreifen. Im Allgemeinen wird aber das Konzept der Services benutzt, welches es einem ermöglicht über definierte Schnittstellen zu kommunizieren. Zudem bleibt die eigene Anwendungslogik verborgen und man hält sich an einen Standard, was eine unkompliziertere Kommunikation mit anderen Anwendungen ermöglicht. Vorzüge von Java EE Da die Sicherheit bei Java Anwendungen generell einen hohen Stellenwert einnimmt, bietet Java EE umfangreiche Möglichkeiten der Authentifizierung und Autorisierung. Flash Remoting bietet einfache Möglichkeiten diese bestehenden Umsetzungen in Flash zu nutzen. Wie auch bei der.net Alternative steht der Funktionsumfang von amfphp und PHP, bezüglich der Schutzmaßnahmen etwas zurück. 42

51 3.3.1 Serverseitige Umsetzung Nachteile von Java EE Da Java Programme in Bytecode vorliegen und somit erst zur Laufzeit von der Virtuellen Maschine interpretiert werden, ist die Ausführungszeit im Regelfall länger als bei Programmiersprachen wie C++. In aktuellen Java Versionen soll dieser Umstand zum Teil behoben worden sein, wie man verschiedenen Tests25 entnehmen kann. Setzt man, wie in unserer Anwendung, einen PHP Cache ein, entfällt die Notwendigkeit die eingesetzten PHP Scripte, bei jeder Ausführung, parsen und kompilieren zu müssen, wodurch Ausführungszeiten vergleichbar mit Java und sogar C++ erreicht werden können. Ein weiterer Nachteil sind, wie auch bei.net, die Kosten der Flash Remoting Gateways. Außerdem fehlt ein Werkezeug, wie der Service Browser in amfphp, mit dem man sich die Service Spezifikationen im Web Browser ansehen kann. Macromedias Java Implementierung benutzt, wie auch.net, ein Remoting spezifisches Objekt (ASObject) auf der Server Seite, um ActionScript Objekte zu wrappen. ASObject steht nach der Installation von Fash Remoting MX for J2EE auf dem Server zur Verfügung. Bei unserer Implementierung mit amfphp wird auf der Serverseite kein Wrapper benötigt, da amfphp ActionScript Objekte automatisch behandelt. OpenAMF Neben Flash Remoting for J2EE steht noch eine zweite Java Alternative zur Verfügung. OpenAMF26 ist eine freie (open source) Java Implementierung des Flash Remoting Gateways basierend auf amfphp. Neben dem Vorteil der kostenlosen Nutzung ist OpenAMF flexibel einsetz- und erweiterbar. Leider schreitet die Entwicklung nicht so schnell voran wie bei amfphp selber, weswegen ein produktiver Einsatz für uns nicht in Frage kommt. 25 Vgl. 26 Vgl. 43

52 3.3.1 Serverseitige Umsetzung AMF::Perl Es handelt sich hierbei um eine weitere Möglichkeit die Kommunikation zwischen dem Client (Flash Remoting Components) und dem Server aufzubauen. Im Gegensatz zu den anderen Alternativen wird hier die Skriptsprache Perl27 eingesetzt. Perl ist eine freie, plattformunabhängige Programmiersprache, die für den praktischen Einsatz entwickelt und konzipiert wurde. Perl ist eine Mischung der Programmiersprache C und den UNIX- Befehlen, da das ursprüngliche Einsatzgebiet von Perl die Systemadministration war. Später erst hat sich Perl zu einer der erfolgreichsten und weit verbreitetsten Sprache zur Umsetzung von Internetanwendungen entwickelt. Bei Perl stehen die einfache Programmierbarkeit, ein großer Funktionsumfang und Effizienz im Vordergrund. Ein besonderes Merkmal von Perl ist die Möglichkeit ein Problem auf verschiedene Weise zu lösen. Perl bietet für die Lösung eines Sachverhalts unterschiedliche Methoden an. So kann man zum Beispiel den logischen Operator wie in C oder or wie in Pascal benutzen, um eine UND Abfrage zu formulieren. Derartige Beispiele gibt es unzählige. Sie erlauben es dem Entwickler seine eigenen Vorlieben zu entwickeln oder zu pflegen und zudem effizient die anstehenden Problemstellungen zu lösen. Funktionsweise von Perl Der Perl Interpreter, ein Teil von Perl, welcher die Scripte einliest und zur Laufzeit ausführt, wurde in C entwickelt. Aus diesem Grund liegt eine einsetzbare Version für fast jedes Betriebssystem vor. Dabei funktioniert die Ausführung eines Perl-Scriptes ähnlich wie bei PHP. Der Quelltext, welcher in einer Textdatei vorliegt, wird ausgelesen und vom Interpreter ausgeführt. Dabei werden die Zeilen der Perl-Datei durch den im Interpreter integrierten Parser in einen Syntaxbaum umgewandelt. Der Syntaxbaum ist lediglich eine leichter zu verarbeitende Form des Programmcodes. Einsatzgebiete von Perl Wie schon gesagt wurde Perl zunächst entwickelt, um einfache Aufgaben zu erledigen und den Systemadministrator zu unterstützen. Dabei bietet es mächtige Funktionen Text zu verarbeiten und diesen auch zwischen verschiedenen, zueinander inkompatiblen Anwendungen auszutauschen. Neben dem reinen Austauschen von Daten erlaubt es Perl zudem relativ einfach andere Programme zu steuern, was sich für den administrativen Einsatz besonders gut eignet. Mit einmal geschriebenen Datenbankabfragen ist man dank 27 Vgl. 44

53 3.3.1 Serverseitige Umsetzung Perls Database Integration Interface (DBI) in der Lage, auf verschiedene Datenbanksysteme zuzugreifen. Es muss nur der passende Datenbanktreiber zur Verfügung stehen. Neben PHP ist Perl wohl wegen seiner mächtigen Stringbearbeitungsfunktionen eine der verbreitetsten Scriptsprachen im Internet. Soll Perl auf einem Webserver betrieben werden, ist es notwendig das Common Gateway Interface (CGI) installiert zu haben. CGI ist eine Schnittstelle, welche es dem Webserver erlaubt, Drittsoftware anzusteuern, was in diesem Fall der Perl Interpreter ist. Da Perl oft so arbeitet, dass man es nicht erkennen kann und es zudem meist als Verbinder verschiedener Dienste eingesetzt wird, wurde es auch scherzhaft als das Klebeband des Internets bezeichnet. Ein weiteres Hauptanwendungsfeld von Perl ist die Bioinformatik. Auch hier spielen die schon genannten Vorteile der Sprache die entscheidende Rolle. In der Bioinformatik ist es unerlässlich, Daten zwischen einzelnen Instituten austauschen zu können. Dank der genannten Fähigkeit, mit unterschiedlicher Software kommunizieren zu können, bietet sich Perl also ganz besonders an. Ein anderes Anwendungsgebiet ist die Entwicklung von Desktop-Anwendungen und Spielen. Bei der Leistungsfähigkeit heutiger Rechner ist es durchaus möglich, Spiele oder ähnliches in einer Scriptsprache zu programmieren. Vorzüge von Perl Durch die genannte Eigenschaft, vieles auf unterschiedliche Art und Weise erledigen zu können, ist es dem Entwickler möglich, nah am Problem und am menschlichen Denken zu programmieren. Neben der logischen Komponente existieren aber noch weitere Vorteile. So kann ein Perl-Entwickler auf zahlreiche Module, welche die Funktionalität der Programmiersprache erweitern, zugreifen. Gesammelt werden diese Module im so genannten Comprehensive Perl Archive Network (CPAN)28. Da es etwas ähnliches für PHP nicht gibt, ist dies einer der Hauptvorteile gegenüber amfphp. Nachteile von Perl Der Vorteil, dem Entwickler viele Freiheiten zu lassen, wie er seine Scripte gestaltet, führt oft dazu, dass sie unleserlich werden. So wird Perl oft nachgesagt, in Perl geschriebene Programme seien schlecht zu interpretieren und selbst vom Entwickler nur schlecht zu verstehen. PHP gilt im allgemeinen als leichter zu pflegen, wobei auch in PHP schlecht programmiert werden kann. Da Perl zunächst nur von freiwilligen Entwicklern programmiert und unterstützt wurde, lief die Entwicklung in den Anfangszeiten schleppend. Aus diesem Grund gab es über einen langen 28 Vgl. 45

54 3.3.1 Serverseitige Umsetzung Zeitraum kaum nennenswerte Änderungen, was Perl den Ruf einbrachte, träge zu sein. Dieser Umstand hat sich aber in den letzten Jahren zunehmend verbessert. Des Weiteren fehlt in AMF::Perl ein Werkzeug, wie der Service Browser von amfphp, der die Service Spezifikationen im Web Browser anzeigt. Wie auch bei PHP existiert für Perl ein Bytecode-Cache 29, welcher die Auführungszeiten verringert. Er bietet aber einen geringeren Funktionsumfang und ist auch nicht so problemlos zu installieren. Zudem scheint die Entwicklung seit einiger Zeit nicht mehr regelmäßig statt zu finden. 29 Vgl. 46

55 Gänzlich andere Umsetzungen Gänzlich andere Umsetzungen An dieser Stelle soll auf alternative Möglichkeiten zur Umsetzung des Projektinformationssystems eingegangen werden. Bei Asynchronous JavaScript and XML (AJAX) geht es um eine gänzlich andere Umsetzung des Client Server Modells. Bei Java-Applets handelt es sich um eine andere Form der Umsetzung des Clients in Form eines Java-Programms und bei PHPObjects um eine andere Form der Kommunikation von Client und Server AJAX AJAX bezeichnet ein Konzept, mit welchem asynchron Daten zwischen einem Internetbrowser und dem Webserver ausgetauscht werden können. Die asynchrone Kommunikation erlaubt es, innerhalb einer HTML Seite HTTP-Anfragen durchzuführen, ohne dass die ganze Webseite neu geladen werden muss. Der eigentliche Vorteil liegt darin, dass die Webseite nach und nach bestimmte Bereiche der Webseite nachladen oder vervollständigen kann und dem Anwender diese Daten somit schneller und direkt zur Verfügung stehen. Die Technologie, die hinter AJAX steckt, ist keinesfalls neu, sie setzt sich aus bekannten, einzelnen Komponenten zusammen. Da wären zum Einen JavaScript30, das auf der Seite des Clients eingesetzt wird und zum Anderen XML31, um die Daten vom Server zum Client zu übertragen (Abb. 13). Die Implementierung der Serverseite ist dabei nicht vom AJAX Konzept festgelegt und kann in verschiedenen Programmiersprachen wie beispielsweise.net, Ruby oder PHP umgesetzt werden. Funktionsweise von AJAX Auf der Clientseite wird ein Internetbrowser vorausgesetzt, der JavaScript und das XMLHttpRequest-Object unterstützt. Auf Seiten des Webservers sind verschiedene Konfigurationen denkbar, da das AJAX-Konzept auf keine spezifische Technik festgelegt ist. So können die serverseitigen Aufgaben durch Enterprise JavaBeans, einer standardisierten Komponente des J2EE-Servers, also in Java erledigt werden. Eine Umsetzung ist auch mit.net Komponenten denkbar..net bietet dabei die Möglichkeit wiederum verschiedene Programmiersprachen zu verwenden. Außerdem kann die Umsetzung auf dem Server auch mit Scriptsprachen wie PHP oder Ruby32 erledigt werden. 30 Vgl. 31 Vgl. 32 Vgl. 47

56 Gänzlich andere Umsetzungen Bei AJAX eingesetzte Technologien Hier sollen nur auf die am häufigsten verwendeten Internet-Techniken im Umgang mit AJAX genannt werden. Hypertext Markup Language (HTML) oder Extensible Hypertext Markup Language (XHTML) sind beides Auszeichnungssprachen zur Darstellung von Inhalten wie Text und Bildern im Internetbrowser. Das Document Object Model (DOM) ist eine Programmierschnittstelle (API), um auf HTML- oder XML-Dokumente zugreifen zu können. JavaScript stellt die Elemente, die dynamisch nachgeladen werden sollen, dar und manipuliert das DOM. Des Weiteren dient JavaScript als Schnittstelle zwischen den anderen Komponenten. Das XMLHttpRequest-Object33 ist der eigentliche Bestandteil moderner Internetbrowser zur asynchronen Datenübertragung zum Webserver. On-Demand JavaScript ist eine weitere Möglichkeit, Daten zwischen dem Internetbrowser und dem Webserver auszutauschen. Hierbei wird eine JavaScriptDatei per DOM-Manipulation angefordert. Simple Object Access Protocol (SOAP) ist ein Protokoll und wird zur Übertragung der Daten benutzt. Dabei wird auf die Dienste anderer Standards zurückgegriffen. Beispielsweise wird XML zur Repräsentation der Daten benutzt. Cascading Style Sheets (CSS) ist eine Sprache zur Strukturierung von Dokumenten, die meist im Zusammenhang mit HTML und XML eingesetzt wird. Ablauf einer AJAX-Anwendung Zunächst wird das Funktionsprinzip und Verhalten einer klassischen Internet-Anwendung erläutert, um die Vorzüge einer AJAX Anwendung zu verdeutlichen. Bei der Übermittlung von Formularen in Internetseiten füllt der Benutzer diese zunächst aus und übermittelt deren Inhalt dann an den Webserver. Der Webserver generiert aus den an ihn übermittelten Daten eine entsprechende Webseite und schickt diese an den Benutzer zurück. Da dieser Vorgang bei jeder Anfrage des Benutzers wiederholt werden muss, also bei jeder Übermittlung an den Webserver eine neue Internetseite erzeugt wird, kommt dem Benutzer das Verhalten der Internetseite träge und wenig intuitiv vor. Bei einer AJAX-Anwendung hingegen ist der Webserver in der Lage zu erkennen, welche Daten dieser benötigt, um diese an ihn zu schicken. Dabei werden die verschickten Daten nicht direkt im Internetbrowser des Clients dargestellt, sondern durch die AJAX Client-Engine bearbeitet und in die Webseite eingefügt (Abb. 13). Das Übermitteln der Daten geschieht 33 Vgl. 48

57 Gänzlich andere Umsetzungen dabei in den meisten Fällen über den Aufruf eines SOAP Webservices. Da nur die benötigten Daten übertragen werden müssen und nicht die komplette Seite, geht dies zum Einen schneller und zum Anderen nimmt das Datenvolumen erheblich ab. Ein weiterer Vorteil ist die geringere Belastung des Webservers, da die Verarbeitung der Daten oft schon vom Client erledigt werden kann. Abbildung 13: Vergleich einer klassischen- mit eine AJAX-Anwendung 49

58 Gänzlich andere Umsetzungen Die Kommunikation im Detail Wenn der Internetbrowser des Benutzers eine Anfrage an den Server stellt, dann geschieht dies nicht wie bei einer klassischen Anwendung direkt, sondern es wird an die AJAX ClientEngine gesendet. Diese Engine übermittelt die Daten dann an den Server. Währenddessen kann der Benutzer ganz normal weiter arbeiten. Hat der Server die Anfrage bearbeitet, schickt er das Ergebnis an den Client zurück, woraufhin dieser es dann für die Ausgabe aufbereitet und in die Webseite einbindet. Bei einer Internetseite ohne AJAX muss der Anwender auf die Antwort des Servers warten, bis er weiterarbeiten kann (Abb. 14). Abbildung 14: Asynchrone Kommunikation einer AJAX-Anwendung Vorzüge von AJAX Einer der wichtigsten Vorteile des AJAX Modells und auch von Flash, gegenüber statischen HTML Seiten, ist wohl, dass Daten verändert werden können, ohne dass alle Daten der Webseite neu an den Internetbrowser übertragen werden müssen. Es wird außerdem vermieden, dass Daten, die sich nicht geändert haben, immer mit übertragen werden müssen. Durch diesen Umstand erhält der Benutzer schneller seine Daten und auf seine Eingaben kann schneller reagiert werden. Die verwendeten AJAX-Technologien sind frei erhältlich und werden somit auf allen Betriebssystemen und Internetbrowsern unterstützt, sofern sie mit JavaScript umgehen können und es nicht abgeschaltet wurde. Die freie Verfügbarkeit der Technologien kann ein Vorteil gegenüber kommerziellen Produkten wie Flash (in unserem Fall) sein. Man ist nicht abhängig von einem Unternehmen und muss somit auch nicht befürchten, dass dieses den Support oder die Weiterentwicklung für die Technologie einstellt. Ein Weiterer Vorteil ist, dass im Gegensatz zu anderen Technologien, 50

59 Gänzlich andere Umsetzungen wie Adobes Shockwave oder Flash, AJAX kein Browserplugin benötigt, welches zusätzlich installiert werden muss. Nachteile von AJAX Umsetzungen mit AJAX wird, ähnlich wie denen in Flash, oft der Vorwurf gemacht, dass der Zurück-Knopf im Internetbrowser nicht funktioniert. Wenn der Benutzer den Zurück-Knopf betätigt, erwartet dieser, wie es bei herkömmlichen HTML Seiten der Fall ist, dass die zuletzt von ihm getätigte Aktion rückgängig gemacht wird. Da bei AJAX Anwendungen aber nicht immer komplette Webseiten übertragen werden und die dynamisch geladenen Teile vom Verlauf des Internetbrowser nicht erkannt werden können, werden diese somit auch nicht rückgängig gemacht wenn man den Zurück-Knopf betätigt. Um diesen Umstand zu verhindern wurden verschiedene Techniken entwickelt, bei denen auf unterschiedliche Weise der Verlauf des Internetbrowsers nachgefüllt wird, um bei Bedarf einzelne Schritte rückgängig zu machen. Gängige Methoden sind das Verwenden von Inline Frames oder das Aufrufen so genannter Rückruffunktionen. In Flash gibt es derartige Funktionen nicht, da der Flash Film gesondert vom Rest der HTML Elemente abläuft. Aktionen die in Flash geschehen, haben keinen Einfluss auf den Verlauf des Internetbrowsers. In diesem Fall hat AJAX einen geringfügigen Vorteil gegenüber Flash. Ein ähnliches Problem tritt beim Anlegen von Lesezeichen auf, da auch diese keine dynamisch nachgeladenen Bereiche erfassen können und somit die Lesezeichen immer nur auf den Anfang der Webseite zeigen können. Um dieses Problem zu beheben arbeitet man bei AJAX-Anwendungen oft mit der Anker -Funktion, mit der man bestimmte Bereiche in einer Webseite markieren kann. Diese Anker kann man mit in die URL der Webseite schreiben und ist somit teilweise in der Lage dynamische Webseiten mit Lesezeichen zu versehen. Dies ist ein Nachteil gegenüber herkömmlichen HTML Seiten, jedoch ein Vorteil gegenüber unserer Anwendung, da Flash diese Funktionalität nicht zur Verfügung stellt. Es kann lediglich ein Lesezeichen zu der Hauptseite erzeugt werden. Ein wichtiger Punkt in der visuellen Kommunikation mit dem Benutzer sind Rückmeldungen. Lädt die Internetseite beispielsweise Daten nach, ist es sinnvoll, dem Benutzer das Nachladen kenntlich zu machen, damit er nicht den Eindruck erhält, die Anwendung sei untätig. Flash stellt für dieses Problem entsprechende Funktionen zur Verfügung, so dass eine bessere visuelle Kommunikation mit dem Benutzer möglich ist. Bei AJAX tritt ein Problem auf, welches man Polling nennt. Es bezeichnet das ständige Nachfragen des Clients, ob sich auf Seiten des Webservers etwas verändert hat, da dieser nicht in der Lage ist bei asynchronen Events richtig zu reagieren. Da dies eine zu hohe Serverlast erzeugen würde, müssen hierfür entsprechende Vorkehrungen getroffen werden. Flash hat dieses Problem hingegen nicht, da bei amfphp über einen RPC kommuniziert wird 51

60 Gänzlich andere Umsetzungen und die aufgerufene Remote Methode ohne erneutes Nachfragen des Clients antworten kann. Mit AJAX stehen einem Entwickler zwar Möglichkeiten zur Verfügung, eine Anwendung zu gestalten, die ein ähnliches Verhalten wie eine Desktopanwendung besitzt, die Animationsfähigkeit ist jedoch beschränkt. Aus diesem Grund kommt AJAX für unsere Umsetzung nicht in Frage. 52

61 Gänzlich andere Umsetzungen JAVA-Applets Ein Java-Applet ist ein Computerprogramm, das im Internetbrowser eines Benutzers abläuft. Als Programmiersprache dient dabei die von SUN34 entwickelte objektorientierte Sprache Java. Als Ende der 1990er Jahre die Technologie der Java-Applets entwickelt wurde, war einer der Hauptgründe Java zu nutzen, die Möglichkeit Applets zu schreiben. Erst in den letzten Jahren gewann Java in der Anwendungsentwicklung an Bedeutung. Eine Java-Applet ist dabei in der Lage direkt mit dem Benutzer zu interagieren, ohne dabei zwingend Daten mit dem Server oder einem anderen Applet austauschen zu müssen. Die Bildschirmausgabe findet in einem Fensterbereich innerhalb des Internetbrowsers statt, ähnlich wie das bei eingebundenen Grafiken der Fall ist. Dabei wird das Applet an der Stelle im Internetbrowser angezeigt, an der es in der HTML-Datei referenziert wurde. Die Größe dieses Fensterbereichs wird dabei ebenfalls von Attributen in der HTML-Datei vorgegeben. Beispiele für Applets sind: kleinere Animationen das Anzeigen von Echtzeitabläufen in bewegten Grafiken, wie bei Newstickern eine Anwendung, wie ein Taschenrechner, bei dem der Benutzer Interaktionen mit dem Applet austauscht. Funktionsweise eines Applets Um ein Java-Applet benutzen zu können, ist es notwendig, einige Voraussetzungen zu erfüllen. Dabei unterscheidet man zwei Ansätze: 1. Es gibt Internetbrowser, die das Ausführen eines Applets selber übernehmen. Sie haben eine vom Hersteller des Internetbrowsers integrierte Java Version. Da die Applet-Technologie und Java ständig weiter entwickelt werden, müssen die Browserhersteller ihre Java-Versionen immer aktuell halten, was zur Folge hat, dass sie oft nur einen Teil der Appletfunktionen bieten können. 2. Sun begegnet diesem Umstand, indem es eine unabhängige Browser-Erweiterung zur Verfügung stellt. Das so genannte Java-Plugin ist ein für alle gängigen Internetbrowser verfügbares Programm, welches den Browser mit dem Java Runtime Environment (JRE)35 verbindet. Die JRE ist ein zusätzliches Programm, das zur Ausführung von Java-Anwendungen und Applets benötigt wird. Anschließend stellt der Internetbrowser nur noch das Fenster zur Bildschirmausgabe bereit. Der Nachteil dabei ist, dass bestehende Applets und deren HTML Seiten auf die Ausführung mit dem Plugin umgestellt werden müssen, sofern sie ein älteres JRE benutzen. So gibt 34 Vgl. 35 Download Link: 53

62 Gänzlich andere Umsetzungen es Unterschiede in der Syntax, die zum Einbinden des Applets in die HTML-Datei nötig sind. Weiterhin muss ein Entwickler berücksichtigen, ob das Java-Plugin installiert ist. Es muss also gegebenenfalls auf die Internetseiten von Sun verweist werden, wo man es herunterladen kann. Aufbau eines Java-Applets Alle Java-Applets werden aus der Klasse java.awt.applet abgeleitet. Auffällig dabei ist, dass die Klasse Applet keine abstrakte Basisklasse ohne Funktionalität ist, sondern eine konkrete Grafikklasse am Ende der Klassenhierarchie. Wie genau die Ableitungshierarchie aufgebaut ist, sieht man in der folgenden Grafik (Abb. 15). Abbildung 15: Ableitungsbaum der Appletklasse Das Applet ist also ein rechteckiges Bildschirmelement, das auch ohne die Zuweisung durch HTML eine Position und eine Größe besitzt. Die Funktionalitäten, die ein Applet benötigt um die Aufgaben zu erledigen, erbt es zum größten Teil schon aus den abgeleiteten Klassen. Da es aber keine main() Methode wie normale Java-Anwendungen besitzt, stellt die Klasse Applet die Funktionen, um das Hauptmodul einer Anwendung zu sein, selber bereit. Die Abmessungen eines Applets sind dabei ähnlich wie die eines Flashfilms. Dieser hat ebenfalls rechteckige Ausmaße und kann durch HTML positioniert werden. Unter Java stehen zwei Grafikbibliotheken mit denen Oberflächenelemente erstellt werden können zur Verfügung. Diese beiden Bibliotheken, nämlich Swing und AWT, können auch bei der Appletentwicklung verwendet werden. Da Applets wie gewöhnliche Anwendungen eigenständige Programme sind, stellen sie zunächst auch das gleiche Sicherheitsrisiko dar. Dem wird aber dadurch entgegengewirkt, dass sie in einer abgeschlossenen Umgebung, nämlich der Virtuellen Maschine des JRE, laufen. Außerdem ist es Applets nicht gestattet, lesend oder schreibend auf das Dateisystem des Clients zuzugreifen, was bei Flash ebenso der Fall ist. Eine weitere Einschränkung ist die Kommunikation mit anderen Rechnern. Es ist Applets nur gestattet, mit dem eigenen Host oder mit Applets von diesem zu kommunizieren. Die Kommunikation mit Applets von anderen Hosts ist also untersagt. Die Kommunikation zwischen dem Internetbrowser und dem Applet läuft auf verschiedenen Ebenen ab. Nachdem das Applet im Browser geladen wurde, muss es zunächst instantiiert und initialisiert werden. Danach kann es gestartet werden und die GUI-Events werden aktiv. Hat das Applet seine Aufgaben erledigt, wird es vom Browser wieder zerstört. Das Applet hat nicht die Möglichkeit, sich selber zu beenden. 54

63 Gänzlich andere Umsetzungen Verschiedene Möglichkeiten der Kommunikation Kommunikation über Sockets (Abb. 16) Bei der Appletprogrammierung hat man verschiedene Möglichkeiten mit der Außenwelt in Verbindung zu treten. Wenn es darum geht, mit anderen Anwendungen oder dem Webserver zu kommunizieren, bietet sich eine Kommunikation über Sockets an. Bei Sockets handelt es sich um eine standardisierte Schnittstelle (API) zwischen der Netzwerk-ProtokollImplementierung des Betriebssystems und der eigentlichen Anwendungssoftware. In diesem Fall dem Applet. Abbildung 16: Kommunikation mit anderen Anwendungen über Sockets Inter Applet Kommunikation (Abb. 17) Eine weitere Form ist die Kommunikation zwischen verschiedenen Applets, Inter Applet Communication (IAC) genannt. Die Applet-Klasse stellt für diese Art des Nachrichtenaustauschs Funktionen zur Verfügung. Es muss bekannt sein, wie die einzelnen Applets heißen, um diese referenzieren zu können. Anschließend kann auf die Methoden des anderen Applets zugegriffen werden, als sei es ein eigenes Objekt. Diese Art der Kommunikation ist sinnvoll, wenn die Applets voneinander abhängig sind und gegebenenfalls eine Aktualisierung der Anzeige ausgelöst werden muss. Da diese Form des Nachrichtenaustauschs eng mit dem Internetbrowser zusammenarbeitet, kommt es oft zu Problemen mit der Kompatibilität. Es muss bei der Entwicklung besonders darauf geachtet werden, dass die Kommunikation in allen gängigen Browsern funktioniert. Abbildung 17: Kommunikation zwischen zwei Applets 55

64 Gänzlich andere Umsetzungen Kommunikation mit dem Internetbrowser (Abb. 18) Es besteht die Möglichkeit, dass der Internetbrowser Parameter an ein Applet übergibt. Dazu muss beim Einbinden des Applets in HTML ein zusätzlicher Parameter (param) mit angegeben werden. Ist dies geschehen, kann das Applet mit der Methode getparameter(string name) auf diesen Parameter zugreifen. Es besteht zudem die Möglichkeit, dass ein Applet Funktionen des Webbrowsers aufruft. So kann zum Beispiel aus einem Applet heraus eine Webseite aufgerufen werden. Dazu wird der Methode showdocument(url url) ein Uniform Resource Locator (URL) übergeben, den der Internetbrowser dann ausführt. Abbildung 18: Kommunikation zwischen Applet und Internetbrowser Vorzüge eines Applets Da bei der Entwicklung von Applets prinzipiell der volle Funktionsumfang von Java zur Verfügung steht, lassen sich auch durch die gute Zusammenarbeit mit Servlets und Application Servern komplexe Anwendungen entwickeln. Nachteile eines Applets Java bietet keine einfache Technologie 2D Animationen zu erstellen. Mit Java 3D36 besteht jedoch die Möglichkeit in Java opengl37 zu programmieren, womit es also denkbar ist, umfangreiche 3D-Animationen zu entwickeln. Da die 3D Programmierung aber sehr gute Java- und Mathematik Kenntnisse voraussetzt und außerdem die Umsetzung sehr hohen Aufwand bedeutet, ist von der Verwendung zur Erzeugung von Benutzeroberflächen eher abzuraten. Mit Flash steht hier eine deutlich bessere Alternative zur Verfügung. Da Flash für die Erstellung von 2D-Animationen entwickelt wurde, erlaubt es die Entwicklungsumgebung unkompliziert Animationen zu erstellen. 36 https://java3d.dev.java.net/ 37 Vgl. 56

65 Gänzlich andere Umsetzungen Ein weiterer Nachteil ist, dass Applets von der installierten Java Version abhängig sind und diese Java Version auf allen Rechnern installiert sein muss. Der Vorteil, dass das Applet im Internetbrowser ausgeführt wird und nicht wie eine normale Anwendung auf dem ClientRechner installiert werden muss, entfällt also zum Teil. Die Größe des JRE spielt dabei eine weitere Rolle. In regelmäßigen Abständen werden Sicherheitsupdates von Sun zur Verfügung gestellt, womit jedes mal ca. 18 MB heruntergeladen werden müssen. 57

66 Gänzlich andere Umsetzungen PHPObject PHPObject stellt eine open source Alternative zu Flash Remoting dar. Hierfür ist die PHPObject Erweiterung für die Flash Entwicklungsumgebung nötig. Der PHPObject Konstruktor sorgt dafür, dass ein Objekt in Flash erzeugt wird und verbindet es mit einer Remote Klasse auf dem Server. Sobald ein PHPObject in Flash erzeugt wird, verbindet sich das Objekt automatisch mit dem Server und empfängt die grundlegenden Eigenschaften der Remote Klasse. Somit können PHP Klassen oder Bibliotheken direkt aus Flash heraus auf dem Web Server aufgerufen werden, als wären sie in Flash definiert. PHPObject kümmert sich selber um die ClientServer-Kommunikation. Das im Flash Film erzeugte PHPObject kann über seine Methoden mit der Remote Klasse auf dem Server kommunizieren. Die Daten werden dann in einem stringbasierten Format übertragen. Vorzüge von PHPObject PHPObject kann mit den meisten Flash-Datentypen umgehen, ähnlich wie amfphp. Sobald ein PHPObject erstellt wird, bezieht dieses sogleich seine Daten vom Remote Service und dem entsprechenden Remote Objekt. Dadurch kann PHPObject vor dem Aufbau einer Verbindung prüfen, ob die entsprechende Methode beim Remote Objekt existiert. Dies wird in unserer Umsetzung durch Flash Remoting erledigt. Um die Datenintegrität zu gewährleisten, erlaubt PHPObject nur eine Serververbindung pro Objekt zu einem bestimmten Zeitpunkt. Viele der Vorzüge von PHPObject finden sich auch in unserer Umsetzung mit Flash Remoting und amfphp und stellen demnach nur Vorteile gegenüber anderer alternativer Umsetzungen dar. Nachteile von PHPObject Die Übertragungszeit zwischen Client und Server ist deutlich höher, da PHPObject eine stringbasierte Datenübertragung durchführt und kein binäres Format (wie AMF) verwendet. Ein weiterer Nachteil von PHPObject gegenüber unserer Umsetzung stellt die fehlende Interoperabilität von PHPObject dar. Der Flashfilm kann nur mit PHPObject arbeiten und keine alternativen serverseitigen Technologien nutzen, wie es mittels Flash Remoting möglich ist. Gegenüber einer solchen sprachspezifischen Lösung bietet amfphp einen interoperabelen Gateway, für den es relativ einfach ist, Anwendungen, die für ColdFusion, Java oder.net entwickelt wurden, zum amfphp Framework zu migrieren. Das ActionScript bleibt im Grunde unverändert. Außerdem fehlen Werkzeuge zur Analyse der Kommunikation 58

67 Gänzlich andere Umsetzungen zwischen Client und Server, wie der NetConnection Debugger in Flash Remoting, sowie Werkzeuge zur Anzeige der Service Spezifikationen in einem Webbrowser, wie der Service Browser von amfphp. 59

68 3.4. Netzwerk der Metadaten 3.4. Netzwerk der Metadaten Die Kategorisierung und Beschreibung der einzelnen Projekte findet durch Metadaten statt. Dabei handelt es sich um festgelegte Begriffe wie ''Betreuer'' oder ''Fach'', die es möglichst genau kennzeichnen sollen. Durch die Zuweisung der einzelnen Metadaten kann der Einsteller festlegen, wie sein Projekt später aufgelistet wird und in welchem Zusammenhang man es wiederfinden kann. Des Weiteren dienen die Metadaten dazu, einzelne Projekte miteinander zu verbinden (Querverweise), um so schneller Projekte mit ähnlichem Inhalt zu finden. Bei dem von uns gewählten Metadatenprinzip kann der Benutzer aus einer Liste von vorgegebenen Begriffen wählen, darf aber nicht ohne Weiteres eigene hinzufügen. Folgende Metadaten stehen zur Auswahl und müssen vom Benutzer beim Einstellen seines Projekts angegeben werden. An dieser Stelle wird nur beispielhaft auf einzelne Auswahlmöglichkeiten eingegangen. Kategorie Hier stehen die verschiedenen Studiengänge wie Medieninformatik, Wirtschaftsinformatik usw. zur Auswahl. Status des Projekts Bei dieser Metadate soll der Einsteller angeben, in welchem Zustand sich das einzustellende Projekt befindet. Ist es abgeschlossen, befindet es sich noch in der Entwicklung oder wurde es nur ausgeschrieben. Projektart Der Benutzer hat die Möglichkeit anzugeben, um welche Art von Arbeit es sich bei seinem Projekt handelt. Ist es eine Bachelorarbeit, ein externes Projekt oder wurde es im Kontext eines Studienfachs entwickelt. Projektumfang An dieser Stelle sollte der Umfang vom Einsteller abgeschätzt werden. Zur Auswahl stehen Punkte wie wenig, mittel und viel. Mit dieser Angabe soll nur eine grobe Einschätzung abgegeben werden. Es ist nicht als ein genaues Maß zu sehen. Einstelldatum Um sich später die Projekte der Aktualität nach anzeigen zu lassen, wird beim Einstellen das Datum gespeichert. Der Benutzer muss dies nicht extra angeben. Das Speichern des Datums geschieht automatisch. Startdatum Da Projekte von externen Mitarbeitern oder Interessierten eingestellt werden können, existiert die Möglichkeit ein Datum anzugeben, zu welchem das Projekt begonnen werden kann. Die Zeit zwischen dem Einstelldatum und dem Startdatum ist also eine Art Bekanntgabe des Projekts. Schwierigkeitsgrad Der Benutzer soll angeben, welchen Schwierigkeitsgrad, gemessen an der Komplexität und den eingesetzten Technologien, sein Projekt hat. Auch hier hängt die Angabe von der Subjektivität des Einstellers ab und dient nur als grober Richtwert, um es dem interessierten Benutzer zu erlauben, eine erste Abschätzung zu machen. 60

69 3.4. Netzwerk der Metadaten Fach Das Fach in dem das Projekt entstanden ist. Sollte es sich um ein Medienprojekt oder ähnliches handeln muss dieser Punkt nicht angegeben werden. Technologie Ist eine Auflistung der verwendeten Programmiersprachen, Techniken usw. Betreuer Hier wird der Professor oder eine andere Person genannt, die das Projekt während der Entwicklung betreut hat. User, der das Projekt einstellte Zusätzlich zu den anderen Metadaten wird der Benutzername gespeichert, um sich später alle Projekte von einem Einsteller anzeigen lassen zu können. Da Projekte auch von Professoren oder anderen Verantwortlichen eingestellt werden können, ist dies interessant, falls man Arbeiten eines Mitarbeiters bevorzugt. Bewertung Diese Metadate wird von einem Verantwortlichen der Fachhochschule oder eines bestimmten Fakultätsmitarbeiters eingetragen. Sie soll ein allgemein gültiger Maßstab für alle Projekte sein, um diese besser vergleichen zu können. Abbildung 19: Netzwerk der Metadaten Tagging Gemeinschaftliches Indexieren, auch als Tagging bezeichnet, ist eine andere Form der Kategorisierung, bei der gemeinschaftlich Deskriptoren (Tags) gesammelt werden. Die Gemeinschaft der Tagger setzt sich dabei meist aus zufällig zusammengetroffenen Internetnutzern zusammen. Beim Tagging kommen Anwendungen zum Einsatz, die die Kommunikation, Zusammenarbeit und Interaktion unter den Benutzern fördern. Diese Art der Software wird auch Soziale Software genannt. Dabei gibt es oftmals keine festgelegten Indexierungsregeln und die Benutzter entscheiden frei und spontan welche Begriffe sie verwenden. Solche Begriffssammlungen bestehend aus Tags, nennt man auch Folksonomies. Eine Zusammensetzung aus dem englischen Wort folk und taxonomy. Da 61

70 Tagging man die Begriffe frei wählen kann, besteht die Gefahr, dass Rechtschreibfehler und Synonyme die Anzahl der Tags unnötig umfangreich werden lassen. Um diesen Umstand tolerieren zu können, ist eine hohe Benutzerzahl Voraussetzung, da so die Wahrscheinlichkeit höher ist, dass die gleichen Begriffe gewählt werden. Aus Gründen der besseren Kontrolle und einer genaueren Kategorisierung bei kleinen Nutzergruppen haben wir uns gegen das Tagging entschieden. Es steht aber zur Diskussion, ob es noch zusätzlich angeboten werden sollte. Beim Tagging kann der Benutzer beliebig viele eigene Tags hinzufügen und ist nicht auf die festgelegten Begriffe, die unser Metadatenprinzip bereitstellt, angewiesen. 62

71 4. Implementierung 4. Implementierung 4. Implementierung Refactoring...66 Beschreibung...66 Anwendung Remote Procedure Call (RPC) Sessionmanagement Singleton Design Pattern...70 Problembeschreibung...70 Problemlösung...70 Singelton Implementierung...70 Bewertung...72 Weiterführende Links zu dem Thema Verzeichnis- und Dateistruktur Aufteilung der Bereiche Außenbereich Interner Bereich Benutzerrechte...75 Angemeldeter Benutzer...75 Fakultät...76 Administrator...76 Allgemeines zu den Benutzerrechten Implementierung in Flash und PHP Allgemeine Betrachtungen Liste aus einem RecordSet erstellen Beschreibung Technischer Ablauf...79 Clientside Flash - Remote Call...79 Serverside PHP - Remote Service...81 Aufbau eines amfphp Services...81 Die Kommunikation zwischen Flash und amfphp...82 Schritt 1: Verbindung mit dem Gateway...83 Schritt 2: Aufruf der Funktion und Übergabe der Parameter...83 Schritt 3: Übergabe der PHP Session...84 Schritt 4: Rückgabe des Ergebnisses...84 Serverside PHP - Remote Method

72 4. Implementierung Clientside Flash - Response verarbeiten Liste aus einem Array erstellen Beschreibung Technischer Ablauf...91 Clientside Flash - Remote Call...91 Serverside PHP - Remote Service...93 Array-Methoden der Projektdaten...95 Projekt Technologien hinzufügen...95 Projekt Medien und Links hinzufügen...97 Clientside Flash - Response verarbeiten RecordSet mit einem Datensatz Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Einfache Rückgabewerte Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Konkrete Anwendungsfälle Projekt ansehen Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Probleme Projekt bearbeiten Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Ändern der Daten (daten.php) Ändern der Medien (medien.php) Upload der Daten und Medien (edit_send.php)

73 4. Implementierung Validieren der Medien Dateiupload am Beispiel der Bilder Eintragen der Projektdaten in die Datenbank Nachrichtensystem Beschreibung Technischer Ablauf Nachrichten zählen Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Nachricht lesen Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Nachricht verschicken Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Nachricht löschen Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Login Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Probleme Serverseitige Probleme mit MySQL und PHP Voraussetzungen Inbetriebnahme Verwendete Technologien und Hardware Software der Entwickler Hard Software des Servers

74 Das Kapitel Implementierung beschäftigt sich zunächst mit allgemeinen Themen wie beispielsweise dem Refactoring, dem Sessionmanagement oder der Verzeichnisstruktur unseres Projekts. Dabei geht die Reihenfolge der Themen vom Abstrakten zum Konkreten. Nachdem die allgemeinen Themen behandelt wurden, erläutern wir, sich in der Anwendung wiederholenden Teile der Implementierng. Ein Beispiel hierfür ist die Erstellung einer Kategorieliste aus einem RecordSet. Daraufhin werden wichtige Anwendungsfälle, wie das Benutzen des Nachrichtensystems, anhand von Quellcode genauer erläutert. Zuletzt werden noch die zum Betrieb des Projektinformationssystem nötigen Vorraussetzungen, sowie die von den Entwicklern eingesetzten Rechner näher beschrieben Refactoring Beschreibung In der deutschen Sprache existiert keine passende Übersetzung für das Wort "refactoring". Refactoring beschreibt die Modifikation bestehender Software bzw. dessen Quellcode, um ihre Lesbarkeit, Wartbarkeit und Erweiterbarkeit zu erhöhen. Hierbei kommt es darauf an, dass der bestehende Quellcode von Fehlern befreit und geändert wird, ohne dass sich die Funktionen der Software ändern, worin es sich vom "developing" (Entwicklung) unterscheidet. Es empfiehlt sich diese beiden Schritte voneinander zu trennen, um keine zusätzlichen Fehlerquellen zu schaffen. Die Software wird also von Innen heraus optimiert, ohne das sich für den Benutzer etwas erkennbar an den Funktionen ändert. Der Mehrwert eines Refactorings lässt sich leicht in der Gegenüberstellung der beiden Versionen erkennen. [1] In der Praxis wird ein Refactoring häufig vor der Entwicklung von neuen Funktionen durchgeführt. Wir folgten diesem Ansatz und optimierten zuerst den gesamten, bestehenden38 Flash Quellcode, bevor es an die Entwicklung neuer Funktionen ging. Anwendung Zuerst wurden viele Teile des Flash Codes in ActionScript Dateien (*.as) ausgelagert. Danach wurde alles auf eine objektorientierte Struktur umgestellt und Klassen für die bisherigen Funktionen entwickelt. Dabei wurde der Quellcode von diversen Fehlern befreit und damit effizienter, lesbarer und zuverlässiger. Des Weiteren wurde dadurch eine weitgehende Trennung der Anzeigelogik von den Funktionen und Daten erreicht. Im Flash Film selbst verblieben nur die jeweiligen MovieClips und Steuerungen für Animationen oder bestimmte Events. Die Funktionen und das Zuweisen 38 Stand vor der Bachelorarbeit, nach dem MMA/MCI 2 Praktikum 66

75 Anwendung von Daten in die entsprechenden Container oder Variablen wurde in die externen Dateien verlegt. Zusätzlich wurden einige Flash Komponenten, wie das ScrollPane, durch einfache MovieClips ersetzt und die Steuerung angepasst. Dadurch kann nun gezielter Einfluss auf die einzelnen Elemente und deren Darstellung genommen werden. Einige Probleme, die mit jenen Komponenten und deren Darstellung bestanden, wurden somit ausgeräumt. Es wurden währenddessen keine weiteren Funktionen ergänzt, sondern darauf geachtet, dass sich für den Benutzer augenscheinlich nichts ändert, obwohl die Anwendung im Kern verbessert wurde. Unsere Arbeit stellt somit ein klassisches Beispiel für Refactoring dar. Während der Implementierungsphase wurden immer wieder kleine "Refactorings" durchgeführt, um den bestehenden Code auszubessern. Dies ergab sich durch den stetig anwachsenden Erfahrungsschatz im Umgang mit Flash und der Lösung von Programmierproblemen. Somit wurde der Quellcode an diversen Stellen ausgebessert, ohne die eigentliche Funktion zu verändern. 67

76 4.2. Remote Procedure Call (RPC) 4.2. Remote Procedure Call (RPC) Der RPC39 ist eine Kommunikationsform, die über ein Netzwerk erfolgt und es erlaubt, Methoden auf einem entfernten Rechner auszuführen. Das Prinzip des RPCs ermöglicht es ebenso, eine Methode von verschiedenen Rechnern aus zu nutzen. Es wird Coderedundanz vermieden. Die meisten RPCs laufen synchron ab, was bedeutet, der Client schickt eine Anfrage an den Server, dieser verarbeitet die Anfrage und wertet sie aus. Nach der Auswertung wird das Ergebnis zurück an den Client geschickt und erst dann arbeitet dieser weiter. Er steht also während der Verarbeitung auf dem Server still. Neben dem synchronen RPC existiert noch eine weitere Kommunikationsform, die auch amfphp nutzt. Diese Form nennt sich asynchroner RPC und unterscheidet sich in dem Verhalten der Kommunikationspartner. Wie beim synchronen RPC, wird eine Anfrage an den Server geschickt, welcher diese verarbeitet. Der große Unterschied besteht darin, dass der Client nicht auf die Antwort des Servers wartet, sondern in der Zwischenzeit andere Aufgaben erledigen kann. Der Client reagiert erst dann auf die Antwort des Servers, wenn diese auch tatsächlich ankommt und verarbeitet werden muss. Dabei findet die Kommunikation zwischen Client und Server über dafür vorgesehene Prozesse statt, weswegen diese Form der Kommunikation auch Interprozesskommunikation genannt wird. Abbildung 20: synchroner und asynchroner RPC 39 Vgl. und 68

77 4.3. Sessionmanagement 4.3. Sessionmanagement Flash Remoting behandelt eine Session intern und versteckt. Das bedeutet, der Benutzer und der Server bekommen vom Flash Sessionmanagement nichts mit. Bei jedem AMF Paket, welches zwischen Server und Client ausgetauscht wird, werden Daten zur aktuellen Session mit gesendet. Es ist also nicht nötig, manuell Sessions per PHP oder Flash zu verwalten, da alles von Flash Remoting erledigt wird. Bei unserer und anderen Rich Client Implementierungen wird der Flashfilm nur einmal beim Starten in den Browser des Benutzers geladen. Somit bleibt die Session bestehen, solange der Flashfilm ausgeführt wird. Ein erneutes Laden des Films erzeugt eine neue Session. Der Vollständigkeit wegen sei an dieser Stelle gesagt, dass es einen Unterschied des Sessionmanagements gibt, wenn ein möglicher Application Server in einem Cluster betrieben wird. Neben der Abhandlung der Sessions durch amfphp, gibt es die Möglichkeit manuell PHP Sessions40 zu verwenden. Leider existiert zu diesem Punkt keine eindeutige Dokumentation. Dem amfphp Diskussionsforum ist zu entnehmen, dass man den entsprechenden Code in die gateway.php und an die passenden Stellen im PHP-Code einbinden muss. 40 Vgl. 69

78 4.4. Singleton Design Pattern 4.4. Singleton Design Pattern Problembeschreibung Unter gewissen Umständen ist es wichtig, dass von einer Klasse nur eine Instanz erzeugt werden kann. Die Gründe hierfür sind vielfältig. Für eine Druckersteuerung sollte nur eine Warteschlange für Druckaufträge erzeugt werden können. Des Weiteren kann man hiermit garantieren, dass nur ein Datenbankverbindungsobjekt existiert, um mit der Datenbank zu kommunizieren. Wie kann man nun sicherstellen, dass solche Objekte nur ein einziges Mal erzeugt werden und trotzdem einfach auf sie zugegriffen werden kann? Mit einer globalen Variable kann man ein Objekt überall verfügbar machen, jedoch verhindert es nicht, dass mehrere Objekte dieser Klasse erzeugt werden. Problemlösung Eine bessere Lösung wäre, die Klasse selbst dafür verantwortlich zu machen, dass nur eine einzige Instanz von ihr erzeugt werden kann. Hierfür wird ein Zeiger als Klassenvariable benutzt, der auf eine eventuell schon erzeugte Instanz verweist. Da der Aufruf des Konstruktors immer ein Objekt einer Klasse liefert, muss verhindert werden, dass dieser von einem Anwender der Klasse aufgerufen werden kann. Somit muss der Konstruktor als private deklariert werden. Das Erzeugen eines Objekts übernimmt nun eine Memberfunktion, welche prüft, ob bereits ein Objekt erzeugt wurde und dementsprechend die bereits existierende Instanz zurück liefert oder ein neues Objekt erzeugt. Diese Memberfunktion besitzt den Zugriff auf den Konstruktor der Klasse. Singelton Implementierung Wir verwenden dieses Desgin-Pattern (Entwurfsmuster) unter anderem im Flash Client, um zu verhindern, dass mehrere Listenobjekte einer entsprechenden Listenklasse erzeugt werden können. Am Beispiel der Projektlisten-Klasse ListProject (Abb. 21) zeigt sich die Zweckmäßigkeit des Singletons. Im System kann eine Projektliste durch unterschiedliche Aufrufe erzeugt werden. Sie kann unter anderem eine Liste der Projekte in einer bestimmten Kategorie zeigen, oder aber die Projekte eines bestimmten Users oder einer bestimmten Metadate. Dank der Möglichkeit sich mittels Querverweise durch die unterschiedlichen Projektlisten zu navigieren, ist es besonders wichtig, dafür zu sorgen, dass trotz der unterschiedlichen Listenaufrufe und Listenelemente, immer nur ein Projektlistenobjekt verwendet wird. 70

79 Singelton Implementierung (1) private static var listinstance:listproject; (2) (3) /** (4) * Konstruktor (5) * (6) Enriko Podehl (7) strstatuspicurl, Pfad zu den Statusgrafiken (8) */ (9) private function ListProject(strStatusPicURL:String) { (10) strpicurl = strstatuspicurl; (11) strgatewayurl = 'http://atheisten.org/amfphp/gateway.php'; (12) NetDebug.initialize(); (13) srvlistpro = new Service(strGatewayURL, null, 'ProInf', null, null); (14) } (15) (16) /** (17)) * Singleton (18) * (19) Enriko Podehl (20) Referenz auf ein ListProject Objekt (21) */ (22) public static function getinstance(strpath:string, strwb:string, strstatuspicurl:string) : ListProject { (23) if ( listinstance == null) { (24) listinstance = new ListProject(strStatusPicURL); (25) strpathmovieclip = strpath; (26) strpathwb = strwb; (27) } (28) arrelements = Array(); (29) return listinstance; (30) } Abbildung 21: Quellcode - Auszug, ListProject Klasse Die Variable listinstance dient hier als Referenz auf eine ListProject-Instanz. Die Singleton-Methode getinstance() wird im Flashfilm aufgerufen: (1) listpro = ListProject.getInstance('container_mc', 'dropzonewb', PARAM['pic_url']); Abbildung 22: Quellcode - Auszug, Flashfilm Der Methode werden die beiden Bezeichnungen der MovieClips mitgegeben, welche als Container fungieren und in denen später die Listenelemente und die Zusatzinformationen angezeigt werden. Des Weiteren bekommt sie die URL zu den Statusgrafiken mit. Diese Parameter sind nur beim Erzeugen eines Objekts von Bedeutung. Der Aufruf von getinstance() (Abb. ) erfolgt vor jedem Anfordern und Ausgeben einer Projektliste. Die Methode prüft, ob schon eine Instanz existiert und gibt diese entweder zurück oder ruft den Konstruktor auf, in dem unter anderem Variablen für die amfphpkommunikation gesetzt werden und gibt dann das erzeugte Objekt zurück. 71

80 Bewertung Bewertung Es besteht die große Gefahr, durch exzessive Verwendung von Singletons ein objektorientiertes Äquivalent zu globalen Variablen zu implementieren. Zu dem ist die Implementierung in anderen Programmiersprachen teilweise schwierig oder nur eingeschränkt möglich. Es empfiehlt sich von daher abzuwägen, für welchen Zweck es verwendet werden soll und ob es keine anderen Lösungsmöglichkeiten gibt. In unserem Anwendungsfall empfahl sich die Verwendung des Singleton Design Patterns und erwies sich als leicht zu implementieren. Weiterführende Links zu dem Thema - Implementierungshilfen für das Entwurfsmuster Singleton - Flash-Beispiel - PHP-Beispiel und Erklärung, Einsatzzwecke - Singleton in Java 72

81 4.5. Verzeichnis- und Dateistruktur 4.5. Verzeichnis- und Dateistruktur An dieser Stelle folgt eine grafische Darstellung (Abb. 23) der Verzeichnis- und Dateistruktur des Projektinformationssystems. Dabei ist das Stammverzeichnis abhängig vom Server, auf dem die Anwendung betrieben wird. In unserem Fall ist das der Medieninformatikserver der Fachhochschule Köln. Es wurde ein Ordner mit dem Namen ProInf41 angelegt, in dem sich neben den Flashfilmen auch die HTML-Dateien befinden. Abbildung 23: Verzeichnisstruktur des Projektinformationssystems 41 Vgl. 73

82 4.6. Aufteilung der Bereiche 4.6. Aufteilung der Bereiche Unsere Anwendung teilt sich in vier Bereiche (Abb. 24), welche über unterschiedliche Darstellungen und einen unterschiedlichen Funktionsumfang verfügen. Abbildung 24: Aufteilung der Bereiche Außenbereich Dieser Bereich ist jedem Internetnutzer zugänglich. Neben der Startseite, auf der man sich die unterschiedlichen Kategorien und Projektlisten (Abb. 25) ansehen kann, existiert noch eine Projektansicht (Abb. 26), die einem alle Daten zu einem eingestellten Projekt anzeigt. Projekte, die neu eingestellt wurden, müssen zunächst von Verantwortlichen auf Seiten der Fachhochschule Abbildung 25: Kategorieliste, Außenbereich überprüft werden (siehe Kapitel: ). Bis zur Freischaltung der Projekte werden diese in keiner Liste des Außenbereichs angezeigt. Sie können also noch nicht angesehen werden. Außerdem gibt es einen Newsbereich, welcher aktuelle Meldungen zum Projektinformationssystem, sowie das Impressum und unsere "AGBs" beinhaltet. Der Newsbereich ist hier nur der Vollständigkeit halber aufgeführt. Im Rahmen der Bachelorarbeit wird dieser Abbildung 26: Pro. ansehen, Außenbereich jedoch nicht implementiert. 74

83 Interner Bereich Interner Bereich Der Interne Bereich, für den ein LogIn bzw. eine Registrierung nötig ist, umfasst drei - von den Benutzerrechten abhängige - Bereiche. Um Zugang zu diesem Bereich zu erhalten, muss man sich entweder registrieren oder Student der Fakultät 10 der Fachhochschule Köln sein. Neben den bekannten Funktionen aus dem Außenbereich, wie die Kategorie- und Projektlisten (Abb. 27), können hier Projekte hinzugefügt werden. Das Aussehen, der Listen unterscheidet sich von denen im Außenbereich, da im Internen Bereich der Fokus auf dem Inhalt liegt Abbildung 27: Kategorieliste, Intern und nicht so sehr auf der Darstellung. Geradliniges Arbeiten hat hier Vorrang, weswegen das Aussehen eher schlicht gehalten wurde. Der Funktionsumfang verringert sich jedoch nicht. Wie im Außenbereich hat der Benutzter die Möglichkeit die Projektinformationen anzusehen (Abb. 28). Des Weiteren steht den angemeldeten Benutzern ein Nachrichtensystem zur Verfügung, welches ihnen den Kontakt zu anderen Benutzern ermöglicht (siehe Kapitel ). Weitere Funktionen zur Verwaltung der Projekte, wie das Freischalten oder Bewerten sind nur mit den entsprechenden Rechten verfügbar. Abbildung 28: Pro. ansehen, Intern Aus technischer Sicht wird jeder angemeldete Benutzer, aufgrund seiner Rechte, in einen für ihn vorgesehenen Bereich geleitet. Die Bereiche unterscheiden sich durch die angebotenen Funktionen, welche von den Benutzerrechten abhängig sind Benutzerrechte Es wird zwischen drei verschiedenen Benutzergruppen und somit auch Bereichen im System differenziert. Der Unterschied besteht darin, dass die verschiedenen Gruppen andere Aufgaben und Pflichten haben, wofür sie dann die benötigten Rechte erhalten. Angemeldeter Benutzer Der normale Benutzer bildet die erste Gruppe. Sie hat Rechte wie das Einstellen von Projekten oder das Kommunizieren über das Nachrichtensystem. Jeder Benutzer, der sich neu im Projektinformationssystem anmeldet, wird zunächst dieser Gruppe zugeordnet. 75

84 Interner Bereich Wie beschrieben, muss ein Projekt erst durch die Gruppe Fakultät freigeschaltet werden, um es in den Listen des Außenbereichs anzeigen zu können. Der Einsteller hat natürlich zu jeder Zeit die Möglichkeit sein Projekt zu ändern, ohne das es zuvor freigeschaltet werden muss. Eine Änderung des Inhalt hat allerdings zur Folge, dass dieses Projekt wieder gesperrt wird, um es nach einer erneuten Überprüfung freischalten zu können. Um die eigenen Projekte schnell finden zu können, werden im Internen Bereich, des angemeldeten Benutzers, nur seine eigenen Projekte angezeigt. Um es ihm so leicht wie möglich zu machen, sind diese Projekte außerdem nach Kategorien sortiert. Möglich wird diese Anzeige durch die Übergabe einer Benutzer ID an die amfphp-methode catlist(). Woraufhin dann nur die Kategorien und Projekte des entsprechenden Benutzers angezeigt werden. Fakultät Eine weitere Gruppe nennt sich Fakultät und ist eine Art Administrator, mit weniger Rechten. Geschaffen wurde diese Gruppe, um verschiedenen Verantwortlichen unterschiedliche Themenbereiche zuordnen zu können. Die Gruppe Fakultät hat die Aufgabe den Inhalt von eingestellten oder bearbeiteten Projekten zu überprüfen. Dabei werden die Prüfkriterien nicht vom Projektinformationssystem vorgegeben. Nach der Überprüfung kann das Projekt freigeschaltet werden oder es wird mit dem Einsteller, über das Nachrichtensystem (siehe Kapitel ) Kontakt aufgenommen. Um neu eingestellte und noch nicht freigeschaltete Projekte schnell finden zu können, existiert eine extra Kategorie in der Kategorieliste, welche die Projekte gesondert anzeigt. Sie wird über den, aus dem Außenbereich, bekannten Kategorien eingefügt. Die Kontrollinstanz dieser Gruppe ist die Gruppe Administrator. Administrator Im System kann es mehrere Administratoren geben, welche alle zur Verfügung stehenden Funktionen bedienen können. Im Speziellen sind das allgemeine Aufgaben wie Sperrungen rückgängig machen oder Benutzerrechte verwalten. Also Aufgaben, die die anderen Gruppen aus Gründen der Sicherheit nicht machen sollten. Auf den vollen Funktionsumfang soll an dieser Stelle nicht eingegangen werden. Allgemeines zu den Benutzerrechten Neben den genannten Gruppen gibt es eigentlich noch eine vierte Gruppe von Benutzern. Dabei handelt es sich um die Benutzer, die sich nicht im Projektinformationssystem angemeldet haben und somit auch keine Sonderrechte besitzen. Sie können sich lediglich 76

85 Interner Bereich den Außenbereich anschauen und müssen somit nicht in der Rechteverwaltung erfasst werden. Aus Gründen der internen Struktur und der Zweckmäßigkeit ist es nicht möglich, dass ein Benutzer gleichzeitig mehrere der genannten Gruppen angehört. Es ist vielmehr so, dass die oberste Gruppe, also die Administratoren alle, die Gruppe Fakultät etwas weniger und die Gruppe Angemeldete Benutzer nur die nötigsten Rechte hat. 77

86 4.7. Implementierung in Flash und PHP 4.7. Implementierung in Flash und PHP Im folgenden Kapitel werden von uns für wichtig befundene Teile der Implementierung vorgestellt Allgemeine Betrachtungen Im Projektinformationssystem gibt es Funktionalitäten und Abläufe die mehrfach verwendet werden. Nachfolgend betrachten wir das Erstellen einer Liste aus einem RecordSets (siehe Kapitel ), sowie aus einem Array (siehe Kapitel ). Außerdem stellen wir die Verarbeitung eines RecordSets mit einem enthaltenen Datensatz (siehe Kapitel ) und die eines einfachen Rückgabewertes vor (siehe Kapitel ). Diese Betrachtungen werden alle an repräsentativen Beispielen durchgeführt Liste aus einem RecordSet erstellen In diesem Kapitel wird anhand von Quellcode erläutert, wie der Aufbau der Kategorieliste erfolgt. Dabei ist das Kapitel in eine Beschreibung und in den technischen Ablauf gegliedert. Dieser technische Ablauf ist wiederum in vier Bereiche aufgeteilt. Der erste dieser Bereiche beschreibt den Aufruf der amfphp Methode aus Flash heraus (Clientside Flash - Remote Call). Der zweite Bereich (Serverside PHP - Remote Service) beschreibt den Aufbau eines amfphp Services, sowie den Ablauf der Kommunikation zwischen Flash und amfphp. Der dritte Bereich beschreibt den Ablauf auf der Serverseite (Serverside PHP - Remote Method). Der vierte und letzte Teil beschreibt die Rückgabe der Daten von amfphp an Flash und dessen Auswertung (Clientside Flash - Response verarbeiten) Beschreibung Das Projektinformationssystem zeigt verschiedene Listen für Kategorien, Projekte, Benutzer und Nachrichten an. Diese Listen werden sowohl im Außenbereich als auch im Internen Bereich auf die gleiche Art und Weise erstellt. Hierzu werden zwei unterschiedliche Verfahren verwendet, welche sich in der Form der Rückgabewerte (Result) unterscheiden. In diesem Abschnitt betrachten wir den Fall, in dem ein RecordSet von amfphp an Flash zurückgegeben wird. Im nachfolgenden Abschnitt betrachten wir die Rückgabe eines assoziativen Arrays, um daraus eine Liste zu erstellen. 78

87 Allgemeine Betrachtungen Wir entschieden uns die Listen und Funktionen des Außenbereiches zu betrachten, da sie jedem Benutzer zugänglich sind und sich nur geringfügig von denen im Internen Bereich unterscheiden, was vor allem auf die Ausgabe und die Benutzerrechte zurückzuführen ist. Ihre Implementierung und Funktion ist prinzipiell die Gleiche. Eine Liste mit den im System vorhandenen Kategorien ist das Erste, was einem Benutzer beim Betreten unserer Webseite42 als Inhalt angezeigt wird. Diese Liste dient ihm als Vorauswahl, da alle Projekte genau einer Kategorie zugeordnet sind. Die Art und Anzahl der Kategorien ist beliebig und veränderbar, da sowohl die Datenbank, als auch die amfphpfunktionen und die Flash-Ausgabe flexibel gestaltet wurden, um eine Erweiterbarkeit zu garantieren. Zum Erstellen der Kategorieliste fertigten wir ein Sequenzdiagramm an, um den Ablauf der einzelnen Kommunikationsschritte besser darstellen zu können. Dieses Sequenzdiagramm befindet sich im Anhang A Technischer Ablauf Clientside Flash - Remote Call Dem Flashfilm müssen zuerst alle verwendeten Klassen zugefügt werden (Abb. 29), um sie und ihre Objekte benutzen zu können. In diesem Fall befinden sie sich im Verzeichnis classes unterhalb des Hauptverzeichnisses, in dem der Film selber liegt. (1) import classes.*; Abbildung 29: Quellcode - Aufruf im Flashfilm, Bild: StartContent Bevor die Daten für eine Kategorieliste angefordert werden, wird ein Kategorielisten-Objekt erstellt. (1) listcat = ListCategory.getInstance('container_mc', 'dropzonewb'); Abbildung 30: Quellcode - Aufruf im Flashfilm, Bild: StartContent Die Klasse ListCategory wurde mit einem Singleton (Siehe Kapitel 4.4. ) implementiert. Die Methode getinstance() (Abb. 30) leitet die Namen (bzw. Pfade) der beiden Ziel MovieClips weiter und gibt dann die Referenz auf das ListCategory-Objekt an listcat zurück. Wenn noch kein ListCategory-Objekt existiert, wird der Konstruktor (Abb. 31) aufgerufen, in dem der Pfad zum amfphp Gateway auf dem Server gesetzt (strgatewayurl) und ein Service-Objekt erstellt wird (srvlistcat). Hierfür wird die URL und der Name der Service-Klasse auf dem Server übergeben. 42 Vgl. 79

88 Allgemeine Betrachtungen (1) private function ListCategory() { (2) strgatewayurl = 'http://mims02.gm.fh- koeln.de/~proinf/amfphp/gateway.php'; (3) NetDebug.initialize(); (4) srvlistcat = new Service(strGatewayURL, null, 'ProInf', null, null); (5) } Abbildung 31: Quellcode - Teil der ListCategory Klasse Die NetDebug.initialize()-Methode initialisiert den Debug-Support für Flash Remoting. Diese Methode muss aufgerufen werden, bevor eine Verbindung hergestellt oder DebuggingOperation durchgeführt werden. Dadurch wird später die Kommunikation im NetConnectionDebugger mit allen Requests, Responses und gesendeten Daten aufgelistet. Danach werden mit der Methode display() (Abb. 32 und Abb. 33) alle nötigen Daten angefordert. (1) listcat.display(1, ); Abbildung 32: Quellcode - Aufruf im Flashfilm, Bild: StartContent (1) public function display(numiniti:number, straddstring:string) : Void { (2) cleancontainer(); (3) numi = numiniti; (4) stradd = straddstring; (5) // Flash Remoting Service aufrufen (6) pcremotecall = srvlistcat.catlist(); (7) pcremotecall.responder = new RelayResponder(this, 'catlist_result', 'catlist_error'); (8) } Abbildung 33: Quellcode - Teil der ListCategory Klasse Die Methode cleancontainer() (Abb. 34) entfernt den Container MovieClip, in dem später die Liste angezeigt wird und erstellt dann einen neuen leeren MovieClip. (1) private function cleancontainer() { (2) // entfernen des alten Containers (3) if (eval("_level0." + strpathmovieclip).cont) { (4) removemovieclip(eval("_level0." + strpathmovieclip).cont); (5) } (6) eval("_level0." + strpathmovieclip).createemptymovieclip('cont', eval("_level0." + strpathmovieclip).getnexthighestdepth()); (7)} Abbildung 34: Quellcode - Teil der ListCategory Klasse Mit der Methode eval() wird ein dynamischer Pfad erstellt, damit das Listenobjekt unabhängig von der Bezeichnung und der Ebene des MovieClips ist. Anschließend wird die entsprechende Servicemethode aufgerufen (Abb. 35) und die Rückgabe an die Variable pcremotecall vom Typ PendingCall übergeben. (1) pcremotecall = srvlistcat.catlist(); Abbildung 35: Quellcode - Teil der ListCategory Klasse 80

89 Allgemeine Betrachtungen Es wird aber kein PendingCall-Objekt erstellt und keine Konstruktorfunktion verwendet; stattdessen gibt die Service-Methode ein PendingCall-Objekt zurück, wenn eine Methode in einem Service-Objekt aufgerufen wird. Serverside PHP - Remote Service Aufbau eines amfphp Services Im folgenden Kapitel behandeln wird den grundsätzlichen Aufbau eines amfphp Services. (1) class HelloWorld (2) { (3) function HelloWorld() (4) { (5) $this->methodtable = array ( "say" => array "description" => "Liefert eine Nachricht zurueck" ) (6) ); (7) } (8) function say($smessage) (9) { (10) return 'Du hast gesagt: '. $smessage; (11) } (12) } ( "access" => "remote", Abbildung 36: Quellcode - Aufbau eines amphp Services Ein amfphp-service ist nichts anderes als eine Klasse. Auch hier dient die Klassenstruktur der Bündelung von Funktionalität und der Strukturierung des Programmcodes. Der Service hat jedoch eine Besonderheit, die für den Einsatz in der Remotingumgebung nötig ist. Jeder amfphp-service hat eine methodtable(), die im Konstruktor aufgerufen wird. In dieser Methode werden alle weiteren Methoden des Services aufgeführt, um ihnen Eigenschaften (sog. Tags) zuzuweisen. Mit diesen Eigenschaften werden unter anderm Methodenbeschreibungen, Zugriffsberechtigungen usw. festgelegt. Eine genaue Auflistung der Methodeneigenschaften ist hier43 zu finden. Im Beispiel erhält die Methode say() die Zugriffseigenschaft remote, was bedeutet, dass sie aus Flash heraus aufgerufen werden kann (Abb. 36 Zeile 6). Alle Eigenschaften bis auf access sind optional und können somit weggelassen werden. Es wird jedoch empfohlen, jeder Methode zusätzlich eine Beschreibung zuzuordnen, um sie besser unterscheiden zu können. Im Beispiel wurde dies durch description erreicht. Da das Pflegen der methodtable() bei vielen Methoden sehr aufwendig werden kann und die Übersicht zudem darunter leidet, kann man die methodtable() auch automatisch erstellen lassen. Der Aufbau ändert sich nur marginal wie das folgende Beispiel zeigt. 43 Vgl. 81

90 Allgemeine Betrachtungen (1) (2) include(amfphp_base. "util/methodtable.php"); include_once(amfphp_base. 'adapters/lib/arrayf.php'); Abbildung 37: Quellcode - Erforderliche Klassen der methodtable() Zunächst ist es notwendig zwei Klassen einzubinden, die die notwendigen Funktionalitäten zur Verfügung stellen (Abb. 37). (1) $this->methodtable = MethodTable::create( FILE ); Abbildung 38: Quellcode - Automatisches erzeugen einer methodtable() Nun muss der Inhalt des Konstruktors, durch den in Abbildung 38 zu sehenden, ersetzt werden. Durch den Aufruf wird im Verzeichnis, wo das aktuelle Skript gespeichert wurde, eine methodtable() erzeugt. Dies wird durch die PHP-Konstante FILE 44 erreicht. Da man bei der automatischen Erstellung zunächst keinen Einfluss hat, die zuvor genannten Eigenschaften der Methoden festzulegen, wird dies direkt bei der Methodenimplementierung erledigt. Dazu wird ein speziell formatierter Kommentarbereich (Abb. 39) direkt über der Methode angelegt, der die entsprechenden Daten enthält. Diese Art des Kommentars ist auch als javadoc45 Kommentar bekannt. (1) /** Liefert eine Nachricht zurueck remote (4) */ (5) function say($smessage) (6) { (7) (...) (8) } Abbildung 39: Quellcode - javadoc Kommentare in amfphp Die Kommunikation zwischen Flash und amfphp Wurde der Request in Flash abgesetzt, also die amfphp Funktion aufgerufen, versucht Flash eine Verbindung mit dem amfphp Gateway aufzubauen. Der genaue Vorgang ist in vier Schritte aufgeteilt und soll im folgenden, anhand von Abbildungen des NetConnection Debuggers46, erläutert werden. Der NetConnection Debugger ist ein Werkzeug, dass einem nach der Installation der Flash Remoting Komponenten zur Verfügung steht. 44 Vgl. 45 Vgl. 46 Vgl. 82

91 Allgemeine Betrachtungen Schritt 1: Verbindung mit dem Gateway Abbildung 40: Verbindung mit dem amfphp - Gateway Im ersten Schritt (Abb. 40) versucht sich der Client, der die Funktion aufruft, mit dem Gateway zu verbinden. Dabei gibt der ConnectionString die absolute URL an, wo dieser zu finden ist. Sollte diese URL nicht verfügbar sein oder der Gateway aus einem anderen Grund nicht zur Verfügung stehen, bricht der Verbindungsversuch mit einem Fehler ab. Der Ereignistyp zeigt dabei an, um welche Art der Kommunikation es sich handelt. Schritt 2: Aufruf der Funktion und Übergabe der Parameter Abbildung 41: Aufruf einer amfphp - Funktion Konnte die Verbindung, wie in Schritt 1 beschrieben, hergestellt werden, findet der eigentliche Aufruf (Abb. 41) der Funktion statt und falls vorhanden, werden die Parameter an PHP übergeben. Der Ereignistyp ist in diesem Fall Call und steht für den Aufruf einer Funktion. Die aufzurufende Funktion ist Teil eines Services/einer Klasse, weswegen der Methodenname mit ProInf.catList angegeben wird (siehe Kapitel Aufbau eines amfphp Services ). 83

92 Allgemeine Betrachtungen Schritt 3: Übergabe der PHP Session Abbildung 42: Übergabe der PHP Sessionid Im dritten Schritt (Abb. 42) muss sich der Client beim Server authentifizieren. Dies bedeutet im Detail, dass dem Server mitgeteilt werden muss, welcher Flash Client welches Ergebnis erwartet. Zu diesem Zweck wird die PHP-Session ID, welche beim Start des Flashfilms erzeugt wurde, an den Gateway übergeben. Danach kann die Anfrage einem Client zugeordnet werden (siehe Kapitel 4.3.). Schritt 4: Rückgabe des Ergebnisses Abbildung 43: Rückgabewerte einer Funktion Im vierten und letzten Schritt (Abb. 43) wird je nach Funktion das Ergebnis in Form eines Result -Ereignistyps zurück geliefert. Dies können Arrays, Resultsets oder jeder andere Typ, den Flash unterstützt, sein. Im Beispiel handelt es sich um ein mysql-resultset. 84

93 Allgemeine Betrachtungen Serverside PHP - Remote Method Nach den allgemeinen Abläufen kommen wir nun zurück zur aufgerufenen Servicemethode catlist(). Die Kategorieliste wird im Projektinformationssystem an zwei verschiedenen Stellen angezeigt und unterscheidet sich an diesen Stellen in der Funktion. Da ein Benutzer intern die Möglichkeit hat, sich seine eigenen Projekte nach Kategorien sortiert anzeigen zu lassen, ist es an dieser Stelle notwendig, dass die Methode catlist() einen Übergabeparameter bekommt, mit dem die Benutzer ID übergeben werden kann. Anschließend kann nach diesem Benutzer gefiltert werden. Um den Kommunikationsaufwand zwischen Flash und PHP möglichst gering zu halten, haben wir uns dazu entschlossen, die verschiedenen Resultsets nur einmal, also in einem einzigen Resultset zurückzugeben. Da in der catlist() Daten aus verschiedenen Datenbanktabellen zurückgegeben werden müssen, gab es zwei Möglichkeiten diese Abfrage zu realisieren. Zum Einen, jede Abfrage einzeln zu tätigen und deren Ergebnisse dann in einem Array zusammenzufügen oder alle Abfragen in einer SELECT-Anweisung 47 mit verschachtelten Unter-SELECTS durchzuführen. Wir haben uns für die zweite Möglichkeit entschieden, da die Anfragen an die Datenbank in beiden Fällen die gleichen bleiben, der Aufwand, die Daten zusammenzufügen aber entfällt. Ein durchgeführter Vergleich der Ausführungszeit zeigte außerdem, dass sich diese kaum unterscheiden. (1) function catlist( $intuserid = 0 ) (2) { (3) $this->dbconnect(); (4) return mysql_query ( (5) "SELECT (6) pr_main_kat.id AS intcatid, (7) pr_main_kat.value AS chrcatname, (8) pr_main_kat.beschreibung AS chrcatdescription, (9) COUNT(pr_main.id) AS intprocount, (10) (11) (SELECT pr_main.id FROM pr_main, pr_main_kat WHERE pr_main.kategorie = intcatid ORDER BY pr_main.id DESC LIMIT 1 ) AS intlastproid, (12) (SELECT pr_main.name FROM pr_main, pr_main_kat WHERE pr_main.kategorie = intcatid ORDER BY pr_main.id DESC LIMIT 1 ) AS chrlastproname, (13) (SELECT pr_main.user_id FROM pr_main, pr_main_kat WHERE pr_main.kategorie = intcatid ORDER BY pr_main.id DESC LIMIT 1 ) AS intlastprouserid, (14) (SELECT nick FROM pr_user WHERE id = intlastprouserid) AS chrlastprousername" (15) (16). ($intuserid > 0? " FROM pr_main, pr_main_kat WHERE pr_main_kat.id = pr_main.kategorie AND pr_main.user_id = $intuserid" : " FROM pr_main_kat LEFT JOIN pr_main ON pr_main_kat.id = pr_main.kategorie" ) (17) (18). " GROUP BY pr_main_kat.id" ); (19) } Abbildung 44: Quellcode - Aufbau der Kategorieliste Wie zuvor beschrieben, ist die Abfrage also in zwei Schritte aufgeteilt. Der erste Schritt ist die äußere SELECT-Anweisung (siehe Abb. 44 Zeile 5), die zunächst alle Projekte selektiert und diese dann den Kategorien zuordnet. Wird die catlist() im Außenbereich des 47 Vgl. 85

94 Allgemeine Betrachtungen Projektinformationssystems aufgerufen, werden alle Kategorien, die sich in der Tabelle pr_main_kat befinden aufgelistet und die Anzahl der Projekte in den jeweiligen Kategorien erfragt. Dabei werden ausdrücklich auch die Kategorien mit ausgewählt, die keine Projekte enthalten. Dies wird durch den LEFT JOIN (siehe Abb. 44 Zeile 20) erreicht. Findet der Aufruf der catlist() jedoch intern, durch einen bestimmten Benutzer statt, werden nur solche Kategorien angezeigt, die mindestens ein Projekt des Benutzers enthalten. Wir haben uns hierfür entschieden, um die Anzeige so übersichtlich wie möglich zu halten. Durch die einfache Verknüpfung der beiden Tabellen mit einer WHERE Bedingung, erreicht man genau dieses Ergebnis. Dabei wird die Kategorie ID in der Hauptprojekttabelle pr_main.kategorie mit der Kategorie ID der Kategorietabelle pr_main_ket.id verglichen (siehe Abb. 44 Zeile 19). Zuletzt muss in beiden genannten Fällen nach der Kategorie gruppiert werden. Im zweite Schritt der Abfrage befinden sich die einzelnen Unter-SELECTS (siehe Abb. 44 Zeile 11 17). Diese werden für jeden Durchlauf des äußeren SELECTS aufgerufen. Werden also im äußeren SELECT sieben Kategorien selektiert, wird auch jedes UnterSELECT siebenmal ausgeführt. Dadurch wird es möglich, dem Benutzer in der Kategorieübersicht Daten, wie den Namen des zuletzt eingestellten Projekts, anzeigen zu können. Weiterhin wird der Name des Benutzers angezeigt, der das letzte Projekt eingestellt hat. Da nahezu alle Objekte im Projektinformationssystem über IDs identifiziert und angesprochen werden, ist es notwendig zu dem Projektnamen und dem Benutzernamen auch die passenden IDs an Flash zu übertragen. Clientside Flash - Response verarbeiten Nachdem die Flash-Client-Anwendung die Servicefunktion aufgerufen hat, wird die Ausführung nicht angehalten, um die Rückgabe eines Wertes abzuwarten. Vielmehr wird die Ausführung fortgesetzt und festgelegt, welche Methoden die Ergebnis- oder die Fehlerbedingung, die die Servicefunktion zurückgeben wird, verarbeiten sollen. Ein PendingCall-Objekt mit einer responder-eigenschaft wird sofort nach Aufruf einer Servicemethode zurückgegeben. Es können Ergebnis- und Fehlerausgabe für jede Servicemethode verarbeitet werden, indem ein mx.rpc.relayresponder-objekt oder ein beliebiges ActionScript-Objekt, das die mx.rpc.responder-schnittstelle implementiert, erstellt und es der responder-eigenschaft des PendingCall-Objekts zugeordnet wird (Abb. 45). (1) pcremotecall.responder = new RelayResponder(this, 'catlist_result', 'catlist_error'); Abbildung 45: Quellcode - Aufruf in der ListCategory Klasse Mit dem RelayResponder-Objekt kann die Weitergabe von Ergebnis- und Fehlerereignissen an die Handlermethoden des PendingCall-Objekts geregelt werden. In unserem Fall gehören die Ergebnis- und Fehlerverarbeitungsmethoden derselben Klasse an, die auch die 86

95 Allgemeine Betrachtungen Servicemethode aufruft, worauf wir hinweisen, indem wir den Parameter responder auf den Bezeichner this einstellen. Den Ergebnis- und Fehlerverarbeitungsmethoden können beliebige Namen zugewiesen werden; wir verwenden hier catlist_result für eine Ergebnisausgabe und catlist_error für eine Fehlerausgabe. Die Namen wurden so gewählt, um einen Bezug zur aufrufenden Servicefunktion herstellen zu können. Im Fehlerfall wird also folgende Methode ausgeführt (Abb. 46), welche eine Nachricht im Bedienfeld Ausgabe des Flash-Authoring-Tools anzeigt. Der Methode wird ein FaultEventObjekt als Argument durch Flash Remoting übergeben, wenn ein Fehler beim Servicefunktionsaufruf auftaucht. (1) private function catlist_error(feerror:faultevent) : Void { (2) trace('there has been an error in ListCategory!'); (3) trace(' '); (4) trace(feerror.fault.faultstring); (5) } Abbildung 46: Quellcode - Teil der ListCategory Klasse Die Eigenschaft feerror.fault.faultstring liefert die Beschreibung des Fehlers. Bei einem erfolgreichen Servicefunktionsaufruf wird ein ResulEvent-Objekt als Argument an die Ergebnisverarbeitungsmethode catlist_result zurückgegeben (Abb. 47). Es enthält eine result-eigenschaft, die das von der Servicefunktion zurückgegebene Ergebnisobjekt speichert. Dieses Ergebnisobjekt kann unterschiedliche Typen von Ergebnissen, wie zum Beispiel String, Array oder RecordSet enthalten. Der RecordSet-Datentyp in Flash entspricht einem Resultset-Datentyp in PHP. In diesem Fall wurde ein RecordSet durch die Servicefunktion zurückgegeben. 87

96 Allgemeine Betrachtungen (1) private function catlist_result(reresult:resultevent) : Void { (2) numheight = 57; (3) _level0.param['content_mask_bonus'] = 0; (4) if (stradd == 'Intern') { (5) numheight = 71.5; (6) _level0.param['content_mask_bonus'] = 110; (7) } (8) // Category Objekte werden erzeugt (9) for (var i = numi; i < reresult.result.length; i++) { (10) arrelements[i-numi] = new Category(reResult.result.getItemAt(i)); (11) } (12) (13) // Elemente erzeugen, Zusatzinfos erzeugen (14) for (var i = 0; i < arrelements.length; i++) { (15) eval("_level0." + strpathmovieclip).cont.attachmovie('category'+stradd,'cat'+i, eval("_level0." + strpathmovieclip).cont.getnexthighestdepth()); (16) eval("_level0." + strpathmovieclip).cont['cat'+i]._x = 2; (17) eval("_level0." + strpathmovieclip).cont['cat'+i]._y = (numheight*i); (18) eval("_level0." + strpathmovieclip).cont['cat'+i].catname = arrelements[i].getcat(); (19) eval("_level0." + strpathmovieclip).cont['cat'+i].catdesc = arrelements[i].getcatdescription(); (20) eval("_level0." + strpathmovieclip).cont['cat'+i].numcatid = arrelements[i].getcatid(); (21) eval("_level0." + strpathmovieclip).cont['cat'+i].numlistpos = i; (22) if ( arrelements[i].getprocount() == 0) { (23) eval("_level0." + strpathmovieclip).cont['cat'+i].butcatname.usehandcursor = false; (24) eval("_level0." + strpathmovieclip).cont['cat'+i].butcatname.enabled = false; (25) eval("_level0." + strpathmovieclip).cont['cat'+i].butcatname.tabenabled = false; (26) } (27) (28) eval("_level0." + strpathwb).attachmovie('catinfo'+stradd,'catinfo'+i, eval("_level0." + strpathwb).getnexthighestdepth()); (29) eval("_level0." + strpathwb)['catinfo'+i]._visible = false; (30) eval("_level0." + strpathwb)['catinfo'+i].numlistpos = i; (31) eval("_level0." + strpathwb)['catinfo'+i].strdyncatinfoname = arrelements[i].getcat(); (32) [...] (33) } (34) } Abbildung 47: Quellcode - Teil der ListCategory Klasse Zu Beginn der Ergebnismethode werden zwei Werte für einen MovieClip gesetzt (siehe Abb. 47 Zeile 2), welcher als Maske fungiert und nur den Bereich anzeigt, der unter dessen Maskenbereich liegt. Danach wird geprüft, ob in der Variablen stradd, deren Wert in der Methode display() als Parameter übergeben wurde, Intern steht. In diesem Fall würde die Kategorieliste für den Internen Bereich angefordert. Hierfür müssen die Maskenwerte anders gesetzt werden, da die Maske und der ihr zugewiesene Content Container MovieClip eine andere Abmessung besitzen. Anschließend folgt eine for-schleife (siehe Abb. 47 Zeile 9), welche für jede Zeile im RecordSet ein Category-Objekt erstellt und diesem den entsprechenden Datensatz mitgibt. Diese Category-Objekte werden jeweils einem Feld im arrelements Array zugewiesen. 88

97 Allgemeine Betrachtungen (1) public function Category(reResultObject:Object) { (2) strcat = reresultobject.chrcatname; (3) numcatid = reresultobject.intcatid; (4) strcatdescription = reresultobject.chrcatdescription; (5) numprocount = reresultobject.intprocount; (6) strlastpro = reresultobject.chrlastproname; (7) numlastproid = reresultobject.intlastproid; (8) strnick = reresultobject.chrlastprousername; (9) numuserid = reresultobject.intlastprouserid; (10) } Abbildung 48: Quellcode - Teil der Category Klasse In der Category-Klasse werden die unterschiedlichen Werte des übergebenen Datensatzes den entsprechenden Attributen zugewiesen (Abb. 48). Die zweite for-schleife (siehe Abb. 47 Zeile 14) läuft von numi, einem Wert, welcher der display() Methode als Parameter übergeben wurde, der regelt, ob die erste Kategorie (diese enthält die gesperrten Projekte) mit angezeigt werden soll oder nicht. Dies ist jedoch nur im Internen Bereich und mit bestimmten Benutzerrechten möglich, weswegen numi den Wert 1 im Außenbereich annimmt. Die for-schleife läuft über alle Felder des Arrays arrelements (mit Ausnahme des Feldes arrelements[0]). Für jedes Feld und demnach für jedes Category-Objekt wird ein MovieClip als Listenelement dem Container-MovieClip auf dessen höchster Ebene angefügt. Dieser MovieClip hat den Verknüpfungsnamen Category oder CategoryIntern (für den Internen Bereich) und liegt in der Bibliothek des Flashfilms. Den angefügten MovieClips wird ein individueller Name gegeben (siehe Abb. 47 Zeile 15), um sie später gezielt ansprechen zu können. Zuerst wird ihre x- und y-posittion im Container MovieClip manipuliert. Danach werden die unterschiedlichen Variablen, dynamischen Textfelder und Schaltflächen der MovieClips mit Werten aus dem Category-Objekt gefüllt. Somit repräsentiert das angezeigte Listenelement die wichtigsten entsprechenden Daten zur Kategorie (Abb. 49). Des Weiteren wird für jedes Abbildung 49: Kategorieliste im Außenbereich arrelements-feld ein MovieClip dem Container-MovieClip für die Zusatzinfos angefügt (siehe Abb. 47 Zeile 28). Auch hier werden alle dynamischen Textfelder und Schaltflächen mit Werten aus dem Category-Objekt gefüllt. Bei jedem dieser MovieClips wird die Eigenschaft _visible, welche festlegt, ob ein MovieClip sichtbar ist oder nicht, auf false gesetzt. Erst wenn sich die Maus des Benutzers über dem Namen der Kategorie in der Kategorieliste befindet, wird ein rollover-event ausgelöst und der zugehörige MovieClip für die Zusatzinfos dieser Kategorie im Container MovieClip angezeigt, in dem die Methode displayinfo() aufgerufen wird. In jener (Abb. 50) wird die _visible Eigenschaft des MovieClips auf true 89

98 Allgemeine Betrachtungen gesetzt. Dadurch erhält der Benutzer zu den allgemeinen Daten aus der Liste noch ein paar weitere in diesem zusätzlichen Bereich. (1) public function displayinfo(numlistpos:number) : Void { (2) if (!isnan(_level0.param['old_listpos_cat']) && _level0.param['old_listpos_cat']!= numlistpos) { (3) eval("_level0." + strpathwb)["catinfo"+_level0.param['old_listpos_cat']]._visible = false; (4) } (5) eval("_level0." + strpathwb)["catinfo"+numlistpos]._visible = true; (6) (7) _level0.loadwbcontent._visible = false; (8) _level0.param['old_listpos_cat'] = numlistpos; (9) } Abbildung 50: Quellcode - Teil der ListCategory Klasse numlistpos steht für die Position der Kategorie im arrelements-array. Wenn bereits ein MovieClip für Zusatzinfos angezeigt wird, welcher nicht der angeforderte MovieClip ist, wird dessen Sichtbarkeit auf false gesetzt. Anschließend wird die Sichtbarkeit des angeforderten MovieClips geändert, die Ladegrafik ausgeblendet und die Listenposition gesichert. In der Klasse ListCategory befinden sich noch weitere Methoden, die auf Ereignisse im Zusammenhang mit der Kategorieliste reagieren oder Servicemethoden aufrufen. Hierzu gehört auch die Reaktion auf den Klick des Benutzers auf den Kategorienamen, wodurch eine Liste mit Projekten zu dieser Kategorie angefordert wird. Außerdem kann der Benutzer auch auf das zuletzt eingestellte Projekt in dieser Kategorie klicken, wodurch er in dessen Projektansicht gelangt. Des Weiteren sorgt ein Klick auf den Namen des Benutzers, der jenes Projekt einstellte, dafür, dass alle Projekte angezeigt werden, die dieser Benutzer eingestellt hat. 90

99 Allgemeine Betrachtungen Liste aus einem Array erstellen Im folgenden Kapitel wird anhand von Quellcode erläutert, wie der Aufbau der Projektliste zu einer bestimmten Kategorie erfolgt. Dabei ist das Kapitel in eine Beschreibung und in den technischen Ablauf gegliedert. Dieser technische Ablauf ist wiederum in drei Bereiche aufgeteilt. Der erste Bereich beschreibt den Aufruf der amfphp Methode aus Flash heraus (Clientside Flash - Remote Call). Der zweite Bereich (Serverside PHP - Remote Service) beschreibt den Ablauf auf der Serverseite, sowie das Hinzufügen verschiedener Medien an ein Resultset (Array-Methoden der Projektdaten). Der dritte und letzte Teil beschreibt die Rückgabe der Daten von amfphp an Flash und dessen Auswertung (Clientside Flash - Response verarbeiten) Beschreibung In diesem Abschnitt betrachten wir die Rückgabe eines assoziativen Arrays, um daraus eine Liste zu erstellen. In unserem System werden drei Arten von Projektlisten unterschieden. Zuerst die Projektliste für Kategorien (prolistcat), welche alle Projekte zu einer Kategorie anzeigt. Außerdem gibt es die Projektliste für Benutzer (prolistuser), welche alle Projekte eines bestimmten Benutzers anzeigt. Zum Schluss gibt es noch die Projektliste für Metadaten (prolistmeta), welche alle Projekte zu einer bestimmten Metadate anzeigt. Diese Listen werden sowohl im Außenbereich, als auch im Internen Bereich verwendet und unterscheiden sich in diesen Bereichen nur durch ihre leicht veränderte Darstellung. Im Internen Bereich gibt es noch die Erweiterung, dass diese Listen auf einen bestimmten Benutzer eingeschränkt werden können. Somit würden bei einer prolistcat nur die Projekte in der gewählten Kategorie angezeigt werden, die zu einem bestimmten Benutzer gehören. Somit soll der Zugriff auf die eigenen Projekte erleichtert werden Technischer Ablauf Clientside Flash - Remote Call Exemplarisch für alle Projektlisten werden wir hier die prolistcat des Außenbereichs betrachten. Sie wird angefordert, wenn der Benutzer auf den Namen einer Kategorie in der Kategorieliste klickt (Abb. 51). 91

100 Allgemeine Betrachtungen (1) (2) (3) on (release) { } _level0.listcat.choosecat(numlistpos); Abbildung 51: Quellcode - Event eines Category-Listenelements Die Methode choosecat() des ListCategory-Objekts erhält als Parameter die Position des gewählten Category-Objekts im arrelements-array (Abb. 52). (1) public function choosecat(numpos:number) { (2) _level0.param['cat'] = arrelements[numpos].getcat(); (3) _level0.param['cat_id'] = arrelements[numpos].getcatid(); (4) _level0.param['last_content'] = _level0.param['act_content']; (5) _level0.param['act_content'] = 'ListProjectCat'; (6) _level0.param['status_page'] = 'prolistc'; (7) _level0.param['list_kind'] = arrelements[numpos].getcat(); (8) _level0.param['act_page'] = 'StartPreContent'; (9) (10) _level0.nextcontent(_level0.param['act_page']); (11) } Abbildung 52: Quellcode - Teil der ListCategory Klasse In der Methode werden einige Felder im PARAM-Array belegt, um diese zwischenzeitlich zu speichern (wie die Kategorie ID der gewählten Kategorie). Dann wird die Methode NextContent() aufgerufen, die als Navigationsfunktion fungiert und die festgelegten Sprungmarken (Bildbezeichnung) ansteuert. In diesem Fall springt sie an die Stelle StartPreContent, welche vor dem aktuellen Bild (StartContent) liegt und dafür sorgt, dass StartContent gleich wieder abgespielt wird, nur mit einer anderen Einstellung der filmspezifischen Parameter im PARAM-Array. Vieles von dem, was für das Erzeugen einer Kategorieliste wichtig ist, gilt gleichermaßen für die Projektlisten. Alle nötigen Klassen müssen eingebunden sein, bevor ein Projektlisten-Objekt (listpro) erzeugt werden kann, wobei wieder auf das Singleton Design Pattern zurückgegriffen wurde (Abb. 54). (1) listpro = ListProject.getInstance('container_mc', 'dropzonewb', PARAM['pic_url']); Abbildung 53: Quellcode - Aufruf im Flashfilm, Bild: StartContent Im Vergleich zur Kategorieliste wird der getinstance-methode noch die URL zu den Statusgrafiken der Projekte übergeben. Danach werden mit der Methode displayc() alle nötigen Daten für die Projektliste angefordert (Abb. 54). (1) listpro.displayc(param['cat_id'], PARAM['cat'], ); Abbildung 54: Quellcode - Aufruf im Flashfilm, Bild: StartContent 92

101 Allgemeine Betrachtungen Der Aufruf displayc() bezeichnet hier die prolistcat. In den anderen Fällen würden die Listen mittels displayu() oder displaym() angefordert. Für die benutzerbezogenen Projektlisten im Internen Bereich steht im Methodennamen ein zusätzliches U. Diese Unterscheidung ist nötig, um auf die jeweiligen Servicemethoden mit ihren spezifischen Parametern und unterschiedlicher Parameteranzahl zugreifen zu können. Der displayc()-methode wird die entsprechende Kategorie ID, der Kategoriename und ggf. der String Intern für den gleichnamigen Bereich übergeben (Abb. 55). (1) public function displayc(numcid:number, strcatname:string, straddstring:string) : Void { (2) cleancontainer(); (3) numcatid = numcid; (4) strcat = strcatname; (5) numuserid = undefined; (6) strnickname = undefined; (7) stradd = straddstring; (8) (9) // Flash Remoting Service aufrufen (10) pcremotecall = srvlistpro.prolistcat(numcatid); (11) pcremotecall.responder = new RelayResponder(this, 'prolist_result', 'prolist_error'); (12) } Abbildung 55: Quellcode - Teil der ListProject Klasse In ihr wird auch eine cleancontainer()-methode durchgeführt, mit dem gleichen Effekt, wie in der ListCategory-Klasse, da es sich um den gleichen MovieClip Container handelt, in dem die Listenelemente angezeigt werden sollen. Zusätzlich werden einige Variablen belegt, bevor die Servicemethode aufgerufen wird. Ihr wird die ID der gewählten Kategorie mitgegeben. Serverside PHP - Remote Service Wir haben uns aus verschiedenen Gründen dazu entschlossen nicht nur Resultsets als Ergebnis an Flash zurück zu geben, sondern in speziellen Fällen auch Arrays. Der Hauptgrund ist, dass es technisch einfach nicht möglich ist, alle benötigten Informationen mit einer Abfrage in einem Resultset zu speichern. Grund dafür ist, dass bei verschiedenen Daten, die Anzahl beim Ausführen der SELECT Abfrage noch nicht feststeht. Die Anzahl wird aus der Datenbank ausgelesen und kann erst dann an das vorherige Ergebnis angehängt werden. Zu diesem Zweck wurde der Inhalt des ursprünglichen Resultsets in einem Array gespeichert. Es existieren verschiedene Funktionen, um die dynamischen Daten anzufügen, auf die später genauer eingegangen wird. Nach dem Anfügen der Daten wäre es prinzipiell möglich, dass Array wieder in ein Resultset umzuwandeln, was sich aber als nicht praktikabel herausgestellt hat. Da es in amfphp ebenso möglich ist, ein Array an Flash zurück zu geben und dieses vergleichbar bearbeitet werden kann, war es nur logisch, sich diesen Arbeitsschritt zu sparen. 93

102 Allgemeine Betrachtungen (1) function prolistcat( $intcatid, $intuserid = 0) (2) { (3) $arrproject = array(); (4) $this->dbconnect(); (5) $result = mysql_query ( (6) "SELECT (7) pr_main.id AS intproid, (8) pr_main.name AS chrproname, (9) pr_main.kurz_beschr AS chrproshortdesc, (10) pr_main.einstell_datum AS chrentrydate, (11) pr_main.start_datum AS chrstartdate, (12) pr_main.user_id AS intprouserid, (13) (... Unter-SELECTS... ) (14) FROM pr_main (15) WHERE pr_main.kategorie = ". $intcatid. ($intuserid > 0? " AND pr_main.user_id = (16) $intuserid" : "" ) (17). " ORDER BY pr_main.id DESC"); (18) // Das Resultset in ein Array schreiben (19) while($arrproject[] = mysql_fetch_assoc($result)); (20) return $this->addprojecttechno($arrproject); (21) } Abbildung 56: Quellcode Aufbau der Projektliste einer Kategorie Der Methode prolistcat() muss beim Aufruf eine Kategorie ID übergeben werden, um festzulegen, zu welcher Kategorie die Projekte selektiert werden sollen. Optional ist wieder die Übergabe einer Benutzer ID. Wird sie angegeben, werden nur solche Projekte selektiert, die zu dieser Benutzer ID gehören. Der Aufbau der Methode unterscheidet sich zunächst kaum vom Aufbau einer Methode die ein Resultset zurück gibt. Unterschiede liegen zum Einen in den Werten, die zurück gegeben werden, und zum Anderen in der weiteren Verarbeitung des Resultsets. Zunächst wird ein Array erzeugt, dass für die spätere Nachbearbeitung wichtig ist. In ihm wird das Resultset gespeichert. Dann findet, wie vor jeder SELECT-Anweisung, ein Datenbank-Connect statt. Dazu existiert eine eigene Methode, auf die an dieser Stelle aber nicht weiter eingegangen werden soll. Anders als bei den Resultset-Methoden wird das Ergebnis der SELECT-Anweisung nicht direkt zurück gegeben, sondern in der Variable $result gespeichert (siehe Abb. 56 Zeile 5). Im ersten Teil des SELECTs werden Daten zu den einzelnen Projekten, wie der Projektname und die Projekt ID aus der Datenbanktabelle pr_main selektiert und in Variablen gespeichert. Dann muss wie auch in den Resultset-Methoden auf den Inhalt anderer Tabellen zugegriffen werden, um weitere Daten zum Projekt in Variablen speichern zu können. Da der Aufbau jedoch sehr dem der Resultset-Methoden ähnelt, wird hier nicht noch einmal darauf eingegangen. In der WHERE Klausel (siehe Abb. 56 Zeile 15-17) der SELECT-Anweisung wird je nachdem, ob eine Benutzer ID übergeben wurde oder nicht, die Auswahl der Projekte durchgeführt. Die Projekte werden außerdem in umgekehrter Reihenfolge, in der sie eingetragen wurden, ausgegeben, um die aktuellsten Projekte zuerst in der Liste sehen zu können. 94

103 Allgemeine Betrachtungen In den nächsten beiden Schritten liegt der entscheidende Unterschied zu den ResultsetMethoden. Zunächst wird das Resultset, in dem die Daten zu den selektierten Projekten stehen, in ein Array geschrieben. Im nächsten Schritt wird dieses Array an eine Methode übergeben, die zusätzliche Daten zu den Projekten anhängt (siehe Abb. 56 Zeile 19 20). Bei den zusätzlichen Daten handelt es sich in diesem speziellen Fall um die ausgewählten Technologien eines Projekts. Wie das Anhängen der zusätzlichen Daten genau funktioniert und um welche Daten es sich dabei handelt, wird im nächsten Kapitel behandelt. Array-Methoden der Projektdaten Die folgenden Methoden haben die Aufgabe Arrays, in denen Projektdaten gespeichert sind, um zusätzliche Daten zu erweitern. Bei den übergebenen Arrays handelt es sich um assoziative, zweidimensionale Arrays, in denen jede Zeile ein Projekt aus dem Projektinformationssystem darstellt. Der Vorteil von assoziativen Arrays im Gegensatz zu normalen Arrays besteht darin, dass die einzelnen Elemente über so genannte Schlüssel angesprochen werden können. In unserem Fall sind das die Spaltennamen der Datenbank, falls dies beim Erstellen der Resultsets nicht geändert wurde. Projekt Technologien hinzufügen Die folgende Methode wurde aus Gründen der Übersichtlichkeit in drei Abbildungen aufgeteilt. (1) (2) (3) (4) (5) function addprojecttechno($array) { $arrproject = $array; // Die zugewiesenen Technologien werden ausgelesen $result2 = mysql_query("select id FROM pr_meta_main_def WHERE value = 'Technologie'"); (6) $row = mysql_fetch_row($result2); (7) $intprotechtabid = $row[0]; Abbildung 57: Quellcode - Projekttechnologien einem Array hinzufügen - Teil 1 Die einzelnen Metadaten, zu denen auch die Technologien gehören, stehen in einer eigenen Tabelle. Deswegen muss zunächst die ID der Metadate Technologie selektiert werden. Anschließend wird diese ID, zur späteren Nutzung in der Variable $intprotechtabid gespeichert. 95

104 Allgemeine Betrachtungen (1) (2) (3) (4) for($i = 0; $i < sizeof($arrproject) -1; $i++) { $arrproject[$i]["intprotechtabid"] = $intprotechtabid; $result3 = mysql_query("select meta_sub_id FROM pr_meta_main_set WHERE pr_id = ". (5) $arrproject[$i][intproid]. " AND meta_id = $intprotechtabid"); (6) // Anzahl der Technologien eines Projekts bestimmt die Laufzeit (7) $inttechnumber = 1; (8) while ($techsubids = mysql_fetch_array($result3)) (9) { (10) // Dynamische Technologienamen erzeugen (11) $techidname = "intprotech".$inttechnumber.id; (12) $arrproject[$i][$techidname] = $techsubids[0]; (13) $restechname = mysql_fetch_row(mysql_query("select value FROM pr_meta_techno WHERE id = $techsubids[0]")); (14) $techname = "chrprotech".$inttechnumber; (15) $arrproject[$i][$techname] = $restechname[0]; (16) $inttechnumber++; (17) } Abbildung 58: Projekttechnologien einem Array hinzufügen - Teil 2 Als Nächstes wird das Array in der for-schleife so lange durchlaufen, wie es Einträge im Array gibt. Um jedes Projekt eindeutig identifizieren zu können, wurde auch hier die Projekt ID im Array gespeichert. Zudem werden zur Bestimmung der Technologien noch zwei weitere IDs benötigt, zum Einen die ID der Technologietabelle in der Datenbank und zum Anderen die ID der eigentlichen Technologie. Mit diesen beiden IDs kann dann aus der passenden Datenbanktabelle ausgelesen werden, welche Technologien zu dem aktuellen Projekt gespeichert wurden. In $result3 stehen nach der Abfrage alle Technologie IDs zu dem aktuellen Arrayeintrag (Projekt) zur Verfügung (siehe Abb. 57 Zeile 4 5). In der whileschleife die dann folgt, werden die selektierten Technologie IDs dazu benutzt, um die Technologienamen auszulesen, da diese Namen in Flash angezeigt werden (siehe Abb. 57 Zeile 13 14). Im Regelfall besitzt ein Projekt mehr als eine Technologie, weswegen die Schlüssel dieser, im Array unterschiedlich sein müssen. Dazu wird ein dynamischer ArraySchlüssel erzeugt und mit dem passenden Wert in das Array geschrieben (siehe Abb. 57 Zeile 15 16). (1) (2) (3) (4) (5) // Die vorhandenen Technologien zaehlen $arrproject[$i]["intprotechcount"] = $inttechnumber -1; } return $arrproject; } Abbildung 59: Projekttechnologien einem Array hinzufügen - Teil 3 Damit Flash beim Auslesen des Array bekannt ist, wie viele Technologieeinträge es zu einem Projekt gibt, wird zu den Arraynamen und deren Werten noch die Gesamtzahl der Technologien im Array-Schlüssel intprotechcount gespeichert. Dazu muss von der Zählervariable $inttechnumber eins abgezogen werden, da sie bei eins anfängt zu zählen und nicht wie üblich bei null. Der Grund liegt darin, dass diese Variable auch dazu gebraucht 96

105 Allgemeine Betrachtungen wird, die dynamischen Technologie-Array-Schlüssel zu erzeugen und der Zählvorgang dort nicht mit null beginnen soll. Projekt Medien und Links hinzufügen Der Vollständigkeit halber sollen an dieser Stelle noch zwei weitere Methoden erwähnt werden. Ihre Implementierung ähnelt der vorherigen Methode aber zu stark, als dass nochmal im Detail auf sie eingegangen werden müsste. addprojectmedia($array) Bilder, Dokumente und weitere Medien hinzufügen addprojectlinks($array) Links hinzufügen Beiden Methoden wird wieder ein Array mit Projekten übergeben, die dann durch die entsprechenden Daten ergänzt werden. In der Methode addprojectmedia() werden nur Verweise auf die Medien übergeben und nicht die tatsächlichen Dateien. Beim Anzeigen dieser Dateien fordert Flash sie später gesondert an. Clientside Flash - Response verarbeiten Auch hier werden die Ergebnis- oder Fehlerereignisse an das PendingCall-Objekt weitergegeben. Die Methode für ein Fehlerereignis prolist_error() gleicht der Methode catlist_error() und wird hier nicht weiter betrachtet. Im Ergebnisfall wird die Methode prolist_result() aufgerufen. Ihr wird ebenfalls ein ResultEvent-Objekt mitgegeben, in dem das Ergebnis der Servicemethode steckt. Im ersten Teil der Methode werden Variablen für den Masken MovieClip gesetzt. Darauf folgt eine forschleife (Abb. 60), die über alle Felder des zurückgegebenen Result-Arrays reresult.result läuft. Für jedes Feld der ersten Dimension des mehrdimensionalen Arrays wird ein ProjectObjekt erstellt und dem Array arrelements zugewiesen. (1) for (var i = 0; i < reresult.result.length-1; i++) { (2) arrelements[i] = new Project(); (3) arrelements[i].proinitialize(reresult.result[i], numcatid, strcat, numuserid, strnickname); (4) } Abbildung 60: Quellcode - Teil der ListProject Klasse Diesem wird dann in einer weiteren Methode (Abb. 61) der entsprechende Datensatz des Arrays und vier Parameter übergeben. 97

106 Allgemeine Betrachtungen (1) public function proinitialize(reresultarray:array, numcatid:number, strcat:string, numuserid:number, strnickname:string) { (2) strpro = reresultarray['chrproname']; (3) numproid = reresultarray['intproid']; (4) strshortdescription = reresultarray['chrproshortdesc']; (5) strentrydate = reresultarray['chrentrydate']; (6) strstartdate = reresultarray['chrstartdate']; (7) strcourse = reresultarray['chrprocourse']; (8) numcoursetabid = reresultarray['intprocoursetabid']; (9) [...] (10) if (!numcatid) { (11) this.numcatid = reresultarray['intprocatid']; (12) this.strcat = reresultarray['chrprocatname']; (13) } else { (14) this.numcatid = numcatid; (15) this.strcat = strcat; (16) } (17) [...] (18) } Abbildung 61: Quellcode - Teil der Project Klasse In der Methode proinitialize() werden die Attribute eines Projekts mit den Werten aus dem übergebenen Array gefüllt. Da es sich um ein assoziatives Array handelt, kann über die Feldbezeichnungen auf die entsprechenden Werte zugegriffen werden. Des Weiteren wird geprüft, ob die ebenfalls übergebenen Parameter mit Werten gefüllt sind. Ist dies der Fall, werden diese in entsprechende Attribute kopiert, ansonsten wird auf Felder aus dem Array zugegriffen. Der Grund für eine mögliche Vorbelegung der übergebenen Parameter liegt in den unterschiedlichen Projektlisten und deren unterschiedlich vorbelegten Variablen. (1) for (var i = 0; i < arrelements.length; i++) { (2) eval("_level0." + strpathmovieclip).cont.attachmovie('project'+stradd, 'Pro'+i, eval("_level0." + strpathmovieclip).cont.getnexthighestdepth()); (3) eval("_level0." + strpathmovieclip).cont['pro'+i]._x = 2; (4) eval("_level0." + strpathmovieclip).cont['pro'+i]._y = (numheight*i); (5) eval("_level0." + strpathmovieclip).cont['pro'+i].numproid = arrelements[i].getproid(); (6) eval("_level0." + strpathmovieclip).cont['pro'+i].proname = arrelements[i].getpro(); (7) [...] (8) eval("_level0." + strpathwb).attachmovie('proinfo'+stradd, 'ProInfo'+i, eval("_level0." + strpathwb).getnexthighestdepth()); (9) eval("_level0." + strpathwb)['proinfo'+i]._visible = false; (10) eval("_level0." + strpathwb)['proinfo'+i].vinit = true; (11) eval("_level0." + strpathwb)['proinfo'+i].numlistpos = i; Abbildung 62: Quellcode - Teil der ListProject Klasse Im Anschluss an die Erzeugung von Project-Objekten folgt eine erneute for-schleife (Abb. 62), in der für jedes Feld und demnach für jedes Project-Objekt ein Listenelement aus der Bibliothek in den Container MovieClip gefügt und mit Daten gefüllt wird. Zusätzlich wird auch hier ein MovieClip aus der Bibliothek dem Container MovieClip für die Zusatzinfos angefügt und mit Daten gefüllt. Dessen Eigenschaft _visible wird auf false gesetzt und nur dann auf true geändert, was die Anzeige des entsprechenden MovieClips nach sich zieht, wenn der Benutzer den Mauszeiger über den Namen eines Projektes bewegt. Hierfür ist die Methode 98

107 Allgemeine Betrachtungen displayinfo() zuständig, welche im wesentlichen der namensgleichen Methode aus der ListCategory-Klasse gleicht. Mit der fertigen Projektliste (Abb. 63) für eine bestimmte Kategorie stehen Benutzer Möglichkeiten dem viele zur Verfügung, wie er weiter Abbildung 63: Projektliste zur Kategorie Medieninformatik im Außenbereich vorgehen kann. Ein Klick auf eine Metadate oder einen Benutzernamen zieht eine neue Projektliste nach sich, die nach dem hier beschriebenen Prinzip erstellt wird. Über diese Querverweise entstehen unterschiedliche Projektlisten, die unterschiedliche Sortierungen darstellen und Aspekte beleuchten. Ein Klick auf den Projektnamen führt zur Ansicht dieses Projekts, in der alle vorhandenen Daten präsentiert werden (siehe Kapitel ). 99

108 Allgemeine Betrachtungen RecordSet mit einem Datensatz Im Folgenden wird anhand von Quellcode erläutert, wie Daten mit Hilfe von RecordSets vervollständigt werden. Dabei ist das Kapitel in eine Beschreibung und in den technischen Ablauf gegliedert. Dieser technische Ablauf ist wiederum in drei Bereiche aufgeteilt. Der Erste beschreibt den Aufruf der amfphp Methode (Clientside Flash - Remote Call). Der zweite Bereich (Serverside PHP - Remote Service) beschreibt den Ablauf auf der Serverseite. Der dritte und letzte Teil beschreibt die Rückgabe des RecordSets von amfphp an Flash und dessen Auswertung (Clientside Flash - Response verarbeiten) Beschreibung In unserem Projektinformationssystem werden RecordSets nicht nur zum Erstellen von Listenelementen und den ihnen zu Grunde liegenden Objekten verwendet, sondern auch zum nachträglichen Ergänzen von Daten eines Objektes. Wie dies im Einzelnen aussieht, betrachten wir am Beispiel der Vervollständigung der Benutzerdaten Technischer Ablauf Clientside Flash - Remote Call Die folgende Methode usercomplete() (Abb. 66) aus der User-Klasse kann an zwei unterschiedlichen Stellen Abbildung 64: Benutzerliste aufgerufen werden. Zum Einen wird sie verwendet, wenn ein Profil eines Benutzers aus der Benutzerliste (Abb. 64) angefordert wird. Zum Anderen, wenn das eigene Profil (Abb. 65) aufgerufen wird. Auch hier müssen einige Benutzerdaten ergänzt werden. Abbildung 65: Eigenes Profil (1) public function usercomplete() : Void { (2) // hier werden die fehlenden Daten für einen User geholt (3) pcremotecall = srvuser.usercomplete(numuserid); (4) pcremotecall.responder = new RelayResponder(this, 'usercomp_result', 'usercomp_error'); (5)} Abbildung 66: Quellcode - Teil der User Klasse In der usercomplete()-methode wird der betreffende Service aufgerufen. Ihm wird die Benutzer ID mitgegeben, wodurch der Benutzer eindeutig identifiziert wird. Im Anschluss wird wie gewohnt festgelegt, welche Methoden die Ergebnis- oder die Fehlerbedingung, welche die Servicefunktion zurück gibt, verarbeiten sollen. 100

109 Allgemeine Betrachtungen Serverside PHP - Remote Service Die PHP-Methode (Abb. 67) zum Hohlen der Daten unterscheidet sich nur wenig von der Umsetzung der PHP-Listenmethoden. Es wird auch hier ein Resultset zurückgegeben, so das Flash einfach auf die Daten zugreifen kann. (1) (2) (3) (4) (5) (6) (7) (8) function usercomplete($intuserid) { $this->dbconnect(); return mysql_query ( "SELECT pr_user.passwort AS chruserpassword, pr_user.vorname AS chruserfirstname, pr_user.nachname AS chruserlastname, pr_user. AS chruser , pr_user.strasse AS chruserstreetname, pr_user.strasse_nr AS chruserstreetnum, (9) pr_user.ort AS chrusercity, pr_user.plz AS chruserzipcode, (10) (11) (SELECT count(pr_main.id) FROM pr_main WHERE pr_main.user_id = $intuserid) AS intuserprocount, (12) (SELECT pr_main.id FROM pr_main WHERE pr_main.user_id = $intuserid ORDER BY (13) pr_main.id DESC LIMIT 1 ) AS intlastuserproid, (14) (SELECT pr_main.name FROM pr_main WHERE pr_main.user_id = $intuserid ORDER BY pr_main.id DESC LIMIT 1 ) AS chrlastuserproname (15) (16) FROM pr_user (17) WHERE pr_user.id = $intuserid" ); (18) } Abbildung 67: Quellcode - Benutzerdaten vervollständigen Da diese Funktion den Inhalt eines Flash-Benutzerobjekts nur vervollständigt, müssen nicht alle Benutzerdaten aus der Datenbank geholt werden. Daten wie der Benutzername oder die Benutzer ID sind Flash bereits bekannt und können daher ausgelassen werden. Clientside Flash - Response verarbeiten In der Methode für das Ergebnisereignis werden die einzelnen Werte des erhaltenen RecordSet-Datensatzes an die entsprechenden Attribute des User-Objektes übergeben (Abb. 68). Da hier nur ein Datensatz im RecordSet steckt (an der Stelle 0), wird direkt auf diesen zugegriffen. (1) private function usercomp_result(reresult:resultevent) : Void { (2) str = reresult.result.getitemat(0).chruser ; (3) strfirstname = reresult.result.getitemat(0).chruserfirstname; (4) strlastname = reresult.result.getitemat(0).chruserlastname; (5) strstreet = reresult.result.getitemat(0).chruserstreetname; (6) numnumber = reresult.result.getitemat(0).chruserstreetnum; (7) strcity = reresult.result.getitemat(0).chrusercity; (8) numzipcode = reresult.result.getitemat(0).chruserzipcode; (9) strlastpro = reresult.result.getitemat(0).chrlastuserproname; (10) numlastproid = reresult.result.getitemat(0).intlastuserproid; (11) numprocount = reresult.result.getitemat(0).intuserprocount; (12) strpasswordmd5 = reresult.result.getitemat(0).chruserpassword; (13) } Abbildung 68: Quellcode - Teil der User Klasse 101

110 Allgemeine Betrachtungen Einfache Rückgabewerte In diesem Kapitel wird anhand des Quellcodes erläutert, wie einfache Rückgabewerte verarbeitet werden. Das Kapitel unterteilt sich in eine Beschreibung und in den technischen Ablauf. Dieser ist wiederum in drei Bereiche aufgeteilt. Der Erste beschreibt den Aufruf der amfphp Methode (Clientside Flash - Remote Call). Der zweite Bereich (Serverside PHP - Remote Service) beschreibt den Ablauf auf der Serverseite. Der dritte Teil beschreibt das Senden des Rückgabewertes von amfphp an Flash und dessen Auswertung (Clientside Flash - Response verarbeiten) Beschreibung Zu den RecordSets und Arrays, welche durch die unterschiedlichsten Services an Flash zurückgegeben werden, kommen auch einfache Rückgabewerte, die häufig über den Erfolg oder Misserfolg eines Services Auskunft geben. Diese Rückgabewerte werden zum Beispiel beim Sperren, Freischalten oder Löschen von Projekten oder Benutzern verwendet Technischer Ablauf Clientside Flash - Remote Call Exemplarisch für die unterschiedlichen Anwendungsfälle betrachten wir hier das Sperren eines Benutzers. Beim Klick auf den entsprechenden Button (Abb. 69) im Profil des betreffenden Benutzers wird die Methode userlock() ausgeführt (Abb. 70). In Abbildung 69: Benutzer sperren ihr wird der Service aufgerufen und der Methode die Benutzer ID mitgegeben, um den Benutzer identifizieren und sperren zu können. (1) public function userlock() { (2) pcremotecall = srvuser.userlock(numuserid); (3) pcremotecall.responder = new RelayResponder(this, 'userlock_result', 'userlock_error'); (4) } Abbildung 70: Quellcode - Teil der User Klasse Wie bisher wird im Anschluss an den Serviceaufruf festgelegt, welche Methoden die Ergebnis- oder die Fehlerbedingung verarbeiten sollen. 102

111 Allgemeine Betrachtungen Serverside PHP - Remote Service Die Rückgabewerte signalisieren in den meisten Methoden, ob die Ausführung dieser fehlerfrei funktioniert hat oder nicht. Da die Funktion dieser einfachen Methoden sich meist auf SELECT-Anweisungen beschränkt, kann der Status der PHP-Methode mysql_query() übernommen werden. Diese liefert true zurück, wenn die Ausführung erfolgreich war und false, falls nicht. (1) (2) (3) (4) function userlock($intuserid) { $this->dbconnect(); $result = mysql_query ( "UPDATE pr_user SET frei = 0 WHERE id = $intuserid" ); (5) if($result) (6) $return = "1"; (7) else (8) $return = "0"; (9) (10) return $return; (11) } Abbildung 71: Quellcode - Benutzer sperren Im Fall eines Erfolgs wird eine 1 zurückgegeben und im Fall eines Fehlschlags eine 0. Wir haben uns für diese Werte entschieden, da in der Computerwelt 1 true und 0 false bedeutet. Man hätte an dieser Stelle auch direkt das mysql-result zurückgeben können, um sich die ifabfrage zu sparen. Wir haben uns aber für diesen Weg entschieden, da es auch Methoden mit mehr als zwei Rückgabewerten gibt und immer nummerische Werte verwendet werden sollten. Clientside Flash - Response verarbeiten In der Methode userlock_result() (Abb. 72), welche für das Ergebnisereignis zuständig ist, wird unterschieden, ob die Methode erfolgreich war oder nicht. (1) private function userlock_result(reresult:resultevent) : Void { (2) if (reresult.result == 1) { (3) _level0.container_mc.cont.viewprofil.strtxtreg.textcolor = 0x000000; (4) _level0.container_mc.cont.viewprofil.strtxtreg = _level0.lang['profil_user_locked']; (5) } else { (6) _level0.container_mc.cont.viewprofil.strtxtreg.textcolor = 0xFF0000; (7) _level0.container_mc.cont.viewprofil.strtxtreg = _level0.lang['profil_user_locked_false']; (8) _level0.container_mc.cont.viewprofil.butclose.enabled = true; (9) _level0.container_mc.cont.viewprofil.butclose.gotoandplay('mouseou t'); (10) } (11) } Abbildung 72: Quellcode - Teil der User Klasse 103

112 Allgemeine Betrachtungen In beiden Fällen wird eine Textausgabe erzeugt, um den Benutzer über den Erfolg oder Misserfolg zu informieren. Liegt ein Misserfolg vor, dann wird der Button, der den Service startete, wieder zur Benutzung freigegeben, indem seine Eigenschaft enabled auf true gesetzt wird. Die Methode userlock_error() (Abb. 73) wird ausgeführt, wenn ein Fehler bei der Kommunikation aufgetreten ist und statt eines ResultEvents ein FaultEvent zurückgegeben wurde. (1) private function userlock_error(feerror:faultevent) : Void { (2) _level0.container_mc.cont.viewprofil.butclose.enabled = true; (3) _level0.container_mc.cont.viewprofil.butclose.gotoandplay('mouseout'); (4) _level0.container_mc.cont.viewprofil.strtxtreg.textcolor = 0xFF0000; (5) _level0.container_mc.cont.viewprofil.strtxtreg = _level0.lang['profil_user_locked_false']; (6) trace('there has been an error in userlock!'); (7) trace(' '); (8) trace(feerror.fault.faultstring); (9) } Abbildung 73: Quellcode - Teil der User Klasse Diese Methode weist im Grunde den gleichen Inhalt auf, wie der Misserfolgsfall in der userlock_result()-methode, denn auch hier soll der Benutzer über das Misslingen informiert werden. Sie wurde lediglich um eine Ausgabe für die Entwicklungsumgebung ergänzt. 104

113 Konkrete Anwendungsfälle Konkrete Anwendungsfälle In diesem Kapitel betrachten wir anhand von konkreten Anwendungsfällen den Aufbau der wichtigsten Bereiche des Projektinformationssystems. Hierzu gehört das Ansehen eines Projekts mit den dazugehörigen Daten und Medien (siehe Kapitel ), das Bearbeiten der Projektdaten (siehe Kapitel ), aber auch das Nachrichtensystem mit seinen Funktionen (siehe Kapitel ) und der Login zum Internen Bereich (siehe Kapitel ) Projekt ansehen Nachfolgend wird der Ablauf und die Ausgabe des Anwendungsfalls "Projekt ansehen" anhand von Quellcode-Auszügen erläutert. Dabei gliedert sich das Kapitel in eine Beschreibung und in den technischen Ablauf. Dieser teilt sich wiederum in drei Bereiche. Der Erste beschreibt u. a. den Aufruf der amfphp Methode aus Flash heraus (Clientside Flash - Remote Call). Der zweite Bereich (Serverside PHP - Remote Service) stellt die Ausführung eines Services auf der Serverseite dar. Der dritte und letzte Teil beschreibt die Rückgabe des angeforderten Arrays und dessen Auswertung (Clientside Flash - Response verarbeiten) Beschreibung Im Außenbereich stehen dem Benutzer zwei Wege offen, um sich ein Projekt anzusehen. Entweder wählt er ein Projekt aus, welches in den Zusatzinfos zu einer Kategorie steht und das zu letzt eingestellte Projekt jener Kategorie ist. In diesem Fall würde die Methode proget() aus der Project-Klasse ausgeführt, um alle Daten zu dem gewählten Projekt zu holen. Oder er geht den Weg über die Projektlisten. Hier liegen schon einige Daten zu den aufgelisteten Projekten vor und diese müssen nur vervollständigt werden Technischer Ablauf Clientside Flash - Remote Call Im folgenden betrachten wir die Auswahl eines Projekts aus einer Projektliste zu einer bestimmten Kategorie. Es wäre auch möglich, dass ein Projekt aus einer Projektliste zu einer bestimmten Metadate oder einem Benutzer gewählt wird. Durch die Verwendung von Querverweisen ist es möglich sich viele unterschiedliche Projektlisten anzusehen, bevor man eine Auswahl trifft. 105

114 Konkrete Anwendungsfälle In unserem Fall wählt der Benutzer eine Kategorie aus der Kategorieliste. Daraufhin wird ihm eine Projektliste zu dieser Kategorie angezeigt. Nun kann der Benutzer ein Projekt auswählen und braucht nur auf dessen Namen zu klicken, um es sich anzeigen zu lassen. Nun wechselt der Flashfilm in die Szene Projektansicht in der die Methode projectcomplete() aufgerufen wird (Abb. 74), noch bevor die Szene fertig geladen wurde. (1) public function projectcomplete() { (2) // hier werden die fehlenden Daten für ein Projekt geholt (3) pcremotecall = srvpro.procomplete(numproid); (4) pcremotecall.responder = new RelayResponder(this, 'procomp_result', 'procomp_error'); (5) } Abbildung 74: Quellcode - Teil der Project Klasse Die Methode ruft den entsprechenden Service auf und gibt diesem die ID des Projekts mit. Während die Servicemethode ausgeführt wird und das PendingCall-Objekt auf eine Rückgabe wartet, wird die Szene geladen und der Seitenaufbau findet statt. Serverside PHP - Remote Service Nachdem Flash die Methode aufgerufen hat, werden die entsprechenden Daten aus der Datenbank gelesen und können an Flash zurück gegeben werden. Da der generelle Ablauf in den vorherigen Kapiteln schon mehrfach erklärt wurde, gehen wir an dieser Stelle nicht noch einmal detailliert darauf ein. Es wird nur der grobe Aufbau erklärt. (1) (2) (3) (4) (5) (6) (7) function procomplete($intproid) { $arrproject = array(); $this->dbconnect(); $result = mysql_query ( "SELECT id AS intproid, beschreibung AS chrprodesc, (SELECT id FROM pr_meta_main_def WHERE value = 'Schwierigkeitsgrad') AS intprodifftabid, (8) (SELECT meta_sub_id FROM pr_meta_main_set WHERE pr_id = $intproid AND meta_id = intprodifftabid) AS intprodiffmetaid, (9) (SELECT value FROM pr_meta_schwierig WHERE id = intprodiffmetaid) AS chrprodiff, (10) (SELECT id FROM pr_meta_main_def WHERE value = 'Umfang') AS intprosizetabid, (11) (SELECT meta_sub_id FROM pr_meta_main_set WHERE pr_id = $intproid AND meta_id = intprosizetabid) AS intprosizemetaid, (12) (SELECT value FROM pr_meta_umfang WHERE id = intprosizemetaid) AS chrprosize, (13) (SELECT id FROM pr_meta_main_def WHERE value = 'Bewertung') AS intproratetabid, (14) (SELECT meta_sub_id FROM pr_meta_main_set WHERE pr_id = $intproid AND meta_id = intproratetabid) AS intproratemetaid, (15) (SELECT value FROM pr_meta_bew WHERE id = intproratemetaid) AS chrprorate (16) FROM pr_main WHERE id = $intproid" ); (17) // Das Resultset in ein Array schreiben (18) while($arrproject[] = mysql_fetch_assoc($result)); (19) return $this->addprojectmedia($this->addprojectlinks($arrproject)); (20) } Abbildung 75: Quellcode -Projektdaten vervollständigen 106

115 Konkrete Anwendungsfälle Wie in den meisten anderen Methoden auch, werden zunächst in einem großen SELECT und verschiedenen Unter-SELECTs die erforderlichen Projektdaten selektiert. Da diese Methode ein Project-Objekt in Flash um Daten erweitert, werden auch nur Daten zu einem Projekt selektiert und nicht wie in anderen Methoden zu mehreren. Daraus folgt, es gibt nur einen Datensatz im Resultset. Nachdem das Resultset erzeugt wurde, wird es in einem Array gespeichert um weitere Daten hinzufügen zu können (siehe Abb. 75 Zeile 27). Dabei handelt es sich zum Einen um die Mediendateien des Projekts und zum Anderen um die Projektlinks (siehe Abb. 75 Zeile 29). Der genaue Ablauf kann im Kapitel Array-Methoden der Projektdaten eingesehen werden. Wurden alle Daten hinzugefügt, wird das Array an Flash übergeben und kann dort verarbeitet werden. Clientside Flash - Response verarbeiten In procomp_result() wird das ResultEvent-Objekt verarbeitet (Abb. 76). (1) private function procomp_result(reresult:resultevent): Void { (2) strdescription = reresult.result[0].chrprodesc; (3) strdifficulty = reresult.result[0].chrprodiff; (4) strsize = reresult.result[0].chrprosize; (5) strrating = reresult.result[0].chrprorate; (6) for (var i = 1; i <= reresult.result[0].intproimgcount; i++) { (7) arrpics[i-1] = reresult.result[0]['chrproimgname'+i]; (8) } (9) for (var j = 1; j <= reresult.result[0].intprodoccount; j++) { (10) arrdocs[j-1] = reresult.result[0]['chrprodocname'+j]; (11) } (12) for (var k = 1; k <= reresult.result[0].intpromulticount; k++) { (13) arrmedia[k-1] = reresult.result[0]['chrpromultiname'+k]; (14) } (15) } Abbildung 76: Quellcode - Teil der Project Klasse Die Daten im zurückgegebenen Array werden in die entsprechenden Projektattribute übergeben. Die Methode procomp_result() ähnelt der Methode proget_result(), nur das letztere mehr Projektattribute belegt. Gelangt der Flashfilm mit dem Abspielen der Szene an die Stelle ProContent, wird folgende Methode ausgeführt (Abb. 77 und Abb. 78), um die Anzeige des Projekts zu erzeugen. (1) proproject.display('container_mon', 'mask_mon'); Abbildung 77: Quellcode - Aufruf im Flashfilm, Bild: ProContent Dieser Methode werden die Bezeichnungen bzw. die Pfade für den Content Container MovieClip und den Masken MovieClip mitgegeben. 107

116 Konkrete Anwendungsfälle (1) public function display(strmcpath:string, strmaskpath:string) : Void { (2) if (eval("_level0." + strmcpath).cont) { (3) removemovieclip(eval("_level0." + strmcpath).cont); (4) } (5) eval("_level0." + strmcpath).createemptymovieclip('cont', eval("_level0." + strmcpath).getnexthighestdepth()); (6) eval("_level0." + strmcpath).cont.attachmovie('mcproject', 'ViewPro', eval("_level0." + strmcpath).cont.getnexthighestdepth()); (7) eval("_level0." + strmcpath).setmask(eval("_level0." + strmaskpath)); (8) } Abbildung 78: Quellcode - Teil der Project Klasse Zuerst wird der bisherige Inhalt des Content Containers entfernt, bevor in diesem ein neuer, leerer MovieClip erstellt wird. Daraufhin wird in diesen der MovieClip mcproject geladen. Er kümmert sich um die Ausgabe und die Steuerung der Menübutton, die Teil der Anzeige sind. Der Benutzer sieht immer die allgemeinen Projektdaten zuerst (Abb. 79). Die Felder der Anzeige werden mit den Attributen des Projekts gefüllt. Zusätzlich kann sich der Benutzer die hochgeladenen Medien zu diesem Projekt ansehen. Die Bilder werden in einem Picture Slider angezeigt, MP3-Dateien in einem integrierten Player abgespielt und andere Dateien in einem neuen Browserfenster geladen, sofern diese angeklickt wurden. Des Weiteren kann sich der Benutzer zusätzliche Metadaten zu dem Projekt ansehen. Mit einem Klick auf den zurück-post-it gelangt der Benutzer zu der Liste zurück, die er sich zuletzt ansah. Im Internen Bereich findet der Benutzer einen Kontakt-Button, um eine Nachricht an den Eigentümer zu schreiben. Sollte er der Besitzer des Projektes sein, kann er dort ein Script zum Bearbeiten aufrufen. Abbildung 79: Projektdaten ansehen 108

117 Konkrete Anwendungsfälle Probleme Im Internen Bereich wird keine spezielle Szene gestartet, wenn die Daten eines Projekts angezeigt werden sollen. Hier wird nur ein bestimmter MovieClip aus der Bibliothek geladen (ähnlich wie oben). Hierbei macht sich aber ein bestimmtes Problem bemerkbar. Die Kommunikation zwischen Flash Remoting und amfphp verläuft asynchron. Somit läuft der Flashfilm nach dem Aufruf des Services weiter, ohne auf dessen Ergebnis zu warten. Im Außenbereich erhält das Project-Objekt seine Daten während die Szene geladen wird und ihr Seitenaufbau stattfindet. Somit stehen die Daten beim Laden des MovieClips ohne Probleme zur Verfügung. Im Internen Bereich findet der Aufruf von proget() oder procomplete() in dem MovieClip statt, der auch die Ausgabe erzeugt. Hier muss eine Abfrage erstellt werden, die prüft, ob die benötigten Daten schon erhalten wurden, bevor die Ausgabe erfolgt, da sonst die Projektattribute leer sind. Hier würde der Aufbau der Anzeige schneller laufen, als das Holen der nötigen Daten. Auf solche Situationen muss man Acht geben, um Fehler zu vermeiden. An diesem Beispiel konnten wir sehr gut das asynchrone Verhalten von Flash Remoting und amfphp beobachten. 109

118 Konkrete Anwendungsfälle Projekt bearbeiten Im folgenden Kapitel wird anhand von Quellcode erläutert, wie "Projekt bearbeiten" implementiert wurde und wie der Ablauf funktioniert. Dabei ist das Kapitel in eine Beschreibung und in den technischen Ablauf gegliedert. Dieser technische Ablauf ist wiederum in zwei Bereiche aufgeteilt. Der erste dieser Bereiche beschreibt den Aufruf der amfphp Methode aus Flash heraus (Clientside Flash - Remote Call). Der zweite Bereich (Serverside PHP - Remote Service) beschreibt den Ablauf auf der Serverseite. Dazu wird im Detail auf die benötigten PHP Skripte und benötigte PHP-Funktionen eingegangen Beschreibung An dieser Stelle wird beschrieben, wie ein Benutzer ein zuvor eingestelltes Projekt erneut bearbeiten kann. Da es in Flash nicht ohne Umwege möglich ist, auf das Dateisystem eines Benutzers zuzugreifen, muss das Ändern eines Projekts mittels HTML und PHP erfolgen. Der Benutzer muss hierbei die nötigen Kriterien auswählen, die das Projekt am besten beschreiben. Diese Auswahl an Kriterien werden als Metadaten in der Datenbank gespeichert. Weitere Daten wie die Projektbeschreibung, die Mitwirkenden und das Einstelldatum können außerdem vom Benutzer ausgewählt werden. Um eine möglichst lückenlose Beschreibung eines Abbildung 80: Ausschnitt: Daten bearbeiten Projekts zu erhalten, sind die meisten Felder mit einem * versehen, wodurch Pflichtfelder gekennzeichnet sind. Im nächsten Schritt, nachdem man die Eingabe der Daten durch einen Klick auf Weiter bestätigt hat, werden die zu ändernden Medien ausgewählt oder durch das Setzen einer Checkbox zum Löschen markiert. Welche Medien hoch geladen werden dürfen, ist über den jeweiligen Feldern zu lesen. Nachdem man die Änderungen an den Medien vorgenommen Abbildung 81: Ausschnitt: Medien bearbeiten hat, schließt man den Vorgang durch anklicken des ändern -Knopfes ab. 110

119 Konkrete Anwendungsfälle Da sich Projekt einstellen und Projekt bearbeiten in Funktion und Bedienung sehr ähnlich sind, wird an dieser Stelle nur Projekt bearbeiten im Detail erklärt. An Stellen, wo sich die beiden Implementierungen gravierend unterscheiden, wird kurz auf die Unterschiede eingegangen. Prinzipiell entfallen aber nur die Bereiche, in denen die zum Projekt gehörenden Daten geladen werden Technischer Ablauf Clientside Flash - Remote Call Um ein Projekt bearbeiten zu können, muß nur die entsprechende Schaltfläche (Abb. 82) (steht nur dem Besitzer des Projektes zur Verfügung) gedrückt werden (Abb. 83) und der Dialog zur Bearbeitung eines Projektes öffnet sich in einem neuen Browserfenster. (1) on (release) { (2) var winx = (System.capabilities.screenResolutionX )/2; (3) var winy = (System.capabilities.screenResolutionY - 760)/2; (4) geturl("javascript:window.open('http://mims02.gm.fhkoeln.de/~proinf/upload/edit/edit_formular.php?seite=daten&prid="+_level0.proproject.getproid()+"& user="+_level0.usruser.getnick()+"&pass="+_level0.usruser.getpasswordmd5()+"','pro jekt bearbeiten','width=1050,height=760,left="+winx+", top="+winy+", toolbar=no, menubar=no,location=no, status=no, resizable=yes, scrollbars=yes');void(0);", "_blank"); (5) } Abbildung 83: Quellcode - Event der bearbeiten-schaltfläche Abbildung 82: Projekt bearbeiten Serverside PHP - Remote Service Ändern der Daten (daten.php) Um eine einfache Erweiterbarkeit der Metadaten zu gestatten, ohne große Änderungen an dem Skript vornehmen zu müssen, ist der Aufbau dynamisch implementiert. Am folgenden Beispiel (Abb. 84) soll der generelle Aufbau einer dynamisch erzeugten Combobox erklärt werden. Für die Erklärung wurden irrelevante Codezeilen entfernt. 111

120 Konkrete Anwendungsfälle (1) while ($ausgabe = mysql_fetch_array ($result)) (2) { (3) if ($ausgabe['id'] == 8) (4) { (5) $result2 = mysql_query ("SELECT * FROM ".$ausgabe['meta_table']." ORDER BY id"); (6) $i =0; (7) while ($ausgabe2 = mysql_fetch_array ($result2)) (8) { (9) // suchen ob ein Eintrag in der Metatabelle vorhanden ist (10) $result3 = mysql_query ("SELECT * FROM pr_meta_main_set WHERE pr_id='".$_get['prid']."' AND meta_id='".$ausgabe['id']."' AND meta_sub_id='".$ausgabe2['id']."'"); (11) $ausgabe3 = mysql_fetch_object ($result3); (12) $set = ''; (13) if ($ausgabe3) $set = 'checked'; (14) if ($i % 4 == 0) echo '<tr>'; (15) echo '<td><input type="checkbox" name="kat'.$i.'" value="'.$ausgabe2["id"].'" '.$set.'> (16) '.$ausgabe2["value"].'</td>'; (17) if ($i % 4 == 4) echo '</tr>'; (18) $i++; (19) } (20) } (21) } Abbildung 84: Quellcode des dynamischen Aufbaus der Technologie-Checkboxen Zunächst werden die in Frage kommenden Werte (Metadaten) aus dem Resultset $result ausgelesen, um später zwischen ihnen unterscheiden zu können (Abb. 84 Zeile 1). ID 8 bezeichnet im Beispiel die Metadate Alternative Kategorien (Abb. 84 Zeile 3). Somit werden in diesem if-block nur die alternativen Kategorien behandelt. Im ganzen Script existieren ähnliche Blöcke für die anderen Metadaten. Da der Aufbau aber nahezu identisch ist, wird er nur einmal erklärt. Im nächsten Schritt müssen die in der Datenbank vorhandenen alternativen Kategorien ausgelesen werden (Abb. 84 Zeile 5). Die folgende while-schleife läuft so lange, wie Einträge in $result2 vorhanden sind, um Checkboxen48 erzeugen zu können. Da beim Einstellen des betreffenden Projekts eine alternative Kategorie gewählt werden musste, existiert also ein Eintrag dazu in der Datenbank. Um diesen wieder als markiert auswählen zu können, wird er zunächst selektiert (Abb. 84 Zeile 10-11) und dann mit den Einträgen, aus denen Checkboxen generiert werden, verglichen. Stimmen sie überein, wird mit dem HTML Element checked der übereinstimmende Eintrag markiert (Abb. 84 Zeile 14). Damit die einzelnen Zeilen bei der Darstellung nicht zu breit werden, sind sie auf maximal 4 Einträge begrenzt. Dazu wird nach jedem vierten Eintrag eine neue Tabellenzeile begonnen (Abb. 84 Zeile 15 18). Der Name jeder Checkbox wird dynamisch erzeugt, da es mehr als eine gibt und über einen eindeutigen Namen auf sie zugegriffen wird (Abb. 84 Zeile 16). 48 Vgl. 112

121 Konkrete Anwendungsfälle Ändern der Medien (medien.php) Bevor die zum Projekt gehörenden Medien angezeigt werden, um sie ändern zu können, müssen die zuvor vom Benutzer eingegebenen Daten validiert und auf Vollständigkeit überprüft werden. Aus diesem Grund muss zunächst die Datei checkinput.php (Abb. 85 ) eingebunden werden. (1) include 'checkinput.php'; Abbildung 85: Quellcode - Inkludieren von checkinput.php Im einzelnen werden folgende Kriterien überprüft. Zunächst muss sichergestellt werden, dass die mit * gekennzeichneten Felder ausgefüllt oder im Fall der Check- bzw. Comboboxen ausgewählt wurden. Wenn der Benutzer ein Feld vergessen hat, wird ein Hinweis ausgegeben und er wird aufgefordert dies zu korrigieren. Außerdem wird überprüft, ob der gewählte Projektname schon einmal in der Datenbank existiert und ob die Links richtig eingetragen wurden. Der Benutzer wird beim Eintragen der Links darauf hingewiesen, in welcher Form er dies zu tun hat. Zuletzt überprüft das Skript die Korrektheit des Datums und ob das Enddatum nach dem Startdatum liegt. Die zuvor per POST-Methode49 übertragenen Werte werden nach der Validierung in versteckten Formularfeldern (Abb. 86) zwischengespeichert, um sie beim Abschicken des Formulars der Medien mit übertragen zu können. Um Fehler bei der Übertragung auszuschließen, werden die Werte der Textfelder in verschlüsselter Form gespeichert. Dazu wurde die PHP Methode base64_encode()50 benutzt. (1) <input name="pr_name" value="'.base64_encode($_post['pr_name']).'" type="hidden"> Abbildung 86: Quellcode - Zwischenspeichern der Formulardaten Die anderen Metadaten enthalten nur Zahlenwerte und müssen deshalb nicht verschlüsselt werden. Sie werden ähnlich wie in Abbildung 84 dynamisch in versteckten Formularfeldern zwischengespeichert. (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) // Bilder werden augelesen und in ein zweidimensionales Array gespeichert $the_arrayb = Array(); $result = mysql_query ("SELECT * FROM pr_main_files WHERE pr_id=".$_get['prid']." AND typ='bild' ORDER BY id"); $i = 0; while ($ausgabe = mysql_fetch_array ($result)) { $the_arrayb[0][$i] = $ausgabe[id]; $the_arrayb[1][$i++] = $ausgabe[value]; } reset($the_arrayb); Abbildung 87: Quellcode - Speichern von Medien in einem Array (Bsp. Bilder) 49 Vgl. 50 Vgl. 113

122 Konkrete Anwendungsfälle Die Dateinamen der zum Projekt gehörenden Bilder werden in der Datenbank gespeichert. Um besser auf sie zugreifen zu können, werden diese Dateinamen zunächst in einem Array gespeichert (Abb. 87). Genauer gesagt existieren drei Arrays, für jeden der drei Dateitypen (Bilder, Medien, Dokumente) eins. Upload der Daten und Medien (edit_send.php) Da die Vollständigkeit der Daten bereits in der medien.php Datei überprüft wurde ist es an dieser Stelle nicht nochmal notwendig. Es kann jedoch optional eingestellt werden. Das Checkinput Skript ist so implementiert, dass es auch mit den zur Übertragung verschlüsselten Daten funktioniert. Der Upload der Medien findet in 3 einzelnen Schritten statt, nämlich für jede Art in einem einzelnen. In den folgenden Schritten sieht man den Upload der Bilder, da dieser Bereich am Umfangreichsten ist. Beim Upload der Bilder müssen im Gegensatz zu den Medien und den Dokumenten kleine Vorschaubilder erstellt werden um bei der Anzeige nicht unnötig große Dateien übertragen zu müssen. Validieren der Medien Hier soll zunächst auf die grobe Struktur (Abb. 88) eingegangen werden. Die einzelnen Aktionen wurden deshalb zunächst aus dem Quelltext entfernt und durch [...] ersetzt. Auf wichtige Funktionen wird nach der groben Struktur eingegangen. (1) (2) (3) for ($i = 0; $i < 5; $i++) { // Wenn eine Datei geloescht werden soll, ohne das eine neue Datei ausgewaehlt wurde. (4) if ($_POST['del'.$i]!= '') { [...] } (5) if($_files['userfile']['name'][$i]) (6) { (7) if( checkfiletype($_files['userfile']['name'][$i],'bild') ) (8) { (9) // Wenn ein altes file vorhanden ist, erst löschen, dann ein Neues hoch laden. (10) if ( $_POST['file_alt_'.$i]!= '' ) { [...] } (11) (12) (13) [...] } } Abbildung 88: Quellcode Struktur des Medienuploads Da maximal 5 Bilder ausgewählt werden können, muss die for-schleife fünf mal durchlaufen werden. Es werden also alle folgenden Aktionen für jedes der fünf Uploadfelder ausgeführt. Wurde die Checkbox zum Löschen einer Datei ausgewählt wird diese zunächst gelöscht, andernfalls unbehandelt gelassen (Abb. 88 Zeile 4). Um überhaupt eine Aktion durchzuführen, muss der Benutzer eine Datei ausgewählt haben. Ob dies geschehen ist, wird einfach durch die Existenz eines Dateinamens geprüft, welcher 114

123 Konkrete Anwendungsfälle in der Variable $_FILES['userfile']['name'][$i] gespeichert worden wäre (Abb. 88 Zeile 5). Wurde festgestellt, dass eine Datei existiert, muss kontrolliert werden, ob sie eine passende Dateiendung hat. Dazu wird die Funktion checkfiletype() aufgerufen, welcher der Dateiname und der Dateityp übergeben wird. Ist die Endung korrekt, liefert die Funktion true zurück und die Prüfung war erfolgreich. Wenn eine neue Datei hoch geladen werden soll, dass Uploadfeld aber schon eine Datei anzeigt, wird diese zunächst gelöscht (Abb. 88 Zeile 10). Dies erspart dem Benutzer einen Schritt. Er muss eine Datei nicht erst löschen, um eine neue hoch laden zu können. Zuletzt werden die ausgewählten Dateien hoch geladen und an die richtige Stelle verschoben. Außerdem werden die Dateinamen und der Dateityp in die Datenbank eingetragen. Weiteres dazu im nächsten Abschnitt. Der beschriebene Abschnitt ist bis auf das Löschen bereits vorhandener Dateien identisch mit dem äquivalenten Bereich beim Projekt einstellen. Dateiupload am Beispiel der Bilder (1) $uploaddir = '../medien/'.$_get['prid'].'/bilder/'; (2) (3) move_uploaded_file($_files["userfile"]["tmp_name"][$i], $uploaddir $_FILES["userfile"]["name"][$i]); (4) chmod(($uploaddir. $_FILES["userfile"]["name"][$i]), 0775); (5) (6) mksmallthumbs($uploaddir. $_FILES["userfile"]["name"][$i], $uploaddir. 'thumbs/'. $_FILES["userfile"]["name"][$i] ); (7) chmod(($uploaddir. 'thumbs/'. $_FILES["userfile"]["name"][$i]), 0775); (8) (9) mklargethumbs($uploaddir. $_FILES["userfile"]["name"][$i], $uploaddir. 'thumbslarge/'. $_FILES["userfile"]["name"][$i] ); (10) chmod(($uploaddir. 'thumbslarge/'. $_FILES["userfile"]["name"][$i]), 0775); (11) (12) mysql_query ("INSERT INTO pr_main_files (pr_id, typ, value) VALUES ( (13) '".$_GET['prid']."', (14) 'bild', (15) '".$_FILES["userfile"]["name"][$i]."' (16) )"); Abbildung 89: Quellcode - Upload der Bilder Nachdem die Bilder per HTTP Post auf den Webserver übertragen wurden, müssen sie noch an die passenden Stellen verschoben werden. Zu diesem Zweck existiert die PHP-Funktion move_uploaded_file()51 Dabei wird die Quelle, die Zieldatei und der Pfad angegeben ( Abb. 89 Zeile 3). Anschließend werden mit der Funktion chmod() die Rechte der hoch geladenen Dateien auf 755 gesetzt. Dies ist notwendig, da der Webserver beim Verschieben der Dateien Rechte setzt, die ein späteres Anzeigen/Bearbeiten nicht mehr erlauben. 51 Vgl. 115

124 Konkrete Anwendungsfälle Zum Erstellen der Vorschaubilder existieren 2 verschiedene Methoden. Mit mksmallthumbs() werden Bilder erzeugt die genau 150 Pixel hoch sind und die Breite im richtigen Seitenverhältnis angepasst wird. Das Gleiche geschieht in der Funktion mklargethumbs(). Hier werden die Dimensionen der Bilder etwas anders gesetzt. Je nach Ausgangsgröße muss entschieden werden, welche Ausmaße das Bild später hat. Dabei kann ein Bild nicht breiter als 500 Pixel und nicht höher als 300 Pixel sein. Zuletzt werden noch die Projekt ID, zu dem die Bilder gehören, der Dateityp (Bild, Dokument, Multimediadatei) und der Dateiname zu jedem Bild in die Datenbank eingetragen. Eintragen der Projektdaten in die Datenbank (1) (2) (3) (4) (5) (6) (7) (8) // ## Daten werden in die db eingetragen ## mysql_query ("UPDATE pr_main SET name='".base64_decode($_post['pr_name'])."', kategorie='1', start_datum='".base64_decode($_post['start_dat'])."', end_datum='".base64_decode($_post['end_dat'])."', ansp_partner='".base64_decode($_post['ansp_p'])."', mitwirkende='".base64_decode($_post['mitw'])."', kurz_beschr='".base64_decode($_post['kurz_beschr'])."', beschreibung='".base64_decode($_post['beschr'])."', kategorietemp='".$_post['kat']."' (9) WHERE id='".$_get['prid']."'"); (10) (11) // Löschen der alten Metadaten um die neuen einzutragen. (12) mysql_query ("DELETE FROM pr_meta_main_set WHERE pr_id='".$_get['prid']."'"); (13) (14) // Die Metadaten und werden eingetragen (15) savemetadata($_get['prid']); (16) (17) // Löschen der alten Links um die neuen einzutragen. (18) mysql_query ("DELETE FROM pr_main_links WHERE pr_id='".$_get['prid']."'"); (19) (20) // Die Links werden eingetragen (21) savelinks($_get['prid'], base64_decode($_post["links"])); Abbildung 90: Quellcode- Eintragen der Projektdaten in die Datenbank Zunächst wir die betreffende Zeile in der pr_main Datenbanktabelle selektiert, um danach die Einträge zu überschreiben. Dabei werden immer alle Felder aktualisiert, nicht nur die geänderten. Nach jeder Änderung an einem Projekt, durch den Benutzer wird es für die Öffentlichkeit gesperrt und muss erst wieder freigeschaltet werden. Dazu wird das Feld kategorie in der Datenbank auf 1 gesetzt, was es in die Kategorie Noch nicht freigeschaltete Projekte verschiebt. Auch beim Aktualisieren müssen die zur Übertragung verschlüsselten Felder zunächst decodiert werden, um sie unverschlüsselt in die Datenbank eintragen zu können. Metadaten und Links zu einem Projekt befinden sich in einer extra Tabelle. Die Einträge sind durch die Projekt ID mit dem Projekt verknüpft und werden zunächst gelöscht, um sie dann erneut eintragen zu können. Dies ist notwendig, da sich der Inhalt und auch die Anzahl der einzutragenden Daten verändert haben kann. 116

125 Konkrete Anwendungsfälle Nachrichtensystem Folgendes Kapitel erläutert vier Funktionen des Nachrichtensystems anhand ihres Quellcodes. Das Kapitel unterteilt sich ebenfalls in eine Beschreibung und den technischen Ablauf. In diesem werden nacheinander die Funktionen "Nachricht zählen", "Nachricht lesen", "Nachricht verschicken" und "Nachricht löschen" dargestellt. Für jede Funktion betrachten wir den Aufruf der amfphp Methode (Clientside Flash - Remote Call), die Ausführung des Services (Serverside PHP - Remote Service) und die entsprechende Rückgabe mit ihrer Auswertung in Flash (Clientside Flash - Response verarbeiten) Beschreibung Im Projektinformationssystem besteht die Möglichkeit über ein integriertes Nachrichtensystem mit anderen Benutzern oder Projektverantwortlichen in Verbindung zu treten. Dazu wird dem Benutzer eine Übersicht seiner gesendeten und neuen Nachrichten auf der Startseite angezeigt. Von dort kann der Benutzer in die Nachrichtenübersicht wechseln um seine empfangenen Nachrichten zu lesen, diese zu löschen oder neue Nachrichten zu verfassen. Weiterhin hat er die Möglichkeit sich eine Übersicht, seiner zuvor verschickten Nachrichten, anzeigen zu lassen. Es existieren prinzipiell zwei Wege eine Nachricht zu verfassen. Ein Benutzer kann aus der Projektansicht heraus direkt mit dem Verantwortlichen in Verbindung treten, woraufhin dieser auch direkt als Empfänger feststeht und passend eingetragen wird. Als zweite Möglichkeit kann er sich den Empfänger frei aussuchen, muss dazu aber dessen Benutzernamen kennen, um diesen angeben zu können. An dieser Stelle werden nur die wichtigen Funktionen des Nachrichtensystems erklärt. Einfache Funktionen, wie die Listen zum Ansehen der Nachrichten wurden weggelassen, sollen aber der Vollständigkeit wegen genannt werden. msgreceivedlist() - Liste alle empfangenen Nachrichten msgsendlist() - Lieste aller gesendeten Nachrichten Im Anhang A.2. befindet sich ein Anwendungsfalldiagramm, welches die einzelnen Anwendungsfälle des Nachrichtensystems und ihre Zusammenhänge darstellt. 117

126 Konkrete Anwendungsfälle Technischer Ablauf Nachrichten zählen Clientside Flash - Remote Call Die Übersicht (Abb. 91) über die empfangenen und davon ungelesenen Nachrichten wird jedes Mal aufgerufen, wenn sich der Inhalt im Content Container MovieClip des Internen Bereichs ändert. Also jedes Mal, wenn der Flashfilm zur Bildmarkierung InternPreContent springt (Abb. 92). Abbildung 91: Übersicht (1) usruser.msgcount(); Abbildung 92: Quellcode - Aufruf im Flashfilm, Bild: InternPreContent Die Methode msgcount() ist Teil der User Klasse und wird für den eingeloggten Benutzer ausgeführt (Abb. 93). (1) public function msgcount() { (2) pcremotecall = srvuser.msgcount(numuserid); (3) pcremotecall.responder = new RelayResponder(this, 'msgcount_result', 'msgcount_error'); (4) } Abbildung 93: Quellcode - Teil der User Klasse In der Methode wird der benötigte Service aufgerufen. Serverside PHP - Remote Service (1) function msgcount($intuserid) (2) { (3) $this->dbconnect(); (4) return mysql_query ( (5) "SELECT (6) count(pr_nachrichten.id) AS intmsgreceived, (7) (SELECT count(pr_nachrichten.id) FROM pr_nachrichten WHERE pr_nachrichten.loeschen <> '2' AND pr_nachrichten.empf_id = $intuserid) AS intmsgunread (8) FROM pr_nachrichten (9) WHERE pr_nachrichten.empf_id = $intuserid (10) AND pr_nachrichten.loeschen <> '2'"); (11) } Abbildung 94: Quellcode- Übersicht empfangene / neue Nachrichten Um auf der Startseite einen Überblick der empfangenen und neu eingetroffenen Nachrichten zu bekommen, existiert die Funktion msgcount() (Abb. 94). Ihr wird als Parameter die ID des Benutzers mitgegeben, dessen Nachrichten gezählt werden sollen. In den meisten Fällen ist das die ID des angemeldeten Benutzers. Da die Gesamtzahl aller Nachrichten gezählt werden soll und außerdem die Anzahl der ungelesenen Nachrichten, muss zweimal über die 118

127 Konkrete Anwendungsfälle Tabelle gelaufen werden. Der Grund für die verschachtelten SELECT Anweisungen liegt in dem Ergebnis, welches Flash erwartet. Es muss immer genau ein Resultset zurückgegeben werden. In beiden SELECT-Anweisungen müssen Nachrichten, die vom Benutzer gelöscht wurden, ausgefiltert werden. Dies geschieht durch das Abfragen des loeschen Feldes in der Datenbank (Abb. 94 Zeile 8 & 11). Eigene Nachrichten, die der Benutzer gelöscht hat, erhalten den Wert 2. Genaueres zum Löschen einer Nachricht ist in einem späteren Kapitel (siehe Kapitel Nachricht löschen) zu finden. Clientside Flash - Response verarbeiten In der Methode msgcount_result() erfolgt dann die Variablenbelegung zweier Werte für die Ausgabe. Nachricht lesen Clientside Flash - Remote Call Um eine Nachricht lesen zu können, muss sie aus einer der beiden Listen (empfangene Nachrichten (Abb. 95), gesendete Nachrichten) Abbildung 95: Liste empfangener Nachrichten ausgewählt werden. Hierzu muss der Benutzer nur auf den Betreff der Nachricht klicken. Dadurch wir die Methode displaymsg() ausgeführt (Abb. 96). (1) public function displaymsg(nummsgid:number, strpathmc:string, strwb:string) : Void { (2) strpathmovieclip = strpathmc; (3) strpathwb = strwb; (4) cleancontainer(); (5) (6) // Flash Remoting Service aufrufen (7) pcremotecall = srvmessage.msgread(nummsgid); (8) pcremotecall.responder = new RelayResponder(this, 'msg_result', 'msg_error'); (9) } Abbildung 96: Quellcode - Teil der Message Klasse Ihr wird die ID der zu lesenden Nachricht und die Pfade zu den beiden Container MovieClips als Parameter übergeben. Auch hier erfolgt die bekannte cleancontainer()-methode zum leeren des Content Container Inhalts. Danach wird die Service-Methode aufgerufen und die ID der Nachricht, dessen Daten gefordert werden, übergeben. 119

128 Konkrete Anwendungsfälle Serverside PHP - Remote Service (1) (2) (3) (4) function msgread($intmsgid) { $this->dbconnect(); // Ueberpruefen, ob der Sender eine Nachricht liest. In dem Fall darf sie nicht auf gelesen (5) // gesetzt werden (6) $sender = mysql_query ("SELECT send_id FROM pr_nachrichten WHERE id='$intmsgid'"); (7) $sender = mysql_fetch_row($sender); (8) (9) if ($sender[0]!= $intuserid) (10) // Nachricht in der Datenbank als gelesen markieren (11) mysql_query("update pr_nachrichten SET gelesen='1' WHERE id = '$intmsgid'"); (12) (13) return mysql_query ( (14) "SELECT pr_nachrichten.nachricht AS chrmsgtext (15) FROM pr_nachrichten WHERE pr_nachrichten.id = $intmsgid"); (16) } Abbildung 97: Quellcode- Nachrichtentext holen / Nachricht als gelesen markieren Die Funktion msgread() (Abb. 97) hat zwei Funktionen. Zum Einen vervollständigt sie auf Seiten von Flash ein Nachrichtenobjekt um den Nachrichtentext und zum Anderen markiert sie die selektierte Nachricht in der Datenbank als gelesen. Dabei ist zu beachten, dass eine Nachricht nur dann als gelesen markiert werden darf, wenn der Benutzer, der die Nachricht aufruft, der Empfänger ist (Abb. 97 Zeile 6 11). Diese Unterscheidung ist wichtig, da der Absender auch die Möglichkeit hat, diese Nachricht zu lesen. Clientside Flash - Response verarbeiten Die Methode msg_result() verarbeitet das ResultEvent-Objekt bei einem Ergebnisereignis (Abb. 98). (1) private function msg_result(reresult:resultevent) : Void { (2) _level0.param['content_mask_bonus'] = -90; (3) strmessage = reresult.result.getitemat(0).chrmsgtext; (4) (5) eval("_level0." + strpathmovieclip).cont.attachmovie('message', 'Msg', eval("_level0." + strpathmovieclip).cont.getnexthighestdepth()); (6) eval("_level0." + strpathwb).attachmovie('msginfo', 'MsgMenu', eval("_level0." + strpathwb).getnexthighestdepth()); (7) (8) _level0.loadtcontent._visible = false; (9) _level0.loadwbcontent._visible = false; (10) } Abbildung 98: Quellcode - Teil der Message Klasse Das reresult-objekt beinhaltet den Text der gewählten Nachricht. Somit sind alle nötigen Daten für diese Nachricht vorhanden und der MovieClip für die Anzeige der Nachricht (Message) kann aus der Bibliothek in den Flashfilm geladen werden. In diesem MovieClip kann die Nachricht samt Absender, Betreff und Text betrachtet werden. Des Weiteren stehen dem Benutzer zwei Button zur Verfügung, um auf diese Nachricht zu reagieren. Der eine 120

129 Konkrete Anwendungsfälle Button dient dem Weiterleiten der Nachricht. Der zweite Button steht nur bei empfangenen Nachrichten zur Verfügung und ermöglicht das Antworten auf diese Nachricht. Beide Button führen in den send-bereich des Message- MovieClips, in den der Benutzer auch über den Klick auf den Menübutton Nachricht verfassen (Abb. 99) gelangt. Jedoch ist der Betreff schon vorbelegt und wurde um fw: oder re: ergänzt. Beim Antworten auf eine Nachricht kann kein Abbildung 99: Nachrichten Menü Empfänger mehr gewählt werden, da dieser bereits feststeht. Im send-bereich kann nun eine Nachricht geschrieben werden (Abb. 100), wobei der Text der zu Grunde liegenden Nachricht mit eingefügt wurde. Wenn nicht gerade auf eine Nachricht geantwortet wird, muss ein Benutzer als Empfänger ausgewählt werden. Hierzu trägt der Benutzer einen Benutzernamen in das entsprechende Feld und klickt auf den Button zum Auswählen dieses Benutzers. Dieser Button sorgt dafür, dass geprüft wird, ob der gewählte Benutzer im System existiert und ordnet dem Empfängernamen im Erfolgsfall die passende ID des Empfängers zu. Abbildung 100: Nachricht verfassen Nachricht verschicken Clientside Flash - Remote Call Zum Senden einer Nachricht braucht der Benutzer nur noch auf den bereitgestellten Button klicken. 121

130 Konkrete Anwendungsfälle (1) public function sendmsg(numrecid:number, strsub:string, strmsg:string) { (2) // Flash Remoting Service aufrufen (3) pcremotecall = srvmessage.msgsend(numrecid, _level0.usruser.getuserid(), strsub, strmsg); (4) pcremotecall.responder = new RelayResponder(this, 'msgsend_result', 'msgsend_error'); (5) } Abbildung 101: Quellcode - Teil der Message Klasse Die Methode sendmsg() wird daraufhin ausgeführt (Abb. 101) und ruft die entsprechende Service-Methode auf. sendmsg() erhält die ID des Empfängers, den Betreff und den Text der Nachricht als Parameter. Der Service-Methode wird zusätzlich die ID des eingeloggten Benutzers und demnach des Senders mitgegeben. Serverside PHP - Remote Service Beim Senden einer Nachricht wird die Funktion msgsend() (Abb. 102) aufgerufen. Es ist vorgesehen, dass bei projektspezifischen Nachrichten die Projekt ID mit in der Datenbank gespeichert wird, um diese Nachrichten später gesondert anzeigen zu können. Im Rahmen der Bachelorarbeit wird dieser Punkt aber nicht mehr implementiert. (1) function msgsend($intmsgreceiverid, $intmsgsenderid, $chrmsgsubject, $strmsgtext, (2) $intprojektid = 0) (3) { (4) // Aktuelles Datum (5) $datum = date("d.m.y"); (6) $this->dbconnect(); (7) $result = mysql_query ("INSERT INTO pr_nachrichten (pr_id, send_id, empf_id, betreff, (8) nachricht, datum, gelesen) (9) VALUES ( '".$intprojektid."','".$intmsgsenderid."','".$intmsgreceiverid."', (10) '".$chrmsgsubject."','".$strmsgtext."','".$datum."','0')"); (11) if($result) (12) $return = "1"; (13) else (14) $return = "0"; (15) return $return; (16) } Abbildung 102: Quellcode - Nachricht senden Neben der genannten Projekt ID wird die ID des Senders, die ID des Empfängers, der Betreff und der Nachrichtentext von Flash an PHP übergeben. Auf Seiten von PHP wird das aktuelle Datum bestimmt und die Nachricht auf noch nicht gelesen gesetzt. Dazu wird im Datenbankfeld gelesen eine 0 eingetragen. 122

131 Konkrete Anwendungsfälle Clientside Flash - Response verarbeiten Bei Erfolg oder Misserfolg des Services bzw. des Sendevorganges wird dem Benutzer über die beiden Ereignismethoden in Flash eine passende Mitteilung ausgegeben. War das Senden erfolgreich findet sich die Nachricht in der Liste für die gesendeten Nachrichten dieses Benutzers, wo er sie sich weiterhin ansehen oder gar weiterleiten kann. Der Benutzer kann diese Nachricht auch aus jener Liste löschen, was gleichermaßen für die Liste der empfangenen Nachrichten gilt. Nachricht löschen Clientside Flash - Remote Call Um eine Nachricht zu löschen, braucht der Benutzer nur die entsprechende Schaltfläche betätigen (Abb. 103) und der Code für dieses Ereignis wird ausgeführt (Abb. 104). (1) on (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) } Abbildung 103: Nachricht löschen (release) { this._x-=1; this._y-=1; var tmpkind:number; if (_level0.msgmessage.getkind() == 'Received') { tmpkind = 2; } else if (_level0.msgmessage.getkind() == 'Sent') { tmpkind = 1; } _level0.msgmessage.deletemsg(_level0.msgmessage.getmessageid(), tmpkind); Abbildung 104: Quellcode - Event der löschen-schaltfläche Es wird geprüft, aus welcher Liste die Nachricht stammt, bevor die deletemsg()-methode aufgerufen wird. Ihr wird die ID der Nachricht und ein Wert zur Repräsentation einer Liste mitgegeben. In dieser Methode wird der benötigte Service mit den erhaltenen Parametern aufgerufen (Abb. 105). (1) public function deletemsg(nummsgid:number, numkind:number) { (2) // Flash Remoting Service aufrufen (3) pcremotecall = srvmessage.msgdelete(nummsgid, numkind); (4) pcremotecall.responder = new RelayResponder(this, 'msgdelete_result', 'msgdelete_error'); (5) } Abbildung 105: Quellcode - Teil der Message Klasse 123

132 Konkrete Anwendungsfälle Serverside PHP - Remote Service Da die Nachricht, um die Datenbank zu schonen, nur einmal in dieser existiert, ist es notwendig zu unterscheiden, welcher Benutzer eine Nachricht löscht. Hierfür kommen prinzipiell zwei Benutzer in Frage. Zum Einen kann der Sender die Nachricht aus seinem Postausgang löschen und zum Anderen kann der Empfänger seine Nachrichten aus seinem Posteingang löschen. Da bei den jeweiligen Aktionen aber nur die eigene Nachricht verschwinden darf, war es notwendig einen zusätzliches Flag einzuführen. Es handelt sich hierbei um ein zusätzliches Feld in der Datenbank, welches je nachdem, wer die Nachricht gelöscht hat, gesetzt wird. Beim Anzeigen der Nachrichten in den Nachrichtenlisten, können diese Nachrichten dann ausgeblendet werden, ohne sie aus der Datenbank löschen zu müssen. Die gleiche Nachricht kann weiterhin beim Gesprächspartner angezeigt werden. (1) (2) (3) (4) function msgdelete($intmsgid, $intdelstatus) { $this->dbconnect(); // Die Nachrichten werden erst dann aus dem System geloescht, wenn Sender und Empfaenger (5) // sie als geloescht markiert haben (6) $status = mysql_query ( "SELECT loeschen FROM pr_nachrichten WHERE id='$intmsgid'" ); (7) $status = mysql_fetch_row($status); (8) (9) if(($intdelstatus == 1 && $status[0] == 2) ($intdelstatus == 2 && $status[0] == 1)) (10) { (11) $result = mysql_query ("DELETE FROM pr_nachrichten WHERE id='$intmsgid'"); (12) } (13) else if ($status[0] == 0) (14) { (15) $result = mysql_query ( "UPDATE pr_nachrichten SET loeschen='$intdelstatus' WHERE id='$intmsgid'"); (16) } (17) if($result) (18) $return = "1"; (19) else (20) $return = "0"; (21) return $return; (22) } Abbildung 106: Quellcode - Nachricht löschen Die Unterscheidung, ob eine Nachricht als gelöscht markiert werden muss oder ob sie ganz aus der Datenbank entfernt werden soll, ist dabei durch eine einfache Abfrage gelöst worden. Versucht ein Benutzer eine Nachricht zu löschen, die von seinem Gesprächspartner zuvor auch schon zum Löschen markiert wurde, kann diese ganz aus der Datenbank entfernt werden (Abb. 106 Zeile 9 12). Ist dem nicht so, muss das Feld loeschen in der Datenbank aktualisiert werden. Dabei wird, je nachdem welcher Benutzer die Nachricht löschen möchte, eine 1 (Sender) oder eine 2 (Empfänger) eingetragen (Abb. 106 Zeile 13 17). Um die nötigen Informationen zu erhalten, wird der Methode übergeben, wer die Nachrichten löschen möchte. Dieser Wert wird dann mit dem Eintrag in der Datenbank verglichen (Abb. 106 Zeile 5 9). 124

133 Konkrete Anwendungsfälle Clientside Flash - Response verarbeiten Wie gewohnt wird dem Benutzer bei Erfolg oder Misserfolg des Services bzw. des Sendevorganges eine passende Mitteilung ausgegeben. 125

134 Konkrete Anwendungsfälle Login Im folgenden Kapitel wird anhand von Quellcode erläutert, wie der Login erfolgt. Dabei ist das Kapitel zunächst in eine Beschreibung, in den technischen Ablauf und aufgetretene Probleme gegliedert. Der technische Ablauf ist wiederum grob in drei Bereiche aufgeteilt. Der erste dieser Bereiche beschreibt den Aufruf der amfphp Methode aus Flash heraus (Clientside Flash - Remote Call). Der zweite Bereich beschreibt den Ablauf auf der Serverseite (Serverside PHP - Remote Service). Der dritte und letzte Teil beschreibt die Rückgabe der Daten von amfphp an Flash und dessen Auswertung (Clientside Flash - Response verarbeiten) Beschreibung Bei der Konzeptionierung des Anmeldevorgangs wurde großen Wert auf die Benutzertauglichkeit gelegt. Einem Fachhochschulstudent der FH-Köln ist es möglich, sich ohne eine erneute Anmeldung, mit seiner FH-Kennung einzuloggen. Benutzer die Abbildung 107: Anmeldung am System keinen solchen Account besitzen, müssen sich zunächst registrieren, um die erweiterten Funktionen im Internen Bereich nutzen zu können (Siehe Kapitel: 4.6. ). Loggt sich ein FH-Student das erste Mal mit seiner FH-Kennung ein, ist es notwendig, dass er sein Profil um persönliche Daten, wie seine Anschrift und seinen vollständigen Namen erweitert. Er kann das Projektinformationssystem erst in vollem Umfang nutzen, wenn er diese Angaben vollständig gemacht hat. Bei einer Neuanmeldung ist der Vorgang ähnlich. Der Benutzer muss zu seinen persönlichen Abbildung 108: Benutzerprofil vervollständigen Daten noch ein Passwort und eine - Adresse angeben. Hat er die Daten vollständig angegeben, erhält er eine , mit der er seinen Account freischalten kann. Nach der Freischaltung kann der Benutzer sich einloggen und im Internen Bereich eigene Projekte anlegen und das Nachrichtensystem (siehe Kapitel: ) nutzen. 126

135 Konkrete Anwendungsfälle Technischer Ablauf Clientside Flash - Remote Call Nach Eingabe des Benutzernamens, des Passworts und dem Klick auf die entsprechende Schaltfläche wird die Methode login() ausgeführt (Abb. 109). In ihr wird das Passwort in einen MD5-Wert codiert. Hierfür wird eine externe ActionScript-Datei verwendet. (1) function login(struser:string, strpw:string) : Void { (2) var bolpassok:boolean = false; (3) var strgatewayurl:string; (4) var srvlogin:service; (5) var pcremotecall:pendingcall; (6) PARAM['nick'] = struser; (7) PARAM['pwmd5'] = getmd5(strpw); (8) dropzoneli.login.li.txterrormessage.textcolor = 0x000000; (9) dropzoneli.login.li.txterrormessage.text = LANG['login_process']; (10) dropzoneli.login.li.butlogin.enabled = false; (11) strgatewayurl = 'http://mims02.gm.fh-koeln.de/~proinf/amfphp/gateway.php'; (12) NetDebug.initialize(); (13) srvlogin = new Service(strGatewayURL, null, 'ProInf', null, null); (14) pcremotecall = srvlogin.userpassok(struser, strpw); (15) pcremotecall.responder = new RelayResponder(this, 'passok_result', 'passok_error'); (16) } Abbildung 109: Quellcode - Teil der ActionScript Datei functions.as Daraufhin wird ein Service-Objekt erstellt und die entsprechende Servicemethode aufgerufen. Serverside PHP - Remote Service (1) function userpassok( $chrusername, $chruserpassword ) (2) { (3) $this->dbconnect(); (4) $result = mysql_query ( (5) "SELECT id, nick, passwort, frei FROM pr_user WHERE nick = '".$chrusername."'"); (6) $ausgabe = mysql_fetch_array ($result); (7) if ($ausgabe['nick'] == "") (8) { (9) $return = "-1"; // User existiert nicht (10) ($this->checkfhuser($chrusername, $chruserpassword))? $return = "1" : $return = "-1"; // Wenn FH User existiert 1 zurueck geben (11) } (12) else if($ausgabe['passwort']!= md5($chruserpassword)) (13) { (14) $return = "-2"; //Passwort falsch (15) } (16) else if ($ausgabe['frei'] == 0) (17) { (18) $return = "-3"; // User wurde gesperrt (19) } (20) else (21) { (22) $return = "1"; // Alles ok (23) } (24) return $return; (25) } Abbildung 110: Quellcode Benutzerauthentifizierung 127

136 Konkrete Anwendungsfälle Die Funktion userpassok() (Abb. 110) wird aufgerufen, nachdem der Benutzer seinen Benutzernamen und sein Passwort in die dafür vorgesehenen Formularfelder eingetragen hat und das Formular gesendet wurde. Zunächst wird überprüft ob der übermittelte Benutzername in der Datanbanktabelle pr_user des Projektinformationssystem existiert (Abb. 110 Zeile 4 5). An dieser Stelle gilt es verschiedene Resultate auszuwerten und zu verarbeiten. Existiert der Benutzer in der Tabelle, wird überprüft ob sein Passwort mit dem übermittelten übereinstimmt (Abb. 110 Zeile 14 18). Ist dem so wird getestet, ob der Benutzeraccount freigeschaltet bzw. gesperrt wurde. Eine Sperrung kann manuell durch einen Administrator oder einen Fakultätsmitarbeiter vorgenommen worden sein oder der Benutzer hat seinen Account noch nicht freigeschaltet. Sind alle Kriterien erfüllt, wird die Variable $return, welche das Ergebnis an Flash zurück liefert, auf 1 gesetzt und die Überprüfung ist abgeschlossen. Existiert der Benutzer noch nicht in der Datenbank, ist es für das System wichtig, zwischen einer FH-Kennung und einem normalen Account zu unterscheiden. Dazu wird die private Funktion checkfhuser() (Abb. 110 Zeile 12) aufgerufen. Wie die Funktion im einzelnen aufgebaut ist, wird im Folgenden erklärt (Abb. 111). (1) function checkfhuser($chrusername, $chruserpassword) (2) { (3) // Aktuelles Datum (4) $datum = date("d.m.y"); (5) $return = false; (6) $mbox = imap_open("{advm2.gm.fh-koeln.de:143}inbox", $chrusername, $chruserpassword); (7) if ($mbox!= false) (8) { (9) $this->dbconnect(); (10) mysql_query("insert INTO pr_user(nick, passwort, reg_datum, frei) (11) VALUES('".$chrUserName."','".md5($chrUserPassword)."', '".$datum."', '1')"); (12) $return = true; (13) } (14) else (15) { (16) $return = false; (17) } (18) return $return; (19) } Abbildung 111: Quellcode - Überprüfung einer FH-Kennung + Datenbankeintrag Der Campus Gummersbach der Fachhochschule Köln stellt Projekten, die auf einem der FhServer laufen, die Möglichkeit zur Verfügung, über das Internet Message Access Protocol (IMAP)52 auf die Benutzeraccounts der Studenten zuzugreifen. Diese Möglichkeit nutzt das Projektinformationssystem, um zu überprüfen, ob eine bestimmte Benutzername-PasswortKombination existiert. Dazu wird versucht, über die PHP Funktion imap_open()53 eine Verbindung aufzubauen (Abb. 111 Zeile 6). Gelingt dies, ist sichergestellt, dass der Benutzer 52 Vgl. 53 Vgl. 128

137 Konkrete Anwendungsfälle in der Fachhochschule existiert und kann in die Datenbank des Projektinformationssystem eingetragen werden (Abb. 111 Zeile 10-12). Es ist leider nicht möglich, weitere Informationen des Benutzers von der Fachhochschule abzufragen, so dass diese manuell vom Benutzer nachgetragen werden müssen. Clientside Flash - Response verarbeiten Im Erfolgsfall wird die Methode passok_result() ausgeführt, in der je nach Rückgabewert entschieden wird, welche Ausgabe der Benutzer erhält, falls ein Problem auftrat (z. B. Benutzername existiert nicht), oder er andernfalls eingeloggt wird. Nach dem erfolgreichen LogIn gelangt der Benutzer in den Internen Bereich, in dem zu Begin einige persönliche Daten des Benutzers geladen werden. Unter anderem wird geprüft, ob sein Profil vollständig ist. Sollten noch Daten fehlen, wird er aufgefordert diese zu vervollständigen. Es steht ihm keine weitere Funktion zur Verfügung. Allein das Ausloggen ist alternativ möglich. Sobald das Profil vervollständigt wurde, oder es bereits ist, erscheint das individuelle Menü (abhängig von den Benutzerrechten) und sein Start-Content für den Internen Bereich wird geladen Probleme Da das IMAP Protokoll es nicht erlaubt ein Passwort im Message Digest Algorithm 5 (MD5)54 zu übergeben, muss es in Klartext von Flash an PHP übertragen werden. Da diese Übermittlung durch den Benutzer selber angestoßen wird, ist das Sicherheitsrisiko akzeptabel. Im Flashfilm selber liegt das Passwort später nur in verschlüsselter Form vor. Eine Besonderheit von amfphp ist es, dass Fehlermeldungen und Warnings die PHP erzeugt, verarbeitet werden. Generell kann man in PHP die Ausgabe von Warnings, sollte man sie nicht benötigen, durch verschiedene Vorgehensweisen abstellen. Dabei ist zu beachten, dass diese Warnings trotzdem erzeugt werden. Sie werden nur nicht ausgegeben. Genau da liegt auf Seiten von amfphp das Problem. Warnings werden immer verarbeitet und führen zu einem Abbruch einer Funktion. Man muss also auf Seiten von Flash die Warnings verarbeiten und kann keinen eigenen Fehlercode erzeugen. 54 Vgl. 129

138 Serverseitige Probleme mit MySQL und PHP Serverseitige Probleme mit MySQL und PHP Voraussetzungen Wir benötigen für den Betrieb des Projektinformationssystems drei unerlässliche Funktionalitäten. Erstens muss es möglich sein, über IMAP mit der Benutzerdatenbank der Fachhochschule zu kommunizieren. Zweitens muss der Webserver die Funktionalität bieten, Vorschaubilder zu erstellen und drittens muss eine passende Datenbankversion installiert sein. Inbetriebnahme Unsere Anwendung wurde zunächst auf einem eigenen Server entwickelt, den wir nicht selber eingerichtet haben, auf dem aber die Funktionen zur Verfügung standen, die wir benötigen. Nachdem uns dann, von Seiten der Fachhochschule, Webspace und eine Datenbank zur Verfügung gestellt wurde, haben wir uns dazu entschlossen, noch während der Entwicklung den Server zu wechseln, um auf dem bereitgestellten zu arbeiten. Da unser Projekt, in einer früheren Version, schon einmal auf diesem Server betrieben wurde, war sie schnell lauffähig. Wir stellten dann jedoch fest, dass die installierte MySQL Version nicht die Funktionalität zur Verfügung stellt, die wir benötigen. Es ist für unsere Anwendung notwendig, dass MySQL es erlaubt Unter-SELECTS zu benutzen. Diese Funktion wurde allerdings erst ab Version eingeführt. Da dieser Server nur als Zwischenstation gedacht war, weil wir einen Webserver mit PHP 5 benötigen, diese Version aber nicht installiert war, sind wir danach auf einen anderen Server umgezogen. Dieser Server konnte leider auch nicht die gewünschte Funktionalität (siehe Voraussetzungen) bieten. Hier gab es Probleme mit dem Backup der Daten, so dass eine einfache Aktualisierung der erforderlichen Pakete (PHP, MySQL) nicht möglich war. Die letzte Möglichkeit bestand darin, dass wir den Hauptserver der MedieninformatikWebseite benutzen. Nach der Einrichtung unserer Daten stellte sich dann wiederum heraus, dass etwas mit den installierten Paket-Versionen nicht stimmte. Es war zum Einen nicht möglich mit der Fachhochschul-Benutzerdatenbank zu kommunizieren, was auf eine fehlende IMAP Funktionalität hindeutete und zum Anderen war es nicht möglich Vorschaubilder zu erstellen, was an der fehlenden GD Bibliothek lag. Nach 2 Tagen Bemühung unserer Betreuerin in der Fachhochschule, den Server doch noch unseren Bedürfnissen anzupassen, sind wir dann gemeinsam zu dem Entschluss gekommen, die Konfiguration selber zu übernehmen. Mit der Datenbank gab es auf dem neuen Server keinerlei Probleme mehr, so dass diese unangetastet bleiben konnte. Probleme bereitete uns allerdings die installierte PHP-Version. 130

139 Serverseitige Probleme mit MySQL und PHP Dabei sollte ein vorgefertigtes Paket55 zum Einsatz kommen, welches allerdings keine ausreichende IMAP Unterstützung bot. Aus uns unerfindlichen Gründen klappte die Verbindung aus dem lokalen Fachhochschulnetz, aber nicht von außerhalb. Dies könnte an einer Beschränkung verwendeter Ports gelegen haben, da die Fachhochschule bei Sicherheitsfragen sehr restriktiv vorgeht und nicht benutzte Ports sperrt. Vermutlich verwendet das installierte PHP Paket einen anderen Port, was aus der Dokumentation allerdings nicht eindeutig hervor ging. Wir entschlossen uns dann dazu, PHP mit den gewünschten Funktionen selbst zu kompilieren, ohne das genannte PHP Paket zu benutzen. Daraufhin konnten alle benötigten Funktionen, wie IMAP und GD, genutzt werden. Um den amfphp DebugGateway nutzen zu können, ist es notwendig, dass curl auf dem Server installiert ist. Außerdem muss diese Funktionalität in PHP einkompiliert werden. Obwohl augenscheinlich alles richtig installiert und kompiliert war, gelang es nicht, curl und somit auch nicht den DebugGateway richtig zu konfigurieren. Die hatte auf den Betrieb unserer Anwendung jedoch keinen Einfluss. 55 Vgl. 131

140 4.8 Verwendete Technologien und Hardware 4.8 Verwendete Technologien und Hardware An dieser Stelle wird die eingesetzte Software der Entwickler vorgestellt. Außerdem werden die Anforderungen beschrieben, um das Projektinformationssystem auf dem Server zu betreiben. Auf Seiten des Clients reicht ein Flash Plugin ab Version 8.0. Software der Entwickler Client System 1: Webbrowser 1 Mozilla Firefox Version Webbrowser 2 Internet Explorer Version Flash Plugin Version 9.0r28 Systemdaten Windows XP Professionell Service Pack 2, 2 GB Arbeitsspeicher Flashentwicklung + Flash Professionell 8.0 Plugins Aktualisierung für aktiven Flash Inhalt Flash Remoting MX Components for Flash 8 ActionScript 2.0 Client System 2: Webbrowser 1 Mozilla Firefox Version Webbrowser 2 Opera Version 9.10 Build 521 Flash Plugin Version 9.0r31 Systemdaten Kubuntu 6.10 (Edgy), 2 GB Arbeitsspeicher Flashentwicklung + Flash Professionell 8.0 Plugins Aktualisierung für aktiven Flash Inhalt Flash Remoting MX Components for Flash 8 ActionScript 2.0 HTML Editor Quanta Hard Software des Servers Das Projektinformationssystem läuft auf einem Server mit folgenden Spezifikationen. Wichtig zu beachten ist, dass PHP mit der Grafik Bibliothek GD56 kompiliert wurde. Außerdem wird die PHP IMAP-Funktion benötigt. Über dieses Protokoll kommuniziert amfphp mit der Fachhochschul-Benutzer-Datenbank. Server: System Darwin Kernel Version Apache Apache/ (Darwin) PHP/5.2.0 DAV/1.0.3 mod_ssl/ OpenSSL/0.9.7i mod_perl/1.29 Apache Mods mod_webobjects, mod_php5, mod_encoding, mod_dav, mod_ssl, 56 Vgl. 132

141 Hard Software des Servers mod_digest_apple, mod_hfs_apple, mod_perl, mod_spotlight_apple, mod_macbinary_apple, mod_setenvif, mod_so, mod_unique_id, mod_usertrack, mod_headers, mod_expires, mod_cern_meta, mod_proxy, mod_digest, mod_auth_dbm, mod_auth_anon, mod_auth_apple, mod_access, mod_rewrite, mod_alias, mod_userdir, mod_actions, mod_imap, mod_asis, mod_cgi, mod_dir, mod_autoindex, mod_include, mod_info, mod_status, mod_negotiation, mod_mime, mod_log_config, http_core PHP Version DAV PHP Configure './configure' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' Command '--disable-dependency-tracking' '--with-apxs' '--with-ldap=/usr' '--withkerberos=/usr' '--enable-cli' '--with-zlib-dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-ftp' '--enable-mbstring' '--enable-mbregex' '--enable-dbx' '--enablesockets' '--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file-path=/etc' '-sysconfdir=/private/etc' '--with-mysql=/usr' '--with-mysqlsock=/var/mysql/mysql.sock' '--enable-yp' '--enable-exif' '--with-gd' '--with-jpeg' '--with-jpeg-dir=/sw' '--with-imap=/usr/local/imap-2006d' '--with-imap-ssl' Datenbank MySQL Version a 133

142 5. Thesendiskussion 5. Thesendiskussion Noch bevor wir mit der Implementierung begannen, wurden von uns Hypothesen aufgestellt (siehe Kapitel 2.). Diese Hypothesen werden im folgenden diskutiert und schildern unsere Erfahrungen. Weiterhin zeigen sie, ob sich unsere Erwartungen, welche wir in die gewählte Technologie amfphp steckten, bestätigten Hypothese 1 Schnellerer Ablauf der Kommunikation, gegenüber der Umsetzung mit Flash, PHP und XML. Da die Kommunikation über XML, wie wir sie in der ersten Umsetzung einsetzten, gegenüber anderen Umsetzungen den Ruf hat, langsamer zu sein, haben wir uns durch die Umsetzung mit amfphp einen schnelleren Datenaustausch und somit eine schnellere Anzeige der angeforderten Daten erhofft. Da amfphp das binäre AMF Protokoll zur Übertragung nutzt, ist laut der Entwickler, die zu übertragene Datenmenge, im Vergleich zu einer Übertragung mit XML, bis zu 75 % geringer57. Es wird also durch die geringere Übertragungsmenge Zeit gespart. Dies zeigt sich besonders bei der Übertragung komplexer Datentypen wie Resultsets. Da diese Datentypen ohne weitere Bearbeitung, im Flashplayer genutzt werden können, benötigt man angeblich weniger Zeit. Um diese These evaluieren zu können, haben wir uns dazu entschlossen, Ablauftests an der alten und neuen Umsetzung durchzuführen. Dazu wurde in beide Anwendungen ein Zeitnehmer integriert. Dieser Zeitnehmer kommt an zwei, im System hoch frequentierten Stellen zum Einsatz. Einmal misst er die Zeit, die benötigt wird um die Methode catlist() auszuführen und deren Rückgabe auszuwerten. In einem zweiten Test misst er die Ausführung der prolistcat() und deren Auswertung der Rückgabe. Was bei der Ausführung dieser beiden Methoden genau abläuft haben wird zu Beginn der Tests erläutert. Da in der alten Umsetzung, bei einer Anfrage an den Server immer dann eine neue XML Datei erzeugt wird, wenn sich Einträge in der Datenbank ändern, dies aber in den Tests nicht simuliert werden konnte, haben wir uns dazu entschlossen den Browsercache auszuschalten. Dies war notwendig, da der Browser nur dann die XML Datei vom Server lädt, wenn sie sich geändert hat. Dies findet unter realen Umständen häufiger statt als in unseren Tests. 57 Vgl. 134

143 5.1. Hypothese 1 Im Laufe der Tests sind wir zudem auf eine PHP Erweiterung gestoßen, die es uns ermöglicht, eine weitere Performance-Steigerung zu erzielen. Dabei handelt es sich um einen so genannten PHP-Cache58. Dieser PHP-Cache kompiliert PHP-Scripte auf dem Webserver, was eine deutliche Verringerung der Ausführungszeit zur Folge hat, da dies einmalig geschieht und nicht mehr bei jedem Aufruf des Scripts. Weil sich dieser Vorteil auf beide Umsetzungen gleichermaßen auswirkt, müssen wir bei den Tests nicht noch einmal darauf eingehen. Neben den von uns durchgeführten Tests, existiert im Internet ein Performance-Test, der eine Kommunikation über SOAP(XML) mit der Kommunikation über amfphp Vergleicht59. Da dieser Test sehr veraltet ist und sich seitdem viel am Flashplayer verändert hat, sind die Ergebnisse nicht mehr eins zu eins übertragbar. Test 1 catlist() Beim Starten des Flashfilms im Browser, bekommt der Benutzer als erstes eine Liste der zur Verfügung stehenden Kategorien zu sehen. In diesen Kategorien befinden sich die bereits eingestellten Projekte. Der Zeitnehmer fängt im ersten Test an zu zählen, wenn in Flash die amfphp Methode catlist() aufgerufen wird und hört auf, wenn die gesamte Kategorieliste aufgebaut wurde. Es umfasst also die Anfrage an PHP, das Selektieren der Daten aus der Datenbank und ggf. die Erstellung einer XML Datei (alte Umsetzung). Weiterhin umfasst es die Übermittlung an den Flashfilm und die darauf folgende Verarbeitung der übertragenen Daten. Dazu gehört auch die Darstellung dieser. Aufgrund der internen Arbeitsweise von Flash bezüglich der Ausführung von ActionScript Code, ist es technisch nicht möglich diesen Vorgang in noch kleinere Schritte aufzuteilen, so dass nur die Gesamtzeit, des ganzen Vorgangs, gemessen werden konnte. 58 Vgl. 59 Vgl. 135

144 5.1. Hypothese 1 Abbildung 112: Test 1, catlist() In Abbildung 112 sind 100 Testdurchläufe aufgeführt, die immer im Wechsel, erst die alte Umsetzung und danach die neue Umsetzung, durchgeführt wurden. Daraus ergab sich eine durchschnittliche Ausführungszeit von 244,85 ms für die alte Umsetzung und 218,87 ms für die neue Umsetzung. Der Einsatz von amfphp bringt an dieser Stelle also einen Vorteil von ca. 25,98 ms. Die auftretenden Peaks in diesem Test waren nicht reproduzierbar. Außerdem deutet die Tatsache, dass sie in beiden Implementierungen unregelmäßig auftraten darauf hin, dass kein Fehler in der Programmierung der Grund ist. Sie müssen somit Faktoren wie Netzschwankungen oder der Last des Server zugeordnet werden. Test 2 prolistcat() In Test 2 wurde das Abrufen der Projekte einer Kategorie überprüft. Diese Ansicht bekommt der Benutzter immer dann zu sehen, wenn er sich in der Kategorieliste für eine Kategorie entschieden hat. In diesem Test, fängt der Zeitnehmer, ähnlich wie im ersten Test, an zu zählen, wenn der Benutzer auf eine Kategorie klickt, also die amfphp Methode prolistcat() aufgerufen wird. Die Messung fand wieder so lange statt, bis die Daten übertragen wurden und sich die gesamte Liste im Flashfilm aufgebaute. Es fanden insgesamt drei Durchläufe statt, von denen die ersten zwei nach etwa 10 Versuchen abgebrochen wurden, da wir, aufgrund der großen Schwankungen, keine repräsentativen Ausführungszeiten ermitteln konnten. Die Peaks deuten auch bei diesem Test nicht auf einen Fehler in unserer Implementierung hin, sondern auf Faktoren wie Netzwerkschwankungen oder der Serverlast. Der dritte Test war ähnlich schwierig zu bewerten, lieferte aber Werte, von denen wir denken, dass sie eine grobe Richtung erkennen lassen, da deutlich weniger Ausfälle gegenüber den beiden vorherigen Tests auftraten. 136

145 5.1. Hypothese 1 Abbildung 113: Test 2, catlistpro() Auch bei dieser Messung (Abb. 113) haben wir jeweils 100 Testläufe durchgeführt. Die durchschnittliche Ablaufzeit der alten Umsetzung betrug 1098,44 ms und die der neuen Umsetzung 853,45 ms, woraus sich eine Differenz von ca. 244,99 ms ergibt. Es sei aber angemerkt, dass diese Werte, unter den Umständen der Messung, nicht repräsentativ sind. Leider konnte der zweite Test nicht zu unserer Zufriedenheit durchgeführt werden, da immer wieder Timeouts oder sehr lange Ladezeiten auftraten. Wir haben die Tests daraufhin auf verschiedenen Rechnern, mit unterschiedlich schnellen Internetanbindungen verschiedener Provider wiederholt, ohne das wir nennenswerte Unterschiede, in den Ausführungszeiten, feststellten. Wir vermuten, dass die Schwankungen durch den Fachhochschulserver zustande kommen könnten, da sich ähnliche Schwankungen von verschiedenen Clientrechnern, bei beiden Anwendungen ergaben. Wir hatten im Laufe der Bachelorarbeit leider keine Möglichkeit unser System auf einem anderen Server zu testen, um unsere Vermutung zu untermauern. Außerdem konnten wir durch keinen der Tests ausschließen, dass Lastschwankungen des Internetproviders der Grund waren. Auswertung Abschließend können wir sagen, dass sich unsere Erwartungen an amfphp in Bezug auf die Performance-Steigerung erfüllte. In den getesteten Bereichen hat sich ein Vorteil in der Ausführungszeit ergeben, welcher bei steigender Projektanzahl noch deutlicher werden dürfte. Da der zweite Test teilweise nicht wie erwünscht ablief, sind wir mit dem Ergebnis weniger zufrieden. Er zeigt aber eine Tendenz, die sich mit unseren Erwartungen durchaus deckt, wenn man die Ausfälle außer Acht lässt. Zuletzt muss noch gesagt werden, dass die 137

146 5.1. Hypothese 1 alte Umsetzung mit eingeschaltetem Browsercache, teilweise schneller läuft, wenn nicht viele Änderungen in der Datenbank stattfinden. Dies ergibt sich, wie schon zu Anfang erwähnt, aus dem cachen der XML Dateien durch den Browser. Ist das Nutzerverhalten eines Benutzer so ausgerichtet, dass er sich viel im System bewegt und häufig unterschiedliche Listen anfordert, hat er in der Umsetzung mit XML keinen Vorteil. Der Grund liegt darin, dass die XML Dateien der Listen immer neu erzeugt werden müssen. Gleiches gilt auch für ein Nutzerverhalten, bei dem sich der Benutzer wenig im System bewegt aber unterschiedliche Listen abruft. Ruft ein Benutzer jedoch häufig die gleiche Liste ab, beispielsweise die Kategorieübersicht, ergeben sich in der alten Umsetzungen Vorteile, da diese Liste bereits auf seinem Rechner (Browsercache) existiert. 138

147 5.2. Hypothese Hypothese 2 Die Kommunikation ist sicher, in Bezug auf Integrität, Authentizität und Vertraulichkeit. Da in unserem Projektinformationssystem auch benutzerbezogene Daten ausgetauscht werden und es in einer Umgebung betrieben wird, die ein hohes Maß an Sicherheit erfordert (Fachhochschule), erhofften wir uns durch den Einsatz von amfphp, eine sichere Kommunikation. Sicher bedeutet die Überprüfung der Daten auf Integrität, Athentizität und Vertraulichkeit. Weiterhin hoffen wir eine fehlerfreie Datenhaltung gewährleisten zu können. Unsere Erwartung, dass amfphp durch die Kommunikation über ein binäres Kommunikationsprotokoll sicherer sei, als eine Kommunikation, z.b. über XML, hat sich nur teilweise bestätigt. Bei amfphp ist es genauso möglich den Datenstrom auszulesen, da er zwischen dem Client und dem Server nicht zusätzlich verschlüsselt wird. Der einzige Unterschied besteht darin, dass kein gewöhnlicher POST Stream decodiert werden muss, sondern der AMF Stream. Dies bedeutet heutzutage kaum Mehraufwand, da dass AMF Protokoll durch viele Programme unterstützt wird und somit bekannt ist. Eines dieser Programme ist curl60 und kann POST Streams, genauso wie AMF Streams decodieren. Ein weiterer Punkt ist, dass der Flashfilm nicht verschlüsselt auf dem Client abgelegt wird. Es ist also möglich, diesen zu dekompilieren, um so an die gewünschten Daten zu kommen. Dieser Umstand und die mangelnde Kontrolle auf Authentizität und Integrität bei der eigentlichen Übertragung hat zur Folge, dass wir sensible Daten, wie dass Passwort des Benutzers, nur in verschlüsselter Form zum Client übertragen. Alle anderen Daten können im Client selber angesehen werden und müssen somit nicht näher geschützt werden. Neben der verschlüsselten Übertragung wird das Passwort in der Datenbank und auch im Flashfilm nur in verschlüsselter Form gespeichert und kann von einem möglichen Angreifer nicht ausgelesen werden. Es wird nur an einer Stelle unverschlüsselt vom Client zum Server Übertragung, nämlich bei der Anmeldung eines Benutzers am System. An dieser Stelle ist dies notwendig, da die IMAP Funktion von PHP, welche zur Anmeldung an der Fachhochschul-Benutzerdatenbank genutzt wird, keine MD5 verschlüsselten Passwörter unterstützt. Dieser Umstand wird jedoch in der Weiterentwicklung behoben, dazu wird auch im genannten Fall das Passwort verschlüsselt. Wie diese Verschlüsselung genau umgesetzt wird, wurde noch nicht entschieden. Weiterhin werden sensible Daten nur dann übertragen, wenn es absolut notwendig ist. Unnötige Kommunikation bedeutet ein unnötiges Sicherheitsrisiko. 60 Vgl. 139

148 5.2. Hypothese 2 Amfphp bietet die Möglichkeit, ein eingebautes Rechtesystem für die auszuführenden Methoden zu verwenden (Vertraulichkeit). Von dieser Möglichkeit haben wir abgesehen, da wir unser eigenes Rechtemanagement entwickelten. Zudem streben die Entwickler von amfphp an, die Struktur des eingebauten Systems zu ändern. In aktuellen Entwicklerversionen von amfphp wurde dieser Schutz schon umgebaut. Ein weiterer, sicherheitsrelevanter Punkt bei der Arbeit mit PHP und der Datenbank MySQL ist die Möglichkeit, dass ein Angreifer die verwendeten SELECT-Abfragen ausnutzt, um eigenen Code einzuschleusen (SQL-Injections). Um dies zu Verhindern oder das Risiko zu mindern gibt es zwei Ansätze, die sich durchaus kombinieren lassen. Wir vermieden SELECT-Abfragen in der Form (SELECT * from...) zu modellieren, da bei einer solchen Abfrage auch nicht benötigte Datenbankspalten zurückgeliefert werden, die unter Umständen missbraucht werden könnten. Eine weitere Form, die Gefahr durch SQLInjections zu minimieren, besteht darin, die vom Benutzer eingegebenen Daten zu filtern und zu validieren. Dieser Punkt soll nach der Bachelorarbeit umgesetzt werden. Neben den genannten Sicherheitsmaßnahmen besteht noch die Möglichkeit, den Zugriff auf die Anwendung und die Verzeichnisstruktur des Webservers zu beschränken. Dies geschieht über sog..htaccess-files. Dabei handelt es sich um Dateien, die auf dem Webserver abgelegt werden und Sicherheitsregeln beinhalten. Über diese Sicherheitsregeln verhindern wir zum Einen den Zugriff auf die Verzeichnissstruktur des Projektinformationssystems und die Vertraulichkeit zu gewährleisten. Ansonsten wäre es mögliche einzelne Dateien, auch PHP Scripte, aufzurufen und sich den Inhalt anzuschauen. Zum Anderen wird die Domain festgelegt, von der aus ein Flashfilm, per RPC auf die amfphp Dateien zugreifen kann. Würde diese Beschränkung nicht bestehen, wäre es denkbar das ein Angreifer die amfphp Methoden manuell aufruft oder mit einem angepassten Flash Film auf die amfphp Methoden zugreift. Die genannten Sicherheitshinweise werden zum Teil auch von dem amfphp Entwicklern empfohlen und stehen zum Nachlesen auf der Webseite61 zur Verfügung. Auswertung Nach der Umsetzung können wir sagen, dass unsere Anwendung nicht anfälliger für Angriffe durch Dritte ist, sie aber auch keine nennenswerten Vorteile gegenüber einer Umsetzung mit PHP ohne Flash oder XML vorweist. An der Webserverkonfiguration könnte noch Verschiedenes eingestellt werden, was aber tiefere Eingriffe nötig machen würde. In einer erneuten Überarbeitung, nach der Bachelorarbeit, soll dies erledigt werden. 61 Vgl. 140

149 5.3. Hypothese Hypothese 3 Die Technologien der Kommunikationspartner sind plattformunabhängig. Bei der Entscheidungsfindung bezüglich der zu verwendenden Technologien spielte die plattformübergreifende Verfügbarkeit eine große Rolle. Das Projektinformationssystem soll keine Benutzer aufgrund des verwendeten Betriebssystems ausschließen. Da die Entwickler selbst auf unterschiedlichen Betriebssystemen programmieren, war diese Plattformunabhängigkeit auch bei den eingesetzten Implementierungswerkzeugen und Entwicklungsumgebungen interessant aber nicht ausschlaggebend. Während der Evaluationsphase der ersten Umsetzung stellte sich schnell heraus, dass die Auswahl an Clienttechnologien recht eingeschränkt war. Da sich unsere Umsetzung des Clients im Aussehen und den Animationen sehr an der Realität orientiert, standen nur Macromedia Flash und Macromedia Director zur Auswahl. Aufgrund der Tatsache, dass Macromedia kein Shockwave-Browserplugin62 für UNIX anbietet, fiel die Entscheidung zugunsten von Flash aus. Ein weiterer Grund Flash einzusetzen ist, dass die Verbreitung63 und auch die technischen Möglichkeiten deutlich höher sind als bei Director. Weiterhin ist ein kostenloses Flash-Plugin in modernen Webbrowsern wie Firefox auch unter Linux leicht zu installieren, sofern es nicht schon vorinstalliert ist. Bei der Auswahl der zu verwendenden Servertechnologie waren die Alternativen umfangreicher, da nahezu alle in Frage kommenden Technologien für alle Betriebssysteme zur Verfügung stehen. Das Entscheidungskriterium war hier zum Einen die Kompatibilität mit dem Apache Webserver, welcher in der Fachhochschule zum Einsatz kommt und zum Anderen die freie Verfügbarkeit. Bei der Programmierung entschieden wir uns für die Skriptsprache PHP64. Sie steht kostenfrei zur Verfügung, ist auf dem aktuellen Stand der Technik und zudem weit verbreitet, was einen guten Support zur Folge hat. Zur Datenhaltung kommt aus ähnlichen Gründen eine MySQL65 Datenbank zum Einsatz. Sie steht ebenfalls kostenlos zur Verfügung und ist sehr weit verbreitet. Bei der PHP-Entwicklung stehen einem für die gängigen Betriebssysteme wie UNIX, Mac OSX und Microsoft Windows ausreichend Editoren und IDEs zur Verfügung. Man hat also keine Schwierigkeiten seine Scripte plattformübergreifend zu entwickeln, es müssen lediglich Unterschiede in der Bedienung in Kauf genommen werden. Bei der Entwicklung mit Flash ist man jedoch auf Windows oder Mac OSX angewiesen. Die aktuelle Entwicklungsumgebung Flash Professional 8 steht leider nur für diese Plattformen Vgl. Vgl. Vgl. Vgl. 141

150 5.3. Hypothese 3 zur Verfügung. In der Vergangenheit hat es Versuche gegeben, eine freie Entwicklungsumgebung für das Flashformat zu Entwickeln. Diese Programme, sofern sie noch weiter entwickelt werden, stellen jedoch keine ernst zunehmende Alternative dar. Auswertung Während der Entwicklung hatten wir keinerlei Probleme mit der eingesetzten Software und unser Projekt wurde mit dem aktuellen Flash-Plugin auf UNIX, Mac OSX und Microsoft Windows, ohne Probleme, getestet. 142

151 5.4. Hypothese Hypothese 4 Leichtere Datenintegration in Flash, gegenüber der Umsetzung mit XML. Mit "Datenintegration" ist das Einbinden von Daten einer externen Quelle in den Flashcode gemeint. Wir vermuteten, dass dies in der neuen Umsetzung mit Flash Remoting und amfphp leichter gehen würde, als mit der XML-Umsetzung. Zuerst sehen wir uns an wie in beiden Umsetzungen die Daten aus einer externen Quelle im Flashcode vearbeitet werden. Hierfür wird der Quellcode zum Erstellen einer Kategorieliste im Außenbereich herangezogen. Beim Quellcode aus der XML-Umsetzung (Abb. 114) liegt der Fokus auf dem XML-Objekt xmlobj, wodurch auf die Daten in dem entsprechenden XML-Dokument zugegriffen wird. (1) for (var i = 2; i<= xmlobj.firstchild.firstchild.firstchild.nodevalue; i++) { (2) _root.container_mc.cont.attachmovie('kateintrag','kat'+i, 1+i); (3) _root.container_mc.cont['kat'+i]._x = 2; (4) _root.container_mc.cont['kat'+i]._y = -112+(57*i); (5) _root.container_mc.cont['kat'+i].katname = xmlobj.firstchild.childnodes[i].childnodes[1].firstchild.nodevalue; (6) _root.container_mc.cont['kat'+i].katb = xmlobj.firstchild.childnodes[i].childnodes[2].firstchild.nodevalue; (7) _root.container_mc.cont['kat'+i].katid = xmlobj.firstchild.childnodes[i].firstchild.firstchild.nodevalue; (8) _root.container_mc.cont['kat'+i].position = i-2; (9) [...] (10) } Abbildung 114: Teil der ListCategory Klasse, alte Umsetzung Der Quellcode aus der neuen Umsetzung (Abb. 115) unterscheidet sich zum Einen im Zugriff auf den Ziel MovieClip, da mit dynamischen Pfaden gearbeitet wurde. Dies hat aber keinen Einfluss auf den Datenzugriff. (1) for (var i = 0; i < arrelements.length; i++) { (2) eval("_level0." + strpathmovieclip).cont.attachmovie('category'+stradd,'cat'+i, eval("_level0." + strpathmovieclip).cont.getnexthighestdepth()); (3) eval("_level0." + strpathmovieclip).cont['cat'+i]._x = 2; (4) eval("_level0." + strpathmovieclip).cont['cat'+i]._y = (numheight*i); (5) eval("_level0." + strpathmovieclip).cont['cat'+i].catname = arrelements[i].getcat(); (6) eval("_level0." + strpathmovieclip).cont['cat'+i].catdesc = arrelements[i].getcatdescription(); (7) eval("_level0." + strpathmovieclip).cont['cat'+i].numcatid = arrelements[i].getcatid(); (8) eval("_level0." + strpathmovieclip).cont['cat'+i].numlistpos = i; (9) [...] (10) } Abbildung 115: Teil der ListCategory Klasse, neue Umsetzung Zum Anderen unterscheidet sich der Quellcode durch seinen direkten Zugriff auf die nötigen Daten. Während bei der alten Umsetzung ein XML-Dokument geladen werden muss, um sich durch dessen Baum zu arbeiten und an die richtigen Daten zu gelangen, kann man in 143

152 5.4. Hypothese 4 der neuen Umsetzungen direkt auf das übergebene RecordSet und seine Daten zugreifen. Dieser Zugriff erfolgt allerdings schon in der Category-Klasse (Abb. 116), denn für jeden Eintrag in dem RecordSet wird ein Category-Objekt erzeugt und mit Daten gefüllt. Dieses wird im Array arreelements gespeichert. Die Wertübergabe erfolgt durch Aufruf einer Methode im Category-Objekt, die jenen Wert zurückgibt. (1) public function Category(reResultObject:Object) { (2) strcat = reresultobject.chrcatname; (3) numcatid = reresultobject.intcatid; (4) strcatdescription = reresultobject.chrcatdescription; (5) numprocount = reresultobject.intprocount; (6) [...] (7) } Abbildung 116: Teil der Category Klasse Wie man deutlich sieht, erfolgt der Zugriff direkt über die Bezeichnung des Feldes, wogegen der Zugriff auf einen Knoten im XML-Baum kompliziert anmutet und je nach Struktur sehr lange Pfade mit sich bringt. Auswertung Dieser viel kürzere Zugriff ist nicht nur übersichtlicher, sondern lässt direkt erkennen, um welchen Datentyp es sich handelt und welche spezielle Date in diesem Feld steckt. Dies erleichtert den Entwicklungsprozess ungemein, da man nicht jedes XML-Dokument durchsuchen muss, um die richtigen Daten zu finden und den Pfad zu entwickeln. Bei der neuen Umsetzung mit FlashRemoting und amfphp unterscheiden sich die Wertübergaben, je nachdem ob auf ein RecordSet, ein Array oder einen einfachen Rückgabewert zugegriffen wird, nur geringfügig voneinander. Für alle bleiben jedoch die Vorteile in der Kürze und der Lesbarkeit gegenüber der XML-Umsetzung. Abschließend sei noch erwähnt, dass sich in der vorherigen Implementierung die Struktur der XML-Dokumente nicht ändern darf. Soblad sie einen anderen Aufbau besitzen, als den zuvor festgelegten, können die jeweiligen Daten nicht mehr gefunden werden, da die Pfade zu den Knoten nicht mehr zutreffend sind. Diese Abhängigkeit von der passenden Struktur ist ein weiterer Nachteil der alten Umsetzung. 144

153 5.5. Hypothese Hypothese 5 Das Risiko in der Programmierung Fehler zu erzeugen, ist in der neuen Umsetzung geringer. Es gibt viele mögliche Fehlerquellen, die einem bei der Entwicklung begegnen können. Doch kann die Benutzung einer anderen Technologie dazu führen, dass die Entwicklung des gleichen Systems mit weniger Fehlern, bzw. einer geringeren Chance Fehler zu machen, abläuft? Hierzu sollten wir uns Schritt für Schritt den Ablauf beider Kommunikationen und ihre Datenverarbeitung ansehen, um darüber urteilen zu können. Kommunikation im Allgemeinen Wenn man sich den Kommunikationsprozess vom Stellen der Anfrage bis zum Auswerten der Antwort betrachtet, erkennt man, dass sich die Umsetzungen bereits hierin unterscheiden. In der neuen Umsetzung (Abb. 117) sind folgende vier Schritte nötig, um ein Ergebnis anzuzeigen: Anfrage senden, Anfrage verarbeiten und Antwort senden, Antwort empfangen, sowie Antwort auswerten. Die XML-Umsetzung (Abb. 118) umfasst dagegen zwei Abbildung 117: Ablauf der neuen Umsetzung zusätzliche Schritte. Bei ihr sieht der Ablauf wie folgt aus: Anfrage senden, Anfrage verarbeiten und Rückgabewert senden, Rückgabewert empfangen, XML-Dokument laden, Ladeerfolg prüfen, sowie XML-Dokument auswerten. Abbildung 118: Ablauf der vorherigen Umsetzung Es ist augenscheinlich, dass mit zusätzlichen Schritten auch zusätzliche Fehlerquellen entstehen. Betrachten wir nun die einzelnen Schritte, wobei wir uns am Ablauf der neuen Umsetzung orientieren. 145

154 5.5. Hypothese 5 Anfrage senden Zuerst betrachten wir das Senden der Anfrage. In der alten Umsetzung müssen zwei Objekte vom Typ LoadVars erstellt werden. In dem einen Objekt werden die nötigen Parameter gespeichert (Sendeobjekt). Dem anderen Objekt wird die Funktion übergeben, die ausgeführt wird, wenn der Sendevorgang erfolgreich war und die URL, welche mit Hilfe das Sendeobjektes erzeugt und aufgerufen wurde, geladen werden konnte (Ladeobjekt). In der neuen Umsetzung muss ein Service-Objekt erzeugt werden, in dem die URL zum Remote Gateway angegeben werden muss. Danach wird der Remote Service gestartet und die Rückgabe an ein PendingCall-Objekt gegeben. Diesem wird ein RelayResponder-Objekt der Eigenschaft responder zugewiesen, in dem geregelt wird, welche Methoden im Erfolgsoder Fehlerfall ausgeführt werden. In den Aufrufen unterscheiden sich die beiden Umsetzung nicht, was ihre Fehleranfälligkeit anbelangt, da beide eine URL benötigen, an die eine Anfrage geschickt, bzw. die aufgerufen werden soll. Beide Umsetzungen rufen einen Service auf. In der alten Umsetzung wurde dies in der aufzurufenden URL kodiert, in der neuen wurde direkt die Methode aufgerufen, die ausgeführt werden soll. Prinzipiell ist die neue Umsetzung leichter nachvollziehbar und funktioniert direkter, da das aufgerufene PHP-Script nicht erst prüfen muss, welche Parameter mit der URL übergeben wurden, sondern gezielt nur die Methode gestartet wurde, welche auch benötigt wird. Anfrage verarbeiten, Antwort erstellen und senden In beiden Umsetzungen werden die benötigten Daten aus der MySQL-Datenbank geholt. Die neue Umsetzung gibt das Ergebnis der Query entweder direkt zurück oder fügt die Daten in ein Array, welches dem aufrufenden Service zurückgegeben wird. In der alten Umsetzung muss ein XML-Dokument mit den erhaltenen Daten erstellt werden. Hierbei können mehr Fehler (insbesondere Tippfehler) gemacht werden, als in der neuen Umsetzung. Diese Fehler sind teilweise schwer zu finden, da unter Umständen keine Fehlermeldungen erzeugt werden. Während die Daten der neuen Umsetzung bereits zurückgegeben wurden, ohne sonderlich verarbeitet zu werden, muss in der alten Umsetzung nach dem erfolgreichen Erzeugen eines XML-Dokuments ein Rückgabewert an den Browser gegeben werden, damit der Flashfilm und das Ladeobjekt erkennen, dass ein neues XML-Dokument vorliegt oder ein Fehler aufgetreten ist. Antwort empfangen Hierin liegt eine weitere Fehlerquelle in der alten Umsetzung. Wenn diese Ausgabe an den Browser fehlschlägt oder fehlerhaft ist (z. B. wenn PHP-Warnungen ausgegeben werden), 146

155 5.5. Hypothese 5 dann registriert Flash den Fehler zwar, doch wird keine Meldung ausgegeben und die Suche nach der möglichen Quelle gestaltet sich sehr schwierig. Ein kleiner Fehler im PHP-Code reicht aus, um die gesamt Anwendung zu stoppen. Wir hatten unter anderem das Problem, dass eine Leerzeile zu Beginn des PHP-Scriptes dazu führte, dass die gesamte Kommunikation fehl schlug, obwohl die nötige Ausgabe scheinbar erfolgte. Sie wurde nur von Flash nicht erkannt. Solche Probleme können einem mit Flash Remoting und amfphp nicht widerfahren. Sollte hier ein Fehler in der Kommunikation auftreten, gibt die Servicefunktion ein FaultEventObjekt zurück und die Methode für den Fehlerfall wird ausgeführt, welche die entsprechende Fehlermeldung zurück gibt. Sollte die Kommunikation erfolgreich sein, aber ein anderer Fehler auftreten, wie der Aufruf einer falschen Service-Methode, fehlende Parameter, SQLFehler usw. wird einem dieses im NetConnection Debugger66 angezeigt. Im Erfolgsfall muss in der alten Umsetzung ein XML-Dokument geladen werden. Hierin liegen weitere Fehlerquellen, wie Tippfehler beim Aufruf, wodurch das richtige Dokument nicht gefunden werden kann oder generelle Fehler beim Laden des Dokuments. Außerdem kann es passieren, dass der Dateiname durch das PHP-Script nicht richtig erstellt wurde, wodurch das Dokument von Flash ebenfalls nicht gefunden werden kann. Erst wenn das XML-Dokument gefunden und geladen wurde, wird die Methode gestartet, die das Ergebnis verarbeitet. Dieser zusätzliche Ladeprozess entfällt in der neuen Umsetzung völlig, denn hier wird das Ergebnis des Services direkt an die Methode übergeben, die es verarbeiten soll. Diese Methode wird auch nur dann aufgerufen, wenn keine Fehler in der Kommunikation auftraten. Dadurch kann das ResultEvent-Objekt, welches übergeben wurde und das Ergebnis enthält, direkt verwendet werden. Wenn einfache Rückgabewerte an Flash gegeben werden, muss jedoch in dieser ResultMethode geprüft werden, für welches Ergebnis der Wert steht, da auch ein negatives Ergebnis (inhaltlicher "Fehler") vorkommen kann. In der alten Umsetzung erfolgt dies ähnlich, nur dass kein XML-Dokument erzeugt wurde. Der Rückgabewert von PHP an den Browser zeigt dann an, welcher inhaltlicher Fehler vorliegt. Antwort auswerten Wie wir bereits in der vorigen These erkennen konnten, ist der Zugriff auf die nötigen Daten in der neuen Umsetzung direkter und sorgt mit seiner besseren Lesbarkeit für weniger Fehlerquellen. Besonders der umständliche Zugriff auf die Knoten des XML-Baumes sorgten in der alten Umsetzung häufig für Probleme. 66 Vgl. LiveDocs zum NetConnection Debugger: 147

156 5.5. Hypothese 5 Auswertung Alles in allem kann die Frage, ob die Entwicklung eines Systems mit einer anderen Technologie zu einer geringeren Fehlerchance führen kann, in unserem Fall mit einem klaren "Ja" beantworten. Während der Entwicklung mit Flash Remoting und amfphp traten viel weniger Probleme bei der Datenanforderung, Datensendung und Datenverarbeitung auf, als es bei der XML-Umsetzung der Fall war. Des Weiteren mussten wir viel weniger Zeit in die Fehlersuche investieren. 148

157 5.6. Hypothese Hypothese 6 Unterstützung bei der Analyse von Fehlern in der Kommunikation. Inwiefern kann uns Flash Remoting und amfphp bei der Analyse von Fehlern behilflich sein? Um diese Frage beantworten zu können, sehen wir uns an, welche Hilfsmittel bereitgestellt werden. NetConnection Debugger Ein wichtiges Werkzeug zur Fehleranalyse stellt der NetConnection Debugger dar67. Dieser wird mit der Installation der Flash Remoting Components zur Verfügung gestellt. Um ihn zu verwenden, müssen die NetConnection Debugger Klassen in den Flashfilm geladen und dieser dann initialisiert werden (Abb. 119). (1) import mx.remoting.debug.netdebug; (2) NetDebug.initialize(); Abbildung 119: NetConnection Debugger einbinden Der NetConnection Debugger wird in der Entwicklungsumgebung angewendet. Er zeigt Aufrufe und Antworten von: Flash Player Flash Remoting MX Flash Communication Server (worauf wir nicht weiter eingehen) Anwendungsserver NetConnection-Ereignisse Der NetConnection Debugger kann Daten zu vielen Ereignissen anzeigen. Welche Ereignisse angezeigt werden sollen, kann man selber festlegen. Er zeigt Daten zu Ereignissen aus drei verschiedenen Ereigniskategorien an: client, app_server und flashcomm_server, wobei jede Kategorie wiederum eine oder mehrere Ereignisarten enthält. Man kann alle Ereignisse in einer Kategorie oder einzelne Ereignisarten aktivieren bzw. deaktivieren. Diese Ereignisarten können alle im Flash Remoting MX Konfigurationshandbuch68 oder in den LiveDocs von Adobe nachgelesen werden. Verwendung in ActionScript Flash Remoting bietet mehrere Objekte und Methoden, mit deren Hilfe man die im NetConnection Debugger angezeigten Daten steuern kann. Zu diesen Werkzeugen gehören: 67 Vgl. LiveDocs zum NetConnection Debugger: 68 Vgl. 149

158 5.6. Hypothese 6 Die NetDebug.trace-Methode zur Anzeige von Trace-Meldungen im Debugger NetConnection-Objektmethoden zur Angabe von Debugging-Daten für bestimmte Verbindungen Das NetDebugConfig-Objekt zur Auswahl der vom Debugger angezeigten Daten Beispiele Im folgenden Beispiel kann man erkennen, wie die Anzeige eines aufgetretenen Fehlers im NetConnection Debugger aussieht (Abb. 120). Hierfür wurde ein falscher Service-Methodenname (catlisto) angegeben. Abbildung 120: NetConnection Debugger Anwendungsbeispiel Der Ereignistyp (Ereignisart) lautet Status und bedeutet, dass Flash Remoting eine Fehlermeldung vom Gateway erhalten hat. Die Quelle des Fehlers war der Client. Die genaue Fehlermeldung ist im Fehlerobjekt-Status zu lesen. Somit weiß der Entwickler genau, welcher Fehler auftrat. In diesem Fall meldet der Gateway, dass die aufgerufene Methode nicht deklariert wurde und demnach nicht gefunden werden kann. Es gibt natürlich noch viele andere Fehlermeldungen, die im NetConnection Debugger angezeigt werden können. Man muss jedoch beachten, dass der NetConnection Debugger nicht bei allen Problemen hilft. Fehlerhafte PHP-Scripte oder Flashteile können dazu führen, dass trotz der Fehler Daten bzw. Rückgabewerte erzeugt, übertragen und verarbeitet werden, ohne dass es der NetConnection Debugger als Fehler erkennt. Da er aber alle Daten anzeigt, die zwischen 150

159 5.6. Hypothese 6 dem Client und dem Server gesendet werden, kann man anhand derer häufig die Ursachen schnell finden. Dies ist auch der wesentliche Vorteil gegenüber der XML-Umsetzung in der man nicht ohne weiteres erkennen kann, was gesendet und empfangen wurde. DebugGateway Eine weitere Möglichkeit, Fehler ausfindig zu machen, wird von amfphp zur Verfügung gestellt. Neben der Datei gateway.php, welche den Remoting Gateway auf dem Server bereit stellt, wird auch die Datei debuggateway.php installiert69. Während der Entwicklung empfiehlt es sich auf diesen DebugGateway zu zeigen, anstatt auf den normalen Gateway. Dennoch wird dieser gebraucht, da der DebugGateway den Gateway in der gleichen Form aufruft, wie es Flash täte. Es werden Ergebnisse weitergegeben und jeder schwere Fehler aufgefangen. Diese werden dann in ein ErrorEreignis geformt, um im NetConnection Debugger gelesen werden zu können. Somit werden viel mehr Fehler im NetConnection Debugger angezeigt. Man beachte jedoch, dass die Sessionverwaltung nicht richtig arbeitet, wenn man den DebugGateway verwendet. Wenn aber die Sessionverwaltung kritisch am Problem beteiligt ist, sollte man den error log des Servers verwenden, um das Problem zu analysieren. Des Weiteren ist es wichtig, dass curl aktiviert ist, da es vom DebugGateway verwendet wird. Abschließend muss man beachten, dass der DebugGateway nur bei der Entwicklung verwendet werden sollte, da er die Antwortzeiten verlängert. Nach der Entwicklung empfiehlt es sich, wieder auf die gateway.php zu zeigen. Auswertung Mit Hilfe dieser beiden Möglichkeiten zur Fehleranalyse, welche von Flash Remoting und amfphp bereit gestellt werden, können viele Fehler und Probleme schnell identifiziert werden. Sie erleichterten uns die Arbeit und sparten wertvolle Zeit. 69 Vgl. 151

160 6. Erweiterbarkeit und Ausblick 6. Erweiterbarkeit und Ausblick Trotz der umfangreichen Implementierung fehlen noch einige Funktionen, bevor das Projektinformationssystem in eine erste Testphase gehen kann. Ihre Fertigstellung steht an erster Stelle und wird uns über die Bachelorarbeit hinaus beschäftigen. Sobald die fehlenden Funktionen implementiert sind, wird eine summative Evaluation durchgeführt,um zu prüfen, ob unsere Ideen und deren Umsetzung funktionieren. Neben den Funktionen, Abläufen und der Steuerung soll die Usability der gesamten GUI evaluiert werden. Uns liegt es am Herzen die Prozesse und die Darstellung für den Benutzer zu optimieren, um ein angenehmes Arbeiten mit dem System zu ermöglichen. Zu den fehlenden Funktionen gehören: Suchfunktion News-Bereich Bewertung von Projekten Logfunktion Datenbankadministration aus Flash heraus Alternative Kategorien und alternative Darstellung Neben diesen Funktionen gibt es noch eine Reihe von denkbaren oder wünschenswerten Erweiterungen, die vielleicht in späteren Versionen folgen: Lesezeichenfunktion für Projekte individuelle Startseite im Internen Bereich Eastereggs mehrsprachige Frontends Introfilm Benutzer der Gruppe Fakultät können Bilder zu Projekten hinzufügen druckbare Bereiche definieren weitere Metadaten (z. B. Technische Beschreibung mit Fachbegriffen, Spezifikationen,...) Papierkorbfunktion für gelöschte Projekte Hilfefunktion umfangreiche Historyfunktion für alle Handlungen des Benutzers, damit er mehrere Schritte rückgängig machen kann, bzw. weiter zurück navigieren kann Wizard zum Einstellen von Projekten Dateiupload und demnach Projekteinstellen bzw. -ändern aus Flash heraus Vertonung von Mausereignissen Videoplayer, ggf. Streaming Video (automatische Konvertierung in das Flash Video Format.flv) 152

161 6. Erweiterbarkeit und Ausblick Unser Projektinformationssystem stellt darüber hinaus die Grundlage für umfangreichere Weiterentwicklungen dar. Die dynamische Implementierung von Inhalten und die flexible Datenbankstruktur erlauben Erweiterungen, die über den Erwartungshorizont eines Informationssystem hinausgehen. Es könnten Projekte miteinander verglichen werden. Mit weiteren Metadaten und entsprechenden Dialogen wären auch Aufwandsschätzungen für Projekte möglich. Dadurch könnte eine Function-Point-Analyse oder gar ein COCOMO70Verfahren durchgeführt werden, um den Entwicklungsaufwand und die Entwicklungszeit zu schätzen. Des Weiteren könnte eine Projektbörse implementiert werden. Außerdem wäre eine Investorensuche für ausgeschriebene Projekte denkbar. Zusätzlich könnten sich potenzielle Investoren für diese Projekte bewerben. Auch das Ausschreiben von Forschungsthemen, die gesondert und individuell dargestellt würden, wäre eine interessante Erweiterung. Das Projektinformationssystem lässt viel Raum für weitere Ideen und ermöglicht auch auf lange Zeit eine Weiterentwicklung, sowie Steigerung des Funktionsumfangs. Der Kreativität sind keine Grenzen gesetzt, wenn es darum geht, den Studenten einen besseren Überblick zu verschaffen, Außenstehenden die Leistungsfähigkeit unseres Campuses zu präsentieren und Werbung für die Lehranstalt zu machen. 70 COnstructive COst MOdel - Vgl. 153

162 8. Aufgabenverteilung 8. Aufgabenverteilung Da dies Bachelorarbeit nicht von einer Person alleine geschrieben wurde, wird an dieser Stelle aufgeführt, welcher Student, was geschrieben hat. Dabei hat Andy Bucksch die Serverseite implementiert und Enriko Podehl die Clientseite. Im folgenden ist farblich dargestellt, war welche Aufgaben erledigt hat. Wurden Hauptkapitel farbig markiert, bedeutet dies, dass die einleitenden Worte von der angegebenen Person geschrieben wurden. Andy Bucksch Enriko Podehl Danksagung... Zusammenfassung... Abstract... Abkürzungsverzeichnis Einführung Motivation Thema der Bachelorarbeit Schwerpunkt der Arbeit Aufbau der Arbeit Zielgruppe Vorherige Umsetzung Vorzug für amfphp Zeitplanung Hypothesen Konzeption Abgrenzung des eigenen Produkts Die Kommunikationstechnologien unseres Projektinformationssystems Alternative Technologien Serverseitige Umsetzung ColdFusion MX Server-Side ActionScript NET Java EE AMF::Perl Gänzlich andere Umsetzungen AJAX

163 8. Aufgabenverteilung JAVA-Applets PHPObject Netzwerk der Metadaten Implementierung Refactoring Remote Procedure Call (RPC) Sessionmanagement Singleton Design Pattern Verzeichnis- und Dateistruktur Aufteilung der Bereiche Implementierung in Flash und PHP Allgemeine Betrachtungen Liste aus einem RecordSet erstellen Beschreibung Technischer Ablauf...80 Clientside Flash - Remote Call...80 Serverside PHP - Remote Service...81 Serverside PHP - Remote Method...85 Clientside Flash - Response verarbeiten Liste aus einem Array erstellen Beschreibung Technischer Ablauf...91 Clientside Flash - Remote Call...91 Serverside PHP - Remote Service...93 Clientside Flash - Response verarbeiten RecordSet mit einem Datensatz Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Einfache Rückgabewerte Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Konkrete Anwendungsfälle

164 8. Aufgabenverteilung Projekt ansehen Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Probleme Projekt bearbeiten Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Nachrichtensystem Beschreibung Technischer Ablauf Nachrichten zählen Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Nachricht lesen Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Nachricht verschicken Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Nachricht löschen Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Login Beschreibung Technischer Ablauf Clientside Flash - Remote Call Serverside PHP - Remote Service Clientside Flash - Response verarbeiten Probleme

165 8. Aufgabenverteilung Serverseitige Probleme mit MySQL und PHP Verwendete Technologien und Hardware Thesendiskussion Hypothese Hypothese Hypothese Hypothese Hypothese Hypothese Erweiterbarkeit und Ausblick Aufgabenverteilung Erklärung Literaturverzeichnis Glossar Anhang A. UML-Diagramme B. Gantt-Diagramm mit Meilensteinplanung C. Persönliches Nachwort Andy Bucksch Enriko Podehl D. Programmdateien des Projektinformationssystems

166 9. Erklärung 9. Erklärung Hiermit versichern wir, dass wir die vorliegende Arbeit selbständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt haben. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder nicht veröffentlichten Schriften entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer anderen Prüfung noch nicht vorgelegt worden. Köln, den (Andy Bucksch)... (Enriko Podehl) 158

167 Literaturverzeichnis Literaturverzeichnis [1] PRIESBACH, Stefan: Long Live the Code!. In: php architect, Volume 5 - Issue 6, Toronto, 2006, S. 18. [2] KRÜGER, Guido: Handbuch der Java Programmierung. München : ADDISONWESLEY, [3] DUBOIS, Paul: MySQL Cookbook. Sebastopol : O'Reilly, [4] REESE, George: MySQL Pocket Reference. Sebastopol : O'Reilly, [5] MUCK, Tom: Flash Remoting: The Definitive Guide. Sebastopol : O'Reilly, [6] LOTT, Joey: Complete Flash Remoting MX. Indianapolis : Wiley Publishing, Inc., [7] MOOCK, Colin, Essential ActionScript 2.0. Sebastopol : O'Reilly, [8] BLACHE, Alexander; BUCKSCH, Andy; PODEHL, Enriko: Studentisches Projektverwaltungssystem. Köln, Fachhochschule, Fachbereich 10, Institutsbericht, noch nicht erschienen. Mit der Abgabe der Bachelorarbeit wurden alle enthaltenen Links auf Aktualität überprüft. (Stand ) 159

168 Literaturverzeichnis Abbildungsverzeichnis Abbildung 1: Kommunikation des Projektinformationssystems...4 Abbildung 2: Aufbau eines CMS...12 Abbildung 3: Funktionsumfang unseres Systems...13 Abbildung 4: Flash Remoting Architektur...15 Abbildung 5: MVC-Modell in Flash Remoting...17 Abbildung 6: Kommunikation mittels AMF...19 Abbildung 7: n-tier Architektur...21 Abbildung 8: Kommunikationsablauf...23 Abbildung 9: Kommunikation zwischen Flash und ColdFusion...30 Abbildung 10: Kommunikation von.net und ASP.NET...37 Abbildung 11: Aufbau und Funktion einer.net-anwendung...38 Abbildung 12: Aufbau und Kommunikation von Flash und J2EE...42 Abbildung 13: Vergleich einer klassischen- mit eine AJAX-Anwendung...49 Abbildung 14: Asynchrone Kommunikation einer AJAX-Anwendung...50 Abbildung 15: Ableitungsbaum der Appletklasse...54 Abbildung 16: Kommunikation mit anderen Anwendungen über Sockets...55 Abbildung 17: Kommunikation zwischen zwei Applets...55 Abbildung 18: Kommunikation zwischen Applet und Internetbrowser...56 Abbildung 19: Netzwerk der Metadaten...61 Abbildung 20: synchroner und asynchroner RPC...68 Abbildung 21: Quellcode - Auszug, ListProject Klasse...71 Abbildung 22: Quellcode - Auszug, Flashfilm...71 Abbildung 23: Verzeichnisstruktur des Projektinformationssystems...73 Abbildung 24: Aufteilung der Bereiche...74 Abbildung 25: Kategorieliste, Außenbereich...74 Abbildung 26: Pro. ansehen, Außenbereich...74 Abbildung 27: Kategorieliste, Intern...75 Abbildung 28: Pro. ansehen, Intern...75 Abbildung 29: Quellcode - Aufruf im Flashfilm, Bild: StartContent...79 Abbildung 30: Quellcode - Aufruf im Flashfilm, Bild: StartContent...79 Abbildung 31: Quellcode - Teil der ListCategory Klasse...80 Abbildung 32: Quellcode - Aufruf im Flashfilm, Bild: StartContent...80 Abbildung 33: Quellcode - Teil der ListCategory Klasse...80 Abbildung 34: Quellcode - Teil der ListCategory Klasse...80 Abbildung 35: Quellcode - Teil der ListCategory Klasse...80 Abbildung 36: Quellcode - Aufbau eines amphp Services

169 Literaturverzeichnis Abbildung 37: Quellcode - Erforderliche Klassen der methodtable()...82 Abbildung 38: Quellcode - Automatisches erzeugen einer methodtable()...82 Abbildung 39: Quellcode - javadoc Kommentare in amfphp...82 Abbildung 40: Verbindung mit dem amfphp - Gateway...83 Abbildung 41: Aufruf einer amfphp - Funktion...83 Abbildung 42: Übergabe der PHP Sessionid...84 Abbildung 43: Rückgabewerte einer Funktion...84 Abbildung 44: Quellcode - Aufbau der Kategorieliste...85 Abbildung 45: Quellcode - Aufruf in der ListCategory Klasse...86 Abbildung 46: Quellcode - Teil der ListCategory Klasse...87 Abbildung 47: Quellcode - Teil der ListCategory Klasse...88 Abbildung 48: Quellcode - Teil der Category Klasse...89 Abbildung 49: Kategorieliste im Außenbereich...89 Abbildung 50: Quellcode - Teil der ListCategory Klasse...90 Abbildung 51: Quellcode - Event eines Category-Listenelements...92 Abbildung 52: Quellcode - Teil der ListCategory Klasse...92 Abbildung 53: Quellcode - Aufruf im Flashfilm, Bild: StartContent...92 Abbildung 54: Quellcode - Aufruf im Flashfilm, Bild: StartContent...92 Abbildung 55: Quellcode - Teil der ListProject Klasse...93 Abbildung 56: Quellcode Aufbau der Projektliste einer Kategorie...94 Abbildung 57: Quellcode - Projekttechnologien einem Array hinzufügen - Teil Abbildung 58: Projekttechnologien einem Array hinzufügen - Teil Abbildung 59: Projekttechnologien einem Array hinzufügen - Teil Abbildung 60: Quellcode - Teil der ListProject Klasse...97 Abbildung 61: Quellcode - Teil der Project Klasse...98 Abbildung 62: Quellcode - Teil der ListProject Klasse...98 Abbildung 63: Projektliste zur Kategorie Medieninformatik im Außenbereich...99 Abbildung 64: Benutzerliste Abbildung 65: Eigenes Profil Abbildung 66: Quellcode - Teil der User Klasse Abbildung 67: Quellcode - Benutzerdaten vervollständigen Abbildung 68: Quellcode - Teil der User Klasse Abbildung 69: Benutzer sperren Abbildung 70: Quellcode - Teil der User Klasse Abbildung 71: Quellcode - Benutzer sperren Abbildung 72: Quellcode - Teil der User Klasse Abbildung 73: Quellcode - Teil der User Klasse Abbildung 74: Quellcode - Teil der Project Klasse

170 Literaturverzeichnis Abbildung 75: Quellcode -Projektdaten vervollständigen Abbildung 76: Quellcode - Teil der Project Klasse Abbildung 77: Quellcode - Aufruf im Flashfilm, Bild: ProContent Abbildung 78: Quellcode - Teil der Project Klasse Abbildung 79: Projektdaten ansehen Abbildung 80: Ausschnitt: Daten bearbeiten Abbildung 81: Ausschnitt: Medien bearbeiten Abbildung 82: Projekt bearbeiten Abbildung 83: Quellcode - Event der bearbeiten-schaltfläche Abbildung 84: Quellcode des dynamischen Aufbaus der Technologie-Checkboxen Abbildung 85: Quellcode - Inkludieren von checkinput.php Abbildung 86: Quellcode - Zwischenspeichern der Formulardaten Abbildung 87: Quellcode - Speichern von Medien in einem Array (Bsp. Bilder) Abbildung 88: Quellcode Struktur des Medienuploads Abbildung 89: Quellcode - Upload der Bilder Abbildung 90: Quellcode- Eintragen der Projektdaten in die Datenbank Abbildung 91: Übersicht Abbildung 92: Quellcode - Aufruf im Flashfilm, Bild: InternPreContent Abbildung 93: Quellcode - Teil der User Klasse Abbildung 94: Quellcode- Übersicht empfangene / neue Nachrichten Abbildung 95: Liste empfangener Nachrichten Abbildung 96: Quellcode - Teil der Message Klasse Abbildung 97: Quellcode- Nachrichtentext holen / Nachricht als gelesen markieren Abbildung 98: Quellcode - Teil der Message Klasse Abbildung 99: Nachrichten Menü Abbildung 100: Nachricht verfassen Abbildung 101: Quellcode - Teil der Message Klasse Abbildung 102: Quellcode - Nachricht senden Abbildung 103: Nachricht löschen Abbildung 104: Quellcode - Event der löschen-schaltfläche Abbildung 105: Quellcode - Teil der Message Klasse Abbildung 106: Quellcode - Nachricht löschen Abbildung 107: Anmeldung am System Abbildung 108: Benutzerprofil vervollständigen Abbildung 109: Quellcode - Teil der ActionScript Datei functions.as Abbildung 110: Quellcode Benutzerauthentifizierung Abbildung 111: Quellcode - Überprüfung einer FH-Kennung + Datenbankeintrag Abbildung 112: Test 1, catlist()

171 Literaturverzeichnis Abbildung 113: Test 2, catlistpro() Abbildung 114: Teil der ListCategory Klasse, alte Umsetzung Abbildung 115: Teil der ListCategory Klasse, neue Umsetzung Abbildung 116: Teil der Category Klasse Abbildung 117: Ablauf der neuen Umsetzung Abbildung 118: Ablauf der vorherigen Umsetzung Abbildung 119: NetConnection Debugger einbinden Abbildung 120: NetConnection Debugger Anwendungsbeispiel Abbildung 121: Sequenzdiagramm zur Kategorieliste Abbildung 122: Anwendungsfalldiagramm zum Nachrichtensystem Abbildung 123: Flash Klassendiagramm Abbildung 124: Gantt-Diagramm - Teil Abbildung 125: Gantt-Diagramm - Teil

172 Glossar Glossar Anwendungslogik / Anwendungsschicht Ist der mittlere Teil einer dreischichtigen Anwendungsarchitektur (Three-Tier), welche die eigentliche Programmlogik enthält. Application Server Bezeichnet einen Netzwerkserver, auf dem Anwendungsprogramme laufen. Benutzer Benutzer: Ein Mensch, der mit dem Dialogsystem arbeitet. [ISO : 1998, Definition 2.2] Cascading Style Sheets (CSS) Ist eine Ergänzungssprache, um, im speziellen HTML, besser zu strukturieren und formatieren. Content-Type Anhand des Content-Types ist zu erkennen, von welchem Typ übertragene Daten sind. Ein Webbrowser erkennt durch den Content-Typte zum Beispiel, ob es sich bei den gesendeten Daten um Bilder oder Webseiten handelt. Cookies Cookies sind Textdateien, die von Webseiten, auf einem Webclient abgelegt werden können, um Daten zu speichern. (z.b. das Datum des letzten Besuchs) Dialog Eine Interaktion (Kommunikation) zwischen einem Benutzer und einem Dialogsystem, um ein bestimmtes Ziel zu erreichen. ECMAScript Eine andere Bezeichnung für JavaScipt. Wurde durch die ECMA international 71 standardisiert. 71 Vgl. 164

173 Glossar Enterprise-Systeme Beschreibt ein Software, welche auf den Einsatz in großen Unternehmen zugeschnitten ist. Evaluation Evaluation bezeichnet die Ermittlung von Daten über usability eines SystemEntwurfes durch bestimmte Probanden für bestimmte Aktivitäten in einem bestimmten Kontext in Richtung einer bestimmten Zielsetzung. Framework In der Regel gibt eine Framework eine Anwendungsarchitektur vor und ist somit eine Art Gerüst, unter anderem, in der objektorientierten Softwareentwicklung. Gateway Ein Gateway erlaubt es verschiedenen Rechnern/Netzwerken, die unterschiedliche Protokolle verwenden, miteinander zu kommunizieren. Hypertext Markup Language (HTML) Ist eine Sprache zur Erstellung von Hypertextdokumenten und wurde 1989 von Tim Berners-Lee am CERN in Genf festgelegt. Inline-code Hierbei handelt es sich um eine Methode die Ausführungszeit von kompilierten Programmiersprachen zu verringern. Dabei werden unnötige Funktionsaufrufe vermieden indem der Compiler, den Code dieser Funktion direkt an die passende Stelle kopiert. Es entfällt also der eigentliche Funktionsaufruf. Interaktives System Die Kombination von Hardware- und Softwarekomponenten, die Eingaben von einem/r Benutzer/in empfangen und Ausgaben von einem/r Benutzer/in übermitteln, um ihn/sie bei der Ausführung einer Arbeitsaufgabe zu unterstützen. Interface Ist eine Schnittstelle, die Teil eines Systems ist, um Daten auszutauschen. MVC-Modell MVC bezeichnet ein Architekturmuster zur Aufteilung von Softwaresystemen in drei Bereiche: Datenmodell (Model), Präsentation (View) und Programmsteuerung 165

174 Glossar (Controller). Ziele dieses Musters sind: Leichte Wiederverwendbarkeit, flexibles Programmdesign und Strukturierung der Anwendung. N-Tier Beschreibt eine Form der Anwendungslogik. Dabei steht das n für die Anzahl der beteiligten Schichten. Die häufigste Form ist die Three-Tier-Architektur, bei der es demzufolge drei Schichten gibt. (Speicherschicht, Anwendungsschicht, Präsentationsschicht) Nutzungskontext Die Benutzer, Arbeitsaufgaben, Arbeitsmittel (Hardware, Software und Materialien) sowie die physische und soziale Umgebung, in der das Produkt genutzt wird. [ISO : 1998, Definition 3.5] Open Source Es bedeutet Quelloffenheit und sagt, dass zu einer Software auch dessen Quelltext frei zugänglich ist. So hat jeder die Möglichkeit selbst Änderungen daran vorzunehmen72. pageable recordset Hierbei wird ein RecordSet nicht als Ganzes, sondern seitenweise übertragen. pagesize Gibt die Größe eines pageable recordsets an. pattern-based Bezeichnet in der Softwareentwicklung, dass der Programmcode auf Entwurfsmustern (engl. Pattern) basiert. Präprozessor Ein Computerprogramm, welches den übergebenen Text in einen anderen umwandelt. Dies passiert meist bei Quellcode, bevor dieser an den Compiler weitergegeben wird. Präsentationsschicht Ist der äußerste Teil einer dreischichtigen Anwendungsarchitektur (Three-Tier), welche für die Anzeige der Daten zuständig ist. 72 Vgl. 166

175 Glossar Projekt Ein Projekt ist gemäß DIN ein komplexes Vorhaben, das durch folgende Kriterien gekennzeichnet ist: Beschreibung der Aufgabe Vorgabe von klaren Projektzielen Personelle, sachliche, finanzielle und zeitliche Abgrenzung Beteiligung mehrerer Unternehmensbereiche, die in einer projektspezifischen Organisation zusammengefasst werden Einmaligkeit der Bedingungen Projektinformationssystem Bezeichnet ein System zur Darstellung von projektspezifischen Daten und Medien, sowie zur Auflistung von Projekten nach unterschiedlichen Kriterien. Die enthaltenen Projekte können den Zustand ausgeschrieben, in Bearbeitung, abgeschlossen oder weiterführbar annehmen. Prototyp Die Darstellung der Gesamtheit oder eines Teils eines Produkts oder Systems, welche, gegebenenfalls mit Einschränkung, für eine Beurteilung verwendet werden kann. [ISO : 1999, Definition 2.2] Serialisation Mit Serialisation ist die Umformung von Daten in ein Format gemeint, welches leicht über das Web transportiert werden kann. Summative Evaluation Die summative Evaluation (resümierende Evaluation) dient zur abschließenden Bewertung eines Systems. Sie wird üblicherweise nach dem Designprozess eines Projekts durchgeführt. Struct Ein aus verschiedenen Typen zusammengesetzter neuer Datentyp. Stub Bezeichnet einen Programmcode, der anstelle eines anderen Programmcodes steht. Ein Stub steht dabei für den Stellvertretenden Programmcode. 167

176 Glossar System Als System bezeichnen wir eine willkürlich abgegrenzte Gesamtheit von Elementen, die zueinander, zum Ganzen und in der Regel auch zur Umwelt in Beziehung stehen. Web Service / Webdienst Ist eine Software-Anwendung, die anderen Anwendungen über passende Schnittstellen Daten zur Weiterverarbeitung zur Verfügung stellt. wrappen Bezeichnet das Ausführen eines umschlossenen Programmcodebereichs, der auch in einer anderen Programmiersprache geschrieben worden sein kann. zustandsloses Protokoll Im Zusammenhang mit HTML bedeutet dies, dass keine Daten zum Client auf dem Server gespeichert werden. 168

177 Anhang Anhang Der Anhang stellt einige zusätzliche Informationen bereit, welche die Ausführungen im Hauptteil ergänzen. Anhang A umfasst drei UML-Diagramme. Kommunikationsablauf zwischen Flash Das Sequentdiagramm beschreibt den Remoting und amfphp am Beispiel einer Kategorieliste. Das Anwendungsfalldiagramm stellt die möglichen Anwendungsfälle zum Nachrichtensystem dar. Das Klassendiagramm stellt die in Flash verwendeten Klassen dar und wie sie zueinander in Beziehung stehen. Anhang B beinhaltet ein Gantt-Diagramm mit Meilensteinplanung. Dieses Diagramm stellt unseren Zeitplan grafisch dar und zeigt sowohl die Phasen, als auch die einzelnen Aktivitäten auf. Im Anhang C befindet sich ein persönliches Nachwort von Andy Bucksch und Enriko Podehl. Anhang D enthält eine DVD, welche die Programmdateien des Projektinformationssystems beinhaltet. A UML-Diagramme Dieser Anhang umfasst UML-Diagramme73, welche einige zuvor beschriebene Zusammenhänge grafisch darstellen, um die textuelle Beschreibung zu ergänzen. A.1. Sequenzdiagramm In diesem Sequenzdiagramm (Abb. 121) ist der Ablauf zum Erstellen einer Kategorieliste dargestellt. Das besondere Augenmerk liegt hier auf der Kommunikation der Flash Remoting Components mit dem amfphp-service ProInf. Beginnend mit dem Starten des Flashfilms Frontend durch den Benutzer, über den RemoteCall, bis hin zum Erstellen der Category-Objekte und entsprechenden Listenelemente wird der gesamte Weg verfolgt, bis die Liste ausgegeben und demnach der erste Inhalt in den Flashfilm geladen wurde. Dieses Diagramm visualisiert die Beschreibung aus Kapitel und steht repräsentativ für alle Kommunikationsabläufe von Flash Remoting und amfphp, denn der generelle Ablauf, unabhängig von den spezifischen Objekten, ist bei allen gleich. 73 Vgl. 169

178 A.1. Sequenzdiagramm Abbildung 121: Sequenzdiagramm zur Kategorieliste 170

179 A.2. Anwendungsfalldiagramm A.2. Anwendungsfalldiagramm Dieses Anwendungsfalldiagramm (Abb. 122) stellt alle Anwendungsfälle zum Nachrichtensystem dar. Die Anwendungsfälle "empfangene Nachricht lesen", "gesendete Nachricht lesen" und "Nachricht schreiben" sind direkt für den Benutzer erreichbar. Der Anwendungsfall auswählen", um sich "gesendete eine Nachricht verstimmte lesen" Nachricht erfordert "gesendete anzusehen. Er kann Nachricht um die Anwendungsfälle "Nachricht löschen" und "Nachricht weiterleiten" erweitert werden. "Nachricht weiterleiten" erfordert "Nachricht schreiben" für die generelle Funktion zum Schreiben von Nachrichten. In diesem Fall ist der Betreff und die alte Nachricht schon enthalten. Beim Anwendungsfall "Nachricht schreiben" sind jedoch alle Felder leer. Dieser kann auch für sich gewählt werden. Der Anwendungsfall "empfangene Nachricht lesen" ähnelt dem Anwendungsfall "gesendete Nachricht lesen" kann jedoch um den Anwendungsfall "Nachricht beantworten" erweitert werden. Dieser erfordert ebenfalls den Anwendungsfall "Nachricht schreiben" und setzt neben dem Text und dem Betreff auch den Empfänger. Dieses Diagramm ergänzt die Beschreibung aus Kapitel Abbildung 122: Anwendungsfalldiagramm zum Nachrichtensystem 171

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Dynamische Webseiten

Dynamische Webseiten Dynamische Webseiten Seminar Medientechnik 30.06.2003 Dynamische Webseiten 1 Inhalt Allgemeine Funktionsweise eines Webservers Grundgedanke von dynamischen Webseiten Einschub: Dynamische Seitenerzeugung

Mehr

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht.

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht. Technisches Design Inhalt Design Übersicht Menü und DispatcherServlet DWR Servlet Viewer Servlets Controllers Managers Sicherheit Anwendung Architektur Component Diagram Deployment Diagram Komponente Sequence

Mehr

Sicherheit in Rich Internet Applications

Sicherheit in Rich Internet Applications Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Seite 2 Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Inhaltsverzeichnis Grundlagen Ajax und Mashups Adobe Flash-Player

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

Diplomarbeit. Planung eines Webauftritts. Ein Leitfaden für kleine und mittelständische Unternehmen. Daniel Jurischka. Bachelor + Master Publishing

Diplomarbeit. Planung eines Webauftritts. Ein Leitfaden für kleine und mittelständische Unternehmen. Daniel Jurischka. Bachelor + Master Publishing Diplomarbeit Daniel Jurischka Planung eines Webauftritts Ein Leitfaden für kleine und mittelständische Unternehmen Bachelor + Master Publishing Daniel Jurischka Planung eines Webauftritts: Ein Leitfaden

Mehr

Content Management System (CMS) / Zope / Plone. Sin Mei Mak Sebastian Plitt

Content Management System (CMS) / Zope / Plone. Sin Mei Mak Sebastian Plitt Content Management System (CMS) / Zope / Plone Sin Mei Mak Sebastian Plitt Gliederung I Motivation Definition Was ist ein Content-Management-System (CMS)? Warum CMS? Content Life Cycle Effiziente Webpublishing

Mehr

Hochschule Darmstadt Fachbereich Informatik

Hochschule Darmstadt Fachbereich Informatik Hochschule Darmstadt Fachbereich Informatik 6.3 Systemarchitektur 430 6.3 Systemarchitektur Drei Schichten Architektur Die "Standardtechniken" des Software-Engineering sind auch auf die Architektur einer

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Web-Programmierung (WPR)

Web-Programmierung (WPR) Web-Programmierung (WPR) Vorlesung XII. Vergleich Server-Plattformen mailto:wpr@gruner.org 1 Technologien Perl/CGI Einsatzgebiete: Kleine Websites, semiprofessioneller Bereich Pro's: Plattform/Serverneutralität

Mehr

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13 NEWpixi* API und die Umstellung auf REST Fakten NEWpixi* API Technik REST-basierend.NET Webservice IIS Webserver Release 31. August 2013, zusammen mit dem NEWpixi* ELI Release Legacy API und erste NEWpixi*

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

Klausur Verteilte Systeme

Klausur Verteilte Systeme Klausur Verteilte Systeme SS 2005 by Prof. Walter Kriha Klausur Verteilte Systeme: SS 2005 by Prof. Walter Kriha Note Bitte ausfüllen (Fill in please): Vorname: Nachname: Matrikelnummer: Studiengang: Table

Mehr

Ruby on Rails. Florian Ferrano Ralf Heller Markus Nagel

Ruby on Rails. Florian Ferrano Ralf Heller Markus Nagel Ruby on Rails Florian Ferrano Ralf Heller Markus Nagel Überblick Ruby on Rails Ruby Rails Geschichte MVC allgemein MVC in Rails Scaffolding Webserver Installation Beispiele Wo wird Rails verwendet? Ausblick

Mehr

Inhaltsverzeichnis. Hinweise zum Gebrauch des Buches... XIII. Teil I Grundlagen der Web-Programmierung

Inhaltsverzeichnis. Hinweise zum Gebrauch des Buches... XIII. Teil I Grundlagen der Web-Programmierung Hinweise zum Gebrauch des Buches... XIII Teil I Grundlagen der Web-Programmierung 1 Entwicklung der Web-Programmierung... 3 1.1 DerWegzumWorldWideWeb... 3 1.2 Komponenten der frühen Technik..... 5 1.3

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

Herzlich willkommen im Modul Web-Engineering

Herzlich willkommen im Modul Web-Engineering Herbst 2014 Herzlich willkommen im Modul Web-Engineering Wirtschaftsinformatik: 5. Semester Dozenten: Rainer Telesko / Martin Hüsler Fachhochschule Nordwestschweiz FHNW / Martin Hüsler und Rainer Telesko

Mehr

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Konzept eines Datenbankprototypen 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Inhalt (1) Projektvorstellung & Projektzeitplan Softwarekomponenten Detailierte Beschreibung der System Bausteine

Mehr

XPages Good to know. Benjamin Stein & Pierre Hein Stuttgart 7. Mai 2015

XPages Good to know. Benjamin Stein & Pierre Hein Stuttgart 7. Mai 2015 XPages Good to know Benjamin Stein & Pierre Hein Stuttgart 7. Mai 2015 Agenda 1. Einführung Was sind XPages? 2. Allgemeine Tipps Allgemeine Tipps für die Verwendung von XPages 3. Designer Tipps Tipps für

Mehr

Sachwortverzeichnis... 251

Sachwortverzeichnis... 251 Inhalt Vorwort... V 1 WWW World Wide Web... 1 1.1 Das Internet Infrastruktur und Administration... 2 1.2 Datenübertragung... 4 1.3 Sprachen im Web... 6 1.4 Webseiten... 7 1.4.1 Clientseitige Dynamik...

Mehr

Weborientierte Programmiersprachen am Beispiel PHP

Weborientierte Programmiersprachen am Beispiel PHP Weborientierte Programmiersprachen am Beispiel PHP Serak Rezane Seminar Programmiersprachen SS 2004 Betreuer: Prof. Dr. Claudia Leopold Dipl.-Inf. Michael Süß Was ist PHP? Gliederung (Definition, Geschichte,

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Internetanbindung von Datenbanken

Internetanbindung von Datenbanken Internetanbindung von Datenbanken Oracle Application Server Oracle Application Server - 1 Gliederung Einführung Oracle Application Server (OAS) Praxis- und Diplomarbeitenverwaltung LiveHTML Kritik Becker,

Mehr

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner Proseminar Website-Management-Systeme ZOPE/CMF Andreas M. Weiner Technische Universität Kaiserslautern Fachbereich Informatik Arbeitsgruppe Softwaretechnik Betreuer: Dipl. Inf. Christian Stenzel Überblick

Mehr

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Allgemeines 2 Produktübersicht 2 Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems 3 Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Account-Verwaltung 5 Freund-Funktionen

Mehr

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit Hochschule für Technik und Architektur Chur Dr. Bruno Studer Studienleiter NDS Telecom, FH-Dozent bruno.studer@fh-htachur.ch 1 GSM: 079/610 51 75 Agenda Vorteile von Java und Konvergenz Service Creation

Mehr

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Ein Auszug aus... Studie Content Management Systeme im Vergleich Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Die komplette Studie ist bei amazon.de käuflich zu erwerben. Inhaltsverzeichnis

Mehr

Herzlich Willkommen! eine praxisnahe Übersicht. Mit Java ins Web - mb@bebox.franken.de. 26.11.2000 (c) Michael Behrendt -

Herzlich Willkommen! eine praxisnahe Übersicht. Mit Java ins Web - mb@bebox.franken.de. 26.11.2000 (c) Michael Behrendt - Herzlich Willkommen! Mit Java ins Web - eine praxisnahe Übersicht 1 Wer bin ich? Michael Behrendt, 21, Nürnberg kurzer Lebenslauf: 1991 Erster Rechner: Commodore C128 1995 Ausbildung zum Datenverarbeitungskaufmann

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Web-Content-Management-Systeme () dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst

Mehr

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

FuE-Bereich IuK-Systeme im Gesundheitswesen

FuE-Bereich IuK-Systeme im Gesundheitswesen FuE-Bereich IuK-Systeme im Gesundheitswesen IG XML und Web Services Dipl.-Inform. Axel Schwolow IG Kommunikation im Web Entwicklung früher ausschließlich Kommunikation über Browser heute zunehmend direkt

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht

Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Eine Taxonomie und Bewertung von Cloud Computing Diensten aus Entwicklersicht Universität der Bundeswehr München Mario Golling und Michael Kretzschmar Fakultät für Informatik E-Mail: mario.golling@unibw.de

Mehr

Kurs für Microsoft Online Kurs Microsoft Analysten Programmierer

Kurs für Microsoft Online Kurs Microsoft Analysten Programmierer Kurs für Microsoft Online Kurs Microsoft Analysten Programmierer Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses für Microsoft Modul 1 Basis Programm Erste Lerneinheit Einführung

Mehr

Content-Management- Systeme (CMS) Inhaltsverwaltungssystem, Redaktionssystem

Content-Management- Systeme (CMS) Inhaltsverwaltungssystem, Redaktionssystem Content-Management- Systeme (CMS) Inhaltsverwaltungssystem, Redaktionssystem Inhalt Content Management (CM) Allgemeines über CMS CMS Typen Open Source vs. Lizenzsoftware Joomla! Quellen Content Management

Mehr

Web Adressdatenbank mit ASP

Web Adressdatenbank mit ASP Web Adressdatenbank mit ASP 1 Einleitung 1.1 Vorwort Auf den nächsten paar Seiten will ich eine kleine Anleitung geben, wie man per ASP(Active Server Pages) auf eine MS Access Datenbank zugreifen kann.

Mehr

Content Management Systeme

Content Management Systeme Content Management Systeme Ein Vergleich unter besonderer Berücksichtigung von CoreMedia und TYPO3 Bachelorthesis im Kooperativen Bachelor Studiengang Informatik (KoSI) der Fachhochschule Darmstadt University

Mehr

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2010 Ralf Gitzel ralf_gitzel@hotmail.de 1 Einführung + Organisatorisches Ralf Gitzel ralf_gitzel@hotmail.de 2 Dozent Dr. Ralf Gitzel Promotion an der Universität Mannheim in Wirtschaftsinformatik

Mehr

PHP Programmierung. Seminarunterlage. Version 1.02 vom

PHP Programmierung. Seminarunterlage. Version 1.02 vom Seminarunterlage Version: 1.02 Version 1.02 vom 27. August 2013 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen sind Warenzeichen

Mehr

Agenda. Ingo Ebel (ie007) Benjamin Müller (bm032) Was ist AJAX? Sicherheit Vor- und Nachteile. AJAX Frameworks. Wozu benötigt Client/Server

Agenda. Ingo Ebel (ie007) Benjamin Müller (bm032) Was ist AJAX? Sicherheit Vor- und Nachteile. AJAX Frameworks. Wozu benötigt Client/Server AJAX Agenda Ingo Ebel (ie007) Was ist AJAX? Wozu benötigt Client/Server Sicherheit Vor- und Nachteile Benjamin Müller (bm032) AJAX Frameworks GWT ATF Ingo Ebel - ie007 2 Web 2.0 Ingo Ebel - ie007 3 Ingo

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Android Kurs Online Kurs Entwicklung auf Android-Handys

Android Kurs Online Kurs Entwicklung auf Android-Handys Android Kurs Online Kurs Entwicklung auf Android-Handys Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses Modul Eins - Programmierung J2ee 1) Grundlegende Java - Programmierung : Grundlegende

Mehr

Einführung... 1 Anwendungsszenarien multimedialer Client-Server Systeme... 1 Aufbau des Buches... 2 Die Entwicklung des multimedialen Internets...

Einführung... 1 Anwendungsszenarien multimedialer Client-Server Systeme... 1 Aufbau des Buches... 2 Die Entwicklung des multimedialen Internets... Inhaltsverzeichnis Einführung... 1 Anwendungsszenarien multimedialer Client-Server Systeme...... 1 Aufbau des Buches..... 2 Die Entwicklung des multimedialen Internets..... 4 1 Multimediale Client-Server-Systeme...

Mehr

Proseminar Website-Management-Systeme im Wintersemester 2003/2004 AG Softwaretechnik. PHP-Nuke. PHP-Nuke. von Andreas Emrich

Proseminar Website-Management-Systeme im Wintersemester 2003/2004 AG Softwaretechnik. PHP-Nuke. PHP-Nuke. von Andreas Emrich AG Softwaretechnik 1 Übersicht 1. Grundlagen und Konzepte 2. Komponenten von 3. Erweiterungsmöglichkeiten und Personalisierung 4. Abschließende Bewertung 5. Literaturangaben 2 1. : Grundlagen und Konzepte

Mehr

Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts. Thorsten Ludewig. Juni 2004

Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts. Thorsten Ludewig. Juni 2004 METEOR Internet-basierendes Autorensystem zur Erschließung historischen Kulturguts Thorsten Ludewig Juni 2004 1 Übersicht Was ist METEOR Architektur Technische Realisierung Zusammenfassung Zukünftige Entwicklungen

Mehr

4. Verwendete Methoden und Werkzeuge

4. Verwendete Methoden und Werkzeuge 4. Verwendete Methoden und Werkzeuge In diesem Kapitel werden die verschiedenen Methoden und Werkzeuge vorgestellt, die bei der Realisierung der Mediathek eingesetzt wurden. Zuerst werden die Grundlagen

Mehr

FH LU JEE Vorlesung SS 2014. Ralf Gitzel ralf_gitzel@hotmail.de

FH LU JEE Vorlesung SS 2014. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2014 Ralf Gitzel ralf_gitzel@hotmail.de 1 Einführung + Organisatorisches Ralf Gitzel ralf_gitzel@hotmail.de 2 Dozent Dr. Ralf Gitzel Promotion an der Universität Mannheim in Wirtschaftsinformatik

Mehr

Web-Anwendungsentwicklung mit dem Delivery Server

Web-Anwendungsentwicklung mit dem Delivery Server Web-Anwendungsentwicklung mit dem Delivery Server Java-Framework auf Basis der Open API Bernfried Howe, Webertise Consulting GmbH WEBertise Consulting Dipl. Informatiker (Wirtschaftsinformatik) 2001-2010

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Systemvoraussetzungen CustomX. Customer Relationship Management

Systemvoraussetzungen CustomX. Customer Relationship Management Systemvoraussetzungen CustomX Customer Relationship Management ThinX networked business services August 2005 Inhaltsverzeichnis ThinX networked business services Inhaltsverzeichnis 1 Einleitung 3 2 Webserver

Mehr

Seminar: Web Engineering. Grundlagen von Webanwedungen. Von: Johannes Kettern Benjamin Süß

Seminar: Web Engineering. Grundlagen von Webanwedungen. Von: Johannes Kettern Benjamin Süß Seminar: Web Engineering Grundlagen von Webanwedungen Von: Johannes Kettern Benjamin Süß Inhalt Kapitel 1: Grundlagen Aufgaben von Webanwendungen Abgrenzung: Statische HTML vs. Dynamische Websites Architekturen

Mehr

Flex-ibel? In 60 Minuten zur ersten Flex-Anwendung

Flex-ibel? In 60 Minuten zur ersten Flex-Anwendung Flex-ibel? In 60 Minuten zur ersten Flex-Anwendung Kai König Softwarearchitekt msg at.net GmbH, Neuss AGENDA Einführung - Der Präsentationsserver Macromedia Flex Das Problem Die Flex-Lösung Einsatzgebiete

Mehr

Peter Sobe Internettechnologien. HTTP Protokoll (1) Hypertext Transport Protocol, größtenteils zum Austausch von Hypertext (HTML, xhtml) benutzt

Peter Sobe Internettechnologien. HTTP Protokoll (1) Hypertext Transport Protocol, größtenteils zum Austausch von Hypertext (HTML, xhtml) benutzt WWW Web basierend auf dem Internet Das Internet war bereits eher als das Web vorhanden, mit verteilten Anwendungen, Dateitransfer, Netzwerk- Dateisystemen (NFS) Web: entstanden durch Vorhandensein des

Mehr

PHP 6 Beliebte Webskriptsprache wird erwachsen. Linux User Group Bern 14.05.2009 René Moser

PHP 6 Beliebte Webskriptsprache wird erwachsen. Linux User Group Bern 14.05.2009 René Moser <mail@renemoser.net> PHP 6 Beliebte Webskriptsprache wird erwachsen Linux User Group Bern 14.05.2009 René Moser Inhalt 1.Wie entstand PHP? 2.Was PHP? 3.Warum PHP? 4.Wie installiere ich PHP? 5.Wie programmiere

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

PHP Kurs Online Kurs Analysten Programmierer Web PHP

PHP Kurs Online Kurs Analysten Programmierer Web PHP PHP Kurs Online Kurs Analysten Programmierer Web PHP Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses PHP Modul 1 - Einführung und Installation PHP-Umgebung Erste Lerneinheit Introduzione

Mehr

Ruby. Programmieren mit Zucker. Thomas Kühn

Ruby. Programmieren mit Zucker. Thomas Kühn Ruby Programmieren mit Zucker Thomas Kühn Gliederung Geschichte Philosophie Syntax mit Zucker Sprachkonzepte Pakete und Frameworks Ausblick Beispiele Yukihiro Matz Matsumoto Geboren am 14.April 1965 Geschichte

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web Service Entwicklung mit Java. Sven Lindow Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services

Mehr

Einführung in das Microsoft.NET-Framework. Programmiersprache C# MEF Das Managed Extensibility Framework. André Kunz

Einführung in das Microsoft.NET-Framework. Programmiersprache C# MEF Das Managed Extensibility Framework. André Kunz Einführung in das Microsoft.NET-Framework Programmiersprache C# MEF Das Managed Extensibility Framework André Kunz 21.09.2010 1 In dieser Einführung bekommen Sie einen kurzen Einstieg in das.net-framework

Mehr

Von der Literaturverwaltung zur Dokumentenverwaltung

Von der Literaturverwaltung zur Dokumentenverwaltung Von der Literaturverwaltung zur Dokumentenverwaltung Literaturverwaltung erfasst Metadaten über ein Dokument Dokumentenverwaltung kümmert sich um die Dokumenten-Technologien Umsetzung meist in einem Dokumentmanagementsystem

Mehr

Buzzword Bingo Game Documentation (Java based Game)

Buzzword Bingo Game Documentation (Java based Game) Buzzword Bingo Game Documentation (Java based Game) Meppe Patrick Djeufack Stella Beltran Daniel April 15, 2011 1 Inhaltsverzeichnis 1 Einleitung 3 2 Aufgabenstellung 3 3 Allgemeines zu Buzzword Bingo

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Middleware Versuch einer Einleitung Host dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Mainframe enthält vollständige Anwendung Typ. COBOL, C Mainframe contd.! Nachteile! Mainframe ist teuer

Mehr

Einfluss von Social Media auf die Suchmaschinenoptimierung mit spezieller Betrachtung von Google+

Einfluss von Social Media auf die Suchmaschinenoptimierung mit spezieller Betrachtung von Google+ Wirtschaft Lukas Peherstorfer Einfluss von Social Media auf die Suchmaschinenoptimierung mit spezieller Betrachtung von Google+ Bachelorarbeit Peherstorfer, Lukas: Einfluss von Social Media auf die Suchmaschinenoptimierung

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Browserbasiertes, kollaboratives Whiteboard

Browserbasiertes, kollaboratives Whiteboard WS 2011/12 Bachelorarbeit Browserbasiertes, kollaboratives Whiteboard Sebastian Dorn 1 von 21 Inhalt 1. Motivation 2. Analyse 3. Design 4. Evaluation 5. Fazit Inhalt 2 von 21 Motivation Zusammenarbeit

Mehr

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

3.9 Grundelemente einer Benutzeroberfläche

3.9 Grundelemente einer Benutzeroberfläche 92 3 Grundlagen einer ios-anwendung 3.8.4 Target-Actions Einer der häufigsten Anwendungsfälle bei einer Oberfläche ist das Betätigen einer Schaltfläche durch einen Anwender, woraufhin eine bestimmte Aktion

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Architekturen. DB-Anwendungen: Aufgaben. Aufteilung der Funktionen. ƒ Datenbankanwendungen

Architekturen. DB-Anwendungen: Aufgaben. Aufteilung der Funktionen. ƒ Datenbankanwendungen Architekturen ƒ Datenbankanwendungen Aufgaben und Komponenten Aufteilung ƒ Architektur Web-basierter Anwendungen HTTP-basierte Architekturen Applet-basierte Architekturen Vorlesung Internet-Datenbanken

Mehr

Business Applika-onen schnell entwickeln JVx Framework - Live!

Business Applika-onen schnell entwickeln JVx Framework - Live! Business Applika-onen schnell entwickeln JVx Framework - Live! - Enterprise Applica-on Framework h&p://www.sibvisions.com/jvx JVx ermöglicht in kürzester Zeit mit wenig Source Code hoch performante professionelle

Mehr

Mitarbeiterprofil PG0225

Mitarbeiterprofil PG0225 Kurzprofil Senior - PHP/JAVA Entwickler für Backend sowie (Web)-Frontend ist ein ideenreicher Entwickler, der komplexe Sachverhalte schnell erfasst und Softwarelösungen konzeptionell sicher und zeiteffizient

Mehr

Entwicklung und Integration mobiler Anwendungen. Oracle Deutschland B.V. & Co. KG

Entwicklung und Integration mobiler Anwendungen. <Speaker> Oracle Deutschland B.V. & Co. KG Entwicklung und Integration mobiler Anwendungen Oracle Deutschland B.V. & Co. KG Global Users (Millions) Der Trend ist eindeutig. Trend zu mobilen Endgeräten Wachstum des mobilen Datenverkehrs

Mehr

Silverstripe CMS und das Sapphire Framework

Silverstripe CMS und das Sapphire Framework Silverstripe CMS und das Sapphire Framework kurz über mich... Seit 2002 mit PHP Typo3, Wordpress, Radiant (RoR) reingeschaut: Symfony, Zend Seit 2009 Webentwicklung mit SilverStripe Geschichte von SilverStripe

Mehr

Hochschule Heilbronn Technik Wirtschaft Informatik

Hochschule Heilbronn Technik Wirtschaft Informatik Hochschule Heilbronn Technik Wirtschaft Informatik Studiengang Electronic Business (EB) Diplomarbeit (280000) Evaluierung und Einführung eines Web Content Management Systems bei einem internationalen und

Mehr

Diplomarbeit. Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems

Diplomarbeit. Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems Diplomarbeit an der Private Fernfachhochschule Darmstadt Fachbereich Informatik Die Entwicklung eines webbasierten Warenwirtschaftssystems mit dem postrelationalen Datenbanksystem Caché der Firma Intersystems

Mehr

E-Mails in einem lokalen Netzwerk senden mit einem WAGO Controller 750-842 Anwendungshinweis

E-Mails in einem lokalen Netzwerk senden mit einem WAGO Controller 750-842 Anwendungshinweis E-Mails in einem lokalen Netzwerk senden mit einem WAGO Controller 750-842, Deutsch Version 1.0.2 ii Allgemeines Copyright 2002 by WAGO Kontakttechnik GmbH Alle Rechte vorbehalten. WAGO Kontakttechnik

Mehr

Kapitel 6,»Objektorientierte Programmierung«, widmet sich der objektorientierten Programmierung mit Python.

Kapitel 6,»Objektorientierte Programmierung«, widmet sich der objektorientierten Programmierung mit Python. 1.3 Aufbau des Buchs lichkeiten offen. Auf die Unterschiede der beiden Versionen gehe ich besonders ein, sodass ein späterer Umstieg von der einen zur anderen Version leichtfällt. Erste Zusammenhänge werden

Mehr