3.4.2 SOA voor een Organisatie

From Geonovum Wiki
Jump to: navigation, search


In de basis hebben een SOA en de services die binnen een organisatie gebruikt worden, geen andere levenscyclus dan de meer traditionele applicaties die door organisaties gebruikt worden. Toch is er een aantal verschillen dat service oriëntatie anders maakt en waarvoor speciale aandacht noodzakelijk is. Ze spelen niet of nauwelijks in een traditionele omgeving. Hieronder wordt daar er daarom op ingegaan.

Ontwikkelen

Bij het ontwikkelen van functionaliteit binnen een applicatie zijn de gebruikers bekend. In een SOA waarin services ontwikkeld worden zijn de gebruikers niet altijd bekend. Een service zal initieel altijd gebouwd worden met een gebruiker in het vizier, maar om het nut van een service te optimaliseren is het noodzakelijk de service te ontwikkelen voor een bredere gebruikersgroep, of een service moet ontwikkeld worden met hergebruik als doelstelling. Dit betekent dat voor het ontwikkelen van een service gebruik gemaakt moet worden van gestandaardiseerde informatiemodellen, die door een brede gebruikersgroep worden ondersteund.

Binnen de geografische wereld zijn dergelijke informatiemodellen beschikbaar in de vorm van Applicatie Contextmodellen. Het is aan te bevelen zowel de input als het resultaat van een service (functie en informatieverzoek) in te vullen met deze standaard informatiemodellen. Als bijvoorbeeld een service een bestemmingsplan oplevert, dan is het verstandig hiervoor het gestandaardiseerde bestemmingsplan informatiemodel toe te passen.


Doordat services niet alle gebruikers kennen en zeker niet de potentiële hoeveelheid gebruikers, zal bij de ontwikkeling steeds afwegingen gemaakt moeten worden over wat het gevaar is voor de leverende partij indien de service een groot succes wordt. Adequate maatregelen om deze risico’s te voorkomen moeten ingebouwd worden.
Zo kan het voorkomen dat een service informatie oplevert uit een kernsysteem van de leverancier. Doordat het aantal service afnemers te groot wordt, kan dit ertoe leiden dat het kernsysteem niet meer reageert en de leverancier zijn kernproces niet meer kan uitvoeren. Tal van deze scenario’s met risico’s voor leverancier en afnemer zijn mogelijk. Deze zijn actief, proactief en passief op te lossen.

  • Actief zorgt ervoor dat de applicatie die de service levert voldoende schaalbaar is en dat er geen last kan ontstaan. Dit kan gezien worden als een verzekeringspremie die wellicht nooit tot uitkering hoeft te komen.
  • De proactieve methode kan plaatsvinden door actief te monitoren op het gebruik. Het aantal toegelaten actieve serviceverzoeken kan worden beperkt. Indien er een grenswaarde wordt overschreden kan de applicatie (en dus ook de service) worden opgeschaald.
  • De passieve methode behelst het afwachten en oplossen als het probleem zich voordoet. Doordat een service de grenzen van een applicatie verlegt van de organisatie naar de grenzen van het Internet, speelt ook de behoefte aan 7x24 beschikbaarheid een rol.


Een eis die vanuit SOA gesteld wordt aan de service afnemers is dat zij minimale tot geen afhankelijkheden moeten creëren ten opzichte van de gebruikte services. Eventuele wijzigingen die aan een service worden aangebracht moeten zoveel mogelijk zonder aanpassingen aan de code geabsorbeerd kunnen worden. Zo moeten nieuwe informatie elementen die optioneel worden toegevoegd aan het resultaat er niet toe leiden dat de applicatie van de service afnemer niet meer werkt.

Beheren (Governance)

Vanuit de ontwikkeling gezien, mag de afnemer geen ‘last’ hebben van service wijzigingen. De leverancier zal altijd de gebruiker moeten informeren over het wijzigen van een servicedefinitie. Deze definitie kan gezien worden als een bindend contract. Aangezien in de ultieme SOA de service aanbieder niet altijd op de hoogte hoeft te zijn van alle afnemers, is dit een gebied dat speciale aandacht vraagt. De rol die hier gevraagd wordt, is die van een sectorcoördinator die als centraal aanspreekpunt fungeert en service aanbieders en afnemers bij elkaar brengt. Vanuit deze overzichtsrol kan ook analyse uitgevoerd worden op welke servicegebruikers geraakt worden door wijzigingen aan services. Deze partijen kunnen vervolgens actief geïnformeerd worden.


Het principe 'contract is contract en services zullen nooit wijzigen' is geldig binnen de SOA context. Alleen is het in de praktijk onmogelijk om een service een oneindige levensduur te geven. Het is gebruikelijk om bij uitbreiding van een service deze als ‘nieuwe’ aan te bieden naast de bestaande en de gebruikers de mogelijkheid te geven een transitie te maken naar deze service. Door het aantal ‘onderhouden’ versies of de levensduur van een versie, nadat deze is vervangen door een nieuwe te definiëren, kan een oneindige levensduur en wildgroei voorkomen worden. Het vraagstuk rondom versiebeheer speelt niet alleen voor de daadwerkelijke service, maar ook voor het serviceregister waarin de service beschrijvingen worden vastgelegd en beheerd. Het is van groot belang dat versies van service definities ‘oneindig’ bewaard blijven. Zo kunnen wijzigingen in de tijd getraceerd worden.


Een beheersrol, die in een normale applicatiecontext niet bestaat, is het stimuleren van hergebruik. De beheerorganisatie heeft tot taak om SOA actief te promoten en het hergebruik van beschikbare services te stimuleren. Ook indien er verzoeken komen voor nieuwe services zal de beheerorganisatie actief moeten participeren in het definiëren van een service die in een brede context toepasbaar is. Een sectorcoördinator zou de rol van ‘verkopen’ van de service op zich kunnen nemen en vanuit de één loketgedachte een platform kunnen bieden om de aanbieders en vragers bij elkaar te brengen.


Registraties en ‘data bij de bron’-principe

Binnen iedere organisatie zijn voor interne doeleinden vele registraties en administraties te identificeren die van belang zijn voor een tal van (interne) afnemers. Daarbij is 'registratie' te omschrijven als: "het proces waarbij eenduidige identificatie plaatsvindt van het desbetreffende beheerobject op basis van een vaste procedure, veelal op basis van of resulterend in een uniek identificatiekenmerk of document".
Een directe afgeleide van de registratie is de duurzame vastlegging van de geregistreerde gegevens en/of de wijze waarop de afhandelprocedure is doorlopen in een administratie. Vrijwel iedere organisatie maakt voor registratie en administratie gebruik van automatiseringshulpmiddelen als applicaties en databases.


Voorbeelden van registratiefuncties en administraties die binnen elke organisatie voorkomen zijn:

  • de administratie van werkzame personen,
  • gebouw en/of kameraanduidingen,
  • kostenplaatsen,
  • debiteurnummers,
  • projectnummers.


Een belangrijk principe bij het inrichten van dergelijke registraties is het zoveel mogelijk uitgaan van "data bij de bron". Dit biedt zowel garanties op efficiency als data-integriteit.


Binnen maar ook buiten de organisatie zijn verschillende afnemers van deze gegevens te onderkennen. Vanuit het oogpunt van kosten en data-integriteit is het efficiënt de functies zoveel mogelijk te centraliseren. Afhankelijk van inhoud, belang en omvang zal een specifieke functionaris of een specifiek organisatieonderdeel verantwoordelijk zijn voor het verloop van het gegevens verzamelproces en de juistheid van de data. Daarbij kunnen ook specifieke organisatorische of technische maatregelen van toepassing zijn, zoals functiescheiding en (externe) kwaliteitscontroles door toezichthouder of auditor.


Het voorgaande geldt nadrukkelijker voor publiekgerichte organisaties aangezien registraties voor die organisaties een bijzonder belang hebben vanwege:

  • de monopolistische en daardoor unieke positie van de publieke organisaties voor een bepaald werkgebied,
  • een brede afnemersgroep of een hoog volume aan afname.


Een voorbeeld van publieke registers is het register van ingezetenen voor een bepaalde (staatkundige) administratieve eenheid die voor de consument tastbaar wordt in documenten als een geboortebewijs, een bewijs van leven en een paspoort. Andere publieke registers zijn die van kentekens voor voertuigen en registraties voor vliegtuigen. Voor de consument worden dergelijke registraties meestal zichtbaar als een 'goedkeuringsprocedure' die kan bestaan uit een publicatie- en openbaarmakingfase en een bezwaarprocedure die uiteindelijk kan resulteren in een document als een kentekenbewijs, een verblijfsvergunning, een huwelijksvergunning of woonvergunning.

Dit samenhangende stelsel van registraties, zowel basisregistraties als kernregistraties, is een fundamentele component in een nationaal stelsel van voorzieningen zoals een Geo-Informatie Infrastructuur (GII).



previous Services Oriented Architecture (SOA) next