Integratie van applicaties staat hoog op de agenda van vele organisaties. Iedereen heeft het daarom over service oriented architectures (soa), webservices, integration brokers en nog veel meer indrukwekkende termen. Vooral eerstgenoemde is in trek.
Bij een soa wordt functionaliteit, die in bestaande applicaties verstopt zit, via services opnieuw ter beschikking gesteld van nieuwe applicaties. Die services zijn dan aanroepbaar vanuit nieuwe applicaties. De soa wordt vervolgens verrijkt met onder andere business process management engines en content-based routers om de mogelijkheden te versterken. Belangrijk hierbij is dat een soa rust op de bestaande applicaties. Hierin zit de meeste functionaliteit verstopt die uiteindelijk ontsloten moet worden.
In een Powerpoint-presentatie is een koppeling van een nieuwe applicatie via een soa naar een bestaande applicatie snel getekend. We tekenen een lijntje van de ene applicatie via de soa naar de andere applicatie. Een kind kan de was doen. In de praktijk blijkt dit echter een enorm struikelblok te zijn. Vergeet niet dat de meeste bestaande applicaties initieel niet ontwerpen waren om vanuit een soa aangeroepen te worden.
Indien u een soa gaat ontwikkelen, bestudeer dan die bestaande applicaties in detail. Hierbij moet u zeker de volgende aspecten onderzoeken.
Een soa implementeren we niet graag op de presentatielaag van een applicatie, want dit zou betekenen dat we op een vorm van screen-scraping moeten overgaan. De doelstelling is om zoveel mogelijk de applicatielogicalaag te benaderen. Het is echter de vraag of dit wel lukt bij elke bestaande applicatie. Is deze laag wel zo expliciet aanwezig dat we deze direct kunnen aanroepen? U zal niet de eerste organisatie zijn die gedwongen wordt bestaande applicaties te herbouwen om op de goede laag te kunnen aanroepen. Zeker in de jaren negentig zijn er veel client/server-applicaties gebouwd waarbij de scheiding tussen deze twee lagen geheel verdwenen is.
En wat dacht u van batch-applicaties? Deze hebben geheel geen interne structuur om aanroepen vanuit de soa online te verwerken. Misschien moeten we dan proberen met speciale producten de applicatielogica uit de code te destilleren om er een aparte online versie van te maken. Een tijdrovende en dure exercitie.
Als de ontwikkelaar van een bestaande applicatie wel zijn best heeft gedaan en wij wel de applicatielogica kunnen bereiken, moeten we ons de vraag stellen of deze laag wel voldoende getest is. Of zijn alleen de oude aanroepen die vanuit de presentatielaag binnenkomen getest? Als wij ineens op een andere manier binnenkomen, kan het zijn dat we nog ongeteste code wakker schudden en dat deze de applicatie onherstelbaar beschadigt. Vergeet niet dat de bouwer van de applicatie er vanuit was gegaan dat de presentatielaag de enige ‘gebruiker’ van de applicatielogicalaag was.
Stel dat de bestaande applicatie ’s nachts wordt uitgezet. Wat nu als de soa een beschikbaarheid eist van 24 uur per dag en zeven dagen in de week? Uiteraard dient de beschikbaarheid van de bestaande applicatie dan ook opgevoerd te worden, maar misschien kan dat helemaal niet. Wellicht is de verkeerde technologie gekozen. Ook dit probleem is niet snel verholpen.
De nieuwe applicaties die via soa de bestaande applicaties aanroepen, genereren een extra workload. Als een bestaande applicatie al aan een maximum zit, zal dit de verwerkingssnelheid voor alle gebruikers onacceptabel vertragen. Is dit een kwestie van krachtigere hardware kopen of moet er weer in de bestaande applicaties ingegrepen worden.
Het wordt tijd dat we in onze verhalen over soa’s niet meer alleen de mooie plaatjes tonen, maar ook stilstaan bij de probleemgebieden en vooral die problemen die te maken hebben met de bestaande applicaties. Zij vormen het fundament van elke soa, dus hoe goed is dat fundament?< BR>
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
