Het nieuwe paradigma?

 
17 januari 2010

Binnen software ontwikkelland ontstaat meer en meer aandacht voor event gebaseerde systemen. Bertrand Meyer schreef hier in 2003 al een artikel over event driven design. Gregory Young heeft met zijn CQRS benadering van systeembouw een interessante structuur neergezet. Binnen Sogyo hebben we inmiddels ook de eerste event gedreven implementaties in de praktijk toegepast. De voorlopige conclusies zijn dat deze vorm van systeemontwerp en -bouw zeer goed kunnen werken, maar slechts voor een beperkte set aan toepassingen.

Om het toepassingsgebied mogelijk te verbreden is het interessant om even terug te gaan naar de basisprincipes achter de message of event gedreven manier van systeemontwerp, alvorens te verzanden in implementatiedetails. We zijn binnen Sogyo gestart met een onderzoek naar deze manier van systeemontwerp en een paar voorlopige onderzoeksrichtingen en -vragen (bedacht samen met collega’s Ralf Wolter en Arno den Uijl) wil ik hier nu graag delen.

Event gedreven benaderingen hangen bijna altijd samen met een infrastructuur die de events distribueert naar diverse componenten. Tot nu toe is de scope van deze componenten in de meeste gevallen systeemoverstijgend: publishers en subscribers zijn vaak gedefinieerd op applicatieniveau. Deze benadering bewijst zich meer en meer in de praktijk als efficiënt en schaalbaar. Desalniettemin heeft dit niet veel te maken met hoe de applicaties zelf gebouwd worden. Ons idee is dan ook om te gaan kijken hoe we één enkele applicatie volgens hetzelfde principe – tot het meest extreme niveau – vorm kunnen geven.

We hebben dan ook besloten dat we ons in eerste instantie voor dit onderzoek willen richten op ontwerp- en implementatieregels beperkt tot één functioneel domein, binnen één applicatie. Een aantal uitgangspunten voor de componenten (die ik voorlopig nog maar even ‘objecten’ noem) binnen dit systeem die we daarbij willen hanteren zijn:

  • Objecten binnen het applicatiedomein communiceren alleen via messages/events – en deze messages worden altijd naar alle objecten in het systeem gedistribueerd
  • Elk object krijgt zijn eigen thread – alles werkt asynchroon
  • Alle objecten zijn op elk moment live in het geheugen aanwezig

Deze drie (en mogelijk meer) regels impliceren een volledig andere manier van modelleren van de software. Zo zullen objectgeoriënteerde regels als delegation en chain of responsibility veel minder van toepassing zijn. Objecten (of actoren, of agents, of hoe je deze componenten ook zou gaan noemen) zijn zelfstandig en volledig los gekoppeld van hun broertjes en zusjes. Geheugenproblemen treden op als we de klassieke benadering kiezen van association classes: events mogen maar zelden leiden tot het creeëren van nieuwe objectinstanties. De object graph in het geheugen zal dus veel statischer worden. Class diagrams zullen dan ook in deze opzet dan ook niets meer met ERD’s te maken hebben. Waar we nu in de praktijk nog vaak neigen naar een zo goed mogelijke aansluiting tussen database en applicatie (O/R bridging) zal in deze opzet geen enkele aansluiting meer te vinden zijn.

Vragen die hieruit volgen zijn:

  • Hoe identificeren we op deze manier objecten?
  • Hoe bepalen we de juiste payload van de messages / events?
  • Hoe gaan we om met state – verpakken we alle state binnen de – zeer beperkte – set van objecten of moeten we state op een heel andere manier gaan persisteren?
  • Hoe bevragen we ons systeem, of moeten we ook hiervoor een volledig nieuw querying paradigma bedenken? De metafoor van het zoeken door een archief met records lijkt hier niet toepasbaar.
  • Kunnen we nog spreken van transacties binnen een dergelijk volledig asynchroon systeem?
  • Welke talen/paradigma’s zijn voor deze manier van systeemontwerp het meest geschikt (functioneel/object georiënteerd)?

Er zijn voldoende vragen te beantwoorden de komende tijd. Ik zou de lezer dan ook willen vragen om ervaringen te delen via dit blog. Breekt er met het message/event-based systeemontwerp een nieuw tijdperk aan? Of is het de zoveelste vorm van oude wijn in nieuwe zakken?


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Architectuur, Development

Tags: , , , , , ,


Reacties (3)

  • Rick schreef:

    Nou, ik merk op mijn huidige lokatie dat we hier al heel dicht tegenaan zitten. Ik ben de reporting er zo tegenaan aan het opzetten dat we er bijna zijn. Bijna. :)

    Geplaatst op 29 januari 2010 om 21:53 Permalink

  • Hoi David,
    Onze praktijkervaring met een eventgedreven aanpak is heel specifiek, op monitoring van fabrieksmachines gericht. Door deze opzet kunnen we schaalbaar en gemakkelijk meetgegevens en events pushen naar meerdere clients.
    Daarnaast gebruikt Greg Young zijn DDDD / CQRS vooral in een heftig gedistribueerde context (voor zover ik dat goed voor ogen heb).

    Ons doel met dit onderzoek is om te kijken of we een dergelijke opzet meer kunnen generaliseren zodat we ook meer ‘standaard’ administratieve applicaties op deze manier zouden kunnen bouwen.

    Geplaatst op 18 januari 2010 om 9:17 Permalink

  • David schreef:

    Je zegt in je bericht: “De voorlopige conclusies zijn dat deze vorm van systeemontwerp en -bouw zeer goed kunnen werken, maar slechts voor een beperkte set aan toepassingen”
    Waar (volgens jullie conclusies) zak het wel werken en waar niet?

    Geplaatst op 18 januari 2010 om 8:51 Permalink