Toepassen van de SOA verworvenheden met bestaande middelen

SOA is hot! Het aantal evenementen, nieuwsberichten, cursussen en bedrijven dat oplossingen hierover aanbiedt lijkt wel met de maand te groeien. En het lijkt niet de zoveelste hype te zijn. “SOA is here to stay” lazen we al in een vorig nummer van dit magazine. Maar wat moet je er mee als traditionele Oracle ontwikkelaar of als IT manager van een afdeling met een aantal klassieke Oracle applicaties in beheer? Mis je de boot als je niet snel de nieuwe SOA verworvenheden en technieken gaat toepassen? Misschien is dat in sommige gevallen zo, maar aan de andere kant wil je ook niet overhaast meedoen met deze nieuwe trend met alle risico’s van dien. Dit artikel beschrijft een middenweg hierin, namelijk het toepassen van de SOA verworvenheden met bestaande middelen.

In december 2005 kreeg de ITafdeling van het CAK-BZ te horen dat er binnen een jaar tijd een volledig nieuwe applicatie ontwikkeld moest worden om een extra wettelijke taak te ondersteunen. De overheid had besloten dat de administratie en facturatie van het AWBZ onderdeel ZmV (Zorg met Verblijf) gecentraliseerd moest worden. Concreet betekende dit dat het CAK-BZ per 01 april 2007 in mandaat verantwoordelijk werd voor de correcte afhandeling van de eigen bijdrage die iedere Nederlander moet betalen voor een verblijf in een AWBZ-instelling (een verpleegtehuis, psychiatrische instelling, etc.).

De uitvoering van een overheidstaak is vaak aan verandering onderhevig, dus flexibiliteit was zeker een ontwerpeis voor de nieuwe applicatie. Tevens moest in de architectuur rekening gehouden worden met het feit dat er gemakkelijk nieuwe modules af of bij zouden moeten kunnen. Allemaal argumenten om te kiezen voor een SOA aanpak waarbij ‘services’ worden ontwikkeld die geen onderlinge afhankelijkheid hebben en daardoor voor optimale flexibiliteit zorgen. Na onderzoek werd echter besloten om de applicatie te bouwen met de bestaande ontwikkelstraat: Designer/Developer 10g en een Oracle Database 9i.Dit werd gedaan om de volgende redenen :
• De tools die horen bij een SOA aanpak zijn redelijk nieuw en zorgen daarmee voor een extra risico qua bugs, onvolkomenheden, etc.
• Het ontwikkelteam zou in zeer korte tijd moeten worden omgeschoold naar de nieuwe technologie en denkwijze. Je wilt graag leren als IT-afdeling, maar niet door de beginnersfouten die je hebt gemaakt bij de bouw van een cruciale applicatie.
• De deadline was spijkerhard. Risico’s waren er al genoeg, dus je probeert alles te vermijden wat het slagen in gevaar kan brengen.

Dan maar de applicatie bouwen op de traditionele manier: een groot geheel met gedecomponeerde functies die onderling naar elkaar verwijzen en direct door middel van code zijn geïntegreerd? Nee, het bleek namelijk mogelijk om ook in een bestaande omgeving met bewezen technologie een aantal ontwerpprincipes toe te passen uit het SOA gedachtegoed.

Om deze doelstellingen te bereiken zijn binnen dit project twee van die principes toegepast :
1. Het ontwikkelen in gegevensdomeinen
2. Het toepassen van een message broker c.q. message bus.
Hieronder eerst een uitleg van de theorie van deze principes en daarna wordt de architectuur geschetst zoals het CAK-BZ deze met behulp van de traditionele middelen heeft toegepast.

Ontwikkelen in gegevensdomeinen

In een applicatie zijn altijd gebieden aan te wijzen die een grote onderlinge samenhang hebben en die vanuit de business gezien ook echt bij elkaar horen. In dit voorbeeld zijn dat de gebieden: relaties, zorggegevens en inkomensgegevens. Wanneer we deze gebieden qua logica van elkaar gaan scheiden zal het aantal onderlinge afhankelijkheden tussen alle objecten drastisch verminderen. En dat is goed nieuws voor ons onderhoud en de gewenste fl exibiliteit voor komende veranderingen!

Maar hoe is het nu nog mogelijk dat module A zijn benodigde informatie over de zorg en de klantinformatie krijgt ?

Dit gebeurt door de introductie van een zogenaamde ESB (Enterprise Service Bus), een aparte communicatielaag, zie ook afbeelding 2. Alles wat module A nodig heeft aan informatie over relaties en zorg wordt eerst gevraagd aan de ESB, die deze informatie ophaalt in het betreffende gegevensdomein. Op die manier wordt voorkomen dat de structuur van de datalaag en de logicalaag van de relaties overal gebruikt wordt in de andere delen van het systeem. Als we een wijziging krijgen binnen relaties, dan zal dat minder impact hebben binnen het gedeelte inkomens omdat dat minder ‘weet’ over hoe de structuur is van relaties.

Even de voordelen van deze aanpak op een rijtje :
• Het ontstaan van minder onderlinge afhankelijkheden. (zie het voorafgaande)
• Het wordt gemakkelijker om te werken in ontwikkelteams die parallel van elkaar een gegevensdomein realiseren.
• De ontwikkelde code blijft waar het hoort. Code over relaties blijft in het gegevensdomein relaties, waardoor het geheel overzichtelijker is.
• Het maakt het gemakkelijker om een ontwikkelde deelapplicatie in te ruilen voor een standaardpakket of een andere applicatie, mocht dat nodig zijn.
• Doordat de gegevensdomeinen redelijk autonoom zijn is het mogelijk om de informatie zo te scheiden of te versleutelen dat het niet via een zoekvraag mogelijk is om te bepalen welk inkomen een relatie heeft.

Een nadeel van deze aanpak is dat het realiseren van modules ingewikkelder is geworden. Het scherm met klantinformatie in het voorbeeld zal niet rechtstreeks inkomens- en zorggegevens kunnen laten zien, maar moet al deze aanvragen uitzetten via de ESB. Tevens moet een ESB worden opgezet en onderhouden.

Message broker

Deze message broker moet gebeurtenissen binnen een domein opvangen en doorgeven aan andere domeinen die belang bij deze gebeurtenis hebben waarbij de volgende eisen van belang zijn:
- De message broker moet zorgen voor een zo beperkt mogelijke afhankelijkheid tussen de autonome domeinen, zowel functioneel als technisch.
- De verzender van een bericht hoeft niets te weten van de ontvanger en omgekeerd.
- Het moet eenvoudig zijn nieuwe afnemers van een gebeurtenis toe te voegen.
- Het moet eenvoudig zijn nieuwe gebeurtenissen toe te voegen.

De voordelen van deze aanpak zijn :
• De afhankelijkheid tussen modules wordt nog verder gereduceerd (de verzender en ontvanger ‘weten’ niets van elkaar).
• Een proces hoeft alleen te verwerken wat er aan berichten klaarstaat en hoeft geen zware query meer uit te voeren om veranderingen op te merken.
• De berichten (gebeurtenissen) geven inzicht in hoe het bedrijfsproces loopt en waar eventueel stagnaties zijn.

Toepassing bij het CAK-BZ

De front-end is ontwikkeld met Developer Forms en Headstart. Hierbij is het standaard concept van het business rule framework CDM RuleFrame toegepast. Kortweg betekent dit dat er zo min mogelijk logica opgenomen is in de schermen. De communicatie naar de database verloopt via een zogenaamde View API. Een dergelijke view stelt gegevens beschikbaar aan een scherm, mutaties in gegevens worden ook via deze view doorgegeven aan de database. Via het business rule framework worden de business rules gevalideerd voordat de gegevens daadwerkelijk worden opgeslagen.

Voor de services is binnen het CAKBZ onderscheid gemaakt in de volgende type services:
• Realtime service
Dit type service moet direct worden uitgevoerd op het moment dat deze wordt aangevraagd
• Batch service
Een batch service wordt periodiek uitgevoerd, bijvoorbeeld elke ochtend om 6.00 uur. Alle aanvragen voor deze service worden dan als batch proces uitgevoerd.

Een realtime service is geschikt voor zowel het opvragen van gegevens uit een ander domein als het in gang zetten van een actie in een ander domein. Bijvoorbeeld het ophalen van adresgegevens uit het relatie domein. Dit type service wordt geïmplementeerd via een package functie, een package procedure of een view. Het domein dat de service levert stelt het betreffende service object beschikbaar aan de overige domeinen. Een domein dat de service wil gebruiken kan deze vanuit de code aanroepen. Alles wat voor een ander gegevensdomein nodig is moet via deze services afgehandeld worden. Op deze manier is de onderlinge afhankelijkheid tussen gebieden precies aan te wijzen en in de hand te houden.

Bij een batch service worden alle aanvragen voor de betreffende service verzameld. Periodiek worden deze aanvragen in een batch proces afgehandeld. Om batch services te ondersteunen is een message broker (berichtenmanager BMR) ontwikkeld die op generieke wijze voor de afhandeling van de services zorgt. Deze berichtenmanager is volledig met pl/sql ontwikkeld binnen een Oracle Database.

De berichtenmanager

Het domein waarbinnen een gebeurtenis plaatsvindt, geeft een signaal, inclusief relevante gegevens, aan de berichtenmanager dat de betreffende gebeurtenis heeft plaatsgevonden. De berichtenmanager zorgt er vervolgens voor dat voor elke applicatie die zich geabonneerd heeft op de gebeurtenis (afnemers) een bericht wordt klaargezet. Dit bericht wordt vervolgens opgehaald door de afnemer. Wanneer het bericht correct door de afnemer is ontvangen geeft deze dit door aan de berichtenmanager er wordt de status van het bericht op afgehandeld gezet.

De ontwikkelde berichtenmanager bestaat uit de volgende onderdelen:
• Event library
Binnen de event library worden alle gebeurtenissen (events) die zich binnen de verschillende domeinen voor kunnen doen geregistreerd.
• De abonnementen administratie
Hierin worden alle afnemers van berichten geadministreerd. Concreet zijn dit de procedures uit de domeinen die het bericht verwerken. Hierbij worden ook de gegevens (parameters) gedefinieerd die door de afnemer worden verwacht om het bericht te kunnen verwerken.
• Event-handler
Dit onderdeel betreft het eerder beschreven proces van het ontvangen van een event en het klaar zetten van berichten voor de afnemers

Alle events die zich voor kunnen doen worden vastgelegd als Event. De procedures van de afnemende domeinen zijn vastgelegd als Domein service. Met behulp van Abonnement wordt vastgelegd welke Domein service geïnteresseerd is in welk Event. Op het moment dat een event zich voordoet ontstaat een Event bericht met alle relevante informatie over het event. Op basis van de Abonnementen worden vervolgens Domein service berichten aangemaakt. Deze berichten kunnen vervolgens worden opgepakt door de afnemende Domein service.

Voor het aanbieden van een event door de aanbieder en voor het ophalen van de berichten door de afnemer worden door de berichtenmanager standaard API’s beschikbaar gesteld. Hierdoor kunnen nieuwe events en/ of domein services eenvoudig worden toegevoegd zonder dat code van de berichtenmanager aangepast hoeft te worden. Het enige wat een aanbieder hoeft te doen is een aanroep van de API in de code op te nemen en de juiste gegevens hiermee door te geven. Hetzelfde geld voor de afnemer die in de code de aanroep naar de API voor het ophalen van de berichten hoeft op te nemen.

Het aanbieden van events gebeurt ook op een standaard wijze. Binnen CDM RuleFrame worden onder andere zogenaamde change-eventrules onderkend. Dit type business rule wordt gebruikt om de aanroep p naar de standaard API van de berichtenmanager in op te nemen. Op deze manier is het relatief eenvoudig te herleiden waar events ontstaan. Iets wat op dit moment nog niet wordt toegepast, maar waar de berichtenmanager zeker mogelijkheden voor biedt, is BAM (Business Activity Monitoring). Alle gegevens met betrekking tot de opgetreden events worden vastgelegd in de database. Het moet dus relatief eenvoudig zijn hierop rapportages of signaleringen te definiëren, om op die manier het primaire bedrijfsproces te monitoren.

SOA of niet?

De berichtenmanager zorgt voor een ontkoppeling van de verschillende domeinen. Door deze ontkoppeling moet het relatief eenvoudig zijn nieuwe onderdelen toe te voegen of onderdelen te vervangen. Bijvoorbeeld een extra domein “zorg” (waarvan de structuur en data dusdanig afwijken dat dit een apart domein rechtvaardigt). Hierbij kan voor de gegevens van deze nieuwe groep klanten gebruik worden gemaakt van de domeinen “Relatie” en “Inkomens”. Door het gebruik van gebeurtenissen en het reageren van andere domeinen op de gebeurtenissen is er een duidelijkere focus gekomen op het proces. Door gebeurtenissen en reacties elkaar te laten opvolgen ontstaat het proces.

Wat er feitelijk met het toepassen van de berichtenmanager is neergezet is een Event Driven Architectuur (EDA)

Er zijn natuurlijk genoeg beperkingen te bedenken bij de wijze waarop de berichtenmanager hier is geïmplementeerd.
• Er wordt geen gebruik gemaakt van echte services via de standaard SOAP messages, maar via een pl/sql API worden berichten uitgewisseld. Feitelijk betekent dit dat je alleen applicaties die ontwikkeld zijn op een Oracle database met elkaar kunt laten communiceren.
• Doordat geen gebruik gemaakt wordt van SOAP messages is het ook niet eenvoudig ketenintegratie te realiseren.

Evaluatie

Conclusie