SOA en de Legacy Uitdaging
Volgens Gartner gaat het concept SOA (Service Oriented Architecture) momenteel door het ‘dal van de desillusie’. Nu zijn alle technologieën en concepten uit de IT-wereld gedoemd om door die fase gaan. De confrontatie met de realiteit toont immers steeds opnieuw dat ideeën in de praktijk brengen moeilijker blijkt dan oorspronkelijk gedacht. Zonder het betalen van dit leergeld zal een concept nooit de nodige maturiteit bereiken om een blijvende rol te spelen binnen IT. Daarom gaat dit artikel in op het initiële enthousiasme voor SOA – meer bepaald in de context van legacy applicaties – en de ontnuchtering die daarop kan volgen. Daaruit kan je dan weer leren hoe je een SOA- project met meer realiteitszin aan moet vatten.
Binnen een SOA spelen services een centrale rol. Webservices worden vaak in één adem genoemd met SOA. Zo’n insteek belicht echter vooral de infrastructuuraspecten. Die zijn belangrijk, dat wel, maar het uitdenken van een service komt nog altijd voor het aanbieden ervan. Dat uitdenken vergt in de eerste plaats aandacht voor de inhoudelijke aspecten. Voor we hier verder op ingaan, kijken we even terug op de literatuur van pakweg een drietal jaar geleden. Daarin werd een SOA vaak voorgesteld zoals in figuur 1, hieronder, waarbij het begeleidende verhaal zich als volgt laat samenvatten. De businessfunctionaliteit binnen de legacy applicaties wordt op een duurzame wijze ontsloten. Op basis daarvan kunnen businessprocessen verder geautomatiseerd worden. Bovendien lijkt een oplossing in de maak om de talrijke ad-hoc integraties tussen oude en nieuwe IT-systemen beheersbaar te maken. Kortom, SOA heeft op korte termijn hooggespannen verwachtingen gewekt.
DE LEGACY UITDAGING
Op bovenstaande uitgangspunten valt weinig af te dingen. Behalve dan dat de implementatie van services niet vanzelfsprekend is: de legacy uitdaging stelt zich al snel wanneer we dieper ingaan op de inhoudelijke karakteristieken van services. Een service moet business-georiënteerd en autonoom zijn. Dit betekent dat een service binnen een duidelijk afgelijnd domein volledig zelf moet instaan voor het uitvoeren van een zinvolle businessfunctionaliteit. Tot hiertoe weinig nieuws onder de zon, want dit was ook een leidmotief van de softwarecomponenten-beweging uit de jaren negentig.
Maar bij services is het ook belangrijk dat er tijdens het uitvoeren van de functionaliteit geen uigebreide conversatie is tussen de service en zijn gebruiker – een service is stateless.
De gebruiker bezorgt de nodige informatie in één request aan de service. Meestal bezorgt de service nog een response aan de aanroeper, maar dit sluit de interactie af.
Nu zijn het net bovenstaande karakteristieken die ervoor zorgen dat figuur 1 de zaken te rooskleurig schetst. Ja, een legacy systeem vervult veel businessfunctionaliteiten. Maar datzelfde legacy systeem is typisch enkel autonoom als geheel.
De businessfunctionaliteiten zitten met elkaar verstrikt in een web van elkaar aanroepende COBOL-programma’s of klassen geïmplementeerd in JAVA of .NET. Bovendien vergt het uitvoeren van een volledige business functie vaak een omslachtige interactie met en tussen deze programma’s of klassen. Componenten vallen met andere woorden nauwelijks te onderscheiden en het etiket stateless is al helemaal niet aan de orde. Figuur 2 (hierboven) illustreert dat aan de hand van een typevoorbeeld uit de legacy COBOL-wereld. Rondom een kern die het gros van de businessfunctionaliteit omvat, bevinden zich naast batchprogramma’s ook programma’s die fungeren als integratielaag voor een web-applicatie. De functionaliteit van een kandidaat-service is al aanwezig, maar zit verspreid. Het is dus onmogelijk om zonder bijkomende ingrepen een service te creëren bovenop die functionaliteit.
De noodzaak om eerst intern orde op zaken te stellen, brengt ons bovendien bij de relatie tussen services en flexibiliteit. De afname van de interne samenhang ligt immers ook aan de basis van de teloorgang van de oorspronkelijke flexibiliteit van de legacy applicatie. Sleutelen aan één business-functionaliteit vergt ingrepen op verschillende plaatsen in het systeem. Omdat een service de stukken-en-brokken-implementatie van een businessfunctie tot één geheel smeedt, leidt dat bijna automatisch tot een opnieuw stijgende flexibiliteit.
Samengevat zijn er dus twee positieve luiken aan de introductie van services in een legacy systeem.
– Services zijn een uitstekende remedie tegen de toenemende verstarring van de legacy applicaties.
– Services maken het ontsluiten van businessfunctionaliteit mogelijk.
Zoveel goeds heeft natuurlijk zijn prijs: het realiseren van goede service eist een grondige voorbereiding.
HOE REALISEER IK MIJN SERVICE
De eerste stap bestaat vanzelfsprekend uit het identificeren van de businessfunctionaliteit die in een service zal worden ondergebracht. Nu zijn die businessfuncties waarvoor de roep naar ontsluiting en een hogere flexibiliteit het luidst klinkt, vaak ook de meest businesskritische. Het belang van continuïteit en voorspelbaarheid is bijgevolg erg groot. Daarom is het raadzaam de beoogde functionaliteit eerst in de service onder te brengen. Pas als dit achter de rug is, kan de functionaliteit zelf onder handen genomen worden. Dit uitgangspunt vereenvoudigt het testen aanzienlijk omdat men zo over een duidelijke basis van vergelijking beschikt. Het identificeren van de businessfunctionaliteit beperkt zich tot het vastleggen van de grote lijnen. Als die eenmaal vastliggen begint een intensieve analysefase. Het doel van die fase is om de functionaliteit volledig en in detail bloot te leggen en vervolgens te begrijpen. De vergelijking met archeologisch onderzoek is tijdens deze fase nooit ver weg. In de volgende vier activiteiten worden de belangrijkste bronnen van informatie aangeboord.
– Het verzamelen van alle beschikbare documentatie. Die is wellicht onvolledig en gedateerd, maar hoe gering het resultaat ook is, het vormt een vertrekpunt.
– Business en IT-mensen die van ver of dichtbij bij de functionaliteit betrokken (geweest) zijn, kennen of herinneren zich altijd bepaalde elementen. Het naast elkaar leggen van deze informatie levert meestal een goed overzichtsbeeld op met ook al een behoorlijk niveau van detail.
– Het analyseren en opnieuw documenteren van de huidige implementatie van de functionaliteit. Deze benadering is complementair aan punt 2. Het raadplegen van de code is onvermijdelijk om het vereiste niveau van detail te bereiken. Anderzijds kunnen vele technische constructies enkel te volle begrepen worden aan de hand van informatie uit 2.
– Het achterhalen van al de businessprocessen die de functionaliteit gebruiken. Dat helpt om het ‘waarom’ te begrijpen. Deze activiteit is essentieel, want de vorige activiteiten brachten vooral het ‘hoe’ aan het licht. Verder is het nodig om bondig te zijn in deze oefening, zodat je geen aspecten van de beoogde functionaliteit over het hoofd ziet.
Deze activiteiten gebeuren best naast elkaar. Zo kunnen ze elkaar tijdens de uitvoering voeden met belangrijke inzichten. Verder heeft het niet uitvoeren van een activiteit onherroepelijk een negatief effect op het uiteindelijke resultaat. Als deze stap al niet de moeilijkste is, dan is het zeker de meest veeleisende. Men kan immers niet meer rond de legacy blijven draaien. Hier moet men door de vaak zure appel heen.
Op basis van de geconsolideerde informatie uit 1, 2, 3 en 4 kan men met de belangrijkste service design activiteit beginnen: het aflijnen van de verantwoordelijkheden van de service. Als de grenzen daarvan eenmaal vastliggen, is het ook duidelijk wat de verantwoordelijkheden voor de aanroepende partijen zijn. Vanzelfsprekend zijn de hierboven vermelde basiskarakteristieken van services de belangrijkste leidraad bij deze oefening. Tijdens het design moet er ook al rekening gehouden worden met enkele mogelijke evoluties van de functionaliteit. Het opgestelde service contract moet immers in staat zijn de gevolgen
van deze evoluties op een natuurlijke wijze te incorporeren.
IMPLEMENTATIE
Wanneer deze analyse- en designfase achter de rug is, kan men tot implementatie overgaan. Niet alleen moet de service worden gebouwd, ook de aanroepende applicaties moeten worden aangepast. Dit is opnieuw een spannend moment omdat het mes hier echt in de legacy applicatie wordt gezet. In ieder geval moet de integratie tussen de service en de aanroepende programma’s een eenvoudiger beeld opleveren dan voorheen. Is dat niet het geval, dan is de service waarschijnlijk slecht gedefinieerd. Om dit te vermijden, moeten de integratie-aspecten op continue basis geverifieerd worden tijdens de analyse- en designfase.
Belangrijk is dat de service in eerste instantie geïmplementeerd kan worden als een stel van COBOL-programma’s. Zolang die enkel kunnen worden aangesproken via de service interface, vastgelegd tijdens de designfase, kunnen we spreken van een echte service. Om de ontsluiting – bijvoorbeeld via webservices – te realiseren, kunnen de technische mogelijkheden van het gebruikt platform aangesproken worden, maar dat is een ander verhaal.
Services realiseren in een legacy omgeving is dus een werk van lange adem. Een service bouwen gaat namelijk onherroepelijk gepaard met het rechttrekken van situaties die over de jaren heen zijn scheefgegroeid. In zekere zin wordt de rekening gepresenteerd voor de vele ad-hoc beslissingen uit het verleden. Het is die confrontatie met de realiteit die al eens leidt tot een verlies van vertrouwen in SOA. Op dat moment is doorbijten de boodschap. Als de oefening goed gebeurt, wordt niet alleen een duurzame ontsluiting van de businessfunctionaliteit mogelijk, maar wint de legacy applicatie ook haar reeds lang verloren flexibiliteit terug.
Tim Daniels is Enterprise Architect bij Inno.com (www.inno.com).
