SOA of ASO

Het idee om het applicatie denken te veranderen naar een service oriëntatie is, kijkend naar de toekomst, zo gek nog niet. Er zijn geweldig veel applicaties die nu gegevens registreren en deze gegevens vervolgens weer exporteren naar andere applicaties middels ftp. Het veroorzaakt redundantie van gegevens en daarmee de vraag welk gegeven is nu het actuele gegeven.

Het overzetten van data gebeurt meestal in een batchverwerking die vaak ‘s nachts draait zodat ‘s morgens alle gegevens weer actueel zijn. Maar hoe actueel is actueel. De volgorde van verwerking van data kan invloed hebben op de resultaten. De transacties van die dag zijn nog niet verwerkt op andere systemen en de afhankelijkheid van externe data-leveranciers wordt steeds groter. 

Als we in plaats van een stand-alone applicatie gebruik maken van een Service Provider en zorgen dat deze altijd actueel is en blijft zijn we als service consumer verzekerd van de juiste informatie. Maar hoe komen we aan een dergelijke service provider? Een service is herbruikbare functionaliteit die aangeboden wordt. Het belangrijkste onderdeel in een soa is de interface van een service. Deze dient onafhankelijk te zijn van de onderliggende programmeertaal en bekend gemaakt te worden zodat een service aangeroepen kan worden. Soa is een breed spectrum van denken en afspraken. Er wordt ook wel gesteld dat slechts tien procent met ict te maken heeft, veertig procent met het beschrijven van de bedrijfsprocessen en vijftig procent met communicatie over hoe tot standaardisatie binnen processen te komen.

Enterprise Service Bus

De achterliggende techniek van een soa is de esb (enterprise service bus). De esb is de infrastructuur die nodig is om een service te faciliteren. Het maakt het mogelijk applicaties te koppelen die op verschillende platformen draaien en geschreven zijn in verschillende talen op basis van verschillende applicatie architecturen. Er worden verschillende typen services (bijv. WSDL, CICS) onderkent en ondersteund met de daarbij horende protocollen. (HTTP, SMTP, FTP, JMS, TCP, UDP, MQ) en bericht formaten (XML, SOAP, XBRL, …). De esb is niet de enige integratie component, maar wordt omringd door andere componenten. Om er een paar te noemen: Interaction Services (B2C) de Partner Services (B2B) de Business Application Services (koppeling met maatwerk). De ESB wordt gezien als de ‘enabler' van de soa-architectuur.

Op de markt van integratie producten zijn verschillende marktpartijen actief die allemaal een eigen service bus hebben, of zelfs meerdere, waarbinnen onder de motorkap weer andere producten worden aangeroepen. Waar sommige marktpartijen de esb altijd als een architectuurconcept hebben gezien (Gartner, IBM, Microsoft) hadden anderen al vanaf dag één esb als product gepositioneerd (Oracle). Inmiddels lijkt er echter consensus te ontstaan waarbij geconcludeerd mag worden dat een esb een architectuur concept is. In de dynamiek van de technologie en de daarmede gepaard gaande veranderingen is het noodzakelijk om extra nadruk te leggen op het communiceren van veranderingen.

Communicatie is altijd al een belangrijk onderwerp geweest om tot een succesvolle ict-implementatie te komen. Binnen het domein van de soa, waarbij er sprake kan zijn van meerdere services geleverd door verschillende leveranciers met een eigen invulling van het soa-concept, is communicatie cruciaal voor het welslagen van een soa-implementatie. De klant lijkt er gebaat bij te kiezen voor één leverancier, maar ontkomt er toch niet aan de service van een andere klant/partner te willen gebruiken. Als een service wordt aangepast aan de wensen van een consumer betekent dat dit doorwerkt naar alle consumers die gebruik maken van deze service. Communicatie is niet altijd de sterkste kant van de it-dienstverlener en daarom is het aan de klant de teugels in de hand te houden en duidelijk te specificeren wie de eigenaar is van de service en hoe deze te gebruiken, Hierin zit vijftig procent van de inspanning van een soaiimplementatie.