Artikelen & Publicaties

Gepubliceerd op september 2011, TestNet, Wilbert de Wolf

De cloud is onderverdeeld in drie lagen, namelijk IaaS, PaaS en SaaS (Infrastructure-, Platform-, en Software-as-a-Service) waarvan de laatste de meest bekend is. Het gaat hierbij om software die buiten de organisatiegrenzen wordt gehost bij een externe leverancier. In het cloud-paradigma wordt die externe leverancier aangeduid als de cloudprovider. Indien die cloudprovider ook nog platformvoorzieningen ter beschikking stelt om applicaties te ontwikkelen, dan spreken we van PaaS. Beperkt de behoefte zich tot het afnemen van netwerkdiensten en storage bij een provider dan spreken we van IaaS.

Centraal gegeven is de term dientverlening. In plaats van dat een organisatie zelf investeringen pleegt en zo eigenaar wordt van ICT-voorzieningen consumeert het diensten uit de cloud. En waarom dan ook niet de benodigde testfaciliteiten, ofwel STaaS, Software-Test-as-a-Service.

In dit artikel wordt ingegaan op de providerkant van STaaS. Verbeeld jezelf dat je werkzaam bent als provider van testvoorzieningen. Cloudconsumenten stellen cloud-applicaties aan jou ter beschikking met de vraag die door te testen.

Om te kunnen beoordelen wat dit voor jou als tester betekent is het van belang te kijken in hoeverre cloud-applicaties verschillen van conventionele applicaties zoals we die uit het verleden kennen. Het merendeel van de cloud-applicaties die worden ontwikkeld zijn ontsloten middels webtechnologie. Dat komt omdat webtechnologie het mogelijk maakt om op een relatief eenvoudige wijze autonome systemen met elkaar te koppelen. Voor testers biedt dit nieuwe uitdagingen. Immers applicatiesystemen worden niet meer begrensd door bedrijfsmuren, maar steeds vaker worden applicatiesystemen samengesteld uit onderdelen die bij externe bedrijven zijn ondergebracht. Het kan zelfs zo zijn dat je niet eens weet waar systeemonderdelen zich precies bevinden. Die externe systeemonderdelen worden als services geconsumeerd binnen het grotere geheel. Zie daar nog maar eens een sluitende test voor te bedenken.

En toch zijn er mogelijkheden om hier als tester goed mee om te gaan.

In de basis is het van belang om naast de cloud-applicaties ook de cloud-architectuur onder de loep te nemen. Eigenlijk moet je als STaaS-provider verder kijken dan de cloud-systemen zelf. Daarbij rijzen vragen zoals:

• Welke kwaliteitseisen zijn van belang voor de opdrachtgever? Stuurt een opdrachtgever voor een hoge beschikbaarheid of juist hoge een betrouwbaarheid? Kennis over kwaliteitseisen helpen je de juiste testmaatregelen toe te passen.
• Hoe is het te testen cloudsysteem opgebouwd? Wat is de decompositie? Kennis van toegepaste integratie-patterns binnen de cloud helpen je om de structuur van het cloudsysteem te begrijpen en de juiste testmaatregelen toe te passen.

Door gevoel te krijgen voor deze vragen wordt het mogelijk om een oordeel te vormen over de kwaliteit en conditie van de gehele cloud-architectuur.

Cloud-architectuur

Een goede cloud-architectuur is rekbaar en kan met gemak allerlei klappen opvangen. Bovendien is een dergelijke architectuur transparant. Dus mocht er iets aan mankeren dan zou het niet moeilijk moeten zijn om de vinger op de zere plek te leggen. Maar voor zo’n architectuur er is moet er wel wat gebeuren. Een cloudarchitectuur is opgebouwd rondom services die enorm veel berichtenverkeer genereert tussen serviceproviders en serviceconsumenten. Er daarbij kan van alles mis gaan. Niet alleen technisch maar ook organisatorisch. Dat komt omdat zoals eerder gesteld cloudsystemen niet meer terug te herleiden zijn naar één autonome eigenaar maar bestaan uit verschillende systeemonderdelen in een keten met elk hun eigenaar. Als tester kun je het beste een cloudservice in de cloudketen testen indien je de grillen van aangrenzende systeemonderdelen maar goed in de vingers hebt.

Welke kwaliteitseisen zijn van belang voor de cloudservice?

Als eerste kan de tester zich bij cloud-gerelateerde opdrachten het beste eerst concenteren op kwaliteitseisen. Bij het bespreken van kwaliteit draait voornamelijk om het expliciet maken van de meest belangrijke kwaliteitsattributen. Een sluitend overzicht van kwaliteitsattributen binnen de ICT-wereld zijn beschikbaar binnen de kwaliteitsstandaard ISO9126 [Quint2].

[Afbeelding 1] Kwaliteitseisen die van toepassing zijn voor Cloud-architectuur

Er zijn enorm veel kwaliteitsattributen waar tegen je de cloud-architectuur kunt testen. De meest relevante attributen volgens [TMAP] zijn:

[Tabel1:] Strategie testen onder architectuur in de cloud

De werkwijze voor het testen onder architectuur in de cloud is als volgt:

Middels inzicht in een uitgewerkte Randvoorwaarde kan de genoemde Testmethode gericht worden toegepast om een Kwaliteitsattribuut te kunnen testen. Dus om bijvoorbeeld Reliability te beoordelen kan inzicht in de gebruikte Enterprise Integration Patterns [EIP] de basis leggen om de juiste “Negative Testing” Testmethode op te stellen.
 

Afgezien van het testen van Security en Availability blijken Enterprise Integration Patterns een goed startpunt te zijn om de kwaliteit van de onderliggende architectuur te beproeven. Dit artikel beperkt zich tot de toepassing van Enterprise Integration Patterns in relatie tot de gestelde kwaliteitsattributen. Alle genoemde TMapNEXT®-testmethodieken staan uitgebreid beschreven in [TMAP].

Welke Enterprise Integration Patterns zijn van belang voor de cloudservice?

Het testproces is nauw verweven met alle andere activiteiten in het ontwikkelproces van systemen. Onderstaande afbeelding, het zogenaamde V-model, toont een grafische weergave van verschillende stadia in het software ontwikkelproces.

[Afbeelding 2] De testbase (linkerkant V-model) wordt uitgebreid met EIP

De positie van Enterprise Integration Patterns vormt een belangrijke uitbreiding van de testbase voor het testen van cloudsystemen. Het is dus belangrijk voor testers om in een zo vroeg mogelijk stadium de toegepaste architectuurpatronen eigen te maken voor de specifieke cloud-oplossing. Hoe dat precies in zijn werk gaat wordt in onderstaand voorbeeld beschreven.

Puttin’ it all together

Als voorbeeld nemen we een Document Management Systeem (DMS) welke beschikbaar wordt gesteld als een cloudservice. Maar wat is een DMS? Veel organisaties nemen tegenwoordig afscheid van werkprocessen waar het papier rijkelijk vloeit en stappen over op geautomatiseerde werkprocessen onder het mom van digitalisering. Naast argumenten zoals het invoeren van Lean Business Principes [LEAN] is het milieu-aspekt vaak leidend. Digitalisering leidt immers tot minder papierverbruik.

Centraal binnen digitalisering is het plaatsen van een DMS waar digitale werkprocessen documenten in kunnen opslaan en doorzoeken. Er zijn ook legio cloudpartijen die momenteel DMS-diensten aanbieden. Achterliggende reden is dat het verschaffen en beheren van een corporate DMS steeds minder rendabel wordt. Immers naast voldoende storage worden ook hoge eisen gesteld aan het beschikbaar kunnen stellen van veel verschillende documentsoorten. Vroeger kon men volstaan met office-documenten echter tegenwoordig wordt ook rich-media niet geschuwd zoals geluidsfragmenten en video.

Uitwerking EIP voor de testbase van de DMS - cloudservices

Het dataverkeer tussen cloudconsumer en cloudprovider draait dus om het versturen en ontvangen van berichten.Tussen vertrek en ontvangst kan met een bericht veel gebeuren. Het is interessant om de vinger te krijgen achter dit proces omdat er hier legio zaken zijn die de tester kan beproeven. In ons voorbeeld voert de tester een aantal gesprekken met domeindeskundigen en daaruit voortvloeiend wil hij voor de testbase onder andere de volgende onderstaande twee scenario’s beproeven:

Scenario 1: Voordat een document wordt verstuurd naar de DMS-cloudservice provider wordt het document bij de cloudservice consument verpakt in een bericht en ondergaat het een aantal transformaties. Daaruit destilleert de cloudtester vervolgens de volgende decompositie middels EIP:

[Afbeelding 3] EIP Scenario 1 voor de testbase

Scenario 2: Het is voor de DMS-cloudservice consument mogelijk om een veelvoud aan verschillende documentsoorten te verpakken in een bericht en vervolgens te verzenden naar de DMS-cloudservice provider. De cloudtester heeft hieruit middels EIP de volgende decompositie kunnen herleiden:

Aan de hand van de kwaliteitsattributen uit tabel 1 wordt door de cloudtester op een gestructureerde manier een decompositie gemaakt van mogelijke EIP-patterns waardoor bovenbeschreven twee testscenario’s beproefd (assessment) kunnen worden. Eigenlijk draait het bij zo’n decompositie om het identificeren van de juiste EIP-patterns uit [EIP] waarmee de kwaliteitsattribuut wordt uitgetest (assessed). De geïdentificeerde EIP-patterns en bijbehorende assessments worden onderdeel van de testbase.
 

Pattern identificatie voor Adaptibility

Pattern: Datatype Channel 
Assessment: De benodigde processtappen voordat het bericht wordt verzonden leiden tot mogelijk fouten op de respectievelijke koppelvlakken.

Pattern: Content Enricher 
Assessment: Er is mogelijk een probleem met het verrijken van de berichten. Denk hierbij dat bijvoorbeeld een bericht verrijkt wordt met een document.

Pattern identificatie voor Availability

Pattern: Dead Letter Channel 
Assessment: Er is mogelijk een probleem waarbij berichten kwijtraken.

Pattern: Aggregator 
Assessment: Er is mogelijk een probleem waarbij berichten niet worden opgespaard indien de connectiviteit naar de DMS-cloudpartij wegvalt. Dergelijke berichten zouden opgespaard moeten worden.

Pattern identificatie voor Scalability

Naast FOLB kan ook hier de Aggregator assessment helpen. Immers bij een hoge load zal er opgespaard moeten worden (file-vorming). Het systeem dient hier goed mee om te gaan.

Pattern identificatie voor Reliability

Pattern: Claim Check 
Assessment: Wordt tijdens het verpakken en versleutelen de integriteit van de verpakte informatie geschonden?

Pattern: Content Based Router 
Assessment: Worden de verschillende type documenten uit scenario 2 op een verschillende manier opgepakt en verwerkt?

Conclusie

Cloudsystemen zijn gedistribueerd over bedrijfsgrenzen heen. Daardoor wordt het van belang extra testaandacht te besteden aan het koppelvlak tussen de cloudservice consumer en cloudservice provider. Het uitvoeren van een decompositie van dergelijke cloudsystemen middels Enterprise Integration Patterns helpt om de testbase te voorzien van assessments voor het beproeven van cloudspecifieke kwaliteitsattributen binnen een TMapNEXT® testsystematiek.

ir. Wilbert de Wolf
Principal Consultant
CIMSOLUTIONS
w.de.wolf@cimsolutions.nl

Bijlage I Verklaring der toegepaste Enterprise Integration Patterns
 

	Aggregator Werking: Afzonderlijke berichten worden geaggregeerd tot één berichtenpackage. Belang: Hoe zijn de afzonderlijke berichten zodanig te combineren. Dat ze geaggregeerd verwerkt kunnen worden als één geheel?
	Claim Check Werking: De inhoud van het bericht wordt verpakt en versleuteld. Belang: Hoe kan het verpakte bericht verstuurd
	Command Message Werking: Communicatie tussen systemen middels berichtenverkeer. Belang: Hoe kan berichtenverkeer worden ingezet om meerdere systemen logisch één gezamenlijke functie te laten uitvoeren?
	Competing Consumers Werking: Het gelijktijdig verwerken van meerdere berichten. Belang: Kan de cloudservice provider/consumer meerdere berichten gelijktijdig verwerken?
	Content-Based Router: Werking: Een logische functie is geïmplementeerd over meerdere externe systeemonderdelen. Belang: Wordt een cloudbericht waarvan de content verschilt wel even snel verwerkt? Het kan voorkomen dat afhankelijk van de inhoud van het cloudbericht verschillende systemen de respectievelijke inhoud verwerken.
	Content Enricher Werking: Het oorspronkelijke cloudbericht wordt onderweg verrijkt. Belang: Hoe geschiedt het verrijkingsproces en welke maatregelen bestaan indien dit proces niet goed functioneert?
	Datatype Channel Werking: De cloudservice provider weet precies hoe het berichten van de cloudservice consumer moet verwerken. Belang: Weet het ontvangende systeem precies hoe het berichten met verschillende content moet verwerken?
	Dead Letter Channel Werking: Borgen van cloudberichten die niet goed kunnen worden verwerkt door de cloudservice provider of consumer. Belang: Wat doet het cloudsysteem met cloudberichten die niet verwerkt kunnen worden?
	Document Message Werking: Een cloudbericht bevat een document attachment. Belang: Is het transparant wat de begrenzingen voor het document attachment mag zijn en hoe is dit geborgd binnen he cloudsysteem? Denk bijvoorbeeld aan grootte en hoeveelheid documenten binnen een cloudbericht.
	Pipes and Filters Werking: Cloudberichten ondergaan een complex proces. Belang: Hoe wordt kwaliteit van de cloudservice geborgd door het toepassen van complexe processen op cloudberichten?

Bijlage II Referenties

• [EIP] Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions Gregor Hohpe, Bobby Woolf ISBN 0321200683 Addison-Wesley, 2004
• [LEAN] http://www.lean.org/whatslean/principles.cfm
• [TMAP] TMap NEXT® Testing Clouds, Ewald Roodenrijs, Sogeti 2011
• [Quint2] Danny Greefhorst, Mark van Elswijk, “Een kwaliteit-gedreven aanpak voor architectuurreview”,
• Gepubliceerd door Software Engineering Research Centre, 2000