Op 28 November jl. was ik als ‘vertegenwoordiger’ van Finalist aanwezig op het tweede SOA seminar van Rick van de Lans. Rick is consultant bij R20/Consultancy. Hij geeft seminars waarin hij zijn bevindingen uit de SOA-praktijk gebruikt om geïnteresseerden te informeren over de verschillende valkuilen en misvattingen waar men mee te maken gaat krijgen als men met SOA aan de slag gaat.

Organisatie

Na een korte maar duidelijke uitleg over de gebruikte terminologie, ging Rick direct verder met één van de belangrijkste punten: de organisatorische implicaties. Hoe zorg je er nou voor dat een SOA project draagvlak krijgt? Moet je je IT afdeling anders inrichten? Wie wordt waarvoor verantwoordelijk?

Zijn (en velen met hem) visie is dat het belangrijk is de mensen die het voor het zeggen hebben (management) te overtuigen van het belang van SOA. Het herstructureren van de IT afdeling is volgens hem vaak ook onvermijdelijk; veelal zijn teams nu verantwoordelijk voor een applicatie, dat zouden straks services moeten worden.

Techniek

De rest van het seminar was wat technischer van aard en was ruwweg in te delen in drie categorieën: Architectuur, Services en Data. Ik laat daarbij de wat meer technische zaken zoals bijvoorbeeld de SOAP encodeer stijl even weg.

Referentie architectuur

Veel bedrijven hebben geen ervaring met het ontwikkelen van een SOA. Bij het ontwikkelen van een SOA moeten op architectonisch niveau een aantal beslissingen worden genomen, die ervoor zorgen dat er geen wildgroei aan services ontstaat. Rick raadde alle aanwezigen met klem aan een referentie architectuur te bouwen of laten bouwen waarbij wordt vast gelegd wat de granulariteit van services in een bepaalde laag is; en welke laag waarvoor verantwoordelijk is.

Services

Belangrijk in een SOA is het nadenken over de verschillende niveaus waarop men services gaat bouwen; ruwweg heb je basic services, composite services en business services. De basic services zijn verantwoordelijk voor de ontsluiting van bestaande functionaliteit (legacy applicaties) voor gebruik in een SOA. De composite services bundelen een aantal service aanroepen zodat functionaliteit uit verschillende applicaties gecombineerd kan worden (het opzoeken van gebruikers in verschillende subsystemen bijvoorbeeld). De business services bieden daadwerkelijk de functionaliteit waarmee een business proces kan worden uitgevoerd.

Over de granulariteit van de services was Rick heel duidelijk. Laat het object georiënteerde tight-cohesion concept een los en ga denken in documenten dus ‘coarse-grained’. Bijvoorbeeld: bouw geen business service die een creditcard nummer valideert, maar bouw een service die laat weten of de creditcard gegevens in het gegeven document valide zijn.

(Canonical/Common) Datamodel

Een deel van de implementatie van een SOA bestaat uit het definiëren van een applicatie overstijgend datamodel. Dit wordt vaak het ‘canonical datamodel’ of ‘common datamodel’ genoemd. Dit datamodel kun je het beste baseren op eventueel beschikbare standaarden in de betreffende industrie. Voor de meeste industrietakken bestaan deze standaarden reeds.

Er van uitgaande dat het datamodel een hiërarchisch model is zijn er eigenlijk twee uitersten te definiëren waar je het beste tussen kunt gaan zitten: een ‘plat’ model of een ‘diep’ model:

Het bepalen van de juiste ‘diepte’ van je formaat doe je op basis van de verwachte queries en transformaties én de impact die dit heeft op performance; hier bestaan nog geen eenduidige regels voor, Rick verwacht dat we deze de komende jaren wel gaan zien.

XQuery, transformaties

Omdat de meeste SOA implementaties XML gebaseerd zijn is het zaak daar ook als XML mee om te gaan. In de praktijk ziet men vaak dat het in een SOA barst van de vertalingen van programmeertaal Y naar XML en weer terug. Dit is vaak niet nodig, met XSL transformaties en XQuery engines kun je vaak op een veel flexibelere en beter snellere manier met XML omgaan. Vrijwel alle nieuwe database engines komen met ingebouwde support voor deze technieken; gebruik deze ook!

Transacties en het terugdraaien van mutaties

Een SOA brengt een aantal nieuwe problemen met zich mee op het gebied van transacties. Als een service mutaties uitvoert op meerdere applicaties kan het erg lastig zijn om deze weer netjes terug te draaien als er iets mis gaat. Databases ondersteunen al jaren two-phase commits om dit probleem op te lossen, en dergelijke oplossing is niet beschikbaar in een SOA. Veel commerciële oplossingen bieden zogenaamde ‘compensational services’, maar de uiteindelijke logica voor het terugdraaien van de uitgevoerde mutaties dient men zelf te implementeren; dit kan in de prakijk verschrikkelijk lastig of zelfs onmogelijk zijn.

Testen van services

Testen is een vaak ondergeschoven kindje in IT trajecten. Bij veel organisaties is het zo dat testen vooral plaats vind op de gebruikersinterface van een applicatie. Op het moment dat gedeelde functionaliteit zich gaat bevinden in services is het testen van deze services via de bovenliggende applicaties over het algemeen niet afdoende. Er zijn een hele reeks (veelal commerciële) softwarepakketten die puur gericht zijn op het testen van services. Het soort tests wat deze pakketten leveren varieert van belasting tot functioneel tot beveiliging. Het lijstje met softwarepakketten bevatte geen FLOSS oplossingen. Ik ben benieuwd wat er op FLOSS gebied eigenlijk beschikbaar is.

Data

De kwaliteit van bestaande data is vaak minder goed dan verwacht. Vooral bij het samenvoegen van verschillende systemen met vergelijkbare data zijn de problemen vaak legio. Een belangrijk onderdeel van het implementeren van een SOA is het transformeren, opschonen en samenvoegen van bestaande data om deze voor de SOA bruikbaar te maken.

Veel SOA platforms komen met zogenaamde ‘cleaning services’ om data op te schonen. Het is bij de evaluatie van producten belangrijk om hier goed naar te kijken.

In veel gevallen kan het ook geen kwaad om de service die het vervuilende systeem ontsluit te voorzien van logica om de data te vertalen en op te schonen. Denk hierbij vooral aan het ontdubbelen van synoniemen (Holland, Nederland) en het uitschrijven van afkortingen (strt, straat of v.d. van der). In veel gevallen neemt dit een hoop problemen in de bovenliggende service lagen weg.

Master Data Management

Aangezien een SOA systemen bij elkaar gaat brengen die van tevoren los van elkaar stonden zal het vaak voorkomen dat er relaties tussen data gelegd moeten worden die voorheen niet bestonden. In plaats van het zelf ontwikkelen van een overkoepelende database zou je ook kunnen kiezen een MDM oplossing in te zetten. Een MDM kan zorg dragen voor het harmoniseren van verschillende databases.

Enterprise Mashup

In het web 2.0 landschap zien we ze al geruime tijd: mashups. Een mashup in web 2.0 terminologie is eigenlijk niets meer dan een website waarop data vanuit verschillende bronnen wordt samengevoegd en eventueel getransformeerd om een overkoepelende weergave te creëren. De term ‘enterprise mashup’ had ik al een paar maal voorbij horen komen, maar nooit de conclusie getrokken dat het net iets anders was dan de web 2.0 mashup. Het volgende plaatje geef de overeenkomsten en verschillen schematisch weer:

bron: The story of Web 2.0 and SOA continues – Part 1

Een enterprise mashup is eigenlijk een lichtgewicht portal; een eenvoudige manier om met je services al bouwstenen een applicatie of dus view op je services te ontwikkelen. Ik denk dat we hier in de nabije toekomst nog veel over gaan horen, hiermee wordt het mogelijk je SOA flexibel en maximaal te benutten.

Conclusie

Persoonlijk vond ik het een erg goed seminar. Wat ik vooral prettig vond was de nuchtere kijk op de verschillende problemen: het is niet erg om af en toe het SOA paradigma te verbreken, als je tot 80%-90% komt, ben je al een heel eind!

—————————————————————————————
Meer weten over SOA-specialist Finalist IT Group?