Computable legde Don Rippert, chief technology officer bij Accenture, zes prikkelende stellingen voor over soa (service oriented architecture). “Beveiliging, data-integriteit binnen langlopende transacties en testen zie ik als de top drie uitdagingen van soa op dit moment.”
Stelling 1: Mashups zijn alleen geschikt voor eenvoudige applicaties
De term ‘mashup' wordt wel eens geassocieerd met quick en dirty, met een snel in elkaar gezette maar niet zo krachtige wegwerpapplicatie. In werkelijkheid is het verschil tussen mashups en ‘conventionele' samengestelde applicaties niet absoluut, maar gradueel.
Stelling 2: Standaarden en tools voor mashups ontbreken nog grotendeels
Daar ben ik het mee eens voor zover het gaat om standaarden, maar niet als het gaat om tools. De tools voor het maken van mashups zijn inmiddels zo doorontwikkeld, dat mashups behoorlijk geavanceerd zijn. Denk aan Serena, Microsoft Popfly en JackBe.
Stelling 3: Een goede testomgeving voor SOA’s ontbreekt
Dat is een heel terechte opmerking. Ik denk dat de tools op dat gebied geen gelijke tred hebben gehouden met de standaarden. Fabrikanten doen hun best, maar testen blijft ingewikkeld. Beveiliging, data-integriteit binnen langlopende transacties en testen zie ik als de top drie uitdagingen van soa op dit moment.
Stelling 4: Integratiemogelijkheden van middleware vallen tegen
De meeste standaarden zijn geïmplementeerd op een interoperabele manier, maar dat geldt niet voor alle standaarden. Zo is de manier waarop data-integriteit wordt gegarandeerd niet hetzelfde geregeld binnen verschillende platformen. Als je data wilt behouden gedurende de loop van een transactie, bijvoorbeeld een elektronisch recept, dan zou het normale proces zijn: je dokter schrijft een recept, de verzekeringsmaatschappij controleert de dekking van dat recept en de apotheek controleert of het medicijn in voorraad is. Zonder dat ze daarover met elkaar hoeven te overleggen en zonder dat je hoeft te weten welke computersystemen ze daarvoor gebruiken, ook als die van verschillende leveranciers afkomstig zijn. Maar dat is nu nog niet altijd zo.
Dat geldt ook voor beveiliging: binnen één platform werkt authenticatie en autorisatie prima, maar tussen platformen onderling van middleware-vendors als IBM, Microsoft, SAP, BEA, is dat niet altijd het geval. Dat kan problemen opleveren als je de ontvangst van een transactie wilt garanderen. Daarvoor moet nu nog vaak verbindende code worden geschreven.
Daarnaast hebben de softwarelveranciers meer tijd nodig om de soa-standaarden volledig te implementeren dan we twee jaar geleden nog verwachtten. Het grootste probleem ligt op het vlak van één bepaalde standaard: Simple Object Access Protocol (SOAP). Hoewel SOAP heel krachtig is, is het een behoorlijk ingewikkeld protocol om te implementeren. SOAP heeft daardoor de adoptie van soa vertraagd. Maar er bestaat een alternatieve standaard, die gemakkelijker te beheren is: Representational State Transfer (REST). REST heeft niet alle mogelijkheden van SOAP, maar voor de meeste applicaties heb je ook niet alle SOAP-mogelijkheden nodig. Veel bedrijven en instellingen die eerst alleen toegang boden via SOAP doen dat nu ook via REST. Ook de meeste nieuwe web services zijn benaderbaar via REST.
Stelling 5: SOA’s lossen geen legacyproblemen op
Computable: "Het probleem verschuift doordat de leveranciers van legacysystemen gedwongen worden om connectoren te schrijven, vaak zonder dat ze daarvoor de kennis in huis hebben."
Rippert: "Een boel bedrijven hebben legacysystemen die ze niet volledig begrijpen. Om die te vertalen naar representatieve services moet je beginnen met reverse engineering door gebruik te maken van tools die de broncode doorzoeken."
Computable: "Dat klinkt als een nachtmerrie. Kun je dan niet het beste helemaal overnieuw beginnen?"
Rippert: "Nee, voor een groot bedrijf is dat nog ingewikkelder."
Stelling 6: Hergebruik van services is meestal niet mogelijk
In de ideale situatie programmeer je een service die in verschillende omgevingen kan draaien. Maar je moet behoorlijk slim zijn om alle dingen te bedenken die je niet nu, maar misschien in de toekomst afhandelt. Maar voor een softwarebedrijf, dat misschien honderd klanten heeft die één bestaande applicatie gebruiken, kijk je niet naar slechts één gebruiksscenario, maar naar honderd.
Als klant zes iets nieuws wil, zijn de kansen aardig groot dat een ander bedrijf daar al mee bezig is en dat die web service kan worden hergebruikt. Dus er ontstaat een groeiend momentum voor softwareleveranciers om differentiatie in hun aanbod aan te brengen door het aanbieden van verschillende services. Het is niet altijd mogelijk, maar nu is het bijna nooit mogelijk om een non-soa stuk software te hergebruiken zonder het te herschrijven, als het niet exact voor dezelfde omgeving is geschreven.
Computable: "Dus SOA maakt de situatie in ieder geval niet slechter?"
Rippert: "Inderdaad. Zelfs al gaat het maar om twintig procent hergebruik, dan is dat toch mooi meegenomen."
Don Rippert
Don Rippert is de wereldwijde chief technology officer (cto) bij Accenture, een bedrijf met inmiddels meer dan 180.000 medewerkers wereldwijd (waarvan in Nederland ruim 2600). In zijn tot nu toe vijfentwintigjarige carrière bij de dienstverlener was hij onder andere managing partner global solutions, project manager en programmeur. Momenteel is Rippert belast met het bepalen van de technologievisie en -strategie van Accenture en verantwoordelijk voor meer dan achthonderd software architecten werkzaam bij klanten van Accenture en bij de Accenture Technology Labs.
Voor wat betreft de tools voor mashup zijn er twee categorie�n de Consumenten mashup en de Enterprise mashup.
Een belangrijke speler in de Enterprise Mashup markt ontbreekt in het genoemde rijtje: Corizon (zie http://www.corizon.com). Dit product is gebaseerd op een open standaard, dus ook op dat vlak zijn er ontwikkelingen.
Voor wat betreft SOA testen ben ik het ook niet eens met de stelling. Er zijn diverse test automation tools die zich richten op complexe, heterogene op SOA principes gebaseerde applicatie architecturen. Een van de spelers waar wij ervaring mee hebben is LISA van iTKO (www.itko.com). Hiermee zijn zeer complexe SOA omgevingen zeer eenvoudig door te testen.
Wel ben ik het eens met de stelling dat SOA testen zeer complex is en veel van een organisatie vraagt. Virtualisatie van testomgevingen zoals die kan worden gerealiseerd met LISA kan hierbij voor verlichting zorgen.
Op het gebied van mashups vinden diverse ontwikkelingen plaats. Hier richten zich volgens mij vele leveranciers zich op. Denk aan de voorzieningen die Google en Yahoo nu al bieden, hoe primitief ze ook nog lijken. Ook zijn er zoals in de andere reactie is aangegeven, voldoende testomgevingen. TNO biedt een online testomgeving om een webservice van een leverancier te kunnen testen. Hiervoor zijn geen investeringen nodig.
Inderdaad moeten we verschil maken tussen consumenten mashup en enterprise mashups. Binnen enterprise mashups gaat het om omgevingen die rechtstreeks (secure) verbinding kunnen maken met de interne systemen. IBM met MashupHub en WebSphere sMash behoort ook in dit rijtje thuis. Naast SOA is ook information management een belangrijke voorwaarde om een goede infrastructuur voor enterprise mashups neer te leggen. uiteindelijk gaat het om het combineren van informatiebronnen, de vraag is of we met SOA voldoende informatiebronnen kunnen ontsluiten voor de eind-gebruiker mashups. Binnen SOA wordt gericht naar het process gekeken, terwijl de grondslag van mashups in de beschikbare informatie ligt.
Quick and dirty noemen in combinatie met enterprise mashups kan in sommige gevallen terecht zijn. Dit zal zeker voorkomen als binnen IT geen plan bestaat voor het invoeren en onderhouden van mashups. Gelijk aan de wirwar aan Excel sheets, MS Access en Lotus Domino applicaties die nog in veel bedrijven rondzwerven. Evenals SOA is een enterprise mashup geen Haarlemmer olie. Een bedrijf moet zich goed voorbereiden op het gebruik van enterprise mashups.