Igang med BlazeDS

- første artikel i serien om Adobes Servers og Services i Flash Platformen

Intro

Efter et vellykket RIA event i KBH sidst i April, har efterspørgslen efter mere viden om Flash Platformen og de services som Adobe tilbyde været enorm

Jeg vil i de følgende par artikler hen over sommeren forsøge at give et point of entrance i forhold til at komme igang med de forskellige typer muligheder.

Denne første artikel vil primært være omkring det at få BlazeDS installeret på en server, samt at få sat sit udviklingsmiljø op lokalt og lave den første lille Chat applikation der bruger BlazeDS messaging.

Om BlazeDS

BlazeDS er en gratis og open source server (gateway) der kan håndtere remoting fra Flash Platformen, og via AMF sende serialiserede objekter mellem en Java backend og Flash Platformen.
BlazeDS var oprindeligt en del af Live Cycle Data Services (LCDS), men er nu blevet åbnet op for alle at få fingrene i.
Herunder ses de elementer der udgør BlazeDS, de nedtonede elementer er elementer der kun findes i LCDS.

Up and Running

En stor udfordring da jeg selv startede med at rode med BlazeDS er, at de fleste tutorials viser hvordan du får BlazeDS op at køre på din lokale maskine, hvilket er fint, men hvad med den “virkelige” verden? Derfor vil en del af denne tutorial være dedikeret til at få sat BlazeDS op på en linux server der rent faktisk findes og kører ude på nettet.

VPS.

Jeg vil udvikle vores lille applikation på en 20$ Slicehost server (http://www.slicehost.com). Alternativt kan en VPS hos yourshelter bruges. En VPS er forkortelsen for Virtual Private Server, og er kort fortalt en virtuel server du selv har fuld kontrol over. Det er altså stadiet mellem et almindeligt webhotel hvor du kun kan få hostet data og køre en række begrænsede server scripts, og en dedikeret server hvor du selv ejer eller lejer konkret hardware.

Hvis du vælger at oprette en slice host er du velkommen til at indsætte asger [snabel a]webyte.dk som vedkommende der har henvist dig, eller hvis du vælger en yourshelter kan du bruge linket her:
yourshelter.net
Det giver mig et 5$ afslag på min næste regning.

Som sagt er det lige meget hvad du vælger, jeg vil tage udgangspunkt i en frisk installation af Ubuntu 8 LTS Hardy.

Tools.

SSH Klient
Til tutorialen skal vi bruge en klient til at “tale” med vores server med. På Mac kan du bruge Terminal og på PC kan du hente gratis programmet Putty ( http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ). Jeg vil ikke gå ind i hvordan du får sat Putty op, da det er lige til og der er en wizard til at oprette nye accounts.
Putty logger selv på for dig, når du vælger den oprettede konto, på Mac via Terminal skal vi selv skrive at vi vil kontakte vores server.

Flash Builder (tidligere kendt som Flex Builder - jeg vil bruge Flash Builder i denne artikel)
Jeg bruger Flash Builder 4 Plugin i Eclipse 3.4 J2EE edition med Flex SDK 4.0.0.
Du kan hente Flash Builder 4 gratis i Beta version på http://labs.adobe.com
Det er ret vigtigt at du har Flash Builder som plugin til Eclipse med java, da vi skal bruge Java Features.

Du finder Eclipse IDE for JAVA EE developers her:
http://www.eclipse.org/downloads/

FTP
Når vi har vores server oppe at køre, vil vi bruge en ftp klient til at uploade de applikationer vi laver. Jeg bruger Cyberduck til Mac, og du kan bruge winSCP eller lignende til Pc. (begge er gratis).

Setting up the server

Log ind på din nye server.
Putty starter selv en SSH session, og beder dig indtaste dit password (som du har fået fra Slicehost eller Yourshelter) og på Mac åbner du Terminal og skriver:

ssh root@[din ip du har fået til din VPS]

og herefter, når Terminal beder dig om det, indtaster du dit password.

Her efter er der ikke forskel på Pc og Mac delen. Alt følgende indtastes i Terminal eller Putty hvor vi nu har en SSH session kørende med vores server.

Ny Admin user.

Lad os starte med at oprette en ny bruger vi kan bruge til at administrere vores ny server. Denne bruger vil vi videre give mulighed for at logge på via FTP:

useradd -m Admin

Vi giver serveren besked om at tilføje en bruger (useradd) og lave en ny folder struktur et såkaldt “home” dir (-m) og slutteligt siger vi at brugernavnet skal være Admin (det kunne være hvad som helst).

Nu er brugeren oprettet, og vi skal have lavet et password til den nye bruger:

passwd Admin

Herefter spørger systemet dig om hvad det nye password skal være, og det skal du gentage endnu engang efter du klikker enter.

Med vores bruger på plads, kan vi nu gå i gang med at sætte de værktøjer op vi skal bruge på vores server.
Vi skal bruge både Java og en FTP server, begge noget vi kan hente med Ubuntu’s pakke program (APT). APT er et værktøj til at hente software pakker remote, og installere og administrere dem via f.eks. en SSH session, som den vi har åben nu.
Inden vi henter pakker, skal vi sikre at vi har indstillet APT til at kigge efter pakker de steder vi har brug for det.
Du kan læse mere mere om APT og de forskellige Ubunutu pakke “sites” her:

http://www.debian.org/doc/manuals/apt-howto/
https://help.ubuntu.com/community/Repositories/Ubuntu

For at vi kan downloade Java som en pakke skal vi modificere sources.list som er den fil der peger på de steder vi kan hente pakker fra.
skriv

cd /etc/apt

Det bringer dig ind i APT’s mappe, hvor sources.list blandt andet er.
Med en UNIX teksteditor som f.eks. vim kan vi nu åbne listen og udføre ændringerne der skal til. Skriv:

vim sources.list

Det åbner sources.list listen i VI improved som er en tekst baseret word processor ala Word eller Pages, bare uden UI. Alt foregår gennem tekst kommandoer.

Du skulle gerne se noget ala det følgende:

deb <a href="http://archive.ubuntu.com/ubuntu/" title="http://archive.ubuntu.com/ubuntu/">http://archive.ubuntu.com/ubuntu/</a> hardy main restricted universe
deb-src <a href="http://archive.ubuntu.com/ubuntu/" title="http://archive.ubuntu.com/ubuntu/">http://archive.ubuntu.com/ubuntu/</a> hardy main restricted universe
 
deb <a href="http://archive.ubuntu.com/ubuntu/" title="http://archive.ubuntu.com/ubuntu/">http://archive.ubuntu.com/ubuntu/</a> hardy-updates main restricted universe
deb-src <a href="http://archive.ubuntu.com/ubuntu/" title="http://archive.ubuntu.com/ubuntu/">http://archive.ubuntu.com/ubuntu/</a> hardy-updates main restricted universe
 
deb <a href="http://security.ubuntu.com/ubuntu" title="http://security.ubuntu.com/ubuntu">http://security.ubuntu.com/ubuntu</a> hardy-security main restricted universe
deb-src <a href="http://security.ubuntu.com/ubuntu" title="http://security.ubuntu.com/ubuntu">http://security.ubuntu.com/ubuntu</a> hardy-security main restricted universe

Det er de source sites APT kigger på lige nu.
Det eneste vi skal gøre er at føje ordet multiverse for enden af alle definitionerne. Det fortæller APT at det også må kigge efter pakker i multiverset. Se mere info omkring APT.

Det færdige resultat skal se sådan her ud:

deb <a href="http://archive.ubuntu.com/ubuntu/" title="http://archive.ubuntu.com/ubuntu/">http://archive.ubuntu.com/ubuntu/</a> hardy main restricted universe multiverse
deb-src <a href="http://archive.ubuntu.com/ubuntu/" title="http://archive.ubuntu.com/ubuntu/">http://archive.ubuntu.com/ubuntu/</a> hardy main restricted universe multiverse
 
deb <a href="http://archive.ubuntu.com/ubuntu/" title="http://archive.ubuntu.com/ubuntu/">http://archive.ubuntu.com/ubuntu/</a> hardy-updates main restricted universe multiverse
deb-src <a href="http://archive.ubuntu.com/ubuntu/" title="http://archive.ubuntu.com/ubuntu/">http://archive.ubuntu.com/ubuntu/</a> hardy-updates main restricted universe multiverse
 
deb <a href="http://security.ubuntu.com/ubuntu" title="http://security.ubuntu.com/ubuntu">http://security.ubuntu.com/ubuntu</a> hardy-security main restricted universe multiverse
deb-src <a href="http://security.ubuntu.com/ubuntu" title="http://security.ubuntu.com/ubuntu">http://security.ubuntu.com/ubuntu</a> hardy-security main restricted universe multiverse

(læs om hvordan du bruger vim her:
http://www.linuxhelp.net/guides/vim/

Herefter er vi klar til at bruge APT.
Luk vim igen med kommandoen:

:wq

For at skrive (write) og lukke (quit) og vi er nu tilbage i vores kommando prompt i /etc/apt mappen.
For at APT kan vide hvad der er til rådighed af pakker, skal vi have opdateret APT.

apt-get update

Det afgiver et langt output i konsollen hvor du kan se at en lang række elementer opdateres.

For at se hvad vi har af mulige pakker bruger vi en søge funktion i APT. Vi er interesseret i at se om Suns Sava 6 er til rådighed. Det ser vi sådan er:

apt-cache search sun java 6

Her skulle du gerne kunne se en række Java entiteter listet, noget ala det her:

libjaxp1.3-java - Java XML parser and transformer APIs (DOM, SAX, JAXP, TrAX)

java-package - utility for building Java(TM) 2 related Debian packages

ia32-sun-java6-bin - Sun Java(TM) Runtime Environment (JRE) 6 (32-bit)

sun-java6-bin - Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent files)

sun-java6-demo - Sun Java(TM) Development Kit (JDK) 6 demos and examples

sun-java6-doc - Sun JDK(TM) Documention -- integration installer

sun-java6-fonts - Lucida TrueType fonts (from the Sun JRE)

sun-java6-javadb - Java(TM) DB, Sun Microsystems' distribution of Apache Derby

sun-java6-jdk - Sun Java(TM) Development Kit (JDK) 6

sun-java6-jre - Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files)

sun-java6-source - Sun Java(TM) Development Kit (JDK) 6 source files

 Den vi er interesseret i er jre, runtime Environmentet.

Den vi er interesseret i er JRE, runtime Environmentet.
Med kommandoen:

apt-get install sun-java6-jre

-starter vi hentning og efterfølgende installation af Java Runtimet på vores server.
Du vil blive bedt om at skrive “yes” til at du vil installere, samt at godkende licensen (brug TAB for at navigere til ok og yes, og for Enter at vælge), for brugen af Java.

Nu har vi Java installeret, så lad os med det samme gå videre til at få installeret Tomcat server, der kan køre BlazeDS. Adobe har været så venlige at bundle alt vi skal bruge samt en masse lækre eksempler i en såkaldt turn-key pakke.
Den kan hentes på opensource.adobe.com og bruges direkte på din desktop computer. Men vi kan også hente den ned på vores server - og det er det vi vil gøre her.

Gå ind på opensource.adobe.com og browse ind til BlazeDS’ download sektion (http://opensource.adobe.com/wiki/display/blazeds/Release+Builds). Der finder du et link til turn-key’en. Kopier det link og vend tilbage til Putty eller Terminal.
I Putty eller Terminal starter vi med at navigere til vores Admin bruger home mappe, - der vil vi nemlig hente BlazeDS og Tomcat serveren ned. Skriv

cd /home/Admin

Nu er vi i Admins home så med følgende kommando kan vi nu starte hentning af BlazeDS

wget http://flexorg.wip3.adobe.com/blazeds/3.0.x/milestone/3978/blazeds-turnkey-3.2.0.3978.zip

Bemærk at det er en god idé at du selv lige finder seneste link på opensource.adobe.com, da der kan være nyere versioner ude siden denne artikel er skrevet.

Det starter et download af turn-key’en til vores server. Du kan i outputtet følge med i hvordan det går.
Når zippen er nede er næste skridt at udpakke zippen. Du kan lige tjekke at filen er kommet ned, ved at skrive:

ls

hvilket viser en liste af de filer der er i den mappe hvor i du befinder dig.

Til at udpakke er der forskellige muligheder. Den letteste er at tage fat i APT igen og hente programmet Unzip ned. Så lad os gøre det med det samme. Skriv følgende:

apt-get install unzip

Du ser igen en install process og nu er Unzip hentet ned.
Det betyder at vi nu kan skrive

unzip blazeds-turnkey-3.2.0.3978.zip

eller hvad din fil nu hedder. Er det ikke super smart? Der er stort set et lille stykke software til alt hvad du ønsker at gøre med din server.
Nu udpakkes filen og du kan se et stort output med en masse fil navne. På et tidspunkt er alt udpakket og du kan se at konsollen er tilbage til sit idle state. Prøv at vise filerne i mappen igen med:

ls

Nu skulle du gerne se en række mapper og filer ligge der.

Inden vi går igang med at bruge de nye filer skal vi lige sikre at vores Admin bruger kan skrive og læse disse filer. Det gør vi således:

chown -R Admin /home/Admin

Her skifter vi ejer af filerne til at være Admin, og det skal gælde for alle filer i home/Admin og deres undermapper.

Den mappe vi er interesseret i er tomcat mappen. Den indeholder vores server, som vi om lidt skal bruge til at servicere vores BlazeDS/Flex apps.

Tomcat er en Java server, eller en såkaldt application container. For at vi kan starte vores server, skal vi altså først have sikret os at Tomcat kan finde og bruge Java VM’en. Der er forskellige måder at gøre det på. I denne artikel vil vi igen bruge VIM til at editere serverens environment fil.
Inden vi gør det skal du lige sikre dig at Java er installeret samme sted som serveren vi bruger her. Skriv:

cd /usr/lib/jvm/java-6-sun/jre

Hvis ovenstående kommando ikke navigerer dig til stigen /usr/lib/jvm/java-6-sun/jre, så ligger din Java VM et andet sted. Du kan bruge kommandoerne cd og ls for henholdsvis at skifte directory og liste filerne i det dir du befinder dig i. Et godt sted at begynde at kigge, er i /usr.

Når du har fundet stien til jre folderen kan vi nu associere JRE_HOME variablen, som er en såkaldt environment variable, som er en slags global variabel alle applikationer kan tilgå. Den skal vi have defineret med vores sti, så tomcat kan bruge den til at finde Java.
Derfor skriver vi følgende:

export JRE_HOME=/usr/lib/jvm/java-6-sun/jre

Det deklarere JRE_HOME med vores sti. Men kun i denne session. Hvis du logger ud og logger ind igen på din server, er variablen nulstillet, og du skal derfor deklarere den igen. I en senere tutorial ser vi på hvordan vi kan deklarere variabler der bliver ved med at eksistere.

Har du mod på at læse lidt nærmere på hvordan du sætter environmental variabled permenent, kan du her se en god og kort beskrivelse på engelsk.
https://help.ubuntu.com/community/EnvironmentVariables#Persistent%20envi...

Nu er det blevet tid til at teste om vores server virker.
Naviger til bin mappen i tomcat:

cd /home/Admin/tomcat/bin

Her kan vi starte og stoppe vores server fra. Vi starter vores server sådan her:

sh catalina.sh run

Det skulle gerne starte en lang række outputs, som alle stammer fra Tomcat, der nu starter op.

Du vil måske bemærke et der kommer et trace der fortæller at hsql samle databasen ikke kunne startes. Det er alt sammen ok. Vi har ikke sat vores database op endnu, og videre vil vi senere fjerne de build-in samples der er med fra Adobes side.
Slutteligt skulle du gerne se en besked ala denne her, som bekræfter at tomcat er startet og hvor mange mili sekunder det tog at starte op:

INFO: Server startup in 8900 ms

og nu til den endelige test. Nu hvor vores server kører, burde vi jo med en browser kunne se om der er liv. Så åben din foretrukne browser og indtast den IP du har fået til din server, og skriv :8400 bag ved, for at indikere at det er port 8400 du vil tilgå.

Du kan prøve de forskellige samples af, der er bundled med turn-key install pakken. Bemærk, da vi ikke har sat en database op endnu, virker nogle af de samples der omhandler læsning og skrivning til og fra en database ikke.

Det betyder at vores server kører som den skal. Så nu er den svære del overstået, og meget af det resterende ligger i at lave vores Flex og Java applikation.
Inden vi bevæger os over i Eclipse skal vi lige gøre et par sidste småting. Den første ting er at stoppe vores server igen. Nu ved vi at den virker, og derfor kan vi lige nu stoppe den. Videre skal vi have installeret en FTP server, så vi kan lægge applikationer op med vores Admin bruger. Lad os starte med at stoppe vores server igen. Med Terminal eller Putty åben og stadig med vores process der startede tomcat åben, stopper vi tomcat ved at taste denne tastekombination:

CTRL + C

Det skulle gerne give din en markør tilbage og skrive et output om at Tomcat nu er bragt til standsning.

Det var første punkt. Næste er at få installeret en FTP server. Det lyder umiddelbart mere farligt end det er. Igen kan vi benytte os af det super effektive og let tilgængelige pakkeprogram APT. Den FTP server jeg her vil bruge hedder proFTP og den har jeg valgt da den kører fint på både yourshelter og slicehosts installationen af Ubuntu 8 LTS.

Vi starter installationen af proFTP sådan her:

apt-get install proftpd

Skriv “y” til at fortsætte og vælg “standalone” når du skal vælge type. Efter et øjeblik stopper installationen og vi har fået installeret en FTP server. Det var let ikke?
Start nu din foretrukne FTP klient op (Cyberduck bruger jeg), og indtast den IP du har fået, samt Admin som brugernavn og det kodeord du gav denne bruger da du oprettede den. Det skulle gerne vise dig samme billede, som vi før så via terminalen. Nemlig vores Admins “hjemmemappe” (/home/Admin), hvor vores BlazeDS filer ligger.

Med det på plads har vi fået bekræftet at Tomcat og BlazeDS er installeret og kører på vores server. Nu kan vi vende næsen hjemad, nærmere bestemt til vores localhost og sætte vores udviklingsmiljø op. På den måde kan vi have BlazeDS kørende lokalt også, mens vi arbejder så vi kan teste at vores app virker inden vi lægger den ud.

I denne første artikel om BlazeDS er det en simpel chat der bruger BlazeDS’ messaging service. I senere artikler, hvor vi ikke skal bruge tid på at sætte BlazeDS op, vil vi grave langt dybere ned i rigere funktionaliteter og anvendelser med BlazeDS.

Inden vi hopper over i Flash Builder starter vi med at hente samme turn-key ned på vores lokale maskine, som vi installerede på serveren.
Placer .zip filen i en mappe du bruger til udvikling og let kan finde igen, og udpak indholdet. - vi skal nemlig have Eclipse til at snakke sammen med Tomcat serveren om et øjeblik.

Inde i Flash builder starter vi med at oprette et nyt projekt, af typen Flex project.

På New Project Wizard siden, starter vi med at give projektet et navn (SimpleChat), og inden du klikker finish, skal vi lige have sat server delen op. I drop down boksen, vælger du J2EE server, og afhængig om du er Gumbo eller Flex 3 bruger vælger du LCDS eller BlazeDS. Sidste vigtige ting, inden du klikker på “next” er at du vinger af i “create combined Flex and Java project”. Når du siger ja til dette, laves ét projekt hvor vi kan udvikle både AS og Java i samme. *NU* må du klikke “next”.  

Det næste billede i wizarden efterspørger din J2EE server. Den står sikkert til “none” da der ikke er sat nogen op endnu. Så klik på “new” knappen til højre for drop down boksen.

Det åbner “Define New Server” dialogen. Lad server navnet stå til “localhost” som er dets default, og hop ned i feltet for valg af server type.

Her kan du scrolle ned til “T” sektionen, eller begynde at skrive Tomcat i filter filtrerings feltet.

På listen over Tomcat servere vælger du Tomcat Server 6.0. Når du markere denne, bliver feltet med server navn, aktivt og du kan nu også klikke “next”. Lad navnet være som det er, og klik “next”.

Næste skærmbillede beder dig definere hvor du gemmer Tomcat installationen henne på din computer. - det er jo netop den vi lige har hentet og udpakket i vores Turnkey. Godt jeg bad dig huske på hvor du placerede mappen . Brug browse knappen og naviger til, og vælg “tomcat” folderen i den udpakkede blaze turn-key.
Klik herefter på finish.

Det bringer os tilbage til vores New Project Wizard, hvor vi nu, efter denne lille detour, kan vælge vores nye server på listen.

Som du kan se kan vi stadig ikke klikke “next” da vi bliver bedt om at “deploy war file”. -
afhængigt af om du bruger Flash Builder 4, eller Flash Builder 3 vil dette step se en smule forskelligt ud.

WAR eller web archive er en pakket zip fil, der indeholder information omkring hvad pakken indeholder, ud fra nogle standarder, helt som en swc fil, også blot er en zip fil, med specielt info Flash eller Flex kan forstå. BlazeDS serveren kommer som en WAR fil, der kan deployes ud i dit projekt. Det vil sige at alle klasser og det du skal bruge for at arbejde med BlazeDS, bliver tilgængeligt i dit projekt. Igen, helt som var det en SWC med et framework, du skulle bruge for at kunne arbejde med AS. WAR filen og de indeholdte JAR filer er blot den måde Java pakker sine ting.

Naviger til din udpakkede BlazeDS turnkey mappe og vælg blazeds.war filen.

Nu burde du kunne klikke på “finish” og se dit projekt blive oprettet i Eclipse.
I din navigator vil du nu se hele to mapper. Dels dit SimpleChat projekt, men også en mappe der hedder “Servers”. I sidstnævnte er den Tomcat server du netop har defineret.

BETA WORK AROUND

Hvis du bruger Flash Builder 4 Beta 1, kan du have problemer med at dels at deploye WAR filen og ædre af port nummeret for hvor serveren befinder sig.
Løsning af Deploy problemet: Kopier din blazeds.war fil, og ændre .war til .zip og udpak indholdet. Overskriv indholdet i dit Java/Flex projekts WebContent mappe, med indholdet fra den unzippede .war fil.
Løsning til port ændring: Åben .actionsScriptProperties filen og i den lange linje der hedder "Additional compiler arguments" skal du finde argumentet: rootURL="http://localhost:8080/DitProjekt"
- og ændre 8080 til f.eks. 8400

Project Structure

Udfold dit Java/Flex projekt, og se hvad der ligger i det. Har du arbejdet med Flex før, vil du straks kunne se at der ligger væsentligt mere end hvad der plejer. src og lib folderne til AS og MXML er nu omdøbt til flex_lib og flex_src. Mappen der kun hedder src er til Java kode.
Videre kan du se en mappe med navnet WebContent. WebContent er den mappe hvori vores app samles, bygges og til sidst pakkes og som ender ude på serveren.
Hvis du folder den ud vil du kunne se at indholdet i WEB-INF mappen indeholder en række undermapper.

/classes indeholder de compilerede Java klasser vi skriver i src mappen - nærmest beslægtet med vores almindelige bin folder hvori vores .swf filer ryger i.
/flex mappen indeholder alle de config filer vi senere skal rode med for at definere hvordan vores Client kan snakke sammen med BlazeDS.
/lib indeholder alle de .jar filer som der udgør BlazeDS. Det var dem vi deployede ud, da vi for lidt siden valgte blazeds.war filen.

Det var et hurtigt overview over vores kombinerede Java/Flex projekt. Inden vi konkret går igang med at skrive vores Flex applikation, synes jeg lige vi skal starte med at teste om vores lokale server virker.
Hop op i flex_src mappen og åben SimpleChat.mxml filen.
Her skriver vi lige en enkelt linje, så vi kan se at der er hul igennem. Jeg har valgt at skrive følgende.

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">
	<s:SimpleText text="Hello BlazeDS" />
</s:Application>

Gem din fil, og lad os starte vores server op.
I menu linjen i toppen af Eclipse vælger du Window -> Show View -> Other -> Servers.
Det åbner Server panelet op.

Det skulle gerne vise vores ny oprettede Tomcat server.
Højreklik på serveren vælg Add/Remove Projects menuen.

Her skulle du så gerne se vores SimpleChat projekt i venstre side, marker og vælg Add, så projektet ryger over i boksen til højre. Klik “finish”.

Nu har vi fået fortalt vores Tomcat server at den skal servicere vores SimpleChat projekt. Højreklik på serveren igen, og vælg “start”.
Det starter serveren op, og du oplever sikkert at der skrives en række linjer til konsolen.

Ready for Launch

Nu er vi næsten klar. Det eneste vi lige skal gøre, er at sikre os at Flash Builder publicerer til samme url som vores server kører på. Som du måske kan huske skrev vi 8400 som port nummer da vi testede på vores linux server, og Flex tager som udgangspunkt port 8080 så det skal vi lige ændre.
Højreklik på SimpleChat projektet, og vælg properties.
På den lange liste af muligheder, vælger du Flex Build Path, og til højre, nederst i output folder URL ændre du 8080 til 8400, og klikker OK.

Det burde være alt vi skal gøre for at sætte det op. Lad og prøve at køre vores applikation. Vælg Run, og du skulle nu gerne se din standard browser åbne din flex app op, med det test indhold du har sat ind.
Rock On, din første BlazeDS app -næsten i hvert fald.

Lets Get CHATTING

Lad os komme igang med at lege med vores første lille use case med Flex og BlazeDS. En simple Chat hvor alle der browser ind på vores hjemmeside kan Chatte med andre brugere. Ikke noget fancy (endnu) med bruger logind og personlige beskeder. Det gemmer vi til næste artikel.

Config.

Når vi arbejder med BlazeDS skal vi i forbindelse med den kommunikation vi gerne vil skabe mellem Flash Playeren og BlazeDS konfigurere hvad det er vi gerne vil sende, eller modtage, og hvordan vi ønsker at gøre det. En stor del af denne konfigurering foregår i config filerne, som vi kort så på i forrige afsnit (WEB-INF/flex mappen).
Den nærmere gennemgang af de forskellige services, og definition af channels, destinations osv. lader vi stå. Denne artikel er allerede lang nok og der er allerede meget ny information, som er vigtigere for dig at tage med. Så det vi vil se nærmere på i dag, er messaging-config.xml filen og services-config.xml filen.
Med disse to, kan vi definere en messaging service, som vi kan bruge til at sende og modtage beskeder mellem andre klienter der er forbundet med vores server.

Lad os starte med at åbne services-config.xml. Den indeholder en række definerede channels. Kort beskrevet er en channel, det rør, klient og server kan aftale at snakke sammen gennem over nettet. Det smarte er at vi kan definere størrelsen, udseendet og formen på røret, gennem denne xml fil. Ca. midt i filen er der defineret en channel kaldet my-polling-amf, som ser interessant ud til vores formål.

<channel-definition id="my-polling-amf" class="mx.messaging.channels.AMFChannel">

            <endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.AMFEndpoint"/>

            <properties>

                <polling-enabled>true</polling-enabled>

                <polling-interval-seconds>4</polling-interval-seconds>

            </properties>

        </channel-definition>

Id’et på channel’en siger os at det er et rør der er sat op til at sende data i amf format, det kan vi også se på class attributten der også refererer til en AMFChannel klasse. Endpoint noden beskriver hvor konkret på serveren denne channels ende sidder. Altså med andre ord, hvor røret der er hæftet på serveren sidder, og igen er der her defineret en klasse, AMFEndpoint, som er den klasse der står for at styre server enden af “røret”. Videre er der defineret nogle properties. polling-enabled er sat til true, og polling-interval-seconds er sat til 4.

Polling er begrebet om kontinuerlig check for om andre programmer (f.eks. en client) er tilgængelig for data modtagelse.

Du kan se at der er andre channels defineret, og i senere artikler skal vi også lære at definere vores egne channels. For nu, er vores my-polling-amf channel helt fin til vores formål.

Lad os derfor hoppe lystigt videre til messaging-config.xml filen.

Den er noget mere skrabet end vores services-config.xml. Her er kun et adapter tag og et default-channel tag.
Det skarpe øje vil måske bemærke at der i vores default-channel tag faktisk refereres til selv samme channel vi netop så på. Det betyder, at alt hvad vi definerer af typen messaging services, som default får my-polling-amf røret at “tale” i.

I vores eksempel skal vi have opsat en messaging service, som vores klienter kan bruge som destination for den chat vi bygger. Derfor opretter vi en såkaldt destination. En destination giver et bestemmelsessted for vores Flex applikation at kommunikere data til. Så nu har vi altså en channel som er det rør vi gerne vil sende data med, vi har et endpoint som er enden på røret der modtager data på serversiden, og vi har en destination som beskriver røret og den del af serveren der efter at dataene er ankommet gennem røret, skal have data.

I vores eksempel her, skal vi ikke have noget ekstra på serveren, ud over det der allerede ligger i BlazeDS, så alt vi skal gøre er at definere et destinations id:

<destination id=”simpleChat” />

Som nævnt før behøver vi ikke definere en channel for vores destination, da der er defineret en default-channel.

Med disse ændringer på plads, kan vi nu hoppe over i Flex.
Vi vil i vores SimpleChat applikation gøre brug af Producer og Consumer komponenterne. Kort fortalt er de, som navnene antyder istand til dels af producere messages og consumere messages. Så i en tovejs chat, skal vi selvfølgelig både kunne consume og produce og bruger derfor begge to.
Resten er almindelig boilerplate mxml der giver os en knap samt et par input felter.
Koden for vores app er kommenteret med hvad der foregår.

<?xml version="1.0" encoding="utf-8"?>

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/halo" minWidth="1024" minHeight="768">

 

<fx:Declarations>

	<!-- I vores declarations tag laver vi en producer og s¾tter dens destination til simpleChat, den destination

	vi lavede i messaging-config.xml filen. Videre hŒndterer vi fault events fra produceren, som har fŒet id'et producer-->

	<mx:Producer destination="simpleChat" id="producer">

		<mx:fault>

			trace("FAULT, ",event);

		</mx:fault>

	</mx:Producer>

 

	<!-- VI deklarere en consumer som g¿r at vi kan abonnere pŒ messages der kommer ind i vores destination, igen s¾tter vi 

	destination til simpleChat som defineret i config'en. Vi definere message eventet pŒ Consumer objektet til at

	f¿je den besked der ankommers body element til vores output textfelt -->

	<mx:Consumer destination="simpleChat" id="consumer" >

		<mx:message>

			op.text += event.message.body+"\n";

		</mx:message>

	</mx:Consumer>

</fx:Declarations>

 

<!-- NŒr vores applikation er f¾rdig med at loade og dispatcher et creationComplete event, s¾tter vi vores consumer igang med 

at abonnere ved at kalde subscribe  -->

<s:creationComplete>

	consumer.subscribe();

</s:creationComplete>

 

 

 

 

	<fx:Script>

		<![CDATA[

			import mx.messaging.messages.AsyncMessage;

 

 

			/* en bindable variabel til at holde pŒ det brugernavn der logges ind med  */

			[Bindable]

			private var _userName:String;

		]]>

	</fx:Script>

 

 

<!-- For eksemplets skyld definere vi to states, idle er applikationens start state, og ved login gŒr applikationen i chatting-->

<s:states>

	<mx:State name="idle" />

	<mx:State name="chatting" />

</s:states>

 

 

<s:VGroup>

<!-- En simpel text med vore brugernavn-->

<s:SimpleText text="Logged in as {_userName}" includeIn="chatting" />

 

<!-- Vores output text, som l¿bende viser den igang v¾rende chat -->

	<s:TextArea editable="false" id="op" width="100%" height="100%" includeIn="chatting" /> 

 

	<mx:HRule width="100%" />

	<!-- En hj¾lpende text til vores UI-->

	<s:SimpleText>

		<s:text.idle>Type in your user name</s:text.idle>

		<s:text.chatting>Type Chat message and click submit</s:text.chatting>

	</s:SimpleText>

 

	<!-- Vores input felt til navn i idle state og til chat beskeder i chatting state, vi definere properties til at have forskellige

	v¾rdier alt efter hvilket state vi er i-->

	<s:TextArea id="ta">

		<s:width.idle>200</s:width.idle>

		<s:height.idle>20</s:height.idle>

		<s:width.chatting>100%</s:width.chatting>

		<s:height.chatting>100</s:height.chatting>

	</s:TextArea>

 

	<!-- Vores knap til dels at logge ind og submitte chat beskeder til serveren.-->

	<s:Button>

		<s:label.idle>Log In</s:label.idle>

		<s:label.chatting>Submit</s:label.chatting>

 

		<!-- I idle samler knappens klik vores brugernavn op og skifter state-->

		<s:click.idle>

			_userName = ta.text;

			ta.text = "";

			currentState = "chatting";

		</s:click.idle>

 

		<!-- I chatting state laver knappens click en nye AsyncMessag og sender det indhold der er i vores input felt afsted

		ved at kalde producers send metode-->

		<s:click.chatting>

			var m:AsyncMessage = new AsyncMessage();

			m.body = _userName.toUpperCase()+" says: "+ta.text;

			ta.text = "";

			producer.send(m);

		</s:click.chatting>

	</s:Button>

</s:VGroup>

 

 

</s:Application>

Læg mærke til hvor let og lækkert det er blevet at arbejde med states i Gumbo.

Nu er vi klar til at prøve vores chat af. Inden vi kører Flex app’en skal vi lige have restartet vores tomcat server, så vi er sikre på at vores ændringer i config filerne er taget med. Højreklik på serveren i server panelet og vælg “restart”.

Nu må du få lov til at prøve din Flex chat af. Kør applikationen, og forhåbentligt dukker der noget lignende dette her op:

Prøv at skrive noget i feltet og klik submit. Nu skulle du gerne se din text komme til syne i chat vinduet (øvre vidue). Det er selvfølgelig fint nok, men lad os lige åbne endnu et vindue og prøve om chatten nu også virker mellem flere brugere. Kopier URL’en fra det vindue du har åbent nu, og åben endnu et browser vindue og indsæt URL’en så du har to SimpleChat applikationer kørende på samme tid. Prøv så af om chatten virker mellem de to vinduer.

Fantastisk, din første BlazeDS chat applikation!
Ja køn er den ikke og den mangler endnu en masse features for at være på højde med MSN, Skype eller lignende, men nu er fundamentet lagt og du har sikkert selv masser af ideer til hvad der kunne være sjovt at tilføje.

Inden jeg helt slipper taget i dig, for denne gang, så skal vi lige runde vores server del af. Jeg ved at det har været en lang rejse, indtil nu, men hold ud bare lidt endnu, vi er næsten færdige.

Det er fint at vores chat kører lokalt, men lige som hvis man kun er én bruger på en chat, er det heller ikke i længden sjovt kun at kunne køre chat applikationer på samme maskine. Så derfor skal vi selvfølgelig prøve at lægge vores nye app ud på vores rigtige web server, og se om den virker.

Første skridt er at pakke vores app til en WAR så vi kan aflevere den til Tomcat. Tomcat kender WAR formatet, og ved hvordan den skal udpakke og kører indholdet i sådan en fil.
Det er let at lave en WAR fil. Alt du skal gøre, er at højre klikke på dit SimpleChat projekt, vælge “export”.

I Export dialogen vælger du WAR (web -> WAR file), klik næste og vælg destination for din WAR fil. Lad default navnet stå som det er og klik finish.

Real World Deploy

Med denne war i hånden er vi klar til at deploye online. Så lad os starte vores FTP program op, hvis du ikke allerede har det åbent. Log ind som vores Admin bruger og naviger til tomcat/webapps/ og upload din SimpleChat.war file hertil.

Nu skal vi blot starte vores Tomcat server igen, så åben terminal/putty og naviger til /home/Admin/tomcat/bin folderen og skriv som sidst

sh catalina.sh run

Husk, at har du haft lukket terminal eller putty skal du følge steppet med at deklarere JRE_HOME variablen i det tidligere afsnit igen.

Når output tracet er færdigt burde du dels kunne se i din FTP folder at der nu ligger en rigtig mappe ved navn SimpleChat.
Men lad os hoppe over i browsen og se om der er hul igennem.
Skriv ip’en på din server, samt :8400 for portnummer og efterfølgende /SimpleChat/SimpleChat.html

I mit eksempel ser URL’en sådan her ud: http://173.45.229.31:8400/SimpleChat/SimpleChat.html
(det er ikke sikkert at denne URL bliver ved med at virke)

Det skulle gerne åbne samme app op som vi så lokalt, så prøv at åbne et vindue til og kopier URL’en og se om chatten virker.

Outro

Det var første skud på stammen om BlazeDS. Målet med denne første artikel var primært at få dig til at føle tryg ved at arbejde med Server side, og sætte BlazeDS op på en rigtig server og ikke kun lokalt. Videre var målet at vise dig hvor let en applikation kan tilføjes elementer der giver realtime kvaliteter som f.eks. en chat eller lignende.

Du sidder helt sikkert med flere spørgsmål end svar lige nu, men det er bestemt også meningen, for vi har bevæget os milevidt i denne artikel, fra UNIX shell scripting på en remote linux box, til Tomcat server installation og Java VM til Flex og BlazeDS opsætning og udvikling. Skulle vi have dækket alle disse elementer helt i bund skulle dette ikke have været en artikel men en fler-binds bog serie.

I næste afsnit af min serie om BlazeDS tager vi et nærmere kig på det der udgør BlazeDS - det være sig de services vi kan bruge, mere om hvordan vi laver channels samt hvordan vi laver Java klasser der kan snakke sammen med Flex via BlazeDS. Så hold øje med FlashForum.dk hvor næste afsnit lader sig finde i nær fremtid.

Slutteligt håber jeg at du har lært noget nyt og ikke mindst fået vagt din interesse for at leje videre med BlazeDS.

Tak fordi du læste med.

Kredit:

STOR Tak til Atmos og Supermoos for deres review af artiklen!

Asger Laursen
Developer / Technical Architect
Company: www.webyte.dk | Blog: www.asgerlaursen.com |Twitter: www.twitter.com/Flashger

Om forfatteren

Asger er til dagligt Technical Architect hos webyte i Århus, hvor han arbejder med Rich Internet Application arkitektur med særlig vægt på Flash Platformen, med Flash Player og AIR runtime på klient siden, og BlazeDS/LCDS på server siden. Asger er Certificeret Flex og AIR expert, Dansk Adobe User Group Manager samt Dansk Adobe Community Expert.