PP_JoniWartomo-2010

Praxisprojektarbeit im Bachelorstudiengang Medieninformatik
Sommersemester 2009
Datentransfer zwischen Flex und
Drupal – Vergleich, Auswahl
und Implementierung
am Beispiel eines sozialen Netzwerks
Joni Wartomo
11051991
Erstprüfer: Prof. Christian Noss
Zweitprüfer: Prof. Dr. Horst Stenzel
Inhaltsverzeichnis
1. Einleitung...........................................................................................................................3
1.1 Problemstellung...........................................................................................................3
1.2 Ziel der Arbeit..............................................................................................................3
2. Theoretische Grundlagen..................................................................................................5
2.1 Daten...........................................................................................................................5
2.1.1 Datenquellen........................................................................................................5
2.2 Visualisierung...............................................................................................................5
2.3 Soziales Netzwerk.......................................................................................................6
3. Technische Umsetzung......................................................................................................8
3.1 Adobe Flex...................................................................................................................8
3.1.1 Warum Flex..........................................................................................................8
3.2 Drupal..........................................................................................................................9
3.2.2 Warum Drupal.......................................................................................................9
3.2.3 Die Drupal Systemarchitektur...............................................................................9
3.3 Der Datenaustausch zwischen Drupal und Flex.......................................................10
3.4 MAMP, LAMP, WAMP und XAMPP............................................................................11
4. Problemfeld und Kontext..................................................................................................12
4.1 Datenzugriff in Flex....................................................................................................12
4.1.1 HTTPService......................................................................................................12
4.1.2 WebService mit SOAP.......................................................................................12
4.1.3 RemoteObject mit AMF .....................................................................................12
4.1.4 Zusammenfassung.............................................................................................12
4.1.5 Fazit....................................................................................................................13
4.2 AMF Backend - Evaluation........................................................................................14
4.2.1 LiveCycle Data Services....................................................................................16
4.2.2 BlazeDS..............................................................................................................16
4.2.3 WebORB.............................................................................................................17
4.2.4 RED 5.................................................................................................................17
4.2.5 AMFPHP.............................................................................................................17
4.2.6 Fazit....................................................................................................................18
5. Drupal einrichten..............................................................................................................19
6. Flex RemoteObject mit AMFPHP....................................................................................20
6.1 AMFPHP und das Service-Modul einrichten.............................................................20
6.2 Flex einrichten...........................................................................................................21
6.3 Test Programm..........................................................................................................23
6.3.1 Die Oberfläche....................................................................................................23
6.3.3 Funktionen..........................................................................................................26
6.3.2 RemoteObject.....................................................................................................27
7. Fazit und Ausblick............................................................................................................28
7.1 Fazit...........................................................................................................................28
7.2 Ausblick......................................................................................................................28
Tabellenverzeichnis..............................................................................................................29
Abbildungsverzeichnis.........................................................................................................30
Glossar.................................................................................................................................31
Quellen.................................................................................................................................32
Quellcode.............................................................................................................................33
1. Einleitung
1.1 Problemstellung
Die Problemstellung dieser Arbeit ist die reibungslose und schnelle Datenübertragung
zwischen Drupal1 und Flex2.
Durch die enorme Datenmenge, die in einem sozialen Netzwerk anfallen können, kann es
zu großen Zeitverzögerungen beim Datentransfer kommen.
Da eine Visualisierung im Client ohne große Ladezeiten erfolgen soll3, ist dies nicht
wünschenswert.
In diesem Praxisprojekt beschäftige ich mich auch zum Teil mit sozialen Netzwerken. In
meiner Arbeit spielen soziale Netzwerke jedoch nur die Rolle einer Beispiel-Datenquelle,
welche ich ausgesucht habe.
Drupal kann auf Datenbestände die in einer externen Datenbank liegen zugreifen. Die
Daten müssen zentral auf einem Server gespeichert werden, da somit einzelne
Datensätze von Benutzern eines sozialen Netzwerkes schnell und effizient verglichen,
zusammengefasst und visualisiert werden können. Eine Visualisierung dieser Daten ist
sinnvoll, da der Benutzer schnelle relevante Informationen oder auch neue überraschende
Zusammenhänge erfassen und finden kann. Ein Beispiel wäre, die Visualisierung seiner
Freunde und „Freundes-Freunde“4 in einer Art „Soziogramm“5, worüber leicht
Bekanntschaften schneller gefunden werden könnten.
1.2 Ziel der Arbeit
Das Ziel der Arbeit ist es, eine schnelle Datenübertragung zwischen Flex und Drupal zu
finden. Der Datenzugriff soll in kürzer Zeit, trotzt riesiger Datenmenge erfolgreich sein.
In dieser Arbeit werden verschiedene vorhandene Datenübertragungsmöglichkeiten
zwischen dem Back- und dem Frontend der Webanwendung auf seine jeweiligen Vor- und
Nachteile untersucht und miteinander verglichen. Im Anschluss an diese Vergleiche wird
ein Testprogramm erstellt, mit dem ein gelungenes Beispiel für das Zusammenspiel
zwischen den gewählten Software-Produkten gezeigt wird.
Vorgehensweise
Zunächst werde ich die vorhandenen und relevanten Software-Technologien erfassen und
auf ihre Stärken und Schwächen untersuchen. Mit verschiedenen Kriterien werde ich diese
dann bewerten, auswählen und mich am Ende für die beste Kombination entscheiden.
1 Siehe Kapitel 3.1
2 Siehe Kapitel 3.2
3 Siehe ISO-Norm 9241-110 - Benutzerschnittstellen von Webseiten – im speziellen Erwartungskonformität
und Steuerbarkeit.
4 http://www.lokalisten.de Wortschöpfung der Lokalisten-Community – die Freunde meines Freundes.
5 http://www.cmu.edu/joss/content/articles/volume1/images/fig12.gif
Ein Soziogramm ist die graphische Darstellung der Beziehungen in einer Gruppe, etwa in einer Schulklasse
oder in einem Unternehmen.[http://de.wikipedia.org/wiki/Soziogramm]
3
Die verschiedenen Kriterien sind unter anderem:
• Geschwindigkeit*
• Kosten
• Kompatibilität
* Es wird die gesamte Übertragungs- und Verarbeitungsdauer betrachtet. Hierbei steigt
das zu übertragende Datenvolumen und somit auch die Gesamtdauer der Verarbeitung
exponentiell mit der Anzahl an darzustellenden Benutzern an.
4
2. Theoretische Grundlagen
Um einen besseren Überblick zu verschaffen werden hier einige Begriffe und Definitionen
erläutert. Ziel dieses Kapitels ist eine gemeinsame Wissensbasis für dieses Projekt.
Die Angaben stammen aus mehreren Quellen und sind teilweise gekürzt.
2.1 Daten
Plural: Daten; Singular: Datenelement, Angabe oder Wert
allgemeine Definition: „aus Messungen, Beobachtungen u.ä. gewonnene Angaben,
Informationen“
Informatik: “zur Darstellung von Informationen dienende Zeichenfolgen (Digitale D.) oder
kontinuierliche. Funktionen (analoge D.),die auf Datenverarbeitungsanlagen gespeichert,
verarbeitet und/oder erzeugt werden können“
[Meyers Lexikon 1996]
Von der Definition her sind Daten also die maschinenlesbaren Repräsentationen von
Informationen.
2.1.1 Datenquellen
Daten können prinzipiell aus drei verschiedenen Quellen stammen [Schumann/Müller
2000]:
Reale Welt:
Daten werden durch Messgeräte erfasst oder durch
Beobachtungen gewonnen.
Theoretische Welt: Daten werden auf Grundlage mathematischer Modelle
berechnet.
Künstliche Welt:
Daten werden entworfen.
·
Die rasante Zunahme der Datenmenge führt zu Unübersichtlichkeit.
2.2 Visualisierung
Die Visualisierung sollte den Inhalt der Daten nicht verändern. Sie dient nur dazu, den
Inhalt bildhaft darzustellen.
„Ziel des Visualisierungsprozesses ist es, abstrakte Daten, die in der Regel nicht
geometrischer Natur sind, in Form von Bildern zu veranschaulichen.“[Schumann/Müller
2000].
Abbildung 1: Stufen der Visualisierungspipeline nach [Schumann/Müller 2000]
5
Der Visualisierungsprozess besteht aus drei Schritten:
Datenaufbereitung zur Vorverarbeitung
Filtering:
Mapping:
Erzeugung eines Geometriemodells
Rendering:
Bildgenerierung
Mit Hilfe von Visualisierung können viele komplexe Daten besser veranschaulicht und
verstanden werden.
2.3 Soziales Netzwerk
„Soziale Netzwerke lassen sich als Graphen repräsentieren.“ [Pfeffer 2008]
Ein Netzwerk als Graph betrachtet, besteht aus einer Anzahl von Knoten mit beliebig
vielen Kanten (Verbindungen) untereinander. Ein Knoten entspricht dabei einem
vollständigen Objekt . Jedes Objekt muss eindeutig identifiziert werden können und kann
jeweils Felder mit Werten und Verbindungen zu anderen Objekten besitzen. Diese
Verbindungen können näher charakterisiert werden.
Ein Netzwerk wird zu einem sozialen Netzwerk, wenn es Knoten gibt, die für die
Menschen und Verbindungen gibt, die für Beziehungen der Leute untereinander stehen.
„We define social network sites as web-based services that allow individuals to
(1) construct a public or semi-public profile within a bounded system,
(2) articulate a list of other users with whom they share a connection, and
(3) view and traverse their list of connections and those made by others within the system.
The nature and nomenclature of these connections may vary from site to site.“
[Boyd/Ellison 2007]
In elektronischen sozialen Netzwerken gibt es nun u.a. Benutzer-Profile, BenutzerGruppen und verschiedene charakterisierte Beziehungen. Ein Benutzer-Profil beschreibt
dabei den Objekt-Knoten für eine Person.
Verschiedene Internet-Plattformen, die zu Anfang in ihrer Funktionalität auf einen
bestimmten Bereich beschränkt waren, wie Weblogging, Forum, Fotodienst, Webshop
usw., wurden nach und nach zu sozialen Netzwerken erweitert.
6
Abbildung 2: Zeitleiste der bekanntesten sozialen
Netzwerke [Boyd/Ellison 2007]
Wie in Abbildung 2 ersichtlich, wurden die Ende der 90er Jahre ursprünglich als Foren
gegründeten Websites AsianAvenue und BlackPlanet 2005 als vollwertige soziale
Netzwerke neu gestaltet.
7
3. Technische Umsetzung
In diesem Kapitel wird die für diese Praxisarbeit verwendete Software kurz erläutert.
Die Programmierung der Visualisierung erfolgt unter Adobe Flex 3 mit Hilfe der
Visualisierungsbibiliothek Flare.
Um beim Zugang zu den Datensätzen keiner Beschränkung durch Zugriffsrechte
unterworfen zu sein, wird ein neues eigenes soziales Netzwerk mit Drupal entworfen.
Die Entwickler von Adobe Flex und Drupal unterstützen sich gegenseitig, Die Website6 von
Adobe Flex ist selbst mit Drupal gebaut und zeigt, dass beide leicht zu integrieren sind.
Die Entwicklung des Prototypen und die Benutzung der Software sollte kostenlos und
Open Source sein. Drupal, Flex und Flare haben diese Voraussetzung erfüllt.
3.1 Adobe Flex
Adobe Flex7 ist ein Framework, um eine RIA (Rich Internet Application) in Flash zu
entwickeln.
Für die Programmierung in Flex werden die Sprachen MXML und ActionScript 3
verwendet. Beide Sprachen können gemeinsam benutzen werden. Beim Kompilieren wird
der MXML-Code in ActionScript 3 umgewandelt. Um schnell und effektiv ein Programm zu
entwickeln, wird das Layout in MXML beschreiben, der Rest in ActionScript 3 erledigt.
Zur Entwicklung von Flex-Anwendungen wird das Flex SDK benötigt.
3.1.1 Warum Flex
Abbildung 3: Verbreitung von Plattformen auf Internet-fähigen
Rechnern [Cole/Thomas 2008]
Flex ist Open Source und hat das gleiche Format wie Adobe Flash. Für den Entwickler ist
das ein großer Vorteil, weil auf den meisten Rechnern der Flash-Player bereits installiert
ist (siehe Abbildung 3) und daher keine zusätzliche Installation nötig ist.
6 http://flex.org/showcase
7 http://www.adobe.com/de/products/flex/overview/
8
Mit Hilfe von AIR (Adobe Integrated Runtime) kann eine Flex Anwendung auch direkt wie
eine Desktop-Anwendung benutzen werden.
Alles was mit anderen Sprachen entwickeln werden kann, kann Flex auch.
Ein besonderer Pluspunkt ist, dass Flex verschiedene Arten von Datenverbindungen wie
HTTPService, WebService und RemoteObject unterstützt.
3.2 Drupal
Drupal ist ein PHP-basiertes Content Management System (CMS), mit dem Websites,
Internet-Portale, Communities und vieles mehr gebaut werden kann. Wie einige andere
CMS benutzt auch Drupal Module. Der Vorteil daran ist, dass jeder mitentwickeln kann.
Die Mitglieder der starken Drupal-Community helfen sich gegenseitig beim Thema
Sicherheit und anderen Problemen.
Es gibt zwei unabhängige Versionen von Drupal: Version 5 und Version 6.
Für die Entwicklung des Prototypen benutze ich Version 6, weil hier die Entwicklung der
Module intensiver als bei Version 5 ist.
Drupal besteht aus einzelnen Modulen, wie die zu Anfang bei der Installation
mitgelieferten Core-Modulen, und vielen Zusatz-Modulen, die je nach Gebrauch
hinzugefügt werden können, um die Funktionalitäten von Drupal zu erweitern.
3.2.2 Warum Drupal
Um ein soziales Netzwerk zu bauen, sind folgende Funktionalitäten nötig:
Benutzer-Registrierung und -Verwaltung
Kategorisieren und Tagging
Kommentare
Diese Funktionalitäten sind in Drupal durch entsprechende Module leicht zu integrieren.
Besonders wichtig für die Kommunikation zwischen PHP und Flash ist AMFPHP.
Auch dafür steht in Drupal ein passendes Modul zur Verfügung.
3.2.3 Die Drupal Systemarchitektur
Abbildung 4: Die Systemarchitektur von Drupal [van Dyk 2008]
9
Drupal ist in PHP geschrieben. Das Ziel von Drupal ist, die am weitesten verbreitete
Technologie zu verwenden. Dadurch lässt sich Drupal auf jedem System erfolgreich
betreiben.
Beim Webserver gibt es verschiedene Möglichkeiten, obwohl die meisten Anwender
Apache bevorzugen. In der Grundkonfiguration bietet Drupal entweder MySQL oder
PostgreSQL als Datenbank an, aber es werden auch andere Datenbanken wie Microsoft
SQL Server oder Oracle unterstützt.
3.3 Der Datenaustausch zwischen Drupal und Flex
Abbildung 5: Grundprinzipien des Datenaustausches zwischen Drupal und
Flex
Die obere Abbildung erklärt unsere Systemarchitektur. Auf der Client-Seite erfolgt der
Datenaufruf mit einem Flash-fähigen Webbrowser.
10
3.4 MAMP8, LAMP, WAMP und XAMPP
Damit der Prototyp auf dem eigenen Computer entwickeln werden kann, wird einiges an
Software benötigt.
Die in der letzten Überschrift genannten Abkürzungen sind zusammengestellte OpenSource-Pakete (für verschiedene Computer-Systeme).
Jedes Paket enthält folgende Software:
 Apache als Webserver
 MySql als Datenbanksystem
 PHP als Skriptsprache
 und andere Software, je nachdem welches Paket gewählt wird.
Ziel eines solchen Pakets ist eine einfache und schnelle Installation einer
Laufzeitumgebung für Web-Anwendungen. Um die Terminologie zu vereinfachen, werde
ich dafür im weiteren Verlauf nur noch den Begriff „LAMP“ verwenden.
8 http://www.mamp.info
11
4. Problemfeld und Kontext
Die Beziehungen zwischen Benutzern werden visualisiert.Der Datentransfer ist ein
wichtiges Thema, weil die Verbindungen untereinander exponentiell anwachsen und dabei
riesige Datenmengen entstehen können.
Da der Prototyp client-seitig in Flex entwickelt wird, werde ich die in Flex möglichen
Datenübertragungsarten näher betrachten.
4.1 Datenzugriff in Flex
Flex bietet drei verschiedene Dienste, um auf externe Daten zuzugreifen:
• HTTPService mit HTTP GET/POST
• WebService mit SOAP
• RemoteObject mit AMF
4.1.1 HTTPService
Der HTTPService, der auch als REST-style Webservice bekannt ist, benutzt GET/POSTAnfragen, um mit dem Server über HTTP zu kommunizieren.
Die Daten zwischen Server und Client werden dabei als reiner Text transportiert. Bei
riesigen Datenmengen ist das ein großer Nachteil. Einfache Daten können als URLkodierte Variablen übertragen werden. Für komplexere Daten ist die Verwendung von
JSON oder XML möglich.
4.1.2 WebService mit SOAP
Wie andere Anwendungen bietet auch Flex eine Datenkommunikation über Webservices
an. Die Daten werden zwischen den Systemen mit Hilfe von SOAP als Protokoll
ausgetauscht.
Wie bei allen SOAP-Webservices ist die geringe Geschwindigkeit beim Datenaustausch
ein sehr großer Nachteil, im Vergleich zu anderen Techniken.
4.1.3 RemoteObject mit AMF
AMF (Action Message Format) ist ein kompaktes binäres Format um ActionScript-Objekte
zu serialisieren. Dieses codiert die auszutauschenden Informationen binär, die gesendete
Nachricht wird dadurch wesentlich kleiner und kann schneller übertragen werden. Es ist
kein Transferprotokoll an sich. Die Daten werden über HTTP oder RTMP gesendet. Mit
passendem Backend kann eine „Echtzeit-Datenkommunikation“ simuliert werden.
AMF ist für verschiedene Platformen wie Java, Ruby, PHP, Python, ColdFusion und .NET
verfügbar.
4.1.4 Zusammenfassung
Um die Geschwindigkeiten verschiedener Datenformate zu vergleichen, hat James Ward
ein schönes Programm9 geschrieben.
Er hat nicht nur verschiedene Datenzugriffsarten in Flex veglichen, sondern hat auch Ajax
und Dojo mit eingebunden. Alle Tests werden mit 5000 Datenzeilen gesendet. Bei Dojo
jedoch nur mit 500 Datenzeilen. Anhand der Graphik wird deutlich, dass AMF sehr schnell
9 http://www.jamesward.com/census /
12
ist (zweiter Balken von unten).
Abbildung 6: Übertragungsgeschwindigkeit verschiedener Dateizugriffsarten [Ward 2008]
4.1.5 Fazit
Bewertet werden die drei ausgewählten Dienste:
HttpService (REST), WebService SOAP und RemoteObject AMF.
Eine volle Bewertung hat 3 Pluspunkte.
HttpService
WebService
SOAP
RemoteObject
AMF
++
+
+++
Serverseitige
Unterstützung
+++
+++
+
Client-Belastung
++
+
+++
Data format
+
+
+++
Ergebnis
8
6
10
Geschwindigkeit
Hinweis: Je mehr Pluspunkte desto besser.
13
Für den Datenzugriff des Prototypen habe ich mich für das RemoteObject mit AMF
entschieden. Im Vergleich zu XML/SOAP ist diese Datenverbindung viel schneller, da im
Binärformat AMF die Objekte viel kompakter übertragen werden können. AMF ist dabei
rund 10x schneller als XML oder SOAP.
4.2 AMF Backend - Evaluation
Wie oben erklärt, handelt es sich bei AMF um binäre Daten. Damit der Server die Daten
weiter verarbeiten kann, wird ein Backend benötigt auch als AMF-Gateway bekannt.
Es gibt mittlerweile mehrere Backends für verschiedene Sprachen.
Um die Auswahl zu vereinfachen werden hier bestimmte Kriterien betrachtet.
Einführungskosten
Betriebskosten
Strategische Kriterien
Personalkosten
Personalkosten
Stabilität
Beratungskosten
Wartung
Sicherheit
Lizenzkosten
Hardwarekosten
Herstellerunabhängigkeit
Schulungskosten
Lfd. Schulungskosten
Benutzerfreundlichkeit
Migrationskosten
Updatekosten
Interoperabilität
Installationskosten
Anpassbarkeit an individuelle
Zwecke
Einarbeitungsaufwand
Vorhandenes Know-how
Tabelle 1: Kriterienraster zur Bewertung von Softwareprodukten10
Aus diesem Kriterienraster werden einige relevante Kriterien ausgewählt und in eigene
Kriterien angepasst.
Kosten, Herstellerunabhängigkeit
Open Source
Vorhandenes Know-how
Comunity Support
Sicherheit und Stabilität
Update
Einarbeitungsaufwand und
Anpassbarkeit an individuelle Zwecke
Module Support
LAMP Support
Data Push Support
Open Source
Als Open Source wird also Software bezeichnet, deren Quellcode für jedermann
zugänglich ist. Dieser enthält alle Informationen und Funktionen einer Software in
Programmiersprache und ermöglicht die Veränderung und Weiterentwicklung des
jeweiligen Programms. [media.nrw.de 2006]
10 Leipelt, Detlef: Grundgedanken zu Wirtschaftlichkeitsbetrachtungen für den Einsatz von Open Source
Software. [http://www.kbst.bund.de/Anlage305827/Grundgedanken-zu-Wirtschaftlichkeitsbetrachtungen-fuerden-Einsatz-von-OSS-pdf-13-8-kB.pdf]
14
Mit Open Source Software wird eine Reihe von nutzenbringenden Vorteile, jedoch auch
Nachteile für Entwickler und Anwender verbunden. In Tabelle 2 sind die Vor- und Nachteile
von Open Source Software zusammengefasst gegenübergestellt.
Vorteile
Nachteile
Höhere Produktqualität
Höherer Schulungsaufwand
Sicherheit und Zuverlässigkeit
Oft kein Support durch den Entwickler
Offene Standards
Mangelhafte Interoperabilität
Anpassbarkeit
Schulungsaufwand
Wiederverwendbarkeit
Weiterentwicklung
Anbieterunabhängigkeit
Keine Gewährleistungsansprüche
Keine Lizenzkosten
Tabelle 2: Vorteile und Nachteile von Open Source [Renner et al. 2006]
Ein wichtiger Vorteil von Open Source ist die Unabhängigkeit vom Anbieter, Somit fallen
auch Lizenzkosten weg.
Community Support
Eine starke Community hilft uns Probleme zu lösen.
Update
Ein regelmäßiges Update schließt Sicherheitslücken und steigert die Performance.
LAMP und Module Support
Die Unterstützung von LAMP und Modulen vereinfacht Installation und Entwicklung.
Data Push Support
Data Push Support ermöglicht Daten-Push-Prozesse, die Daten automatisch (ohne
vorhergehende Abfrage) an die Client-Anwendung übertragen. Mit diesem hoch
skalierbaren Verfahren können sekundengenaue Daten für mehrere tausend Anwender
gleichzeitig bereitgestellt werden.
Hier sind einige Backends mit AMF-Unterstützung, nach Programmiersprache
unterschieden:
Java
PHP
LiveCycle Data Services, BlazeDS, WebORB für Java,
Granite DS, LightStreamer, RED 5
WebORB für PHP, AMFPHP, SabreAMF, Zend Framework
Ruby
WebORB für Ruby on Rails, RubyAMF
Python
.NET
ColdFusion
PYAMF, DjangoAMF
WebORB für .NET, FluorineFX
integriert
15
Hier werden nur die bekanntesten Backends kurz analysiert und erläutert.
4.2.1 LiveCycle Data Services
LCDS ist ein Framework von Adobe, um Rich-Internet-Anwendungen (RIA) zu entwickeln.
Außer HTTP und AMF bietet LCDS auch RTMP (Real Time Messaging Protocol) als
Transferprotokoll. Als Programmiersprache benutzt LCDS Java. Funktionen, wie
Datensynchronisation, Data Push und das abonieren von Messages, macht LCDS zum
Traum-Framework für Entwickler. Der Nachteil ist jedoch, dass das Produkt kostenpflichtig
und nicht gerade günstig ist.
Vorteile
 professioneller Support
 automatische Datensynchronisation
 RTMP Tunneling
 Message-Themen veröffentlichen und abonieren
 Data Push Support
Nachteile
 kostenpflichtig
 nicht Open Source
 hohe System-Anforderungen
 aufwendige Konfiguration
 eigener Webserver
 keine Module für andere Frameworks
4.2.2 BlazeDS
Als Alternative zu LCDS bietet Adobe BlazeDS. Es ist eine abgespeckte Version von
LiveCycle Data Services. Der Vorteil von BlazeDS ist, dass es Open Source und kostenlos
ist. Einstieger finden auf der Adobe-Seite eine ganze Menge Dokumentation und Tutorials.
Bei einem kleinen Projekt gibt es nur geringe Unterschiede zwischen BlazeDS und LCDS
(wie z.B. RTMP-Support und Messages abonieren). BlazeDS benutzt einen Java Web
Application Server (z.B. Tomcat), deswegen kann es nicht in LAMP intregriert werden.
Aufgrund der aufwendigen Konfiguration, ist dies natürlich ein zeitlicher Nachteil. Des
weiteren ist die Community noch nicht sehr groß.
Vorteile
 Data Push Support
 Open Source
 kostenlos
Nachteile
 aufwendige Konfiguration
 eigener Webserver
 keine Module für andere Frameworks
4.2.3 WebORB
WebORB ist ein kostenloses Open-Source -Produkt für RIA von der Firma Midnight
Coders. WebORB ist für mehrere Platformen verfügbar: .NET, Java, PHP und Ruby. Von
16
den Features her, ist das Produkt vielversprechend, da es beinahe an BlazeDS heran
kommt. Die Dokumentation und der Community-Support sind weniger einsteigerfreundlich,
da die Firma mit Support ihr Geld verdient.
Vorteile
 Data Push Support
 Open Source
 kostenlos
 LAMP Support
Nachteile
 kaum Dokumentation
 keine Module für andere Frameworks
4.2.4 RED 5
RED 5 bietet nicht nur AMF, sondern dient auch als Flash Media Server. Mit RED 5 kann
Audio/Video gestreamt und aufgezeichnet werden. Außerdem bietet RED 5 mit Hilfe von
AMFPHP ein Modul für Drupal an. Leider ist die Dokumentation von RED 5 grauenhaft,
ähnlich wie bei WebORB.
Vorteile
 Open Source
 kostenlos
 starke Community
Nachteile
 kaum Dokumentation
 benötigt AMFPHP als Backend Support
 mangelnde Updates
4.2.5 AMFPHP
AMFPHP ist ein RPC-Toolkit für PHP zur Kommunikation mit Flash über das Action
Message Format (AMF). Weil AMFPHP schon ziemlich lange auf dem Markt ist, ist es
auch das am meisten genutzte Backend. Außerdem gibt es ein Modul für Drupal. Der
Nachteil ist, dass der Entwickler keine Updates mehr herausgebracht hat. Daher ist die
AMFPHP-Technologie etwas veraltet.
Vorteile
 Open Source
 kostenlos
 zahlreiche Beispiele im Internet
 einfach zu konfigurieren
 Module für andere Frameworks
 LAMP Support
Nachteile
 die Entwicklung hat nachgelassen
 kein Data Push Support
 kein Update vorgesehen
17
4.2.6 Fazit
LCDS
BlazeDS
WebORB
Red 5
AMFPHP
-
+++++
+++++
+++++
+++++
++
++++
+
++++
++++
+++++
++++
++++
++
-
LAMP Support
-
-
+++++
-
+++++
Module Support
-
-
-
++++
+++++
+++++
++
+++
-
-
12
15
18
15
19
Open Source
Community support
Update
Data Push Support
Ergebnis
Die Punktevergabe basiert auf meiner Recherche. Hier wurde mit 5 (+) der
höchstmögliche und mit 0 (-) der niederste Wert vergeben.
Ich habe AMFPHP gewählt, weil der Einarbeitungsaufwand von WebORB wegen
fehlendem Support aufwendiger ist als AMFPHP ist. Des Weiteren ist die Unterstützung
von LAMP und Modulen, um eine schnelle Entwicklung zu erreichen sehr hilfreich.
Unter diesen Voraussetzungen passt AMFPHP am besten.
Ein großer negativ Aspekt des AMFPHP besteht darin, dass keine Updates und weitere
Erweiterungen unterstützt werden können, da die Entwicklung seitens der Entwickler von
AMFPHP nicht weiter ausgeführt wurde. Jedoch nimmt dieser große Nachteil für mein
Projekt keinen Einfluss, da ich das AMFPHP nur zur Verarbeitung des Datenformats
benutze. Außerdem sind die zusätzlichen Feature nicht im Rahmen der Problemstellung
dieses Projekts.
18
5. Drupal einrichten
Da ein soziales Netzwerk als Datenlieferante gewählt wurde, wird Drupal als Plattform
verwendet. Als Datenbank kann MySQL oder PostgreSQL genommen werden. LAMP
bietet normalerweise nur MySQL als Datenbanksystem an. Somit wird MySQL als
Datenbank genommen. Drupal selbst bietet eine automatisierte Installation an.
5.1 Drupal-Module
Drupal hat zwei Arten von Modulen: Core Module und und optionale Module. Core Module
werden bei der Drupal-Installation mit installiert. Um ein zusätzliches Feature zu
bekommen, wird ein bestimmtes Modul gebraucht . Die zusätzlichen Module sollten nicht
mit den Core Module im gleichen Ordner zusammengelegt werden. Dafür bietet Drupal
Unterordner, die unter /sites/all/ zu finden sind. Unter /sites/all/
können die Ordner modules und themes erstellt werden. Diese Ordner werden von
Drupal automatisch erkannt.
Für ein soziales Netzwerk wird eine Auswahl an Modulen benötigt (Abbildung 7).
Abbildung 7: Drupal Module
19
6. Flex RemoteObject mit AMFPHP
In diesem Kapitel wird versucht, Daten aus der Drupal-Datenbank über RemoteObject mit
Hilfe von AMFPHP auszulesen.
Da der größere Teil des Prototypen in Flex entwickelt wird, ist es vorteilhaft, den FlexBuilder zu verwenden. Studenten und Lehrkräfte bekommen den Flex Builder kostenlos
und andere können ihn 30 Tage lang testen oder kaufen. Natürlich ist es möglich, für Flex
auch mit einem beliebigen Texteditor ohne weitere Kosten zu programmieren, da der FlexCompiler und das Flex-Framework Open Source und kostenlos sind.
Für die Kommunikation zwischen Drupal und AMFPHP wird ein zusätzliches ServiceModul benötigt.
Kurz zusammengefasst wird verwendet:
• Flex Builder
• AMFPHP 1.9 Beta 2
• AMFPHP-Modul für Drupal
• Service-Modul für Drupal
6.1 AMFPHP und das Service-Modul einrichten
Üblicherweise werden die Module (AMFPHP und Service) nach /sites/all/modules und das
AMFPHP-Paket in den AMFPHP-Module-Ordner entpackt
(/sites/all/modules/amfphp/ampfphp).
Für das Service-Modul muss nichts besonderes eingerichtet werden.
amfphp and this gateway are installed correctly. You may now connect to this gateway from
Flash.
Note: If you're reading an old tutorial, it will tell you that you should see a download window
instead of this message. This confused people so this is the new behaviour starting from amfphp
1.2.
View the amfphp documentation
Load the service browser
Abbildung 8: AMFPHP - Meldung in Drupal-Services-Menü
Um zu testen, ob AMFPHP funktioniert, muss in das Menü gegangen werden.
administer > site building > services und den Link AMFPHP /services/amfphp gedruckt werden. Wenn es läuft, sollte die folgende Seite (Abbildung 8)
angezeigt werden. Vorher müssen natürlich im Admin-Menü die Module aktiviert werden.
20
6.2 Flex einrichten
Damit Flex weiß, welche Art von Verbindung benutzt werden soll, müssen zuerst einige
Konfigurationen durchführt werden.
Zuerst wird die Datei service-config.xml (siehe Abildung 9) benötigt. Diese
<?xml version="1.0" encoding="UTF-8"?>
<services-config>
<services>
<service id="amfphp-flashremoting-service"
class="flex.messaging.services.RemotingService"
messageTypes="flex.messaging.messages.RemotingMessage">
<destination id="amfphp">
<channels>
<channel ref="my-amfphp"/>
</channels>
<properties>
<source>*</source>
</properties>
</destination>
</service>
</services>
<channels>
<channel-definition id="my-amfphp"
class="mx.messaging.channels.AMFChannel">
<endpoint uri="//localhost:8888/services/amfphp"
class="flex.messaging.endpoints.AMFEndpoint"/>
</channel-definition>
</channels>
</services-config>
Abbildung 9: service-config.xml
Konfigurationsdatei sollte im Root-Verzeichnis des Flex-Projekts abgespeichert werden.
Das einzige, was zu ändern ist, ist die endpoint URI. Die Adresse ist die WebserverAdresse. Im oberen Beispiel ist dies das localhost mit Port 8888. Danach muss nur
noch der Pfad zur Datei service-config.xml dem Flex-Compiler mitgeteilt werden
(siehe Abildung 10).
21
Abbildung 10: Flex Compiler Setting
Dieses Menü befindet sich unter File > Properties > Flex Compiler. Damit der Compiler die
Datei service-config.xml auch findet, sollte der korrekte Pfad eingegeben
werden. Weil die Datei im Root-Verzeichnis des Flex-Projekts gespeichert wird,kann die
komplette Pfadeingabe gespart werden.
22
6.3 Test Programm
Bevor mit dem Prototypen begonnen werden kann, ist es sinvoll, ein kleines TestProgramm zu schreiben. In diesem Fall ist die Datenverbindung eine notwendige
Voraussetzung. Das Programm dient dazu, die Verbindung zwischen Drupal und Flex über
RemoteObject zu testen.
6.3.1 Die Oberfläche
Die grafische Benutzeroberfläche (GUI – Graphical User Interface) spielt in diesem TestProgramm nur eine kleine Rolle. Wichtig ist nur, dass der Benutzer die Testverbindung
ausführen kann.
Ein paar Datenobjekte werden zur Probe aus der Drupal-Datenbank ausgelesen.
Notwendige Daten wie Name und Email-Adresse müssen bei der Registrierung von
jedem Mitglied eines sozialen Netzwerks angegeben werden. Aus diesem Grund sind sie
als Datenarten sinnvoll. Da Interesse an den Beziehungen zwischen den Mitgliedern
besteht, gehören auch diese zu den Daten, die ausgelesen werden.
Die GUI besteht aus:
• 1 Text Input
• 2 Text Area
• 1 DataGrid
• 1 Button
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute" creationComplete="init()">
<mx:Panel width="792" height="400" layout="absolute" title="User Profile"
horizontalCenter="0" verticalCenter="0">
<mx:DataGrid x="10" y="158" width="306" id="friend_name"
dataProvider="{FriendList}" change="relationships_detail()" >
<mx:columns>
<mx:DataGridColumn headerText="Name"
dataField="users_user_relationships_name" width="80"/>
</mx:columns>
</mx:DataGrid>
<mx:TextArea width="306" height="74" id="result_text" x="10" y="40"
selectable="false"/>
<mx:Button id="btn" label="Laden" click="show();" width="115"
x="10" y="328"/>
<mx:FormItem label="ID:" fontWeight="bold" x="10" y="10">
<mx:TextInput id="ID" width="50" />
</mx:FormItem>
<mx:Label text="Relationships" x="10" y="132"
fontWeight="bold"/>
<mx:TextArea x="345" y="160" id="friend_profile" width="300"
height="150"/>
</mx:Panel>
</mx:Application>
Durch den Flex Builder wird das Bauen einer GUI sehr erleichtert. Die Oberfläche wird
einfach grafisch dargestellt. Dadurch wird viel Aufwand erspart, da die Beschreibung mit
dem Texteditor wegfällt. Der Flex Builder generiert dann den passenden MXML-Code, den
der Compiler später versteht. Der obere Quelltext generiert eine GUI, Siehe Abbildung 11
aussieht.
23
Abbildung 11: GUI nach Programm-Start
Wenn eine User ID eingegeben wird, wird der passende Benutzer-Name mit der
Mailadresse und dessen Beziehungen aufgelistet (Abbildung 12). Mit einem Klick auf
einen Namen in der Beziehungsliste (unter Relationships) wird die ID, der Typ und die
Mail-Adresse dieser Beziehung ausgegeben (Abbildung 13).
Abbildung 12: GUI nach Eingabe einer User ID.
24
Abbildung 13: GUI nachdem ein User-Name geklickt wurde.
25
6.3.3 Funktionen
Damit das ganze Programm funktioniert, mussten einige Funktionen deklarieren werden.
import mx.controls.*;
import mx.rpc.events.*;
import mx.utils.ArrayUtil;
[Bindable]
public var FriendList:Array;
public var resObject:Object ;
public function onFault(event:FaultEvent):void{
Alert.show(event.fault.faultString, "Error");
}
public function onViewsResult(event:ResultEvent):void{
FriendList = ArrayUtil.toArray(event.result);
}
public function onViewsUser(event:ResultEvent):void{
resObject = event.result;
result_text.text = "Name: " + event.result.name
+"\n"+"Mail:"+event.result.mail+"\n" ;
}
public function show():void{
views.get("relationships",
['rid','users_user_relationships_name'],[ID.text]);
user.get(ID.text);
}
...
]]>
public function relationships_detail():void{
</mx:Script>
Zuerst werden einige Pakete importiert. Dadurch werden bestimmte Funktionen benutzbar.
Im Test-Programm gibt es fünf Methoden.
Die Methode onFault gibt eine Meldung aus, wenn ein Fehler auftritt.
Interessanter ist die Methode show(), besonders der Funktionsaufruf
views.get("relationships"['rid','users_user_relationships_name'],
[ID.text]).
Hiermit werden die Daten aus der Drupal-Datenbank abgerufen. Views ist ein DrupalModul, das Datenbank-Abfragen erstellt. Durch Nutzung des Views-Moduls muss man
sich später nicht mehr um einzelne SQL-Querys kümmern. In diesem Beispiel heißt die
Abfrage „relationships“.
Wenn eine dazu passende Views-Abfrage vorhanden ist, sind beliebige Daten aus der
Datenbank abfrufbar. Diese Funktionalität findet sich unter Site building > Services im
Admin-Menü von Drupal.
26
6.3.2 RemoteObject
<mx:RemoteObject id="views" fault="onFault(event)"
showBusyCursor="true" source="views" destination="amfphp">
<mx:method name="get" result="onViewsResult(event)"
fault="onFault(event)" />
</mx:RemoteObject>
<mx:RemoteObject id="user" fault="onFault(event)"
showBusyCursor="true" source="user" destination="amfphp">
<mx:method name="get" result="onViewsUser(event)"
fault="onFault(event)"/>
</mx:RemoteObject>
Interessanter ist, wie Flex die Objekte aufruft. Was zu beachten ist, ist source und
destination.
Abbildung 14: Auszug aus dem ServicesMenü in Drupal
source ist der Paketpfad der Remote PHP-Klasse. Da mit Drupal gearbeitet wird, ist
dies ein bestimmtes Attribut des Service-Moduls.
destination ist die <destination id> in der service-config.xml, in
diesem Fall AMFPHP.
In jeder RemoteObject-Verbindung können beliebige Methoden zugewiesen werden. Da
es zwei verschiedene Paketpfade gibt,werden jedoch nicht beide Methoden unter ein
einzelnes RemoteObject geschreiben.
Die Methodennamen befinden sich in Drupal im Menü Services. In Abbildung 14 sind das
die zwei Paketpfade (user und views) mit mehreren Methoden (delete, get,
login usw.).
27
7. Fazit und Ausblick
7.1 Fazit
Dieses Praxisprojekt hat gezeigt, dass die Entwicklung einer einfachen Anwendung mit
Drupal, Flex und einer Datenbankbasierte Middleware sehr unkompliziert ist. Eine
Datenbankschnittstelle sowie deren Datenbankmodell sind mit den Drupal/PHP einfach zu
gestalten.
Die Datenbankverbindung zwischen Flex (Flash/ActionScript) und Drupal/PHP funktioniert.
Der Vergleich von verschiedener Datenübertragungsarten und vorhandener Backends hat
mir die Entscheidung erleichtert, eine passende Datenübertragungsart zu finden. Durch
seine überwiegende Stärke in der Webanwendung hat das RemoteObject AMF als
alternative Datenübertragungsart seine Vorteile in punkto Geschwindigkeit, Kosten und
Kompabilität ausspielen können.
Des weiteren kann man in meinem Testprogramm ersehen, dass AMFPHP für meines
Projekt gut gewählt sind, da die Datenauslesung erfolgreich und ohne Problem verlief.
Drupal selbst bietet viele Möglichkeit eine Community zu bauen, trotz vieler Updates und
einigen Schwierigkeiten beim Aktualisieren.
7.2 Ausblick
Der nächste Schritt ist der Visualisierungsteil. Die Visualisierung sollte eine Interaktion
zwischen dem Benutzer und den aufgerufenen Daten unterstützen, damit diese
übersichtlicher und informativer präsentiert werden können. Wichtig ist außerdem,
Möglichkeiten zu finden, falls die Visualisierung an Grenzen stößt. Zu meiner Arbeit
befasse ich mich unter anderem mit der Frage, was man beispielsweise tun kann, wenn
die zu übertragende Datenmenge riesig ist. Die Visualisierungsmöglichkeit von Flare
werde ich näher betrachten,da ich zu Beginn Flare gewählt habe.
28
Tabellenverzeichnis
Tabelle 1
Kriterienraster zur Bewertung von Softwareprodukten
13
Tabelle 2
Vorteile und Nachteile von Open Source
15
29
Abbildungsverzeichnis
Abbildung 1
Stufen der Visualisierungspipeline.
5
Abbildung 2
Zeitleiste der bekanntesten sozialen Netzwerke.
7
Abbildung 3
Systemarchitektur von Drupal.
8
Abbildung 4
Verbreitung von Plattformen auf Internet-fähigen Rechnern.
9
Abbildung 5
Grundprinzipien des Datenaustauschs zwischen Drupal und
Flex.
10
Abbildung 6
Übertragungsgeschwindigkeit verschiedener
Dateizugriffsarten.
12
Abbildung 7
Drupal Modules.
17
Abbildung 8
AMFPHP: Meldung in Drupal-Services-Menü.
18
Abbildung 9.
service-config.xml.
19
Abbildung 10
Flex Compiler Setting.
20
Abbildung 11
GUI nach dem Programm-Start.
22
Abbildung 12
GUI nach Eingabe einer User ID.
22
Abbildung 13
GUI nachdem ein User-Name geklickt wurde.
23
Abbildung 14
Auszug aus dem Services-Menü in Drupal.
25
30
Glossar
AMF (Action Message Format) ist ein Binärformat zum Datenaustausch zwischen Flash
und einer Gegenstelle über RPC.
AIR (Adobe Integrated Runtime) ermöglicht den Einsatz bewährter Web-Technologien für
die Entwicklung plattformübergreifender Rich-Internet-Anwendungen für den Desktop.
CMS (Content Management System) bezeichnet ein Verwaltungssystem, bei dem der
Anwender ohne jegliche Programmierkenntnisse eine Webseite (Homepage) mit Content
(wörtlich: Inhalt) füllen kann.
LAMP (Linux Apache MySQL PHP) ist eine Laufzeitumgebung für Webanwendungen und
besteht aus Open-Source-Software-Paketen für das Betriebssystem Linux.
MAMP (Macintosh Apache MySQL PHP) ist eine Laufzeitumgebung für Webanwendungen
und besteht aus Open-Source-Software-Paketen für das Betriebssystem MacOS X.
MXML (M eXtensible Markup Language) ist eine XML-basierte Markup-Sprache, in der die
Flash-Komponenten deklarativ beschrieben werden.
PHP (Personal Home Page) ist eine C-ähnliche Programmsprache für WebAnwendungen.
REST (Representational State Transfer) bezeichnet ein Architekturkonzept für skalierbare
verteilte Hypermedia-Informationssysteme wie das World Wide Web.
RIA (Rich Internet Application) ist eine Webanwendung, die die Fähigkeiten einer
Desktopanwendung beherrscht, wie z.B. Drag‘n‘Drop, lokaler Dateizugriff usw.
RPC (Remote Procedure Call) Entfernter Prozedur-Aufruf, meist über ein Netzwerk.
RTMP (Real Time Messaging Protocol) ist ein von Adobe entwickeltes proprietäres
Netzwerkprotokoll, um Audio-, Video- und sonstige Daten über das Internet von einem
Media Server zu einem Flash-Player zu übertragen.
SDK (Software Development Kit) ist eine Sammlung von Werkzeugen und Anwendungen,
um eine Software zu erstellen, meist inklusive Dokumentation. Mit diesem ist es
Softwareentwicklern möglich, eigene darauf basierende Anwendungen zu erstellen.
SOAP (Simple Object Access Protocol) ist ein Netzwerkprotokoll mit dessen Hilfe Daten
zwischen Systemen ausgetauscht und RPCs (entfernte Prozeduraufrufe) ausgeführt
werden können.
XAMPP (X Apache MySQL PHP PEAR) ist eine Laufzeitumgebung für Webanwendungen
und besteht aus Open-Source-Software-Paketen; X steht für ein beliebiges Betriebsystem.
WAMP (Windows Apache MySQL PHP) ist eine Laufzeitumgebung für Webanwendungen
und besteht aus Open-Source-Software-Paketen für das Betriebssystem Windows.
31
Quellen
Flex-Developer Center: http://www.adobe.com/de/devnet/flex/
[Boyd/Ellison 2007]
Boyd, d. m., & Ellison, N. B. (2007): Social network sites: Definition, history, and
scholarship. Journal of Computer-Mediated Communication, 13(1), article 11
[Cole/Thomas 2008]
Cole A;Thomas R(2008): Learning Flex 3
[Heer et al. 2005]
Jeffrey Heer, Stuart K. Card, James A. Landay(2005): Prefuse: A Toolkit for Interactive
Information Visualization.
[Heer/Boyd 2005]
Heer, J.; Boyd, D. (2005): Vizster: Visualizing Online Social Networks. IEEE Information
Visualization.
[Meyers Lexikon 1996]
Meyers Lexikonverlag (2006): Meyers Großes Taschenlexikon in 24 Bänden, Band 4,
ISBN 978-3-411-10064-4
[Pfeffer 2008]
Pfeffer, J. (2008): Visualisierung sozialer Netzwerke. Erschienen in: Stegbauer, C. (Hrsg.),
(2008): Netzwerkanalyse und Netzwerktheorie. Ein neues Paradigma in den
Sozialwissenschaften. Wiesbaden. S. 231-238.
[Schumann/Müller 2000]
Schumann, H.; Müller, W. (2000): Visualisierung. Grundlagen und allgemeine Methoden.
Berlin, Heidelberg.
[VanDyk 2008]
VanDyk K. J (2008): Pro Drupal Development, Second Edition.
[Renner et al. 2006]
Thomas Renner, Michael Vetter, Sascha Rex, Holger Kett (2006): Open Source Software:
Einsatzpotentiale und Wirtschaftlichkeit, Fraunhofer-Institut für Arbeitswirtschaft und
Organisation IAO, Stuttgart.
32
Quellcode
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute" creationComplete="init()">
<mx:Script>
<![CDATA[
import mx.controls.*;
import mx.rpc.events.*;
import mx.utils.ArrayUtil;
[Bindable]
public var FriendList:Array;
public var resObject:Object ;
public function onFault(event:FaultEvent):void{
Alert.show(event.fault.faultString, "Error");
}
public function onViewsResult(event:ResultEvent):void{
FriendList = ArrayUtil.toArray(event.result);
}
public function onViewsUser(event:ResultEvent):void{
resObject = event.result;
result_text.text = "Name: " + event.result.name
+"\n"+"Mail:"+event.result.mail+"\n" ;
}
public function show():void{
views.get("relationships",
['rid','users_user_relationships_name'],[ID.text]);
user.get(ID.text);
}
public function relationships_detail():void{
friend_profile.text = "Relationship ID: " +
friend_name.selectedItem.rid + "\n" + "Relationship Type: " +
friend_name.selectedItem.user_relationship_types_user_relationship
s_name + "\n" + "Mail: " +
friend_name.selectedItem.users_user_relationships_mail + "\n";
}
]]>
</mx:Script>
<mx:RemoteObject id="views" fault="onFault(event)"
showBusyCursor="true" source="views" destination="amfphp">
<mx:method name="get" result="onViewsResult(event)"
fault="onFault(event)" />
</mx:RemoteObject>
<mx:RemoteObject id="user" fault="onFault(event)"
showBusyCursor="true" source="user" destination="amfphp">
<mx:method name="get" result="onViewsUser(event)"
fault="onFault(event)"/>
</mx:RemoteObject>
33
<mx:Panel width="792" height="400" layout="absolute"
title="User Profile" horizontalCenter="0" verticalCenter="0">
<mx:DataGrid x="10" y="158" width="306" id="friend_name"
dataProvider="{FriendList}" change="relationships_detail()" >
<mx:columns>
<mx:DataGridColumn headerText="Name"
dataField="users_user_relationships_name" width="80"/>
</mx:columns>
</mx:DataGrid>
<mx:TextArea width="306" height="74" id="result_text" x="10"
y="40" selectable="false"/>
<mx:Button id="btn" label="Laden" click="show();"
width="115" x="10" y="328"/>
<mx:FormItem label="ID:" fontWeight="bold" x="10"
y="10">
<mx:TextInput id="ID" width="50" />
</mx:FormItem>
<mx:Label text="Relationships" x="10" y="132"
fontWeight="bold"/>
<mx:TextArea x="345" y="160"
id="friend_profile" width="300" height="150"/>
</mx:Panel>
</mx:Application>
34