3.4.1 Introductie SOA voor Organisaties

From Geonovum Wiki
Jump to: navigation, search


Relatie tussen business en techniek

SOA biedt de business nieuwe mogelijkheden om meer sturing te geven aan ontwikkelingen en op een andere, meer effectieve manier te voorzien in haar behoeften op het gebied van functionaliteit. Het toepassen van een SOA werpt pas echt haar vruchten af als het zowel vanuit de business als vanuit de techniek wordt ondersteund en toegepast.


Een SOA is geen korte termijn investering of inspanning. Het is een aanpak die gericht is op de langere termijnen dit vraagt om een duidelijke borging binnen de organisatie op het snijpunt van business en techniek. Deze aanpak komt daarom automatisch op het bord van de Enterprise Architecten. Het is hun taak om de strategische business visie van de organisatie te vertalen in een stabiele lange termijn aanpak die de realisatie van deze strategische visie vanuit de techniek mogelijk maakt. De Enterprise architectuur schept niet alleen kaders via principes en richtlijnen, maar zorgt ook voor de bewaking van deze kaders.


Het is een onderdeel van de Enterprise architectuur om op zijn minst de primaire processen van de organisatie helder te hebben. De processen worden door proces architecten in kaart gebracht. Binnen een SOA context is de rol van deze procesarchitecten cruciaal. Services zijn namelijk het meest eenvoudig te destilleren uit de processen. De procesovergangen of individuele processtappen zijn dé kandidaten om de gewenste functionaliteit en/of informatie via een service beschikbaar te maken. Indien meerdere primaire processen gebruik maken van dezelfde informatie en/of functionaliteit, neemt het nut van het als service beschikbaar stellen toe.


De proces architecten kunnen vanuit hun expertise een lijst opleveren van potentiële services. De business architecten vormen bij uitstek het aanspreekpunt om het nut van de services voor de business aan te geven en waarderen. De combinatie van expertises binnen de Enterprise Architectuur, die zorgdragen voor borging op de lange termijn, het bepalen van potentiële services en het nut per service, zijn van essentieel belang voor een SOA.


Binnen een keten moeten grofweg dezelfde aanpak en expertisegebieden ingevuld worden voor een succesvolle SOA. Het verschil tussen keten een organisatie is dat een keten autonoom beslissingen kan nemen over wat een service is en een eigen definitie heeft van nut en noodzaak. Binnen een keten is het noodzakelijk om zorg te dragen voor een consistente en coherente set van services die voor de keten nuttig zijn. Dit betekent dat vanuit een ‘keten architectuur’ de ketenprocessen helder gemaakt moeten zijn en op basis van criteria als nut voor de keten services gedestilleerd kunnen worden vanuit de procesovergangen en processtappen. De keten architectuur zal daarnaast invulling moeten geven aan standaardisatie van o.a. naamgeving van services, berichtdefinities, metadata. Bovendien moet het toepassen van services gestimuleerd worden.


Eigenaarschap

Aangeboden services kennen in principe een eenduidige eigenaar. De functionaliteit en informatie die door een service geboden wordt, worden door deze eigenaar op tal van manieren gegarandeerd. Hieronder vallen onder andere:

  • de verschillende manieren van beschikbaarheid;
  • de kwaliteit en het gebruiksrecht.

Bovenstaande zaken moeten worden vastgelegd in een Service Level Agreement (SLA). Binnen de ebXML familie bestaan mogelijkheden om die zaken vast te leggen, maar deze zijn onvoldoende uitgekristalliseerd en toegepast. Gezien het principe dat een service afnemer een ‘menselijke’ validatie slag uitvoert op het nut van een service, kan dezelfde validatie ook plaatsvinden op de SLA van de service. Dit betekent dat de SLA in een goed leesbare en duidelijke vorm beschikbaar moet zijn als onderdeel of bijlage van een service definitie.


Service oriëntatie maakt het mogelijk, of nodigt uit om services te leveren die functioneler ingericht en business gerelateerder zijn. Hiervoor kan gebruik gemaakt worden van het orkestreren (assemblage) van services. Een voorbeeld is aanbieden van een kadastrale kaart op provincieniveau die diverse gemeentelijke systemen combineert tot één gebied. Het is zaak om ook voor deze gecombineerde services een eenduidige eigenaar te hebben.


Binnen een organisatie is dit (relatief) eenvoudig te regelen, maar binnen een keten waar services van meerdere partijen tot één service omgesmeed worden, moeten hiervoor voorzieningen getroffen worden. Dit kan onderlinge afspraken te maken en één van de aanbieders van de onderliggende services eigenaar te maken. Er kan ook door een derde partij ingeschakeld worden. Zo kan de service via gedelegeerd eigenaarschap aangeboden worden. Er moet gestreefd worden naar een aanspreekpunt voor een service. Deze derde partij kan de ketencoördinator zijn die als een soort uitgever van services acteert.


Beveiliging

Services leveren informatie en functionaliteit die niet door of voor iedereen bruikbaar mag zijn. Een adequate beveiliging is een vereiste van een SOA. Binnen een keten zal de ketencoördinator of de gezamenlijke partijen een minimale set van beveiligingseisen neerleggen waaraan de partners moeten voldoen.


Een belangrijk onderdeel van deze eisen is het vertrouwen van de andere partijen. Dit is een eis die ervoor zorgt dat de kosten die met de beveiliging gemoeid zijn op een acceptabel niveau gehouden worden. Als er geen vertrouwen is zal de beveiliging extreme vormen aannemen met bijbehorende kosten.
Beveiliging kent een aantal aspecten, waarbij een tweedeling de meest voor de hand liggende optie is:

  1. Het verlenen van toegang tot de service;
  2. Het mogen uitvoeren van de service.


Het verlenen van toegang is een functionaliteit die door de infrastructuur opgelost moet worden. Onderdeel hiervan is de authenticatie van de service afnemer en validatie voor het mogen aanroepen van de service. Dit is een puur technische aangelegenheid die ingevuld kan worden met WS Security. Deze WS security schrijft SOA geldige standaarden voor op dit terrein. De beveiliging van het uitvoeren van services is niet de verantwoordelijkheid van de infrastructuur, maar van de service (leverancier) zelf. Uiteraard wordt hierbij gebruik gemaakt van de authenticatie gegevens. Het mogen uitvoeren of inzien van informatie die door een service wordt geleverd is een business functionaliteit. Het kan immers zo zijn dat het resultaat van een informatie leverende service verschilt van gebruiker tot gebruiker. Zo kan bijvoorbeeld de ene service gebruiker wel prijsinformatie zien, terwijl dat er voor de andere service gebruiker eruit wordt gefilterd.



previous Services Oriented Architecture (SOA) next