In een vorige blog gaven we reeds een uitvoerige inleiding van het “Reactive” paradigma. Vermits dit toch wel een belangrijke en invloedrijke zaak geworden is binnen de developer wereld, lijkt het ons nuttig om hier op terug te komen en wat dieper in te gaan op een voorbeeld van een Reactive framework: het Akka framework, één van de pioniers binnen de Reactive beweging.

Wat is Reactive alweer?

Reactieve systemen worden gezien als één van de belangrijkste ontwikkelingen om systemen responsiever te maken voor meer veeleisende eindgebruikers, en om overweg te kunnen met de grote hoeveelheid data die moderne systemen overspoelt. Zogenaamde “wearables” en andere IoT zaken kunnen bijvoorbeeld een constante stroom aan data genereren. Wanneer men dan de data van vele honderden van zulke devices moet verwerken, komen traditionele systemen vaak in de problemen. Maar ook voor ‘gewone’ toepassingen kan deze technologie heil brengen, doordat de responsiviteit en resiliëntie ook kunnen worden verhoogd.

Aan de grondslag van Reactive ligt het feit dat het “message driven” is (Zie Fig. 1). Men zal een systeem bouwen aan de hand van een aantal met elkaar communicerende subsystemen die berichten zullen uitwisselen. Dit kan zowel rechtstreeks als via het publish/subscribe mechanisme van Events. Deze communicatie is altijd inherent asynchroon. Men weet niet wanneer er op een bericht zal worden gereageerd en men gaat er ook niet expliciet op wachten. Deze vorm van communicatie tussen componenten zorgt ervoor dat ze losjes gekoppeld zijn en locatietransparant. Dit “message driven” fundament leidt verder tot verschillende voordelen.

Eerst en vooral zorgt dit voor resiliëntie. Asynchrone communicatie laat toe om componenten veel onafhankelijker van elkaar te laten opereren dan synchrone communicatie, wat ervoor kan zorgen dat één component verder kan indien de andere (tijdelijk) faalt. De manier waarop berichten behandeld worden bij Reactive maakt ook van foutmeldingen gewone berichten; men behandelt deze als ‘first class citizen’, en niet zozeer als een uitzondering. Het omgaan met fouten en met niet-werkende componenten wordt dan als van nature mee opgenomen in het programmeren van zo’n systeem.

Ten tweede stijgt ook de elasticiteit. Bij reactieve systemen is de berichtenstroom heel belangrijk. Men kan deze gaan monitoren en ingrijpen wanneer deze sterk in volume toe- of afneemt, en snel reageren door meer componenten op te starten (of te stoppen), om deze berichten af te handelen. Ook het feit dat het systeem bestaat uit een heel aantal samenwerkende componenten, en niet afhankelijk is van een centrale bottleneck, komt de schaalbaarheid ten goede.

Ten slotte moet dit alles samen zorgen voor een verhoogde responsiviteit. Men zorgt ervoor dat men tijdig en vooral binnen een bepaalde tijd kan reageren op alle binnenkomende berichten, voor een consistente Quality of Service.

Het Akka raamwerk

Akka zag het licht in 2009 als één van de eerste raamwerken die het principe van het Actor programmeermodel naar een mainstream server programmeertaal bracht. Het is beschikbaar zowel voor de programmeertaal Scala (een taal die werkt op de JVM), waar het in principe voor is gebouwd, als voor Java (waar het iets meer boilerplate code vergt). Tegenwoordig maakt het deel uit van het Lightbend platform, samen met het Play raamwerk en de taal Scala.

Actoren kan men zien als kleine onafhankelijke machines binnen een softwaresysteem. Ze communiceren enkel met de buitenwereld (en dus met andere actors) via asynchrone berichten. Wanneer een actor een bericht krijgt, kan deze een aantal verschillende dingen doen: lokale code uitvoeren, zijn eigen toestand veranderen, zelf berichten uitsturen, andere actoren creëren, en beslissen hoe op het volgende bericht zal worden gereageerd. Een actor leeft dus volledig binnen zijn eigen executie-stack. Men kan deze dus beschouwen als een apart proces of een aparte thread, maar in een raamwerk als Akka is het mogelijk om deze veel efficiënter te instantiëren dan dat (zelfs threads zijn nog relatieve zwaargewichten, terwijl een actor in akka maar een paar honderd bytes hoeft in te nemen; één thread zal dan ook typisch vele actors tegelijk aansturen). Daarnaast kan men er voor zorgen dat een actor een andere actor als “supervisor” krijgt. Deze zal in het oog houden of de gesuperviseerde actor faalt, en kan dus indien nodig gepast reageren.

Eén van de meest interessante zaken aan actors is dat het voor de programmeur transparant kan gemaakt worden waar een actor zich bevindt: het kan een andere actor binnen hetzelfde proces zijn, een actor binnen een ander proces op dezelfde machine, of een actor aan de andere kant van het internet: de programmeur kan deze op dezelfde manier behandelen. Dit is één van de eigenschappen die Akka Cloud Native maakt: het is een technologie gebouwd vóór de Cloud, waarmee men optimaal kan gebruik maken van de eigenschappen van de Cloud.

Naast de ‘core’ Akka bibliotheek, bestaan er ook nog heel wat modulaire uitbreidingen, zoals b.v. voor het werken met streams, persistentie, webservers en http, en allerlei integraties, zoals b.v. met het Play framework, of met Apache Kafka. Ook RESTful APIs worden ondersteund.

Een voorbeeld

In de code duiken zou een beetje te technisch worden, maar we kunnen toch illustreren wat men met deze manier van programmeren kan bereiken aan de hand van een eenvoudig voorbeeld.

In onderstaande figuur zie je een tekening van een aantal actoren in een boekenwinkel systeem en de berichten die ze elkaar sturen: er zijn klanten, de boekenwinkel zelf, en bedienden (die boeken opsturen). Het systeem zal als volgt werken: klanten sturen bestellingen naar de winkel; deze zal de bestellingen verder doorgeven aan een bediende. Deze hebben wat tijd nodig om een bestelling af te handelen, dus er zijn er meerdere, om meer bestellingen aan te kunnen. Hoe de winkel kiest welke taak aan welke bediende te geven, zouden we op verschillende manieren kunnen oplossen (b.v. “neem een willekeurige vrije bediende”), maar zoveel detail laten we hier niet zien.

De bediende die een bestelling krijgt wordt “bezig” (een andere toestand dan “vrij”) en zal uiteindelijk een boek terugsturen naar de klant (in het geval van het IT systeem dat dit systeem modelleert, kan dit b.v. een bericht zijn met de tracking code van het pakket). Daarna wordt de bediende terug “vrij”.

Soms gaat er echter iets mis met de bestelling: de bediende vindt b.v. het boek niet dat de klant wil. In dat geval stuurt deze een verontschuldigend bericht terug naar de klant, met een cadeaubon. Als er echter te vaak van deze dingen gebeuren, krijgt een bediende teveel stress en geeft deze er de brui aan (zijn actor gaat in error-modus). Dit geeft dus een foutmelding, die geëscaleerd wordt naar de supervisor van de bediende, in dit geval de winkel (zie Fig. 3). Deze zal dan moeten beslissen wat er met de fout gebeurt: we kiezen ervoor om de bestelling aan een andere bediende te geven en de gestresseerde bediende een paar dagen “verlof” te geven (waarna zijn actor terug in toestand “vrij” zal komen).

Dit voorbeeld illustreert het principe van resiliëntie, gebruikmakende van actoren: de fout wordt niet speciaal als fout behandeld, maar als een bericht naar de winkel, die het probleem op dat niveau kan oplossen. Er wordt ook niet alleen gezorgd voor fout-tolerantie, maar ook voor veerkracht: uiteindelijk zal de foutieve actor worden hersteld en terug ter beschikking komen van de pool. Deze veerkracht maakt net het verschil tussen gewone fout-tolerantie en echte resiliëntie.

Besluit

De meeste bestaande raamwerken voor Reactive systemen focussen zich op het gebruik van streams van berichten/events, en op hoe deze zo efficiënt mogelijk te behandelen. Een raamwerk zoals Akka doet het net iets anders, door gebruik te maken van het actor paradigma. Dit biedt een verfrissende kijk op multi-threaded programming, en kan het bouwen van sommige systemen net iets gemakkelijker maken.

Het gebruik van actoren verhoogt in ieder geval het niveau van abstractie wanneer men over parallellisme en multi-threading probeert te redeneren, een oefening die berucht is voor zijn moeilijkheid.

Actors lijken erg nuttig voor het modelleren van zaken die een toestand en een gedrag vertonen in de echte wereld, zoals mensen, machines, of bedrijven. In het algemeen zijn ze goed inzetbaar wanneer je systeem goed decomposeerbaar is in een set van onafhankelijke taken, of een set van taken die een bepaalde workflow volgt. Ten slotte zijn ze ook erg geschikt voor het programmeren van Event Driven systemen.

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.