Tijd dan voor een denkoefening: we gaan de klassieke manier van ontwerpen toepassen op de werking van een McDonalds restaurant…

Synchrone verwerking

Bij McDonalds is de verwerking van de bestellingen ontkoppeld van het vervaardigen van de hamburgers.  Beeld u in dat een verkoper verantwoordelijk zou zijn voor de hele (verticale) keten.   Hij zou de bestelling opnemen, de hamburger klaarmaken,de afrekening geven en slechts dan de volgende klant bedienen.  Als deze handeling 5 minuten duurt, kun je met één verkoper 12 klanten kunnen bedienen per uur.

Hij zou niet weten dat de volgende bestelling identiek zou zijn.. Hij zou voortdurend van context moeten veranderen (handen wassen), geld in ontvangst nemen.   Ook zou er erg moeilijk samengewerkt kunnen worden tussen de verschillende verkopers. Niet echt efficiënt dus.

Geen concurrency control (volledige parallellisatie)

Wat als je 24 klanten per uur wil bedienen? Per veelvoud van 12 moet er een extra verkoper aangeworven worden.  En wat als op een bepaald moment  deze 12 klanten tegelijk zouden aankomen?  De 12de zou een uur moeten wachten…

Maar wacht — deze verkoper kan misschien wel verschillende bestellingen tegelijk aannemen? (cf. multithreading) In het extreme geval wordt elke nieuwe bestelling meteen door een verkoper behandeld.  Hij is dan tegelijk bezig met het afhandelen van een betaling, het maken van een paar hamburgers, het opnemen van enkele bestellingen.  Iedereen ziet wel in dat de efficiëntie van deze verkoper drastisch zal dalen door deze “parallellisatie” –– hij beschikt immers slechts over beperkte resources (kan bv. maar N woorden per minuut schrijven – I/O)

Het is duidelijk dat er een optimale trade-off moet gevonden worden tussen de hoeveelheid parallellisatie (# tegelijk behandelde requests door een machine) en de grootte van de wachtrijen.  Stel dan nog dat je “oneindig” veel verkopers kunt aannemen… Op een bepaald moment is er een plaatsgebrek, niet?  Het evenwicht bevindt zich typisch niet aan een van de extremen en hangt af van de bezoekpatronen van de McDanolds —  misschien komen er nooit 12 mensen tegelijk aan?

Centraal register met recepten (centrale database)

Omwille de kwaliteit te garanderen, stelt de chef-kok een centraal register op waarin beschreven staat hoe elke hamburger bereid moet worden.  Omdat de chef zeker wil zijn dat de juiste recepten gevolgd worden, is het een verplichting  om het register steeds te raadplegen voor het klaarmaken van een hamburger.  5 verkopers kunnen wel samen lezen, maar als de chef een wijziging aanbrengt, is het register niet meer zichtbaar.

Wat als er 50 verkopers een recept willen lezen? Of wat als er heel vaak wijzigingen gebeuren?  Hoeveel verkopers er ook aangeworven worden, de bottleneck bevindt zich op het centraal register.  En wat als iemand het register per ongeluk onleesbaar maakt?

Caching aan het eind van de keten

Een ingrediënt voor een bepaald type hamburger is niet meer in stock.  Het is dus onmogelijk om deze hamburger te bereiden.   Omdat de verkoper echter geen korte-termijn geheugen heeft (geen cache), moet hij telkens het recept gaan opzoeken in het centraal register.  Hier haalt hij de ingrediënten op en vraagt of ze nog beschikbaar zijn.  Niet dus — de verkoper loopt terug naar de klant en brengt het spijtige nieuws. Hij loopt onnodig heen, en weer.

Bottom line

Het is belangrijk om bepaalde ontwerp-reflexen in vraag te stellen. Vaak zijn het dogma’s die niet universeel geldig zijn en een serieuze performantie, beschikbaarheid en schaalbaarheidsimpact hebben.

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.