BE1024939B1 - Systeem en apparaat voor het gegarandeerd precies eenmalig verwerken van een gebeurtenis in een verdeelde gebeurtenissen-aangedreven omgeving - Google Patents

Abstract

De onderhavige uitvinding heeft betrekking op een gebeurtenissen-aangedreven verwerkend systeem dat verzekert dat een welbepaalde gebeurtenis slechts een enkele keer en precies een enkele keer wordt uitgevoerd in een datanetwerk.

Description

Systeem en apparaat voor het gegarandeerd precies eenmalig verwerken van een gebeurtenis in een verdeelde gebeurtenissen-aangedreven omgeving

Technisch vakgebied van de uitvinding

Aspecten van de onderhavige uitvinding hebben betrekking op een gegevensopslag en op een gegevensopvraging, en meer bepaald op een werkwijze, op een systeem, en op een computerprogrammaproduct voor het creëren en het gebruiken van een specifieke gegevensgebeurtenis in een in-memory datanetwerk of in een gelijkaardige gegevensopslagopstelling, meer bepaald voor een instelling die grote hoeveelheden gegevens gebruikt in voor missies van kritisch belang zijnde systemen. De uitvinding heeft meer bepaald betrekking op een front-end interface met een verwerker die verbonden is met een knoop waarin gegevens worden opgeslagen die betrekking hebben op gebeurtenissen die worden opgenomen door een gebeurtenisseninterface, teneinde een snellere respons van het systeem en van het apparaat te kunnen bieden op een verzoek van een klant, waarbij de aan de gebeurtenis gerelateerde acties gegarandeerd slechts een enkele keer worden uitgevoerd.

Achtergrond van de uitvinding

In diverse omgevingen is één van de belangrijkste eisen dat er voor gezorgd dient te worden dat een lopende toepassing, zelfs bij het zich voordoen van één of meerdere systeem- of softwarefouten, blijft lopen en een order of een activiteit precies eenmaal uitvoert.

Zogenaamde missie-kritieke systemen in telecommunicatie-, militaire, navigatie-, financiële, en andere real-time verwerkende systemen vertrouwen op een ingebouwde redundantie of replicatie om fouten te herstellen en te voorkomen, en om te verzekeren dat een welbepaald verzoek slechts een enkele keer wordt uitgevoerd.

Alhoewel in traditionele monolithische toepassingen fouten, bijvoorbeeld van servers, netwerken, of subsystemen worden opgevangen door gebruik te maken van een fysiek back-upsysteem of door middel van een overname door een toepassingsreplica, waarna de dienst verder geleverd wordt, verzekert dit niet dat een welbepaalde transactie of gebeurtenis verwerkt is en afgewerkt is, wat aanleiding kan geven tot een verdubbeling of het verdwijnen van een welbepaalde actie zodra een server of een replica de taken heeft overgenomen. Een fout van een server of van een ander deel van het computersysteem vereist echter het opnieuw opstarten van het systeem, wat betekent dat de status van processen dient gerecupereerd te worden uit de back-upgegevens die verzameld werden, wat typisch traag en duur is om te implementeren.

Een redundantie om dergelijke problemen te vermijden, kan eveneens gerealiseerd worden door een volledig systeem parallel te laten lopen. Problemen kunnen echter gemakkelijk opgelost worden omdat de systemen lineair en sequentieel gestructureerd zijn, waardoor verzekerd kan worden dat een proces als het resultaat van een welbepaald verzoek slechts een enkele keer wordt uitgevoerd. Zodoende zijn deze processen niet geschikt voor hoge gegevensvolumes en voor een intens gebeurtenissenverkeer.

De afgelopen jaren zijn verdeelde computersystemen die een parallelle verwerking mogelijk maken door het gebruik van een microdienstenarchitectuur, zoals bijvoorbeeld in een gebeurtenissen-aangedreven architectuur (Event Driven Architecture) populair geworden. EDA is tegenwoordig breed toegepast, meer bepaald bij gebruikers met grote hoeveelheden gegevens en toenemende aantallen transacties. Dergelijke gebruikers omvatten nutsbedrijven, bijvoorbeeld leveranciers van elektriciteit, gas, warmte, en water; telecomleveranciers, en transportleveranciers, zowel traditionele spoorwegsystemen als meer recente ontwikkelingen zoals navigatiesystemen van bijvoorbeeld auto's, processen voor het plannen van producties, logistieke processen zoals verkeersplanningsgegevens voor treinen, metro's, waterwegen, bruggen, luchtcontrole, en dergelijke, levering van elektriciteit of aardgas, maar eveneens de levering van gezondheidsdiensten. Ook banken zijn een goed voorbeeld van het bovenstaande omdat ze gebruik maken van grote databases en verplicht zijn om grote hoeveelheden verzoeken door een variëteit aan verschillende gebruikers te verwerken, alsook vele externe gebeurtenissen.

Al deze grootschalige processen met een hoog gegevensverkeer hebben gemeenschappelijk dat ze op kritieke wijze afhangen van de nauwkeurigheid van gegevens die wijzigingen in het systeem aanbrengen, en zijn zodoende missies-kritiek. Meer bepaald is het in dergelijke processen van kritiek belang dat welbepaalde transacties singulier zijn, dat wil zeggen dat ze slechts een enkele keer mogen uitgevoerd worden.

Omdat gebeurtenissen-gebaseerde architecturen echter inherent systeemcomponenten

ontkoppelen, is de implementatie van foutenbestendige systemen in een systeem met EDA bijzonder uitdagend gebleken ten opzichte van de traditionele lineaire architectuur. In EDA-systemen dient het systeem, in plaats van in staat te zijn om transacties te beheren en te verwerken binnen de grenzen van een enkele monolithische toepassing, in staat te zijn om een consistentie te behouden wanneer er gebruik wordt gemaakt van transacties die verdeeld zijn over een netwerk van vele verschillende toepassingen en databases.

Vanwege de gedecentraliseerde aard van de verdeelde verwerking in welbepaalde systemen met behulp van een datanetwerk kan dit aanleiding geven tot problemen bij het herkennen van fouten, en om een uitvoering te verzekeren indien er zich een gedeeltelijke systeemfout voordoet, omdat de onderling gelinkte aard van het netwerk het moeilijker maakt om fouten op te merken en te corrigeren, omdat de verdeelde toestand betekent dat de noodzakelijke diagnose en foutenverwerking complexer zijn dan in sequentiële synchrone voorspelbare transactionele gecentraliseerde systemen.

In een gebeurtenissen-aangedreven systeem kan een toepassing op de hoogte gebracht worden van het feit dat een gebeurtenis heeft plaatsgevonden en vervolgens actie ondernemen. Indien er echter iets misgaat, bijvoorbeeld een machine wordt uitgeschakeld terwijl de gebeurtenis plaatsvindt, wordt de verwerking van de gebeurtenis gestopt. Zelfs indien de machine wordt gerecupereerd zal de verwerking van de gebeurtenis niet volledig zijn omdat de gebeurtenis zou opgetekend zijn als reeds uitgevoerd of plaatsgevonden, en bestanden van de gebeurtenis en van de verwerkingstoestanden zijn verloren gegaan zijn.

Zodoende bestaat de behoefte aan verbeterde gegevensverwerkende systemen die een verdeelde verwerking en een gebeurtenissen-aangedreven architectuur mogelijk maken, alsook gegarandeerde en stabiele processen om ervoor te zorgen dat een welbepaalde gebeurtenissenactiviteit of gegevensgebeurtenis gegarandeerd wordt uitgevoerd, en dan slechts een enkele keer.

Samenvatting van de uitvinding

Dienovereenkomstig heeft de onderhavige uitvinding betrekking op een gebeurtenissen-aangedreven systeem om te voorzien in een gegarandeerd exact eenmalige verwerking van een gebeurtenis in een datanetwerk, waarbij het systeem een netwerk van knopen omvat die voorzien in een verwerking en in in-memory opgeslagen gegevens, waarbij het systeem bovendien een cachemodule omvat waarin voorzien wordt door het datanetwerk, een gebeurtenissenverwerkende module waarin voorzien wordt door het datanetwerk, en een reactieve stroommodule die verbonden is met maar waarin niet voorzien wordt door het netwerk, en geconfigureerd om een gebeurtenis uit te voeren wanneer daartoe de opdracht wordt gegeven door de gebeurtenissenverwerkende module, waarbij: a. de cachemodule ten minste een cache omvat om identificatiegegevens op te slaan betreffende te verwerken gebeurtenissen in een knoop (“to-handle cache”); b. de gegevensverwerkende module ten minste een eerste knoop omvat die omvat: i. een verzoekverwerker om een verzoek te ontvangen dat overeenstemt met een gebeurtenis die geassocieerd is met een aantal verwerkende stappen die in het systeem moeten uitgevoerd worden; en ii. een verwerkingsinterceptorlogica (“notifier”) voor het kopiëren van de entiteitsreferentie naar de reactieve stroom; en c. waarbij de reactieve stroommodule omvat: i. een verwerkingsmodule (“reactive stream”) voor het parallel uitvoeren van gebeurtenissen, ii. een entiteitspecifieke logica voor het actualiseren van de eerste en/of tweede cache nadat een gebeurtenis is verwerkt en gerelateerde transacties zijn toegekend; en iii. een controlelogica voor het controleren of gegevens in de to-handle cache met betrekking tot een specifieke te verwerken gebeurtenis nog steeds aanwezig zijn met transacties die toegekend moeten worden door de reactieve stroom, en om ofwel de gegevens uit de stroom te verwijderen voor een gebeurtenis die is toegekend, of om een roll-back uit te voeren van welke transactie dan ook voor gebeurtenissen die niet langer aanwezig zijn in de eerste cache, zodat een gebeurtenisentiteit precies één keer wordt uitgevoerd.

Het verbeterde systeem is bij voorkeur compatibel met een bestaand gegevensverwerkend apparaat en systeem van de instelling. De onderhavige uitvinding heeft bij voorkeur eveneens betrekking op een werkwijze om te voorzien in een singuliere gebeurtenis voor een gegeven gebeurtenissenverzoek of een externe gebeurtenis, waarbij het verzoek ten minste één type gebeurtenis omvat, waarbij een gebeurtenis een begin en een einde omvat en een veelheid aan acties omvat die getriggerd wordt door de externe gebeurtenissen of door gebeurtenissen die vertaald zijn uit gebruikersverzoeken die door het systeem ontvangen zijn, waarbij de werkwijze omvat: i) het voorzien van een verzoekverwerker voor het ontvangen van een verzoek dat overeenstemt met een gebeurtenis die geassocieerd is met een aantal verwerkingstappen die door het systeem uitgevoerd moeten worden; ii) het voorzien van een eerste netwerkcache voor het opslaan van identificatiegegevens betreffende gebeurtenissen die in een knoop dienen uitgevoerd te worden; vi) het voorzien van een tweede cache voor het opslaan van gegevens die geassocieerd zijn met de geplande gebeurtenissen, de zogenaamde to-handle cache; vii) het voorzien van ten minste een eerste knoop, elk een verzoekprocessor omvattende om een verzoek te ontvangen vanuit de verzoekverwerker, en het identificeren van een gebeurtenis die verwerkt dient te worden op basis van het verzoek; en bij voorkeur het voorzien van een tweede knoop die bedoeld is om een inactieve back-upversie te omvatten van de gegevens betreffende gebeurtenissen die verwerkt dienen te worden in de primaire knoop, vii) het voorzien van verwerkingsinterceptorlogica om de verwerkingstappen te starten bij het opslaan van identificatiegegevens betreffende een gebeurtenis in de tweede cache; en viii) het voorzien van een reactieve stroom om de transacties die geassocieerd zijn met de gebeurtenisentiteit toe te kennen en af te werken, en ix) het voorzien van gebeurtenissen -transferlogica voor het overbrengen van de identificatiegegevens betreffende een gebeurtenis vanuit de eerste cache naar een entiteitsarchiefcache bij het afronden van de verwerkingstappen die geassocieerd zijn met gebeurtenis; en x) het voorzien van een controlelogica en van een entiteitspecifieke logica voor het uitvoeren van een roll-back van welke transactie dan ook die gedupliceerd werd.

Volgens een bijkomend aspect van de onderhavige uitvinding heeft deze laatste betrekking op door een machine uitvoerbare instructies die, wanneer ze worden uitgevoerd door ten minste één processor, ervoor zorgen dat de ten minste ene processor de werkwijze uitvoert. Volgens een bijkomend aspect heeft de onderhavige uitvinding betrekking op een niet-transitoir, door een machine leesbaar medium waarin door een machine uitvoerbare instructies volgens de werkwijze zijn opgeslagen. Volgens een bijkomend aspect van de onderhavige uitvinding heeft deze laatste betrekking op door een machine leesbare opslag waarin door een machine uitvoerbare instructies zijn opgeslagen volgens de werkwijze. Nog volgens een bijkomend aspect heeft de onderhavige uitvinding eveneens betrekking op het gebruik van het systeem volgens de uitvinding om zodoende de stabiliteit van het systeem te verbeteren door te verzekeren dat een gebeurtenis slechts een enkele en precies een enkele keer wordt uitgevoerd.

Korte beschrijving van de tekeningen

De onderhavige uitvinding wordt hierna nader in detail beschreven onder verwijzing naar de tekeningen, en dit bij wijze van niet-beperkende voorbeelden van uitvoeringsvormen van de onderhavige uitvinding waarin dezelfde referentiecijfers gelijkaardige delen aanduiden doorheen alle tekeningen, en waarin:

Figuur 1 een stroomdiagram is van een werkwijze die gebruik maakt van de architectuur, vanuit het standpunt van een toepassing, van een te verkiezen uitvoeringsvorm van een server in het systeem en het apparaat volgens deze uitvinding. Bij voorkeur omvatten het systeem en het apparaat volgens de onderhavige uitvinding ten minste twee parallelle servers, waarbij een daarvan een back-up vormt voor de andere, en waarbij elk van de beide exemplaren in het bezit is van zijn eigen front-end interface, gebeurtenisseninterface, back-end interface, en een veelheid aan knopen.

Figuur 2 een stroomdiagram is van de werking van de front-end interface of verzoekverwerker van het systeem en het apparaat, en van de verschillende entiteiten die actief zijn. De verzoekverwerker communiceert met front-end toepassingen om zodoende externe verzoeken van gebruikers te ontvangen, teneinde het de gebruikers mogelijk te maken om toegang te krijgen tot diensten die via het systeem en het apparaat worden aangeboden. Figuur 2 illustreert de specifieke werking van het onderhavige systeem en van de onderhavige werkwijze, waarbij de meest relevante componenten zijn terug te vinden.

Figuur 3 een stroomdiagram is van de werking van de waakhondwerkwijze die de verwerking van de gebeurtenissen beschermt ingeval één of meerdere servers onderhevig zouden zijn aan fout, en die de gebeurtenissen in de reactieve stroom plaatst.

Figuur 4 een stroomdiagram is van de werking van de gebeurtenisseninterface van het systeem en het apparaat volgens de onderhavige uitvinding, waarbij verschillende knopen een missie-kritiek verzoek verwerken, waardoor een eenmalige uitvoering mogelijk wordt gemaakt, en waardoor het ontdubbelen van activiteiten kan vermeden worden.

De stroomdiagrammen en blokdiagrammen in de figuren illustreren de architectuur, de functionaliteit, en de werking van mogelijke implementaties van systemen, werkwijzen, en computerprogrammaproducten volgens de verschillende uitvoeringsvormen van de onderhavige uitvinding. Wat dit betreft, kan elk blok in de stroom- of blokdiagrammen een module, een segment, of een deel van code omvatten die of dat één of meerdere uitvoerbare instructies omvat voor het implementeren van de gespecificeerde logische functie(s). Er dient eveneens opgemerkt te worden dat, in sommige alternatieve implementaties, de in het blok vermelde functies kunnen voorkomen in een volgorde die verschillend is van deze die terug te vinden in de figuren. Twee blokken die bijvoorbeeld na elkaar worden weergegeven, kunnen in de praktijk bijvoorbeeld in hoofdzaak tegelijkertijd worden uitgevoerd, of de blokken kunnen soms uitgevoerd worden in de omgekeerde volgorde, afhankelijk van de functionaliteit in kwestie. Er dient tevens opgemerkt te worden dat elk blok van de blokdiagrammen en/of stroomdiagrammen, en combinaties van blokken in de blokdiagrammen en/of stroomdiagrammen kan of kunnen geïmplementeerd worden door speciaal opgezette hardware-gebaseerde systemen die de gespecificeerde functies of acties uitvoeren, of door combinaties van speciaal opgezette hardware-gebaseerde en computerinstructies.

Gedetailleerde beschrijving van de uitvinding

In een gebeurtenissen-aangedreven systeem kan een toepassing op de hoogte worden gebracht van het feit dat een gebeurtenis zich heeft voorgedaan, en vervolgens actie ondernemen. Indien er iets misgaat, zoals een machine die crasht terwijl de gebeurtenis wordt uitgevoerd, wordt de gebeurtenissenverwerking gestopt. Zelfs indien de machine wordt gerecupereerd, zal de verwerking van de gebeurtenis niet volledig zijn omdat de gebeurtenis “reeds heeft plaatsgehad” en bestanden met betrekking tot de gebeurtenis en de verwerkingstoestanden zijn dan verloren gegaan. Indien een gebeurtenis bijvoorbeeld plaatsvindt om 12:00 uur, de verwerking bijvoorbeeld start om 12:01 uur (maar niet wordt afgewerkt), en een systeem crasht om 12:01 uur en niet wordt gerecupereerd voor 12:02 uur, zal de gebeurtenis niet verwerkt zijn. Voor de meeste systemen wordt de gebeurtenis niet van hoog belang geacht, wat inhoudt dat er geen werkwijze voorzien is om een dergelijk voorval te beheren en op te vangen. Zoals men kan opmaken uit de onderstaande figuur zal, wanneer een systeem crasht, de activiteit niet worden uitgevoerd. Gebeurtenissen-sourcing is een generiek mechanisme van gebeurtenissen, maar gebeurtenissen kunnen meer dan een enkele keer of helemaal niet uitgevoerd worden.

Het onderhavige systeem verzekert op interessante wijze de verwerking van een gebeurtenis, en dit slechts een enkele keer, terwijl er gebruik wordt gemaakt van een minimale mate van redundantie.

Wanneer een systeem op de hoogte wordt gebracht van een gebeurtenis wordt de gebeurtenis onmiddellijk opgeslagen in een cache en op schijf zodat ze niet verloren gaat.

Het onderhavige systeem maakt het mogelijk om als volgt te werk te gaan: na een fout kan het systeem de verwerking starten en de reeks gebeurtenissen bekijken die zich hebben voorgedaan maar die nog niet verwerkt zijn, en kan het de verwerking van deze gebeurtenissen opnieuw starten. Zodra de gebeurtenis zich heeft voorgedaan, wordt ze permanent opgeslagen in geheugen en vervolgens weggeschreven naar een schijf.

Dit combineert op interessante wijze kenmerken van het in-memory datanetwerk, omdat het netwerk een snelle opslag mogelijk maakt en dat doet zodra de gebeurtenis zich heeft voorgedaan, en zodat vervolgens, wanneer er zich een fout voordoet in het systeem, dit laatste precies weet wat er nog niet verwerkt is, en dit met de kenmerken van een lineair systeem, bijvoorbeeld een reactieve stroom die niet in het netwerk loopt.

Het datanetwerk maakt het bovendien op interessante wijze mogelijk dat een gebeurtenis automatisch wordt weggeschreven naar het in-memory datanetwerk en wordt opgeslagen op een schijf. Door de gegevens op te slaan met betrekking tot wat er verwerkt is, is het mogelijk om te controleren welke gebeurtenissen niet verwerkt zijn en om de exemplaren terug te vinden die nog verwerkt moeten worden.

Tenzij expliciet anders vermeld, hebben alle technische en wetenschappelijke termen die hier gebruikt worden dezelfde betekenis als deze die gebruikelijk begrepen wordt door de vakman in het vakgebied waartoe deze uitvinding behoort. De in de beschrijving van de uitvinding gebruikte terminologie is enkel bedoeld voor het beschrijven van welbepaalde uitvoeringsvormen en is niet bedoeld om de uitvinding op welke wijze dan ook te beperken.

De stroomdiagrammen en blokdiagrammen in de figuren illustreren de architectuur, de functionaliteit, en de werking van mogelijke implementaties van systemen, werkwijzen, en computerprogrammaproducten volgens diverse uitvoeringsvormen van de onderhavige uitvinding. In deze context dient opgemerkt te worden dat elk blok in de stroomdiagrammen en blokdiagrammen een module, een segment, of een deel van code kan vertegenwoordigen waarin een of meerdere uitvoerbare instructies aanwezig zijn voor het implementeren van de gespecificeerde logische functie(s). Er dient eveneens opgemerkt te worden dat in sommige alternatieve implementaties, de functies die vermeld worden in het blok in een volgorde kunnen uitgevoerd worden die verschillend is van deze uit de figuren. Zo kunnen twee blokken die na elkaar weergegeven zijn, in de praktijk bijvoorbeeld in hoofdzaak tegelijkertijd worden uitgevoerd, of de blokken kunnen soms in de omgekeerde volgorde uitgevoerd worden, afhankelijk van de functionaliteit in kwestie. Er dient eveneens opgemerkt te worden dat elk blok van de blokdiagrammen en van de stroomdiagrammen, en combinaties van blokken in de blokdiagrammen en/of stroomdiagrammen kan of kunnen geïmplementeerd worden door speciaal opgezette hardware-gebaseerde systemen die de gespecificeerde functies of acties uitvoeren, of door combinaties van speciaal opgezette hardware-gebaseerde en computerinstructies. De hier gebruikte terminologie is enkel bedoeld voor het beschrijven van welbepaalde uitvoeringsvormen en is niet bedoeld om uitvoeringsvormen van de uitvinding op welke wijze dan ook te beperken. Zoals zij hier gebruikt worden, zijn de enkelvoudsvormen “een”, “de”, “het” bedoeld om eveneens de meervoudsvormen te omvatten, tenzij de context duidelijk aangeeft dat dat niet het geval is. Daarenboven dient opgemerkt te worden dat de termen “omvat” en/of “omvattende”, wanneer ze voorkomen in deze beschrijving, de aanwezigheid aanduiden van de vermelde kenmerken, gehele getallen, stappen, bewerkingen, elementen, en/of componenten, zonder echter de aanwezigheid of het toevoegen uit te sluiten van één of meerdere andere kenmerken, gehele getallen, stappen, bewerkingen, elementen, componenten en/of groepen daarvan.

Het zal voor de vakman in het vakgebied duidelijk zijn dat bepaalde aspecten van de onderhavige uitvinding uitgevoerd kunnen worden als een systeem, als een werkwijze, of als een computerprogrammaproduct. Dienovereenkomstig kunnen aspecten van de onderhavige uitvinding de vorm aannemen van een volledige hardware-matige uitvoeringsvorm, van een volledige software-matige uitvoeringsvorm (met inbegrip van firmware, aanwezige software, micro-code, enzovoort), of van een uitvoeringsvorm die een combinatie maakt van software- en hardware-aspecten waarnaar algemeen kan verwezen worden als “schakeling”, “module”, of “systeem”. Daarenboven kunnen bepaalde aspecten van de onderhavige uitvinding de vorm aannemen van een computerprogrammaproduct dat is uitgevoerd in één of meerdere door een computer leesbare media waarin door een computer leesbare programmacode is opgeslagen.

Welke combinatie dan ook van door computer leesbare media kan gebruikt worden. Het door een computer leesbare medium kan een door een computer leesbaar signaalmedium of door een computer leesbaar opslagmedium zijn. Een door een computer leesbaar opslagmedium kan bijvoorbeeld, zonder dat dit echter een beperking inhoudt, een elektronisch, magnetisch, optisch, elektromagnetisch, infrarood, of halfgeleidersysteem, apparaat, of inrichting zijn, dan wel welke geschikte combinatie dan ook van de voorgaande. Meer specifieke voorbeelden (een onvolledige lijst) van door een computer leesbare opslagmedia zou de volgende omvatten: een elektrische verbinding met één of meerdere draden, een draagbare computerschijf, een harde schijf, random acces memory (RAM), read-only memory (ROM), uitwisselbaar programmeerbaar read-only memory (EPROM of flash/) geheugen, een optische vezel, een draagbaar compact disc read-only memory (CD-ROM), een optische opslaginrichting, een magnetische opslaginrichting, of welke geschikte combinatie dan ook van de voorgaande. In de context van dit document kan een door een computer leesbaar opslagmedium welk tastbaar medium dan ook zijn dat een programma kan omvatten of opslaan voor gebruik met of in verband met een systeem, een apparaat, of een inrichting dat of die instructies uitvoert.

Een door een computer leesbaar signaalmedium kan een gepropageerd gegevenssignaal omvatten waarin door een computer leesbare programmacode zit vervat, bijvoorbeeld in de basisband of als onderdeel van een dragergolf. Een dergelijk gepropageerd signaal kan welke dan ook van een heel scala aan vormen aannemen, met inbegrip van, zonder daar echter beperkt toe te zijn, elektromagnetisch, optisch, of welke geschikte combinatie daarvan dan ook. Een door een computer leesbaar signaalmedium kan welk door een computer medium dan ook zijn dat geen door een computer opslagmedium is en dat een programma kan communiceren, propageren, of transporteren dat gebruikt wordt door of in verband met een systeem, een apparaat, of een inrichting dat of die instructies uitvoert.

Programmacode die vervat zit in een door een computer leesbaar medium kan verzonden worden door gebruik te maken van welk geschikt medium dan ook, met inbegrip van, zonder daar echter toe beperkt te zijn, draadloos, draadgebonden, optische vezel, RF, enzovoort, of door gebruik te maken van welke geschikte combinatie van de voorgaande dan ook. Computerprogrammacode voor het uitvoeren van bewerkingen voor bepaalde aspecten van de onderhavige uitvinding kan geschreven zijn in welke combinatie dan ook van één of meerdere programmeertalen, met inbegrip van een objectgeoriënteerde programmeertaal zoals Java, Smalltalk, C++ of dergelijke, en conventionele procedurele programmeertalen zoals “C” of gelijkaardige programmeertalen. De programmacode kan volledig uitgevoerd worden op de computer van een gebruiker, gedeeltelijk op de computer van een gebruiker, in de vorm van een onafhankelijk softwarepakket, gedeeltelijk op de computer van een gebruiker en gedeeltelijk op een zich op afstand bevindende computer, of gedeeltelijk op de zich op afstand bevindende computer of server. In het laatste scenario kan de zich op afstand bevindende computer verbonden zijn met de computer van een gebruiker via welk type netwerk dan ook, met inbegrip van een LAN of WAN, of de verbinding kan tot stand zijn gebracht met een externe computer (bijvoorbeeld via het internet door gebruik te maken van een internetprovider).

Bepaalde aspecten van de onderhavige uitvinding zullen hierna beschreven worden onder verwijzing naar illustraties van stroomdiagrammen en/of blokdiagrammen van werkwijzen, apparaten (systemen), en computerprogrammaproducten volgens de uitvindingsvormen van de uitvinding. Het zal duidelijk zijn dat elk blok van de weergegeven stroomdiagrammen en/of blokdiagrammen, en combinaties van blokken in de stroomdiagrammen en/of blokdiagrammen geïmplementeerd kan of kunnen zijn door computerprogramma/instructies. Deze computerprogramma-instructies kunnen aangeleverd worden aan een processor van een gewone computer, van een speciaal ontwikkelde computer, of van een ander programmeerbaar gegevensverwerkend apparaat, teneinde een machine te produceren die de instructies, wanneer ze worden uitgevoerd via de processor van de computer of van een ander programmeerbaar gegevensverwerkend apparaat, middelen creëren voor het implementeren van de functies/acties die gespecificeerd zijn in het blok of de blokken van de stroomdiagrammen en/of van de blokdiagrammen.

Deze computerprogramma-instructies kunnen eveneens opgeslagen zijn in een door een computer leesbaar medium dat een computer of een ander programmeerbaar gegevensverwerkend apparaat, of andere inrichtingen kan aansturen om op een welbepaalde manier te functioneren, zodat de instructies die zijn opgeslagen in het door een computer leesbaar medium een productie-artikel produceren met inbegrip van instructies die de functie/actie omvatten die gespecificeerd is of zijn in het blok of de blokken van het stroomdiagram en/of blokdiagrammen.

De computerprogramma-instructies kunnen eveneens in een computer of in een ander programmeerbaar gegevensverwerkend apparaat geladen worden of in andere inrichtingen die er voor zorgen dat een reeks operationele stappen wordt uitgevoerd op de computer, op andere programmeerbare apparaten, of op andere inrichtingen, teneinde een door de computer geïmplementeerde werkwijze te produceren die ervoor zorgt dat de instructies die worden uitgevoerd op de computer of op een ander programmeerbaar apparaat voorzien in werkwijzen voor het implementeren van de functies/acties die gespecificeerd zijn in het blok of in de blokken van het stroomdiagram en/of blokdiagrammen.

Een cache-module (a) omvat bij voorkeur ten minste een eerste cache om identificatiegegevens op te slaan betreffende gebeurtenissen/entiteiten die in een knopen verwerk moeten worden (“gebeurtenis/entiteitcache”); alsook een tweede cache om gegevens op te slaan die geassocieerd zijn met de planning en verwerking van de gebeurtenissen door de knoop (“to-handle cache“).

De ten minste ene eerste knoop omvat een verzoekprocessor om een verzoek van de verzoekverwerker te ontvangen en om een gebeurtenis te identificeren die verwerkt dient te worden op basis van het verzoek; en een interne in-memory lijst (“gewijzigde gebeurtenissenlijst”) waarin de gebeurtenissen worden opgesomd, gegevens die geassocieerd zijn met de gebeurtenissenidentificatie en de run-time van de gebeurtenis, alsook gegevens die geassocieerd zijn met het feit of de knoop is aangeduid als primaire knoop die bedoeld is om de gebeurtenis uit te voeren, of als een secundaire back-up knoop; en een eerste verwerkingsinterceptorlogica (“notifier”) om de identificatiegegevens betreffende de gebeurtenisentiteit over te dragen van de eerste gebeurteniscache (entiteit) naar de tweede cache (to-handle), en om identificatiegegevens betreffende een gebeurtenisentiteit te kopiëren van de tweede cache (to-handle) naar de (“gewijzigde gebeurtenissenlijst”).

Ook kunnen nieuwe gebeurtenissen gecreëerd worden als onderdeel van de verwerking van een vroegere gebeurtenis. Deze nieuwe gebeurtenissen worden vervolgens op dezelfde wijze verwerkt, dat wil zeggen dat ze in de geschikte caches worden geplaatst, van waaruit de verwerking start.

De verwerkingsmodule omvat bij voorkeur bij voorkeur een gebeurtenissen-dispatcherlogica (“dispatcher”) voor het verzenden van de gebeurtenisentiteitsgegevens naar een module voor het toekennen en het uitvoeren van gebeurtenissen die specifiek is voor een gegeven entiteit, en entiteitspecifieke logica om vast te stellen of gegevens betreffende een specifieke gebeurtenisentiteit die dient uitgevoerd te worden nog steeds aanwezig zijn in de eerste en/of tweede cache, alsook logica voor het actualiseren van de eerste en/of tweede cache nadat een gebeurtenis is afgerond.

Bij elke actualisatie van de eerste en tweede cache worden de gegevens in de eerste en de tweede cache bij voorkeur weggeschreven naar een schijf. De cachemodule omvat bij voorkeur eveneens een derde cache (“entiteitsarchief”) om een archief bij te houden van afgeronde gebeurtenissen, geconfigureerd om gegevens te bewaren die door de verwerkingsmodulelogica op een afgewerkte gebeurtenis zijn geplaatst, en na verwijdering uit de eerste cache. De cachemodule omvat bij voorkeur eveneens een vierde entiteitcache (“dead letter cache”) om gegevens op te slaan die betrekking hebben op gebeurtenissen die niet uitgevoerd konden worden naar aanleiding van een aan het systeem externe factor, bijvoorbeeld bedoeld voor een operator. Bij voorkeur omvat het systeem bovendien een entiteitspecifieke logica om een roll-back te initiëren van een transactie die betrekking heeft op een voordien afgeronde gebeurtenis, en om de eerste cache dienovereenkomstig te actualiseren.

De knoop is bij voorkeur een eerste knoop, en het systeem omvat bovendien één of meerdere tweede knopen die voorzien zijn van een afzonderlijke cache (“gewijzigde entiteitlijst cache”), verwerkende interceptorlogica, en gebeurtenis-transferlogica, waarbij de knoop die de primaire kopie (“de primaire knoop”) van een gebeurtenis in kwestie wordt bepaald als de primaire actieve knoop in de tweede (“to-handle”) cache, terwijl de ene of meerdere knopen waarin een secundaire kopie aanwezig is, wordt of worden bepaald als de secundaire of back-up knopen die de gebeurtenis in kwestie niet uitvoeren.

Een recuperatielogica kopieert bij voorkeur, bij elke actualisatie van de eerste en/of tweede cache, gegevens en de gewijzigde entiteitlijstcache van de eerste knoop naar de gewijzigde entiteitlijst van de één of meerdere knopen waarin een secundaire kopie aanwezig is (“de secundaire of back-up knopen”) die de gegevens en hun interne cache dienovereenkomstig vanuit de to-handle cache actualiseren.

De recuperatielogica kan zodoende “te verwerken” gebeurtenissen selecteren waarvoor de knoop waarop de recuperatielogica wordt uitgevoerd de primaire kopie van de gebeurtenis omvat, en kan deze in de gewijzigde entiteitlijst plaatsen.

De recuperatielogica draait bij voorkeur op elke knoop, dat wil zeggen eveneens op de knopen waarin een back-up kopie aanwezig is. Op de “back-up” knoop worden de “backed up” gebeurtenissen echter niet geselecteerd om zodoende geen dubbele verwerking te creëren. Enkel indien deze back-up knoop primair wordt gemaakt, kan de waakhond de geplande gebeurtenissen uit de to-handle cache ophalen om deze te laten verwerken in de nu primaire knoop.

Daarenboven is bij voorkeur waakhondlogica aanwezig die geconfigureerd is om op regelmatige tijdstippen of bij het zich voordoen van een vooraf bepaalde gebeurtenis alle in de lijst voorkomende entiteitgebeurtenissen te controleren alsook de gewijzigde entiteitlijstcache, en om deze te vergelijken met de gegevens in de tweede cache (“to-handle cache”), de eerste cache, en om de verwerkende interceptorlogica opnieuw te triggeren en de knoop die is aangeduid als de knoop waarin de primaire kopie van de entiteit in kwestie is opgeslagen in de gewijzigde entiteitlijstcache, bij voorkeur na een vooraf bepaalde tijdsduur, nog beter op een tijdsinterval dat geschikt is om een onmiddellijke verwerking te kunnen verzekeren door de reactieve stroom, en nog beter in een interval met een duur die gelegen is tussen 1 seconde en 20 seconden.

Elke knoop omvat bij voorkeur een waakhondlogica, waarbij de waakhondlogica geconfigureerd is om de ingangen en de tweede cache te controleren en om te bepalen of de knoop waarin de waakhond actief is, de primaire kopie van de entiteit in kwestie omvat; de leeftijd van de ingangsreferentie, en/of de ingangsreferentie aanwezig is in de reactieve stroom; en geconfigureerd om in gevallen waarin de leeftijd van de ingangsreferentie kleiner is dan een vooraf bepaalde maximumleeftijd en de ingangsreferentie nog niet aanwezig in de reactieve stroom, de referentie onmiddellijk in een reactieve stroom te plaatsen.

Bij elke actualisatie van de eerste en van de tweede cache worden de gegevens uit de eerste en het tweede cache bij voorkeur weggeschreven naar een schijf.

De waakhondlogica is bij voorkeur zodanig geconfigureerd dat een gebeurtenis onmiddellijk wordt toegevoegd aan de reactieve stroom om zodoende een onmiddellijke verwerking te verzekeren. Bij voorkeur omvat de reactieve stroom een dispatcherlogica die geconfigureerd is om de reactieve stroom op te splitsen in verdeelde parallelle stromen, waarbij elke stroom op sequentiële wijze de gebeurtenissen verwerkt die betrekking hebben op een specifieke entiteit in kwestie. Bij voorkeur omvat de reactieve stroom een entiteitsverwerkingslogica die geconfigureerd is om te controleren of er verjaarde entiteitgegevens aanwezig zijn in de tweede cache die verwerkt moeten worden, en om de entiteitsreferentie rechtstreeks naar de transactie te verplaatsen in de reactieve stroom.

Het systeem en de werkwijze volgens de onderhavige uitvinding omvatten eveneens netwerklogica die geconfigureerd is om een secundaire knoop te bevorderen tot een primaire knoop indien een gebeurtenis wordt ontdekt die verwerkt had moeten worden door de primaire knoop, en waarbij de promotie wordt geactualiseerd in de tweede cache. Zodra de secundaire knoop bevorderd is tot primaire knoop zal de waakhondlogica die in deze nieuwe primaire knoop draait, de gebeurtenissen oppikken die aanwezig zijn in de to-handle cache, en deze doorsturen met het oog op de verwerking ervan.

Bij voorkeur omvat het systeem bovendien een processor die geconfigureerd is om een entiteit te verplaatsen naar een dead letter cache waar ze de aandacht trekt van een operator indien een aan het systeem extern probleem de beëindiging van een transactie onmogelijk maakt.

Het systeem omvat bovendien bij voorkeur een processor die geconfigureerd is om entiteitspecifieke logica te starten om een roll-back te initiëren van de transactie, en om de eerste cache dienovereenkomstig te actualiseren.

De term EDA (Event-Driven Architecture) of gebeurtenissen-aangedreven architectuur verwijst naar een werkwijze in een systeem waarmee de implementatie mogelijk wordt gemaakt van meertrapse werkwijzen die goederen, diensten, en informatie leveren, en dit met een minimum vertraging. EDA is gebaseerd op een verdeelde verwerking, waarbij “knopen”, dat wil zeggen microdiensten reageren op binnenkomende gebeurtenissen, en als respons daarop gebeurtenissen publiceren. Gebeurtenissenkanalen transporteren vervolgens gebeurtenissen van de ene knoop naar de volgende, gewoonlijk op asynchrone wijze. Dit betekent dat het systeem sneller is en sneller reageert omdat een reactie volgt zodra een gebeurtenis getriggerd is, en dat er gewoonlijk geen centrale respons nodig is om de werkwijze verder te doen lopen. EDA wordt dikwijls gebruikt in combinatie met inmemory datanetwerken (IMDG) om gegevens op te slaan die meer frequent gebruikt of opgevraagd worden, omdat het een snelle inschaling mogelijk maakt. Het IMDG kan op zijn beurt dan gebruikt worden in combinatie met traditionele databases. De frequenter gebruikte of opgevraagde gegevens in de cache van het IMDG maken een snellere toegang tot gegevens mogelijk omdat de gegevens worden opgevraagd uit het geheugen in plaats van uit de database, wat eveneens de belasting van de database beperkt. Ook hebben IMDGs het voordeel dat ze voorzien in caches die verdeeld zijn over een aantal knopen, zodat er een kanaalwerking optreedt waardoor een snellere uitwisseling van gebeurtenissen mogelijk wordt gemaakt.

Omdat alle verwerkende logica opgenomen is in een enkele grote gebruikerstoepassing, namelijk het netwerk, bestaat steeds het risico dat er code of een actie gecorrumpeerd of incompleet is bij het invoeren van wijzigingen, wat aanleiding geeft tot een potentieel totale of gedeeltelijke crash van het volledige systeem.

De term “gebeurtenissen-gebaseerde verwerking” zoals die hier gebruikt wordt, verwijst bij voorkeur naar een gebeurtenissen-aangedreven gegevensprogrammering met een toepassingstromingscontrole die bepaald wordt door gebeurtenissen of toestandswijzigingen. Een gebeurtenissen-gebaseerde verwerking is een geordende structuur of keten van gebeurtenissen en functies. Er is sprake van diverse connectoren die alternatieve en parallelle uitvoeringen van werkwijzen mogelijk maken. Daarenboven wordt het gespecificeerd door het gebruik van logische operatoren zoals OR, AND, en XOR. Een gebeurtenissen-gebaseerde verwerking vereist niet-plaatselijke semantiek, dat wil zeggen dat het gedrag tijdens de uitvoering van een welbepaalde knoop binnen een gebeurtenissen-gebaseerde verwerkingstroom kan afhangen van de toestand van andere delen van de gebeurtenissen-gebaseerde verwerking.

De term “activiteit” of “functie” zoals hij hier gebruikt wordt, verwijst bij voorkeur naar een actieve component van een gebeurtenissen-gebaseerde verwerking die in het bezit is van een mogelijkheid tot het nemen van een beslissing, en die typisch tijd en bronnen nodig heeft.

De term “gebeurtenis” verwijst bij voorkeur, in overeenstemming met DIN 69900, naar een toestand van een gebeurtenissen-gebaseerde verwerking die zich heeft voorgedaan en aanleiding geeft tot een reeks van activiteiten. Een gebeurtenis is een passieve component van een gebeurtenissen-gebaseerde verwerking, en is niet in staat om een beslissing te nemen. Gebeurtenissen kunnen activiteiten triggeren.

De term “knoop” zoals hij hier gebruikt wordt, verwijst naar een autonome opslagknoop van een gebeurtenissen-gebaseerde verwerking, in het bijzonder een knoop die verbonden is met andere knopen in een opslagnetwerk zodat welke dan ook van de knopen kunnen communiceren met welke dan ook van de andere knopen zonder dat de gegevens door een gecentraliseerde switch dienen te passeren. Elke knoop omvat zijn eigen opslagmedium, microprocessor, mogelijkheid tot indexeren, en beheerslaag. Omdat een gebeurtenissen-gebaseerde verwerking een niet-plaatselijke semantiek vereist, kan het gedrag tijdens de uitvoering van een welbepaalde knoop binnen een gebeurtenissen-gebaseerde verwerking afhangen van de toestand van andere knopen van de gebeurtenissen-gebaseerde verwerking, waarbij deze knopen op zeer grote afstand gelegen kunnen zijn. Een cluster van verschillende knopen kan een gemeenschappelijke switch gebruiken, maar elke knoop is eveneens verbonden met ten minste een andere knoopcluster. Knopen zijn individuele onderdelen van de grotere gegevensstructuur, zoals gelinkte lijsten en boom-gegevensstructuren.

Een knoop kan in deze context beschouwd worden als welke deelverzameling dan ook omvattende van de beschikbare software- en hardware-bronnen in een gegevensverwerkend systeem, en kan gewoonlijk maar niet noodzakelijkerwijze één of meerdere processoren omvatten, één of meerdere geheugeninrichtingen, en in sommige gevallen bijkomende hardware-bronnen zoals invoer/uitvoer (I/O) bronnen, netwerkbronnen, of andere types bronnen die toegekend kunnen worden aan een logische partitie. Knopen kunnen in sommige uitvoeringsvormen geïmplementeerd worden in de vorm van modules met meerdere chips, schakelingplaten of -kaarten, boeken, laders, racks, sleuven, sessies, of zelfs combinaties daarvan.

Knopen kunnen eveneens in sommige uitvoeringsvormen autonome computersystemen zijn. In uitvoeringsvormen waarbij een gebeurtenissen-aangedreven optimalisatie wordt gebruikt om de gegevensstabiliteit of het vermogensverbruik te optimaliseren, kunnen knopen eveneens gedefinieerd worden op basis van groeperingen van hardware-bronnen die afzonderlijk ingeschakeld, uitgeschakeld, of op een andere wijze gecontroleerd kunnen worden om het vermogenverbruik te beperken.

Vanuit het standpunt van de hier beschreven uitvoeringsvormen kan een knoop dan ook ten minste een verzameling van processoren en geheugen omvatten die neergeschakeld of volledig uitgeschakeld kan worden, onafhankelijk van andere knopen.

Bij voorkeur zijn knopen opgeslagen in netwerken. Een opslag in netwerken introduceert een nieuw niveau van foutentolerantie en redundantie. Indien er sprake is van een fout in een welbepaalde opslagknoop of indien een traject tussen twee knopen wordt onderbroken, kan het netwerk de toegang op een andere manier opnieuw routen of naar een redundante knoop leiden. Dit reduceert de noodzaak voor online-onderhoud, wat nagenoeg een eliminatie inhoudt van eventuele downtime. Ook zorgen de meerdere trajecten of paden tussen paren met knopen ervoor dat een opslagnetwerk een optimale performantie kan behouden in omstandigheden met fluctuerende belasting. Ook is een netwerkopslag inschaalbaar. Indien een nieuwe opslag wordt toegevoegd, kan deze automatisch herkend worden door de rest van het netwerk. Dit beperkt de noodzaak aan dure hardware-upgrades en voorkomt downtime. Geschikte softwarepakketten voor netwerkopslag voor het verwerken van de opgeslagen gegevens zijn te verkrijgen bij Gemfire, Hazelcast, XAP Gigaspaces en GridGrain. Wat dit betreft, zal het gebruikte softwarepakket bij voorkeur fungeren als gegevenstoegangs- en verwerkende laag tussen de toepassing en de gegevensopslag, en zal het gebruikmaken van geheugen (RAM) als primaire gegevensopslag voor gegevens die verwerkt worden, in plaats van deze weg te schrijven naar een schijf.

Normaal gezien maken netwerkopslagsystemen voor het verwerken van opgeslagen gegevens gebruik van een enkele gegevenscache die toegankelijk is voor alle knopen. Omdat echter niet alle knopen in het systeem en het apparaat volgens de onderhavige uitvinding dezelfde functionaliteit bezitten, mag elke afzonderlijke gebeurtenis die door het systeem en door het apparaat volgens de onderhavige uitvinding verwerkt wordt, enkel terechtkomen in de knopen die in staat zijn om ze te verwerken. Hiervoor zijn het systeem en het apparaat volgens de onderhavige uitvinding in het bezit van verschillende voorbehouden gegevenscaches voor elk type gebeurtenis, en elke van deze gegevenscaches is enkel toegankelijk voor de knopen die in het bezit zijn van de code voor dit type gebeurtenis. Gridgrain biedt bijvoorbeeld technologie aan om gegevens op te slaan in een voorbehouden gegevenscache, waarbij deze gegevens enkel verdeeld worden naar een vooraf bepaalde verzameling van knopen. Wanneer gegevens in een gegevenscache geplaatst worden, volstaat het om GridGain op de hoogte brengen van de naam van de voorbehouden gegevenscache. Wat dit betreft, kunnen de namen van elke verzameling van voorbehouden gegevenscaches opgeslagen worden en voorGridGain toegankelijk zijn in een configuratiecash.

In het systeem en het apparaat volgens de onderhavige uitvinding is elke voorbehouden gegevenscache voorzien van een specifieke naam voor elke van de gebeurtenissen volgens de uitvinding waarvoor gegevens worden opgeslagen. De knopen die een specifieke gebeurtenis kunnen verwerken, plaatsen de naam van de voorbehouden gegevenscache in een eerste entiteitcache en in drie andere caches die allemaal voorzien zijn in het netwerk. Wanneer een knoop opstart, registreert deze zich in het netwerk en verzoekt dat het netwerk hem toegang verleent tot de voorbehouden gegevenscache met de specifieke naam van de gebeurtenis die door de knoop verwerkt wordt.

De netwerkcache wordt eveneens op de hoogte gebracht wanneer knopen opstarten, en welke knopen beschikbaar zijn. De voorbehouden cache omvat het type gebeurtenis en de naam van de gebeurtenis. Doordat elke knoop zich in het netwerk registreert, kent het netwerk op basis van de configuratiecash de knopen die in staat moeten zijn om toegang te krijgen tot de voorbehouden gegevenscache met de specifieke naam van de gebeurtenis. De verzoekverwerker kent de naam van de voorbehouden gegevenscache door deze op te zoeken in de to-handle cache. Wanneer de verzoekverwerker het verzoek naar de knopen wenst te versturen, plaatst hij dit in de voorbehouden gegevenscache met de correcte naam, waarna het netwerk weet naar welke knopen het het verzoek kan versturen. Door op deze wijze gebruik te maken van de voorbehouden gegevenscaches en van de to-handle cache, dient de verzoekverwerker enkel de naam of de namen van de voorbehouden gegevenscache(s) te kennen voor elk verzoek. De verzoekverwerker duidt eveneens een knoop als primaire knoop aan, dat wil zeggen de knoop waarin de primaire actieve kopie van de gebeurtenis aanwezig is.

Knopen die zijn aangeduid als in het bezit zijnde van een secundaire, back-up kopie van de gebeurteniszullen “secundaire” of back-up-knopen genoemd worden.

De term “gebeurtenissen” zoals hij hier gebruikt wordt, verwijst bij voorkeur naar de acties (bijvoorbeeld autorisaties, verificatie, back-end verzoeken, enzovoort) die zich voordoen in een gebeurtenissen-gebaseerde verwerking, getriggerd door externe verzoeken door gebruikers, of door de verwerking van vroegere gebeurtenissen. In het geval van een bankomgeving kan er bijvoorbeeld als volgt sprake zijn van een gebeurtenisentiteit van een klant tussen een front-end veiligheidslaag en een back-end gegevensverwerkende laag van een bank: een gebeurtenisentiteit van een klant kan onderverdeeld worden in meerdere kleine gebeurtenissen, zoals: 1) het door hem of haar controleren van zijn of haar bankrekening om de balans ervan te kennen; 2) het vervolgens starten met het uitvoeren van een betaling vanuit zijn of haar rekening; 3) het vervolgens bevestigen en finaliseren van de betaling, waarbij er zich een gebeurtenis voordoet en de gebeurtenis eindigt. Een gebeurtenis in overeenstemming met de onderhavige uitvinding zou kunnen zijn: bijvoorbeeld een gebeurtenis voor een bankrekening: elke ingang en de actuele balans van een klant, alsook elke autorisatie, verificatie, back-end verzoek, enzovoort die zich intern voordoen en die getriggerd worden door gebeurtenissen en externe verzoeken, wordt opgeslagen en geactualiseerd, en alle wijzigingen kunnen weergegeven worden; een gebeurtenis van een toestemmingsstatus: elke wijziging van de toestemming van een klant om in zijn of haar naam een actie uit te voeren, bijvoorbeeld door een handelaar, wordt opgeslagen en geactualiseerd, en alle wijzigingen kunnen weergegeven worden; een gebeurtenis voor energiebeheer, bijvoorbeeld een elektriciteit- of gasmeter: elke uitlezing van een gas-en/of elektriciteitmeter wordt opgeslagen, en alle wijzigingen kunnen weergegeven worden; een gebeurtenis van een computer/telefoon-back-up: alle systeem back-ups worden opgeslagen, en alle wijzigingen kunnen weergegeven worden zodat de redenen voor welk probleem dan ook met de computer/telefoon geïdentificeerd kan worden.

Figuur 1 geeft een weergave van een te verkiezen uitvoeringsvorm van het apparaat en van het systeem (101), een externe gebeurtenis (102) verwerker (107) omvattende. Een gebruikersterminal (103) voor het versturen van verzoeken en voor het ontvangen van responsen is met de front-end interface (106) verbonden via de veiligheidslaag (104). De front-end interface omvat één of meerdere verzoekverwerkers (105) die het verzoek controleren. De verzoekverwerker heeft eveneens toegang tot de ID van de entiteit en tot de entiteitsgevenscache, alsook tot het netwerk, teneinde het verzoek naar een knoop (413) te sturen met de geschikte gebeurtenisverwerkingslogica. Een gelijkaardige opeenvolging kan bestaan voor verschillende gebeurtenissen, waarbij een afzonderlijke gebeurtenisverwerker beschouwd kan worden als een verschillende soort knoop..

De knoop is bij voorkeur aanwezig in een container, en omvat een verzoekverwerker (415), een gebeurtenissenprocessor (418) en logica om een welbepaalde gebeurtenisentiteit te verwerken. Een primaire en één of meerdere secundaire knopen van hetzelfde type maken gemeenschappelijk gebruik van de gebeurtenis- en gegevenscaches die enkel toegankelijk zijn voor knopen van dit type (416), terwijl alle knopen de dynamische configuratiecache (411) gemeenschappelijk kunnen hebben.

Zodra een gebeurtenis verwerkt is, treedt de gebeurtenisprocessor in onderhandeling en communiceert hij met de communicatiegebeurtenisgegevenscache en met de reactieve stroom (425) via een communicatieknoop (422). Het systeem brengt zodoende een verbinding tot stand met een back-end, en levert een front-end voor gebruikers, en is in grote mate inschaalbaar omdat bijkomende knopen kunnen toegevoegd worden, en door gebruik te maken van de dynamische configuratiecache in een netwerk.

Figuur 2 geeft een weergave van een werkwijzestroom in het systeem, dat wil zeggen wanneer er een verzoek komt en de verzoekverwerker het verzoek doorstuurt naar het netwerk. Het netwerk voorziet in de volgende caches: entiteitcache (209A), to-handle cache (209B) waarin de diverse gebeurtenissen worden weergegeven die verdeeld zijn naar twee knopen, dead letter cache (209C), en de entiteitsarchiefcache (209D). Het systeem omvat bovendien een transactiemonitor (221), een te consulteren opslag (220), na-afrondingslogica (212), en na-toekenningslogica (214), waakhondlogica (211), een notifier (213), en een in-memory gewijzigde-entiteitlijst (210) die in de knoop in geheugen wordt gehouden, en alle gegevens van de “to-handle cache” omvattende. Het systeem omvat bovendien een verwerkend systeem voor de reactieve stroom, een dispatcher (216), alsook per traject-ID een voorbehouden entiteitprocessor. Bij voorkeur worden gebeurtenissen gericht op een specifieke trajectinstantie. Gebeurtenissen voor verschillende trajectinstanties kunnen bijvoorbeeld parallel verwerkt worden, maar gebeurtenissen voor dezelfde trajectinstantie zullen bij voorkeur op sequentiële wijze verwerkt worden. Dit wordt uitgevoerd door de dispatcherlogica die de gebeurtenissen naar een nieuwe reactieve stroom verplaatst die enkel gebeurtenissen voor dezelfde trajectinstantie omvat.

De verzoekverwerker vindt een verzoekprocessor en voert het verzoekproces zo snel mogelijk uit en slaat het verzoek op voor toekomstige referentie. De verzoekprocessor vertaalt vervolgens het verzoek in een gebeurtenis. Nadat de verzoekprocessor de gebeurtenis in een cache heeft geplaatst, wordt het geheel bij voorkeur weggeschreven naar een schijf als onderdeel van de verwerking.

Als onderdeel van deze transactie wordt de gebeurtenisreferentie eveneens in de “to-handle cache” geplaatst en in de “gewijzigde-entiteitlijst”. Wanneer deze transactie wordt toegekend, wordt de “na-toekenningslogica” getriggerd. Voor elke gebeurtenis die deel uitmaakt van de “gewijzigde-entiteitlijst” wordt de notifier getriggerd op de knopen waarin de primaire kopie van de gebeurtenis aanwezig is. De notifier plaats vervolgens de gebeurtenis op de reactieve stroom van de knoop waarin de primaire kopie aanwezig is. Wanneer dit gebeurd is voor alle ingangen van de “gewijzigde-entiteitlijst” wordt de “na-afrondingslogica” getriggerd die de “gewijzigde-entiteitlijst” wist.

Het gebeurtenissenproces wordt zodoende door de reactieve stroom geïnitieerd en zodra het is afgerond, wordt de gebeurtenis in de eerste netwerk geplaatst en weggeschreven naar een schijf of naar een ander niet-transitoir geheugen, eerder dan naar een wachtrij, zodat gegevens nooit verloren gaan. De primaire gebeurtenissenknoop voert de actuele gebeurtenissenprocesstappen uit van de gebeurtenisseninterceptor tot het doorgeven aan de reactieve stroom.

Tijdens deze periode verzekert een recuperatielogica (niet weergegeven in dit diagram) bij voorkeur dat, indien een knoop crasht naar aanleiding van een technologisch probleem en indien gebeurtenissen niet verwerkt worden, de gebeurtenis zal opgepikt worden en zal verwerkt worden door de processor wanneer het systeem opnieuw opstart. Zodra een nieuwe gebeurtenis binnenkomt, wordt ze opgeslagen in de eerste cache, en wordt de interceptor getriggerd. Indien de verwerking wordt onderbroken, zou de nieuwe gebeurtenis niet verwerkt worden omdat ze reeds aanwezig is in de cache, zonder dat er een spoor is van de werkelijke uitvoering. De recuperatielogica, ook wel waakhond genoemd, controleert daarom op regelmatige tijdstippen om te kijkien of de gebeurtenissen in de cache verwerkt zijn en, indien dit niet het geval is, triggert hij opnieuw de interceptor en plaatst hij oudere gebeurtenissen rechtstreeks op de reactieve stroom.

Figuur 3 geeft een meer gedetailleerde weergave van de wijze waarop de waakhondlogica werkt: de planner (319) start de waakhondlogica (311) op basis van een commando dat door een timer wordt afgegeven. De waakhond controleert vervolgens (302) voor elke ingangsreferentie in de gewijzigde-ingangslijst” (310) of de knoop waarin hij werkzaam is de primaire kopie van de entiteit in kwestie omvat, of de leeftijd van de ingangsreferentie kleiner is dan de maximum leeftijd; en of deze referentie niet reeds aanwezig is op een reactieve stroom. Indien dat niet het geval is, keert hij terug naar het controleren van de “gewijzigde-ingangslijst”. Indien de leeftijd te hoog is en indien de primaire knoop actief is, wordt de referentie rechtstreeks op de reactieve stroom geplaatst.

Figuur 4 geeft een weergave van een stroomdiagram voor stappen en systeementiteiten (401) die deelnemen aan de verwerking en aan de uitvoering van een gebeurtenis. Een entiteitscreatie-eenheid (402) creëert een gebeurtenisentiteit (403). Deze entiteit wordt vervolgens in de eerste cache geplaatst (404) als persisterende entiteit, en vervolgens initieert de te consulteren opslag (420) de transactie (405) door de entiteit in de eerste entiteitcache in het netwerk te plaatsen (406). Het netwerk plaatst de entiteitsreferentie eveneens in de tweede, “to-handle cache” (422), voorzien van een tijdstempel (tijdstip van creatie en aantal pogingen = 0). Een primaire knoop plaatst de entiteitsreferentie in de gewijzigde-entiteitlijst (423), en de toekenningstransactie-interceptorlogica (42) kent een transactie toe (425), dat wil zeggen aan het einde van de transactie wordt de “toekenning” uitgevoerd en dit verzekert dat al de wijzigingen die doorgevoerd zijn, permanent zijn gemaakt. Een transactiemonitor van het netwerk beheert de diverse caches en ingangen daarin, en zorgt ervoor dat de gegevens regelmatig worden geactualiseerd en indien nodig weggeschreven worden naar een schijf.

Na de toekenning (414) controleert (427), voor elke ingangsreferentie in de “gewijzigde-ingangslijst” 426, het systeem of een knoop de primaire kopie van de entiteit in kwestie omvat, dat wil zeggen of de primaire knoop de gebeurtenis zal dienen uit te voeren. Indien de knoop niet een primaire knoop is maar eerder een secundaire of een back-up-knoop, geeft het systeem (427) het netwerk de opdracht (431) om de notifier (413) uit te voeren op de knopen waarin de primaire kopie van de entiteit in kwestie bewaard wordt. De notifier (413) kopieert (428) vervolgens de entiteitsreferentie naar de reactieve stroom (415). Na afronding (414) maakt het systeem de gewijzigde-ingangslijstcache van de knoop leeg (432). Wanneer er entiteitsreferenties in de stroom aanwezig zijn, geeft een reactieve stroomdoorstuureenheid (416) de gebeurtenissen door aan de dispatcher en verwijdert ze uit de stroom. De dispatcher groepeert (435) de entiteitsreferenties op basis van de entiteit-IDs, en verplaatst elke groep naar een voor de entiteit-ID in kwestie voorbehouden reactieve stroom. Dit maakt het op interessante wijze mogelijk om de gebeurtenissen te verdelen over de reactieve stroom en tegelijkertijd om een sequentiële verwerking mogelijk te maken van een specifieke entiteit, om zodoende een duplicatie te vermijden, en dit zonder gebruik te moeten maken van welk statisch geheugen dan ook. De relevante entiteitsprocessor (417) neemt vervolgens de gebeurtenissen die terug te vinden zijn in de stroom in de volgorde waarin ze voorkomen, en start een transactie (437) om de knoop te actualiseren en om de in de cache opgeslagen gegevens in de transactiemonitor (421) van het netwerk te actualiseren (438).

Ook nu weer, wanneer er entiteitsreferenties zijn in de stroom, zal de reactieve doorstuureenheid de gebeurtenissen doorsturen naar de entiteitsprocessor en ze verwijderen uit de stroom-entiteitsprocessor (436).

Om dan de eenmalige verwerking te verzekeren voert de reactieve stroom eveneens het volgende uit: de reactieve stroom roept de entiteitdetails op uit de entiteitcache (431).

Vervolgens controleert hij of de entiteit-ID een aantal pogingen tot transactie vertoont dat boven het vooraf bepaalde maximum aantal pogingen (440) is gelegen. Indien dat het geval is, verplaatst hij de entiteitsreferentie van de “to-handle cache” (de tweede cache in het netwerk) naar de derde cache, de “dead letter cache”, teneinde deze zodoende onder de aandacht te brengen van een operator. Dit is bijzonder relevant indien de verbinding met een backofficesysteem, bijvoorbeeld een database van een bank of dergelijke, gecrasht is, zodat een gebeurtenis niet kan verwerkt worden naar aanleiding van een aan het systeem externe oorzaak. Dit zal eveneens een transactie toekennen in de knoop en zal een transactie toekennen in de cache zodat een gebeurtenisentiteit wordt verwijderd uit de eerste en tweede cache.

Indien de entiteit-ID en de geschiedenis van de verwerkingspogingen die aanwezig is in de to-handle cache een aantal pogingen aantoont om de transactie uit te voeren, een aantal dat lager is dan de vooraf bepaalde drempelwaarde voor het maximum aantal pogingen (440) kan het systeem eveneens het aantal pogingen (445) incrementeren, en start het (446) de entiteitspecifieke logica (447). Deze entiteitspecifieke logica (447) evalueert de gegevens vervolgens die betrekking hebben op de entiteit-ID in de eerste en tweede caches, en actualiseert ofwel de caches indien de transactie is afgerond, of, indien de entiteitspecifieke logica een fout meldt (448), dat wil zeggen dat de gebeurtenisgegevens die behoren tot de specifieke gebeurtenis niet langer aanwezig zijn in de to-handle cache, wordt er een roll-back geïnitieerd van de relevante transactie (457 en 458), respectievelijk in de knoop en in de cache. Indien de entiteitspecifieke logica vaststelt dat er geen verkeerde ontdubbeling van activiteiten heeft plaatsgevonden, verwijdert (453) hij de entiteitsreferentie die nog steeds aanwezig is in de “to-handle cache” uit de “to-handle cache“, en verplaatst (454) hij de entiteit van de “entiteitcache” naar de “entiteitsarchiefcache” en kent hij de relevante transacties toe (455 en 456) in beide knopen en in het netwerk. Door de controle op te nemen in de stap met het verwijderen van de gegevens uit de to-handle cache wordt het systeem ontzettend efficiënt gemaakt omdat het kleine aantal potentiële gevallen waarin twee of meerdere knopen, of twee of meerdere reactieve stromen dezelfde gebeurtenis zouden kunnen uitvoeren, inhoud dat slechts in een zeer klein aantal gevallen een roll-back dient geïnitialiseerd te worden, waarbij het overgrote deel van de gevallen eenvoudigweg aanleiding zal geven tot een normale en precies eenmalige uitvoering. Meer bepaald in combinatie met de waakhondlogica, en met de netwerklogica die knopen opnieuw opstart of toevoegt, zijn de onderhavige werkwijze en het onderhavige systeem in staat om een gegarandeerd foutloze en gegarandeerd slechts eenmalige uitvoering van een gebeurtenis door te voeren, met een minimale ontdubbeling van bronnen, waarbij een verveelvoudiging van beide knopen, alsook van de reactieve stromen mogelijk wordt gemaakt zodat ingespeeld kan worden op een variatie van het gegevensverkeer.

Stap a) van de onderhavige werkwijze omvat bij voorkeur het wegschrijven van de opeenvolgende wijzigingen in de statusgegevens naar de eerste en/of tweede cache, waarbij een knoop wordt aangeduid als zijnde een primaire knoop voor het uitvoeren van een gebeurtenis, en waarbij ten minste een tweede knoop wordt aangeduid als secundaire knoop die niet actief is om dezelfde gebeurtenis uit te voeren, en waarbij de eerste en tweede caches dienovereenkomstig worden geactualiseerd. Indien de primaire knoop niet actief is of gedeactiveerd is alvorens een transactie uit te voeren, omvat het netwerk bij voorkeur logica die een secundaire knoop bevordert tot primaire status, geconfigureerd om de gebeurtenis als primaire knoop uit te voeren.

Op deze wijze kan verzekerd worden dat een transactie die vergeten zou kunnen zijn, wordt gestart door de waakhondlogica. In het geval waarin dit veroorzaakt wordt door een duplicatie, dat wil zeggen naar aanleiding van asynchrone gegevens, zal de roll-back werkwijze die geïnitialiseerd wordt door een entiteitspecifieke logica op de reactieve stroom ook alle dergelijke activiteiten inhouden, zoals hierna nader zal worden beschreven. De combinatie van de twee stappen en het gebruik van de netwerkcache voor niet-transitoire gegevens maakt het mogelijk om, zonder gebruik te moeten maken van al te veel schijfruimte en zonder de daarmee gepaard gaande vertraging te moeten accepteren, een werkwijze uit te voeren aan een optimale snelheid en met een optimale verdeling, waarbij een onmiddellijke en enkel eenmalige uitvoering echter verzekerd wordt.

In het onderhavige systeem zijn bij voorkeur gebeurtenisverwerkers en gebeurtenissenprocessoren voorzien die gebeurtenissen kunnen definiëren, implementeren, testen, starten, monitoren, en/of wijzigen. Het netwerk maakt dat op interessante wijze mogelijk door de gegevens en de verwerking daarvan samen te houden, waardoor een pan-systeem gegevenstransfer vermeden kan worden.

Elke gebeurtenis wordt bij voorkeur gestart in een afzonderlijke container. De oplossing is dan ook een concrete praktische en nuttige realisatie van het microdienstenconcept op hoog niveau. Door elke gebeurtenis te creëren in de vorm van een individuele, uit te voeren microdienst kan deze op interessante wijze gemodificeerd worden zonder een effect te hebben op de reeds bestaande knopen, waardoor het risico op het crashen van het systeem gereduceerd wordt.

Wanneer een gebeurtenis gestart wordt, kan het systeem vervolgens een nieuwe secundaire knoop opstarten als back-up functionaliteit, parallel aan de primaire knoop. Dit maakt het op interessante wijze mogelijk om variantie en nieuwe aanbiedingen en gebeurtenissen aan te kunnen bieden zonder het bestaande systeem stil te moeten leggen, en zonder dat dat een effect heeft op de werking ervan. In het geval dat een knoop niet correct zou werken, kan de secundaire knoop eenvoudigweg gestopt worden en kunnen de problemen verholpen worden zonder welke dan ook van de werkwijzen en processen te moeten stoppen.

Voorbeelden van gebeurtenissen zijn de volgende: in een bankomgeving kan een klant verzoeken om een transactie uit te voeren, bijvoorbeeld een transfer van fondsen van een rekening. Dit verzoek wordt dan verwerkt door een verzoekverwerker die een primaire knoop aanduidt voor de uitvoering, alsook één of meerdere secundaire knopen die fungeren als niet-actieve back-up knopen. Zodra het verzoek gestart is, zal de knoop normaal gesproken een werkwijze uitvoeren die het controleren van een balans kan omvatten, de correctheid van de rekeningnummers, en het controleren van het recht van de klant om de actie uit te voeren, en eventueel vereisten uitwisselen indien bijvoorbeeld de valuta gewijzigd wordt. Het ligt voor de hand dat een dergelijke werkwijze of proces kritisch slechts een enkele keer en precies een enkele keer kan uitgevoerd worden, omdat anders de transactie gedupliceerd zou worden. In het geval dat de primaire knoop niet reageert, bijvoorbeeld naar aanleiding van een fout of van een onderbreking van een communicatielijn, kan de transactie in haar volledigheid niet uitgevoerd zijn, wat aanleiding kan geven tot praktische problemen, bijvoorbeeld een uitzetting indien de betaling bedoeld was voor het betalen van huurgelden, of andere gelijkaardige ongewenste effecten. Als alternatief zal een back-up- en herstartprocedure ontzettend traag verlopen en de rest van de volledige procedure verstoren, dat wil zeggen ook voor andere transacties.

De onderhavige oplossing kan gebruikt worden om een flexibel systeem te creëren dat een ingebouwde redundantie en een gegarandeerd eenmalige verwerking van een bezoek mogelijk maakt, terwijl enkel gebruik wordt gemaakt van minimale bijkomende bronnen. Daarenboven kan de nodige geografische stabiliteit worden gerealiseerd om problemen te vermijden naar aanleiding van plaatselijke gebeurtenissen, bijvoorbeeld stroomonderbrekingen of onderbrekingen van communicatielijnen, door een geografisch gestabiliseerde omgeving te creëren. Ook kunnen pieken in gegevensverkeer opgevangen worden door gebruik te maken van zich op afstand bevindende componenten die niet volledig belast worden, bijvoorbeeld op verschillende tijdstippen die verspreid zijn over de volledige dag.

De term “container” zoals die hier gebruikt wordt, verwijst bij voorkeur naar een softwarepakket, ook wel een microdienst genoemd van een gebeurtenissen-gebaseerde verwerking, alles omvattende wat nodig is om het softwarepakket uit te kunnen voeren: code, run-time, systeemhulpmiddelen, systeembibliotheken, namelijk alles wat op een server kan uitgevoerd worden. Een container verzekert dat de software ervan steeds op dezelfde wijze zal uitgevoerd worden, ongeacht de omgeving. Een container omvat gewoonlijk een volledige run-time omgeving: een toepassing, met inbegrip van al de afhankelijke onderdelen ervan, bibliotheken, en andere binaire bronnen, alsook configuratiebestanden die nodig zijn om de software uit te voeren, en dit alles gebundeld in een enkel pakket. Door het tot een container omvormen van een toepassingsplatform en van de afhankelijkheden ervan zullen de effecten van verschillende bedieningssystemen en in de onderliggende infrastructuur vermeden kunnen worden. Geschikte container-softwarepakketten zijn bijvoorbeeld verkrijgbaar bij Docker, Linux Containers, FreeBSD jails, AIX Workload Partitions, Solaris Containers, en CoreOS rkt.

Het tot een container omvormen van de knopen verzekert op interessante wijze de werking en ontwikkelingen; veiligheid door middel van redundantie de isolatie van knopen in geval van problemen, eenvoudige beperkingen van de toegang; vereist een communicatie tussen de knopen; encryptie; maar laat een wijzigbaarheid en aanpassing van de versies mogelijk zonder lopende activiteiten te verstoren.

Het systeem en het apparaat omvatten bij voorkeur eveneens een kopie van de container die de één of meerdere knopen omvat. Het systeem en het apparaat laten nog beter toe dat de container en de kopie ervan op verschillende servers lopen.

Het systeem en het apparaat omvatten bij voorkeur ook alle knopen die elk in communicatie staan met een configuratiecache die toegankelijk is voor de front-end interface. Wat dit betreft, is elke knoop geconfigureerd om gegevens op te slaan betreffende de ene of meerdere gebeurtenissen waarvoor hij geconfigureerd is om die te verwerken, volgens gegevens in de configuratiecache, terwijl de front-end interface geconfigureerd is om het verzoek naar de knoop. door te sturen op basis van gegevens in de configuratiecache

Het systeem en het apparaat omvatten bij voorkeur ook alle knopen die geconfigureerd zijn om een gebeurtenis-ID te genereren voor elke aangevatte gebeurtenis, en om de gebeurtenis-ID mee te delen aan de front-end interface, waarbij de front-end interface geconfigureerd is om een verzoek van een aangevatte gebeurtenis door te sturen naar de knoop op basis van de gebeurtenis-ID. De gebeurtenis-ID wordt vervolgens gedeeld tussen de primaire knoop en de secundaire knoop of knopen, via de eerste en tweede (en bijkomende) caches.

Het systeem en het apparaat omvatten bij voorkeur eveneens één of meerdere acties van ten minste één van de gebeurtenissen, een verzoek omvattende voor informatie die is opgeslagen in een back-end systeem, waarbij de back-end interface geconfigureerd is om vooraf gegevens te laden uit het back-end systeem in een gegevenscache die toegankelijk is voor een veelheid aan knopen wanneer er zich een gebeurtenis voordoet. Het systeem en het apparaat omvatten nog beter eveneens de gebeurtenis die overeenstemt met een gebruiker die een gebeurtenisproces initieert.

Het systeem en het apparaat omvatten bij voorkeur eveneens een back-end systeem, zoals een bank- of verzekeringsysteem, of een nuts-, verkeerscontrole-, of een ander systeem dat een gegarandeerd eenmalige uitvoering vereist.

Het systeem en het apparaat omvatten bij voorkeur eveneens de veelheid aan gebeurtenissen die ten minste één uit een veelheid aan acties omvatten voor het controleren van een balans van een rekening van een gebruiker, een veelheid aan acties voor het versturen van geld naar of vanuit een bankrekening, een veelheid aan acties voor het uitvoeren van een betaling, een veelheid aan acties voor het uitvoeren van een financiële transactie.

Zoals hierboven reeds werd vermeld, illustreert figuur 1 de elementaire architectuur vanuit het standpunt van een toepassing, van een server in het systeem en in het apparaat volgens de onderhavige uitvinding. Het systeem en het apparaat volgens de onderhavige uitvinding omvatten bij voorkeur eveneens ten minste twee parallelle servers, waarvan de ene een back-up is voor de andere, elke met zijn eigen front-end interface, gebeurtenisseninterface, back-end interface, een veelheid aan knopen, en een verzoekverwerker.

De functionaliteit van het systeem en van het apparaat en van elke van de servers ervan is geïmplementeerd met behulp van een centrale processor die het opstarten van script-bestanden beheert en die de werking van elke server controleert. De centrale processor maakt gebruik van een centrale service-eenheid die in de achtergrond loopt en die taken automatiseert van het systeem en van het apparaat. De centrale service-eenheid omvat twee types diensten, een type dat draait op de individuele servers en een ander dat draait over alle servers.

De centrale service-eenheid maakt gebruik van een gebeurtenissen-aangedreven ontwerp om taken uit te voeren door een verzameling directories te monitoren op de verschillende servers en door de aanwezigheid te identificeren van een gebeurtenis alvorens een daarmee geassocieerd script of een daarmee geassocieerde toepassing te initiëren of te triggeren. Diverse scripts en vlaggen kunnen samen gebruikt worden om taken af te werken, en elke taak kan bestaan uit meerdere scripts en/of uit programma's van derde partijen. Een gebeurtenis kan een leeg bestand omvatten, een bestand dat een enkele lijn met gegevens omvat, of een compleet gegevensbestand; terwijl een vlagbestand gegevens omvat die aangeven welke taak moet uitgevoerd worden op basis van de gebeurtenis.

De centrale server-eenheid ondersteunt taken die uitgevoerd worden door standaard internet-gebaseerde diensten (bijvoorbeeld Internet Information Services (IIS) en Active Server Page Network (ASP.NET) diensten, alsook standaard software-framewerk-gebaseerde diensten (bijvoorbeeld Component Object Model Plus (COM+) en .NET diensten). De internet-gebaseerde diensten bieden de nodige functionaliteit voor de robuuste en interactieve gegevensuitwisselingen volgens de onderhavige uitvinding en bieden de nodige functionaliteit voor het aanleveren van gegevens aan gebruikers van de diverse systemen van de IPI 100 in een formaat van het type webbrowser. De software-framewerk-gebaseerde diensten bieden de nodige functionaliteit voor het centraal beheren van alle zakelijke logica en routines die gebruikt worden door de onderhavige uitvinding.

Het systeem omvat bij voorkeur een netwerk van knopen die instaan voor de verwerking en voor in-memory gegevens, waarbij het netwerk van knopen een eerste knoop omvat die de eerste voorbehouden gegevenscache en de eerste voorbehoudenlogica omvat.

Het systeem omvat bij voorkeur een verzoekverwerker om van gebruikers verzoeken te ontvangen voor diensten, waarbij de verzoekverwerker logica en gegevens omvat om een versie van gebeurtenis te bepalen waarop een verzoek betrekking heeft, alsook logica om het verzoek naar de eerste knoop door te sturen indien wordt vastgesteld dat het verzoek betrekking heeft op een versie die door de eerste knoop kan verwerkt worden.

Zoals men kan opmaken uit het architecturale diagram uit figuur 1 komt een verzoek toe en stuurt de verzoekverwerker dit door naar het netwerk. De verzoekverwerker vindt de verzoekprocessor en voert het verzoekproces zo snel mogelijk uit en slaat het verzoek op voor toekomstige referentie.

De verzoekprocessor vertaalt vervolgens het verzoek in een gebeurtenis. Na de verzoekprocessor wordt het gebeurtenisproces geïnitieerd en wordt de gebeurtenis in een cache geplaatst in plaats van in een wachtrij, zodat gegevens nooit verloren gaan.

De stappen in de primaire gebeurtenis worden nu uitgevoerd, vanaf de gebeurtenisseninterceptor tot het einde. Tijdens de volledige periode is er een waakhond (niet weergegeven in dit diagram) actief die ervoor zorgt dat indien de knopen crashen naar aanleiding van een probleem, en gebeurtenissen niet zouden verwerkt worden, de gebeurtenis zal opgepikt worden en zal verwerkt worden door de processor op het moment dat het systeem opnieuw opstart.

Zodra een gebeurtenis toekomt, wordt ze opgeslagen in de cache. De interceptor wordt getriggerd indien er een nieuwe gebeurtenis in de cache wordt geplaatst, en wordt niet getriggerd wanneer de gebeurtenis daar reeds in aanwezig is.

Indien de verwerking op dat punt wordt onderbroken, zal de nieuwe gebeurtenis niet verwerkt worden omdat de gebeurtenis reeds aanwezig is in de cache. De waakhond controleert daarom om er zeker van te zijn of de gebeurtenissen in de cache zijn verwerkt, en indien dat niet het geval is, triggert hij de interceptor opnieuw.

De gegevens die zijn opgeslagen in de primaire knoop zijn eveneens opgeslagen in ten minste één andere, secundaire knoop. Indien de primaire knoop crasht, worden deze weggeschreven naar een schijf/cache. Indien de knoop niet crasht, detecteert de waakhond dat en triggert hij de interceptor op de andere knoop die reeds actief is, zonder echter een verwerking uit te voeren omdat deze knoop was aangeduid als zijnde een secundaire, back-up knoop.

In het systeem volgens de onderhavige uitvinding omvatten de eerste en tweede knopen dienovereenkomstig bij voorkeur een configuratiecache die toegankelijk is voor de verzoekverwerker, waarbij de configuratiecache geconfigureerd is om gegevens op te slaan betreffende de een of meerdere versies van gebeurtenissen die de eerste knoop kan verwerken, waarbij de verzoekverwerker geconfigureerd is om het verzoek te routen naar de eerste knoop op basis van gegevens die aanwezig zijn in de configuratiecache van de eerste knoop.

In het systeem volgens de onderhavige uitvinding omvat het netwerk van knopen bij voorkeur een tweede knoop die de tweede voorbehouden cache omvat en voorbehouden logica. In het systeem volgens de onderhavige uitvinding wordt bij voorkeur voorzien in de eerste gegevenscache en logica door een eerste container, terwijl in de tweede gegevenscache en logica worden voorzien door een tweede container.

De hier gebruikte terminologie is enkel bedoeld voor het beschrijven van welbepaalde uitvoeringsvormen en is niet bedoeld om uitvoeringsvormen van de uitvinding op welke wijze dan ook te beperken. Zoals zij hier gebruikt worden, zijn de enkelvoudsvormen “een”, “de”, “het” bedoeld om eveneens de meervoudsvormen te omvatten, tenzij de context duidelijk aangeeft dat dat niet het geval is. Daarenboven dient opgemerkt te worden dat de termen “omvat” en/of “omvattende”, wanneer ze voorkomen in deze beschrijving, de aanwezigheid aanduiden van de vermelde kenmerken, gehele getallen, stappen, bewerkingen, elementen, en/of componenten, zonder echter de aanwezigheid of het toevoegen uit te sluiten van één of meerdere andere kenmerken, gehele getallen, stappen, bewerkingen, elementen, componenten en/of groepen daarvan.

Figuur 3 geeft een illustratie van de “normale werking” van de werkwijze. De werkelijke planning van de verwerking maakt gebruik van een “reactieve stroom”. Deze bevindt zich in een in-memory wachtrij. Deze reactieve stroom is bij voorkeur onderdeel van een reactief framewerk dat niet verdeeld is, dat wil zeggen dat er geen “back-up kopieën” aanwezig zijn in andere knopen, waardoor de mate van redundantie geminimaliseerd wordt die vereist is voor het systeem volgens de onderhavige uitvinding. Dit kan bijvoorbeeld het geval zijn in een Java-omgeving.

Wanneer er zich een technisch probleem voordoet waardoor een knoop op een server niet verder actief kan zijn, wordt een server of een verbinding uitgeschakeld en verdwijnt deze reactieve stroom of verdwijnen deze reactieve stromen.

In tegenstelling tot het traditionele gebruik van een IMDG waarbij slechts een enkele gegevenscache is voorzien die toegankelijk is voor alle knopen, voorzien het onderhavige systeem en de onderhavige werkwijze in een configuratiecache en in een afzonderlijke gegevenscache. Omdat niet alle knopen dezelfde functionaliteit hebben, moet verzekerd worden dat gebeurtenissen enkel terechtkomen in de knopen dien in staat zijn om deze te verwerken. Het systeem maakt daarom gebruik van voorbehouden caches per type gebeurtenis en deze caches zijn enkel toegankelijk voor de knopen die de code bezitten voor dit type gebeurtenis.

Omdat een IMDG de technologie biedt om gegevens op te slaan in een cache die verdeeld is over een verzameling knopen, zal het netwerk, wanneer gegevens in een cache worden geplaatst, op de hoogte worden gebracht betreffende de unieke naam van de cache. Bij voorkeur worden voorbehouden caches gebruikt met een specifieke naam/benaming voor elk van de types gebeurtenissen. De knopen die in staat zijn om een specifiek type gebeurtenis te verwerken, kunnen dan bij voorkeur de naam van de cache in de configuratiecache plaatsen. Wanneer een knoop opstart, registreert hij zich in het netwerk en verzoekt hij het netwerk om toegang te bekomen tot de cache met de specifieke naam. Het resultaat daarvan is dat de cache, hier ook wel dynamische configuratiecache genoemd, het type gebeurtenis en de naam ervan omvat. Doordat de knoop zich registreert bij het netwerk weet dit laatste welke knopen toegang hebben tot de cache met een specifieke naam. De verzoekverwerker kent op zijn beurt de naam van de cache door deze op te zoeken in de configuratiecache. Wanneer de verzoekverwerker het verzoek naar de knopen wenst te sturen, plaatst hij dat in de cache met de correcte naam, waarna het netwerk weet naar welke knopen het verzoek kan gestuurd worden.

Het op deze wijze gebruikmaken van caches zorgt ervoor dat de verzoekverwerker enkel de naam van de cache dient te weten waarin hij de verzoeken dient te plaatsen; het is dan ook voor de verzoekverwerker volledig transparant hoeveel knopen er beschikbaar zijn die het verzoek kunnen verwerken.

Het gebruik van een gedefinieerde configuratiecache die gevuld wordt wanneer de knopen opstarten en die beschikbaar is voor alle knopen maakt het dan ook op interessante wijze mogelijk om de gegevensoverdracht te beperken, alsook de tijd die nodig is om de cache op te sporen. Alhoewel een verdeelde-cachetechnologie op zich typisch deel uitmaakt van het IMDG, maakt het onderhavige systeem gebruik van een dynamische configuratiecache.

Een tweede cache omvat back-end gegevens in het in-memory datanetwerk, en dit om redenen van performantie. De oorspronkelijke kopie van de gegevens wordt steeds ter hoogte van het back-end bewaard, en om de meest recente gegevens op te vragen, wordt er gebruik gemaakt van een “gegevensopvraaginstructiegebeurtenis”. Om de noodzaak te beperken aan het continu verzoeken van de meest actuele gegevens uit de back-end databases, kan gebruik worden gemaakt van gegevens met een bepaalde leeftijd zonder de werkwijze verstoren, ook wel “gebruik-gebaseerde versheid”. Wanneer een gebeurtenis gegevens dient op te vragen uit het back-end zoekt zij eerst de meest recente gegevens op in de in-memory cache. Hiervoor dient de maximum leeftijd gespecificeerd te worden die de gegevens mogen hebben, vermits de leeftijd de verlopen tijd is sinds het moment dat de gegevens werden opgeslagen in de cache. Indien de gegevens in de cache ouder zijn dan deze maximum leeftijd zal de cache van de “gegevensopvraaginstructiegebeurtenis” starten om de “meest recente” gegevens op te vragen uit het back-end. Wanneer de gegevensopvraaggebeurtenis, die verbonden is met een “communicatiegebeurtenis” de waarde vanuit het back-end terug overbrengt, wordt de waarde in de cache geactualiseerd en voorzien van een tijdstempel. Vervolgens worden de gegevens teruggestuurd naar de oorspronkelijke gebeurtenis die dan vers genoeg is omdat de gegevens net werden opgevraagd.

Op gelijkaardige wijze kan gebruik worden gemaakt van een vooropvraging als optimalisatie, door gebeurtenissen te koppelen die typisch gebruikt worden voor een welbepaalde actie. Wanneer bijvoorbeeld een gebeurtenis voor een geldoverdracht wordt gestart, is het reeds duidelijk dat tijdens een latere fase tijdens de verwerking de details van de te debiteren rekening dienen gecontroleerd te worden. Een gegevensopvraaggebeurtenis die bedoeld is om deze gegevens op te vragen kan dan ook reeds deze waarden uit het back-end ophalen, zelfs indien deze waarden niet onmiddellijk vereist zijn, zodat ze reeds aanwezig zijn in de geheugencache.

Back-end voorladen: in het geval van zeer grote databases kan het laden van in hoofdzaak alle gegevens in het IMDG niet economisch of praktisch verantwoord zijn. In dergelijke omstandigheden kan een gebruiker op selectieve wijze gegevens voorladen waarvan men verwacht dat ze dikwijls opgevraagd of gebruikt zullen worden door of in het IMDG voor gegevens die niet voorgeladen zijn in het IMDG, kan een IMDG klant-voorlader of plug-in fungeren als gegevenstoegangslaag om frequent bezochte gegevens op te halen of te verzamelen uit de database, en om deze gegevens in een cache op te slaan in het IMDG.

Verzochte gegevens kunnen gedefinieerd worden als welke gegevens of gegevensobjecten dan ook die een welbepaald aantal keren of met een welbepaalde frequentie gebruikt, verzocht, of aangesproken worden, waarbij het aantal keren of de frequentie ervan een vooraf bepaalde drempelwaarde overschrijdt, of waarbij een vooraf ingesteld aantal keren toegang wordt bekomen tot de gegevens over een geselecteerde periode.

De werkelijke planning van de verwerking maakt gebruik van een “reactieve stroom”. Dit is een in-memory wachtrij. Deze reactieve stroom maakt bij voorkeur deel uit van een reactief Java-framewerk dat niet verdeeld is, dat wil zeggen dat er geen sprake is van “back-up kopieën” in andere knopen, waardoor de mate van redundantie die vereist is voor het onderhavige systeem geminimaliseerd wordt. Wanneer er zich een technisch probleem voordoet waardoor een knoop of een server crasht, of een server of een verbindingslijn wordt onderbroken, zal deze reactieve stroom of zullen deze reactieve stromen verdwijnen.

Op regelmatige tijdstippen kan een waakhondlogica geactiveerd worden, zoals is terug te vinden in de figuren 3 en 4.

De werking van de waakhond is nodig om ervoor te zorgen dat elke “entiteit” verwerkt wordt, ook ingeval van problemen.

De onderhavige uitvinding biedt ook het voordeel dat het mogelijk is om het systeem te stabiliseren tegen geografische rampen. Back-ups zijn gewoonlijk vereist voor een recuperatie ingeval van een ramp. Gewoonlijk dienen twee machines of datacentra die dezelfde gegevens opslaan, in elkaars buurt gelegen te zijn zodat de actualisatie gesynchroniseerd is omdat, indien ze onderling ver van elkaar afstaan gelegen zijn, er sprake is van een vertraging vanwege de tijd die nodig is voor de gegevens om de tweede machine te bereiken. De normale maximum afstand om latentieproblemen te vermijden, bedraagt 30 km.

In het geval van een plaatselijke ramp wordt typisch een derde machine verder op afstand voorzien, waarbij deze machine niet gesynchroniseerd is, wat betekent dat er een klein venster is van de gegevens dat verloren zal gaan indien de eerste en de tweede machines crashen. Conventioneel bestaan er oplossingen waarbij een knoop gelokaliseerd is aan de oostkust van de Verenigde Staten, terwijl een andere knoop gelokaliseerd is aan de westkust, waarbij gegevens op asynchrone wijze worden geactualiseerd, met het risico dat sommige gegevens verloren gaan indien een knoop zou crashen. Er is echter sprake van een probleem voor wat betreft de nabijheid versus de performantie, wat maakt dat de op afstand gelegen systemen traag zijn.

Om dit probleem op te lossen kan een opstellingsmodel voor de onderhavige uitvinding op interessante wijze twee synchrone machines omvatten die dicht bij elkaar staan opgesteld, bijvoorbeeld in naastgelegen gebouwen, alsook een derde machine die nog steeds dichtbij staat maar die zich op een grotere afstand bevindt dan de twee machines, bijvoorbeeld 15 km (10 km tot 25 km), alsook een vierde asynchrone machine die op zeer grote afstand staat, bijvoorbeeld op 100 km of meer ten opzichte van de andere machines, bijvoorbeeld aan de andere kant van de wereld. Het systeem is bovendien bij voorkeur geconfigureerd om op synchrone wijze gegevens te kopiëren naar een tweede en/of bijkomende knoop die op een verschillende plaats gelokaliseerd is om de stabiliteit van het systeem te garanderen. Bij voorkeur is de ten minste ene tweede knoop gelokaliseerd op een server op een eerste vooraf bepaalde fysieke afstand van ten minste 10 km ten opzichte van de server waarop de eerste knoop draait en waarin de eerste gegevenscache aanwezig is. De verwerking wordt bij voorkeur enkel uitgevoerd op de meest nabijgelegen twee machines, terwijl de andere machines enkel voorzien in backup knopen en de cache delen. Zodra een gebeurtenis is verwerkt, dient er niets meer te gebeuren omdat de gegevens beschikbaar zullen zijn in meerdere machines indien er één of meerdere zouden crashen. De onderhavige uitvinding heeft dienovereenkomstig eveneens betrekking op een systeem dat bovendien geconfigureerd is om op synchrone wijze gegevens te kopiëren naar een tweede en/of bijkomende knopen, en een tweede of bijkomende cache die gelokaliseerd is op een verschillende plaats om de stabiliteit van het systeem te garanderen. Bij voorkeur is ten minste een tweede knoop gelokaliseerd in een server op een vooraf bepaalde fysieke afstand die gelegen is het bereik van 10 km tot 20 km ten opzichte van de server waarop de eerste knoop draait en waarin de eerste gegevenscache aanwezig is. Het systeem kan op interessante wijze eveneens op asynchrone wijze gegevens kopiëren naar een bijkomende secundaire knoop op een tweede vooraf bepaalde fysieke afstand, bij voorkeur op een server die gelokaliseerd is op een afstand van meer dan 100 km, te vergelijken door een bijkomende asynchrone recuperatielogica.

Het systeem is bovendien bij voorkeur geconfigureerd om op asynchrone wijze gegevens te kopiëren naar een bijkomende secundaire knoop op een tweede vooraf bepaalde fysieke afstand, bij voorkeur op een server die gelokaliseerd is op een afstand van meer dan 100 km, om gecontroleerd te worden door een asynchrone recuperatielogica.

De overeenstemmende structuren, materialen, acties, en equivalenten van alle middelen of stappen en functionele elementen in de hierna volgende conclusies zijn bedoeld om welke structuur, welk materiaal, of welke actie dan ook voor het uitvoeren van de functie in combinatie met andere geclaimde elementen te omvatten. De beschrijving van de onderhavige uitvinding werd gegeven ter illustratie en ter beschrijving, en is niet bedoeld om volledig te zijn of om beperkt te zijn tot de beschreven uitvoeringsvormen van de uitvinding. Diverse modificaties en variaties zullen duidelijk zijn en voor de hand liggen voor de vakman in het vakgebied, zonder buiten de reikwijdte te treden van uitvoeringsvormen van de uitvinding. De uitvoeringsvorm werd gekozen en beschreven om zo goed mogelijk de principes van de uitvoeringsvormen van de uitvinding en de praktische toepassing ervan te beschrijven, en om het de vakman in het vakgebied mogelijk te maken om uitvoeringsvormen van de uitvinding te begrijpen voor diverse uitvoeringsvormen met diverse modificaties die geschikt zouden zijn voor het welbepaalde beoogde gebruik. Alhoewel specifieke uitvoeringsvormen werden geïllustreerd en beschreven, zal het voor de vakman in het vakgebied duidelijk zijn en voor de hand liggen dat welk geheel of welke opstelling dan ook die geacht wordt hetzelfde doel te realiseren, kan gesubstitueerd worden voor de specifieke uitvoeringsvormen die beschreven zijn, alsook dat uitvoeringsvormen van de uitvinding in andere omgevingen andere toepassingen kunnen hebben.

Figuren

Figuur 1: 107 externe verzoekverwerker 121 verbindingsknoop

Figuur 3: 301 starten van de waakhond op basis van een timer 302 voor elke ingangsreferentie in de to-handle cache 304 ja 305 nee 306 laatste referentie in de reactieve stroom

Figuur 4: 402 Entiteitscreatie-eenheid 403 creëer een gebeurtenisentiteit 404 Persisterende entiteit 405 Start transactie 406 Plaats entiteit in entiteitscache 407 Start transactie 413 Verwerkingsinterceptorlogica 414 Na toekenning Y Wanneer de entiteitsreferenties in de stroom zijn, stuurt de reactieve doorstuureenheid de gebeurtenissen naar de entiteitsprocessor en verwijdert ze uit de stroom 416 Stroomdoorstuureenheid 417 Entiteitsbewerker 419 Na voltooiing 420 De te controleren opslag 421 Transactiemonitor 422 Plaats entiteitreferentie in ‘to-handle-cache' met tijdstempel (tijdstip van creatie en aantal pogingen =0) 423 Plaats entiteitsreferentie in gewijzigde-entiteitslijst 424 Ken transactie toe 425 Ken transactie toe 426 Voor iedere referentie op de « gewijzigde-entiteitslijst » 427 De knoop omvat de primaire kopie van de entiteit in kwestie 428 Kopieer de entiteitsreferentie naar de reactieve stroom 431 Haal entiteitsdetails op uit entiteitscache 432 Leeg « gewijzigde-ingangslijstcache » 435 Groepeer de entiteitsreferenties op basis van Entiteit-ID en verplaats elke groep naar een voor de entiteits-ID in kwestie voorbehouden reactieve stroom 436 Wanneer de entiteitsreferenties in de stroom zijn, stuurt de reactieve doorstuureenheid de gebeurtenissen naar de entiteitsprocessor en verwijdert ze uit de stroom 437 Start transactie 438 Start transactie 440 Aantal pogingen < maximaal aantal pogingen 441 Verplaats entiteitsreferentie van ‘to-handle-cache' naar ‘dead-letter-cache' 442 Ken transactie toe 443 Ken transactie toe 444 Updates naar caches 445 Incrementeer aantal pogingen 446 Start de entiteitsspecifieke logica 447 Entiteitsspecifieke logica 448 Entiteitsspecifieke logica meldt « Fout »? 450 Roll back van de transactie 452 Entiteitsreferentie is nog in de « To-handle cache » 453 Verwijder entiteitsreferentie uit de « To-handle cache » 454 Verplaats entiteit van « Entiteitscache » naar « Entiteitsarchiefcache » 455 Ken transactie toe 456 Ken transactie toe 457 Roll back van de transactie 458 Roll back van de transactie

Claims (29)

1. GEWIJZIGDE CONCLUSIES

   1. Gebeurtenissen-aangedreven systeem om te voorzien in een gegarandeerd exact eenmalige verwerking van een gebeurtenis in een datanetwerk, waarbij het systeem een netwerk van knopen omvat die voorzien in de verwerking en in in-memory geheugen opgeslagen gegevens, waarbij het systeem bovendien een cachemodule omvat waarin voorzien wordt door het datanetwerk, een gebeurtenissenverwerkende module waarin voorzien wordt door het datanetwerk, en een reactieve stroommodule die verbonden is met maar waarin niet voorzien wordt door het netwerk, en geconfigureerd om een gebeurtenis uit te voeren wanneer daartoe de opdracht wordt gegeven door de gebeurtenissenverwerkende module, waarbij: a. de cachemodule ten minste een cache omvat om identificatiegegevens op te slaan betreffende te verwerken gebeurtenissen in een knoop (“to-handle cache”); b. de gegevensverwerkende module ten minste een eerste knoop omvat die omvat: i. een verzoekverwerker om een verzoek te ontvangen dat overeenstemt met een gebeurtenis die geassocieerd is met een aantal verwerkende stappen die in het systeem moeten uitgevoerd worden; en ii. een verwerkingsinterceptorlogica (“notifier”) voor het kopiëren van de entiteitsreferentie naar de reactieve stroom; en c. waarbij de reactieve stroommodule omvat: i. een verwerkingsmodule (“reactive stream”) voor het parallel uitvoeren van gebeurtenissen, iii. een entiteitspecifieke logica voor het actualiseren van de eerste en/of tweede cache nadat een gebeurtenis is verwerkt en gerelateerde transacties zijn toegekend; en iv. een controlelogica voor het controleren of gegevens in de to-handle cache met betrekking tot een specifieke te verwerken gebeurtenis nog steeds aanwezig zijn voor een toe te kennen transactie, en om een roll-back uit te voeren van welke transactie dan ook voor gebeurtenissen die niet langer aanwezig zijn in de to-handle cache, zodat een gebeurtenisentiteit precies een enkele keer uitgevoerd wordt; waarbij de cachemodule (a) ten minste omvat: i. een eerste cache voor het opslaan van identificatiegegevens betreffende te verwerken gebeurtenissen in een knoop (“event cache”); en ii. een tweede cache voor het opslaan van gegevens die geassocieerd zijn met een gebeurtenissenplanning en -verwerking voor de gebeurtenis die verwerkt wordt door de knoop (“to-handle cache”).
2. 2. Systeem volgens conclusie 1, waarbij de ten minste ene eerste knoop omvat: iii. een verzoekprocessor om een verzoek te ontvangen vanuit de verzoekverwerker en om een te verwerken gebeurtenis te identificeren op basis van het verzoek; en iv. een interne geheugencache (“change entity list”) voor het opsommen van een gebeurtenissenidentificatie, gegevens die geassocieerd zijn met de gebeurtenissenidentificatie en een run-time van de gebeurtenis, alsook gegevens die geassocieerd zijn met het feit of de knoop al of niet staat aangemerkt als een primaire knoop die bedoeld is om de gebeurtenis uit te voeren, of eerder als een secundaire back-up-knoop; en v. een eerste verwerkingsinterceptorlogica (“notifier”) om de identificatiegegevens betreffende de gebeurtenis over te dragen van de eerste gebeurtenissencache (entity) naar de tweede cache (to-handle), en om identificatiegegevens te kopiëren betreffende een gebeurtenisentiteit van de tweede cache (to-handle) naar de “changed entity list”.
3. 3. Systeem volgens een der conclusies 1 of 2, waarbij de verwerking omvat: iv. gebeurtenis-dispatchlogica (“dispatcher”) voor het verzenden van de gebeurtenisgegevens naar een toekennings- en uitvoeringsmodule die specifiek is voor een welbepaalde gebeurtenis, en v. een gebeurtenisspecifieke logica om vast te stellen of gegevens met betrekking tot een specifieke uit te voeren gebeurtenis nog steeds aanwezig zijn in de tweede cache, alsook logica voor het actualiseren van de tweede cache nadat een gebeurtenistransactie op het punt staat om toegekend worden.
4. 4. Systeem volgens een der voorgaande conclusies, waarbij bij elke actualisatie van de tweede cache de gegevens in de tweede cache weggeschreven worden naar een schijf.
5. 5. Systeem volgens een der voorgaande conclusies, waarbij de cachemodule eveneens een derde cache (“entity archive”) omvat om een archief bij te houden van afgewerkte gebeurtenissen, en geconfigureerd om gegevens te omvatten die daarin geplaatst zijn door de logica van de verwerking betreffende een afgewerkte gebeurtenis, en na verwijdering uit de eerste cache.
6. 6. Systeem volgens een der voorgaande conclusies, waarbij de cachemodule eveneens een vierde entiteitcache (“dead letter cache”) omvat voor het opslaan van gegevens die betrekking hebben op gebeurtenissen die niet uitgevoerd konden worden naar aanleiding van een ten opzichte van het systeem externe factor, om geraadpleegd te worden door een operator.
7. 7. Systeem volgens een der voorgaande conclusies, bovendien een entiteitspecifieke logica omvattende om een roll-back te initiëren van een transactie die op het punt staat zijn om toegekend te worden, maar waarvoor er geen overeenstemmende ingang gevonden is in de to-handle cache.
8. 8. Systeem volgens een der voorgaande conclusies, waarbij de knoop een eerste knoop is, en waarbij het systeem bovendien één of meerdere tweede knopen omvat met een afzonderlijke cache (“changed entity list cache”, verwerkings-interceptorlogica, en gebeurtenis-transferlogica, waarbij de knoop die de primaire kopie (“primary node”) omvat van een gebeurtenis waarnaar verwezen wordt, wordt bepaald als zijnde de primaire actieve knoop in de tweede (“to-handle”) cache, waarbij de één of meerdere knopen die een secundaire kopie omvatten, worden bepaald als zijnde de secundaire of back-up knopen die de gebeurtenis waarnaar verwezen wordt niet uitvoeren.
9. 9. Systeem volgens conclusie 8, waarbij bij elke actualisatie in de eerste en/of de tweede cache een recuperatielogica gegevens kopieert in de gewijzigde-entiteitslijstcache van de eerste knoop naar de gewijzigde-entiteitslijst van de één of meerdere knopen die een secundaire kopie omvatten (“secondary or back-up nodes”), teneinde de gegevens in hun interne cache overeenstemmend te actualiseren vanuit de eerste en/of tweede cache.
10. 10. Systeem volgens een der voorgaande conclusies, bovendien waakhondlogica omvattende die geconfigureerd is om op regelmatige tijdstippen of bij het zich voordoen van een vooraf bepaalde gebeurtenis alle opgesomde entiteitgebeurtenissen te controleren in de gewijzigde-entiteitslijst, en om een vergelijking door te voeren met de gegevens in de tweede “to-handle” cache, en de verwerkingsinterceptorlogica opnieuw triggert in de knoop die is aangeduid als deze zijnde die de primaire kopie van de gebeurtenis waarnaar verwezen wordt, omvat, opgeslagen in de gewijzigde-entiteitslijstcache, bij voorkeur na een vooraf bepaalde tijd, nog beter op een tijdstip dat geschikt is om een onmiddellijke verwerking door het reactieve systeem te verzekeren, maar het liefst in een interval van 1 tot 20 seconden.
11. 11. Systeem volgens conclusie 10, waarbij elke knoop een waakhondlogica omvat, waarbij de waakhondlogica is geconfigureerd om de ingangen te controleren in de to-handle cache, en om te bepalen of de knoop waarin de waakhond is geactiveerd de primaire kopie omvat van de entiteit waarnaar verwezen wordt; de ouderdom van de ingangsreferentie, en/of de ingangsreferentie deel uitmaakt van de reactieve stroom; en waarbij, indien de ouderdom van de ingangsreferentie kleiner is dan een vooraf bepaalde maximum ouderdom, de ingangsreferentie nog geen deel uitmaakt van de reactieve stroom, de referentie onmiddellijk in de reactieve stroom wordt geplaatst.
12. 12. Systeem volgens een der voorgaande conclusies, waarbij bij elke actualisatie in één of meerdere van de eerste en tweede caches de gegevens in de eerste en in de tweede caches naar een schijf worden weggeschreven.
13. 13. Systeem volgens één der voorgaande conclusies, waarbij het netwerk logica omvat die geconfigureerd is om een secundaire knoop tot een primaire knoop te bevorderen indien een gebeurtenis wordt gevonden die verwerkt zou moeten zijn door de primaire knoop.
14. 14. Systeem volgens één der voorgaande conclusies, waarbij de waakhondlogica geconfigureerd is om een gebeurtenis onmiddellijk toe te voegen aan de reactieve stroom om een ogenblikkelijke verwerking te verzekeren.
15. 15. Systeem volgens één der voorgaande conclusies, waarbij de reactieve stroom een dispatcherlogica omvat die geconfigureerd is om de reactieve stroom op te splitsen in verdeelde parallelle stromen, waarbij elke stroom op sequentiële wijze de gebeurtenissen verwerkt die betrekking hebben op een specifieke entiteit waarnaar verwezen wordt.
16. 16. Systeem volgens een der voorgaande conclusies, waarbij de reactieve stroom een entiteitsverwerkingslogica omvat die geconfigureerd is om te controleren of er verjaarde entiteitsdetails aanwezig zijn in de tweede cache die verwerkt moeten worden, en om de entiteitsreferentie onmiddellijk over te brengen naar de transactie in de reactieve stroom.
17. 17. Systeem volgens conclusie 16, bovendien een processor omvattende die geconfigureerd is om een entiteit naar een dead letter cache te verplaatsen om deze onder de aandacht te brengen van een operator indien een aan het systeem extern probleem de afronding van een transactie verhindert.
18. 18. Systeem volgens conclusie 16 of conclusie 17, een processor omvattende die geconfigureerd is om entiteitspecifieke logica te starten om een roll-back te initiëren van de transactie indien er geen overeenstemmende entiteit in de to-handle cache aanwezig is.
19. 19. Systeem volgens één der voorgaande conclusies, bovendien geconfigureerd om op synchrone wijze gegevens te kopiëren naar een tweede en/of bijkomende knoop die gelokaliseerd is of zijn in een verschillende locatie, teneinde de stabiliteit van het systeem te verzekeren.
20. 20. Systeem volgens conclusie 19, waarbij de ten minste tweede knoop gelokaliseerd is op een server op een eerste, vooraf bepaalde fysieke afstand van ten minste 10 km van de server waarop de eerste knoop en de eerste gegevenscache worden uitgevoerd.
21. 21. Systeem volgens conclusie 19 of conclusie 20, bovendien geconfigureerd om gegevens aan te leveren en op asynchrone wijze te kopiëren naar een bijkomende tweede knoop op een tweede, vooraf bepaalde fysieke afstand, bij voorkeur op een server die gelokaliseerd is op een afstand van meer dan 100 km, om gecontroleerd te worden door een asynchrone recuperatielogica.
22. 22. Werkwijze om te voorzien in een eenmalige gebeurtenis voor een gegeven gebeurtenissenverzoek of externe gebeurtenis, waarbij het verzoek ten minste één type gebeurtenis omvat, waarbij een gebeurtenis in het bezit is van een begin en van een einde, en een veelheid aan acties omvat die getriggerd wordt door de externe gebeurtenissen of gebeurtenissen die vertaald zijn uit gebruikersverzoeken die ontvangen worden in een systeem volgens een der conclusies 1 tot en met 21, waarbij de werkwijze omvat: i. het voorzien van een verzoekverwerker voor het ontvangen van een verzoek dat overeenstemt met een gebeurtenis die geassocieerd is met een aantal verwerkingstappen dat door het systeem uitgevoerd moeten worden; ii. het voorzien van een eerste netwerkcache voor het opslaan van identificatiegegevens betreffende gebeurtenissen die in een knoop dienen uitgevoerd te worden; iii. het voorzien van een tweede, to-handle cache voor het opslaan van gegevens die geassocieerd zijn met de geplande gebeurtenissen; iv. het voorzien van ten minste een eerste knoop, elk een processor omvattende om een verzoek te ontvangen vanuit de verzoekverwerker, en het identificeren van een gebeurtenis die verwerkt dient te worden op basis van het verzoek; en bij voorkeur het voorzien van een tweede knoop die bedoeld is om een inactieve back-up versie te omvatten van de gegevens betreffende gebeurtenissen die verwerkt dienen te worden in de primaire knoop, v. het voorzien van verwerkingsinterceptorlogica om de verwerkingstappen te starten bij het opslaan van identificatiegegevens betreffende een gebeurtenis in de tweede cache; en vi. het voorzien van een reactieve stroom om de transacties die geassocieerd zijn met de gebeurtenisentiteit toe te kennen en af te werken, en vii. het voorzien van gebeurtenissen-transferlogica voor het overbrengen van de identieke gegevens betreffende een gebeurtenis vanuit de eerste cache naar een entiteitsarchiefcache bij het afronden van de verwerkingstappen die geassocieerd zijn met de gebeurtenis; en viii. het voorzien van een controlelogica en van een entiteitspecifieke logica voor het uitvoeren van een roll-back van welke transacties dan ook waarvoor er geen overeenstemmende ingang is terug te vinden in de to-handle cache voorafgaand aan de toekenning.
23. 23. Werkwijze volgens conclusie 22, bovendien omvattende: a. het opslaan van identificatiegegevens betreffende een te verwerken gebeurtenis in ten minste een eerste knoop in de eerste cache, en het opslaan van gegevens in de knoop waarvan wordt vastgesteld dat hij de knoop is waarin de primaire kopie van de gebeurtenis aanwezig is in de tweede cache, en het aansturen van de gebeurtenisverwerkende module waarin de ten minste ene eerste knoop aanwezig is, teneinde een verzoekverwerker te activeren om een verzoek te ontvangen dat overeenstemt met een gebeurtenis die geassocieerd is met een aantal verwerkingstappen dat door het systeem dient uitgevoerd te worden; en b. het kopiëren van de entiteitsreferentie naar de reactieve stroom door een verwerkingsinterceptorlogica (“notifier”); en c. het verzenden van de entiteitsreferentie naar de reactieve stroommodule voor het toekennen van transacties, en, bij het afronden van de gebeurtenistransacties, het overbrengen van de gegevens van de eerste en/of tweede cache naar een entiteitsarchiefcache, en het uitvoeren van een roll-back van welke transacties dan ook voor gebeurtenissen die niet langer aanwezig zijn in de eerste cache, zodat een gebeurtenisentiteit slechts een enkele keer wordt uitgevoerd.
24. 24. Werkwijze volgens conclusie 23, waarbij stap (a) het wegschrijven omvat van de wijzigingen in de statusgegevens naar de eerste en/of tweede cache, en waarbij een knoop wordt bepaald als zijnde een primaire knoop voor het uitvoeren van een gebeurtenis, en waarbij ten minste een tweede knoop wordt bepaald als zijnde een secundaire knoop die niet actief is om dezelfde gebeurtenis uit te voeren, en waarbij de eerste en tweede caches overeenstemmend worden geactualiseerd.
25. 25. Werkwijze volgens een der conclusies 21 tot en met 24, waarbij, indien de primaire knoop niet actief is of is gedeactiveerd alvorens een transactie uit te voeren, de netwerklogica een secundaire knoop bevordert tot primaire status, geconfigureerd om de gebeurtenis uit te voeren in de vorm van een primaire knoop.
26. 26. Door een machine uitvoerbare instructies die, wanneer ze worden uitgevoerd door ten minste één processor, ervoor zorgen dat de ten minste ene processor de werkwijze volgens een der conclusies 21 tot en met 25 uitvoert.
27. 27. Niet-transitoir, door een machine leesbaar medium, door een machine uitvoerbare instructies volgens conclusie 26 omvattende.
28. 28. Door een machine leesbare opslag waarin door een machine uitvoerbare instructies volgens conclusie 26 zijn opgeslagen.
29. 29. Gebruik van een systeem volgens eender conclusies 1 tot en met ,om een onmiddellijke uitvoering van een gebeurtenis te verzekeren, zelfs indien er zich een gedeeltelijke systeemfout voordoet, terwijl een eenmalige uitvoering van een gebeurtenis toch wordt verzekerd.