De overgang naar een SOA

Uw IT-architectuur voldoet aan de noden van vandaag. Maar wat met de toekomst? Gaan we allemaal service oriented architecture moeten implementeren? En hoe moet dat dan? We vroegen het aan iemand die er nu volop mee bezig is.

Vroeger was het leven simpel. Er was de relationele database en de toepassing. De gebruiker gaf input, de toepassing schreef gegevens in de database. Vandaag werken vele bedrijven met een n-tier architecture: de user interface, de business logic en de data storage bevinden zich in verschillende lagen. Wilt u overstappen naar een service oriented architecture, dan stelt u zich een boel vragen, moet u vele beslissingen nemen. We namen een kijkje bij een project dat de overgang naar een SOA voorbereidt.

DE OMGEVING
Het RSVZ, het Rijksinstituut voor de Sociale Verzekeringen der Zelfstandigen (//www.rsvz-inasti.fgov.be) zorgt voor het sociaal statuut van de zelfstandigen. Bovendien beschikt het RSVZ over een eigen sociaal verzekeringsfonds, de Nationale Hulpkas, dat zoals de andere fondsen instaat voor de toepassing van de sociale wetgeving.

Deze overheidsdienst beschikt over een eigen IT-afdeling, maar voor twee belangrijke toepassingen, de berekening van de pensioenen en het innen van de sociale bijdragen van bedrijven, wordt een beroep gedaan op Computer Sciences Corporation. De twee toepassingen draaien vandaag op een n-tier architecture, de architectuur Windows DNA, die Microsoft vroeger aanprees.

DE USER INTERFACE LAYER
Voor de berekening van de pensioenen en het innen van de sociale bijdragen van bedrijven werkt men met een ‘web interface’: de gebruikers werken via het intranet, met hun browser. Yves Van Dooren, consultant bij de fi rma SCS en software architect voor dit project: ‘De toepassing staat volledig op de server; de pc is een ‘thin client’. Bij de ingebruikname van een nieuwe versie moet de nieuwe software dus maar op één plaats geïnstalleerd worden; dat is gemakkelijk en veilig. We vermijden zo ook problemen van incompatibiliteit tussen de clientomgeving en serveromgeving.

Deze werkwijze heeft echter ook nadelen: op de client is slechts een beperkte verwerking van gegevens mogelijk (in de browser, in Javascript). Bovendien is debuggen niet gemakkelijk, en het gaat trager dan op een smart client. In de nieuwe architectuur gaan we het anders aanpakken.’

DE DATA STORAGE LAYER
De data storage layer bevat de database, met het bijbehorende database management system. Met een relationele database hebt u de mogelijkheid om gegevens te verwerken met behulp van triggers en stored procedures. Aan u de keuze: maakt uw toepassing gebruik van die mogelijkheid om gegevens te verwerken in de data storage layer, of niet?

Als u een pakkettoepassing ontwikkelt die op meer dan één Relational Data Base Management System moet draaien, dan maakt u natuurlijk géén gebruik van de mogelijkheid om gegevens te verwerken.

‘Als men die mogelijkheid wel gebruikt, dan verplaatst men eigenlijk een deel van de verwerking van de business logic logic layer naar de data storage layer, en heeft men minder verkeer tussen die twee lagen,’ verteld Van Dooren, ‘Dat kan nuttig zijn als de database zich op een ander systeem bevindt dan de application server, en de uitwisseling van de gegevens tussen de twee lagen via een connectie verloopt.

Zo’n situatie geeft problemen van performance en complexiteit, die men op deze manier kan verminderen. Voor onze twee toepassingen maken we gebruik van deze mogelijkheid; maar hier draaien ook toepassingen die dat niet doen.’

DE COMMUNICATIE TUSSEN DE LAGEN
Het project werkt met drie lagen: de user interface layer, de business logic layer en de data storage layer. ‘We hebben nog twee extra lagen nodig om de communicatie te verzorgen’, zegt Van Dooren, ‘de presentation layer verzorgt de communicatie tussen user interface layer en business logic layer, en de data access layer verzorgt de communicatie tussen business logic layer en data storage layer. De boodschappen zijn geschreven in XML.’

DE TOEKOMSTIGE SITUATIE: SERVICE-ORIENTED ARCHITECTURE
Het RSVZ gebruikt nog vele andere toepassingen, naast de toepassingen voor de berekening van de pensioenen en het innen van de sociale bijdragen van bedrijven. Binnenkort moeten die twee toepassingen op een flexibele manier kunnen samenwerken met andere toepassingen. Daarom hebben RSVZ en CSC gekozen voor een SOA.

Dat heeft een aantal voor- en nadelen, volgens Van Dooren: ‘Eén van de voordelen is dat deze aanpak gebruikt kan worden in een heterogene omgeving. Een ander voordeel is dat het ‘client team’ en het ‘server team’ onafhankelijk van elkaar kunnen werken. De toepassing is ook makkelijk te testen. Deze aanpak dwingt je tot een goede (voorafgaande) analyse van de bedrijfsprocessen. Deze manier van werken vergemakkelijkt het onderhoud van de toepassing en de verdere evolutie. En de geschreven services kunnen ook gebruikt worden door andere clienttoepassingen.

‘Maar aan deze aanpak zijn ook nadelen verbonden,’ gaat hij verder, ‘Een toepassing in een SOA is trager bij de uitvoering, ze presteert minder goed. Bij de creatie van de toepassing moet je rekening houden met een langere ontwikkeltijd. En je moet dezelfde gegevens op verschillende plaatsen definiëren.’

INTERFACE
Het RSVZ werkt met Microsoft .Net voor de nieuwe toepassing. ‘De toepassing op de client en de toepassing op de server zijn volledig van elkaar gescheiden. De toepassing op de server bestaat uit services, die aangeroepen worden door middel van messages. (zie afbeelding 2) Elke service heeft een ‘service contract’, dat bepaalt welke input (actie en gegevens) de service verwacht, en welke output (gegevens) de service aflevert. Hiervoor gebruiken we SOAP (Simple Object Access Protocol) en XML web-services.’

In de nieuwe architectuur gaat men de user interface bouwen met Winforms. Doordat in het Ms .Net framework 2.0 de deployment van een toepassing gemakkelijker is dan vroeger, wordt dit mogelijk. Men zal dus gegevens kunnen verwerken op de PC; de PC wordt een ‘smart client’.

HET FRAMEWORK
Yves Van Dooren: ‘We gaan werken met het Microsoft .Net framework, dat we zelf uitbreiden. We spreken een werkwijze af, kiezen voor bepaalde concepten en bouwen software modules die straks door de toepassing opgeroepen worden.’

Een goed framework biedt een heleboel diensten aan de ontwikkelaar, volgens Van Dooren. Het laat de ontwikkelaars toe om object-georiënteerd te werken, met uitbreiding en herdefinitie van de basisverwerking. Het implementeert de gekozen architectuur. Het zorgt voor eenvoudiger programma’s. De ontwikkelaar wint tijd. Het is schaalbaar; het houdt rekening met een mogelijke uitbreiding in de toekomst. Het zorgt voor een optimale performance.

‘Het biedt een heleboel interessante mogelijkheden, zoals n-level undo (edit – cancel – apply), beheer van validatieregels, beheer van autorisatieregels, beheer van data binding (een object in de database komt overeen met een object op het scherm), integratie met het systeem van distributed transactions (transacties die meerdere databases bijwerken), beheer van de vertalingen, beheer van de codelijsten, tracing en diagnose,’ voegt hij eraan toe.

Wanneer wordt het framework ontworpen en gebouwd? Wat is de juiste volgorde? Volgens Van Dooren begint alles bij een goede analyse: ‘Eerst maakt een analist de functionele analyse op hoog niveau; we willen zicht krijgen op de gewenste gegevensverwerking. Dan wordt de technische analyse gemaakt, in grote lijnen, en de architectuur gedefiniëerd. En dan komen wij aan de beurt, dan wordt het framework opgesteld. Daarna kan de functionele analyse verder uitgewerkt worden, dan de technische analyse, en dan kan de toepassing ontwikkeld worden.’