Maar wat bedoel ik dan met deze “zware” internet applicaties? In tegenstelling tot FIA, zal iedereen allicht al ooit wel eens hebben gehoord van RIA – Rich Internet Applications. Dit zijn webapplicaties met een rijke gebruikersinterface, m.a.w. webapps die er “goed” uitzien en de interactiemogelijkheden bieden van traditionele desktop applicaties.

Waar men misschien ook al eens van heeft gehoord, zijn Fat Clients, een gemakkelijk bekkende naam voor Heavyweight Clients. Deze zware clients zijn desktop applicaties die een deel van het werk van een server op zich nemen, en dus lichtere servers toelaten – in tegenstelling tot Thin Clients. De kracht van de gebruikers eigen machine wordt op die manier nuttig gebruikt. Fat clients waren een natuurlijke evolutie toen de machine van de eindgebruiker beter werd en zware mainframes uit de mode geraakten. Van terminal-mainframe communicaties ging men dus over op client-server. Later, dankzij de populariteit van het web, is men dan uiteindelijk overgeschakeld op webserver-RIA-browser.

Fat Internet Applications vormen dan een mengsel van RIA met fat clients. Fat clients dus, maar dan in de vorm van een webapplicatie. Een internettoepassing, zeg maar, die een deel business logica bevat om de server – en de netwerkverbinding met de server – te ontlasten. En omdat men niet meer anders kan tegenwoordig, zal deze er ook goed moeten uitzien, en dus een RIA zijn. Men kan zelfs stellen dat FIA’s een evolutie zijn op RIA’s, en dat sommige RIA’s eigenlijk al FIA’s kunnen worden genoemd. Niet alle bestaande RIA’s zijn echter noodzakelijkerwijs FIA’s. Het al dan niet rich zijn heeft eigenlijk niets te maken met het al dan niet fat zijn, en een aantal RIA’s ondersteunen vooral de Look & Feel van de app, en gebruiken de server voor het grootste deel van de achterliggende logica.

Aan de invoering van FIA’s zijn een aantal voor- en nadelen verbonden. Allereerst een nadeel: men moet aan dubbele validatie doen van de ingevoerde gegevens. Een eerste keer in de client, zodat deze er zonder gevaar mee kan werken, en een tweede keer aan de serverkant, omdat men nooit kan garanderen dat het wel degelijk een zich goed gedragende client-applicatie is, die met de server communiceert. Vooral dit tweede zou men al eens kunnen vergeten…

Het grote voordeel is natuurlijk dat zware operaties door de client kunnen worden uitgevoerd. Denk maar aan compressie of encryptie van gegevens. Dit opent een aantal deuren voor applicatieontwikkelaars, die er bij het gebruik van thin clients niet waren. Zo kan men tegenwoordig een applicatie maken voor online gegevensopslag, waarbij de gegevens door de client geëncrypteerd worden. Dit is niet alleen performanter, maar ook veiliger, want de gegevens hoeven niet eens in onvercijferde vorm naar de server te worden gestuurd.

Spijtig genoeg is het momenteel wel mogelijk, maar nog niet zeer vanzelfsprekend om een FIA te bouwen. Er zijn namelijk een aantal zaken nodig, die men vaak slechts door gebruik van plugins ter beschikking heeft in webapplicaties. Om een zeer responsieve gebruikersinterface te hebben, kan het bijvoorbeeld nodig zijn multithreading toe te passen, zodat de user interface niet ‘hangt’ tijdens een zware berekening. Bovendien zou een FIA wel eens veel geheugen kunnen vragen, hetwelke het misschien niet altijd krijgt van de browser.

Momenteel is het nog erg lastig om, gebruikmakende van enkel javascript, een FIA te maken. Technologieën zoals Flash en Silverlight laten dit wel al toe, maar vereisen uiteraard een browser plugin. Er is dus nog nood aan betere frameworks en browserondersteuning.

In mobile devices heeft men een andere oplossing dan browser-plugins: dit zijn de native apps. Deze kunnen gebruik maken van de uitgebreide functionaliteit van het toestel, omdat ze buiten de browser opereren. Het grote nadeel hiervan is natuurlijk dat zulke apps voor elk soort device opnieuw moeten worden geschreven – eigenlijk zijn het gewoon fat clients die eruitzien als een webapp.

Misschien zorgt Html 5 voor een stap in de goede richting. Met Html 5 wordt het mogelijk om stukken javascript code in een aparte thread uit te voeren, wat voor een vorm van concurrency kan zorgen in de applicatie. Verder zal er in de nieuwe markup taal een soort lokaal geheugen voorzien zijn voor applicaties. Op die manier wordt het terug mogelijk om FIA’s te bouwen voor elke browser die Html 5 ondersteunt, zonder dat deze plugins nodig heeft, waardoor men dus platformonafhankelijk zou kunnen ontwikkelen.

Besluit? Het internet van morgen zal zowel de voordelen van internet-connectiviteit kunnen nuttigen, als de voordelen die ontstaan uit steeds krachtiger wordende client-devices, zowel vast als mobiel. De technologie om dit mogelijk te maken is in volle ontwikkeling en Fat Internet Applications zijn begonnen aan hun opmars.

Bovenstaand bericht hebben we allicht allemaal al een paar keer gezien. Alhoewel het nog een hele tijd zal duren eer zulke zaken tot het verleden behoren, is er verbetering op komst. De W3C, een consortium dat webstandaarden beheert, is samen met een hele groep producenten van webtechnologie bezig met het definiëren van de nieuwe HTML-standaard: versie 5. Deze verbetering aan de taal van het web zal het mogelijk maken rijkere website’s te ontwikkelen zonder nood aan plugins zoals Flash, Java Web Start en Silverlight.

Een greep uit de nieuwe mogelijkheden van HTML5:

• Een canvas, waarin rechtstreeks grafische elementen getekend kunnen worden
• Audio- en Videofunctionaliteit
• Drag-and-drop (integratie met de desktop)
• Nieuwe mogelijkheden voor webforms (om het typische verliezen van alle reeds ingevulde vakjes te voorkomen).
• Algemene verbeteringen die het maken van Rich Internet Applications (RIA) moeten vereenvoudigen

Dit alles zorgt ervoor, dat wanneer Html 5 zal ingeburgerd zijn, er minder nood zal zijn aan extra plugins voor de browser om geavanceerde, mooi uitziende webtoepassingen te maken. Dit zal het voor developers eenvoudiger maken om RIAs te ontwikkelen, en ook gebruikers zullen een vlottere surf-ervaring krijgen. Bovendien zal het web ook efficienter worden, want men probeert er ook voor te zorgen dat er voor minder veel grafische zaken (b.v. word-art, eenvoudige tekeningen en mooie drukknoppen) afbeeldingsbestanden nodig zullen zijn, wat de tijd om zulke zaken binnen te halen drastisch kan verminderen.

Het is natuurlijk belangrijk dat er niet alleen een goede standaard is, maar dat er ook manieren zijn om er goed gebruik van te kunnen maken.  In de marge van deze standaardisatie zijn softwaregiganten als google en vmware daarom ook bezig met het onwtikkelen van handige frameworks voor het maken van webtoepassingen. Deze zijn er nu al, en ze worden constant verbeterd. Het spreekt dus voor zich dat ze in de toekomst ook Html 5 zullen gaan ondersteunen.

Voor de client side hebben we bijvoorbeeld Google’s GWT (Google Web Toolkit), een raamwerk dat toelaat om AJAX webapplicaties te schrijven in Java, en ze dan omzet naar javascript dat werkt in alle browsers en zelfs op mobiele toestellen. Dit verhoogt aanzienlijk de productiviteit, en laat ontwikkelaars toe om in een vertrouwde taal te werken.

Fabrikant VmWare, vooral bekend van zijn  virtuele machines, biedt dan weer Spring Roo aan, een lichtgewicht ontwikkelingstool dat toelaat om zeer snel volledige Java-applicaties voor het web te bouwen (dus inclusief het servergedeelte, dat op een applicatieserver zal draaien), en dit ook volledig in Java.

De twee hebben er nu voor gezorgd dat Spring Roo en GWT kunnen samenwerken, waardoor een onwtikkelaar bliksemsnel een volledige client-server applicatie kan opzetten, die er ook nog eens goed uitziet, dankzij de widgets van GWT. Het is nu afwachten hoe krachtig deze technologieën kunnen worden, zodat ook de meest veeleisende bouwers van webtoepassingen er hun applicaties mee kunnen maken. Voor kleinere projecten, die bijvoorbeeld geen gebruik hoeven te maken van een zware SQL-database, staat de ontwikkeling echter al ver genoeg.

Daarbij komt nog Google Apps , een plek waar ontwikkelaars hun webapps beschikbaar kunnen stellen aan het grote publiek, zonder zelf over servers te moeten beschikken. Voeg daar nog allerlei tools aan toe die ontwikkelaars kunnen gebruiken om hun webapps te optimaliseren voor gebruik, en je hebt een volledig ecosysteem in de cloud dat ruimte biedt aan tal van developers om op het web hun ding te doen, en nog veel meer gebruikers die de keuze zullen hebben uit een enorm aanbod van applicaties.

Vooraleer deze frameworks volledig op HTML5 draaien, kan het echter nog even duren, want de standaard heeft spijtig genoeg al veel vertraging opgelopen. Wat echter browserondersteuning betreft, zien we dat steeds meer browsers, met chrome op kop, reeds nu al features van de nieuwe standaard implementeren. Of dit het standaardisatieproces zal versnellen of net zal afremmen (door divergerende implementaties), is nog af te wachten.

Om te besluiten: De evolutie van het web naar een omgeving waarin men niet alleen surft, maar alles kan doen wat men traditioneel via gewone desktop applicaties deed, zal worden ondersteund door een nieuwe versie van HTML. Het kan echter nog even duren vooraleer deze de standaard is, en voorlopig zijn we voor RIAs dus aangewezen op javascript en plugin-frameworks (zoals Flex, javaFX, en Silverlight).