3.3.3 SOA Services

From Geonovum Wiki
Jump to: navigation, search


Typering van services

Binnen de Services Oriented Architecture (SOA) context kan een onderscheid gemaakt worden tussen de diverse aangeboden services. Deze services vallen uiteen in een drietal lagen:

  • technische services;
  • business services;
  • samengestelde (proces)services.


De technische services zijn technisch van aard en bieden geen functionaliteit die direct aan de business gerelateerd is. Het zijn veelal ondersteunende services die een grote toepasbaarheid hebben. Een voorbeeld is een bewakings-service die bijhoud welke gebruikers bepaalde services geraadpleegd hebben. Een ander voorbeeld is een service die regelt wie toegang krijgt (beveiliging) om services te mogen aanroepen. Technische services kunnen gezien worden als infrastructuurcomponenten. In de geo-informatie wereld zijn dit bijvoorbeeld OGC WMS of OGC WFS.


De business services bieden een functionaliteit die voor de business begrijpelijk en direct toepasbaar zijn. Ze zijn vaak als ‘losse functie’ bekend binnen de gebruikerstoepassingen. Een voorbeeld van een business service is de ´geefBommenopGemeente´ service die op basis van een locatie aanduiding een kaart met gevaarlijke locaties teruggeeft. Ook een conversieservice die formaat conversie uitvoert op geografische informatie of een betaalservice, zijn voorbeelden van business services.


De proces services bieden een combinatie (assemblage) van meerdere services als één geheel aan. Een voorbeeld op basis van de twee eerder genoemde services is de service ‘geefBommenkaartopGemeente in RD’ als de coördinaten bijvoorbeeld in WGS84 zijn geregistreerd.

Voor elk van de type services en voor de proces services in het bijzonder, geldt dat het eigenaarschap van de service en geleverde informatie eenduidig moet zijn vastgelegd.


Web services

De Web Services architectuur wordt met de dag complexer. Er worden steeds nieuwe specificaties gerealiseerd die specifieke deelgebieden van web services invullen. Voor het algemene begrip van web services is de initiële opzet, zoals beschreven in het W3C web services architectuur document meer dan voldoende. In dit document worden onderstaande drie functies benoemd:

  • uitwisselen van berichten;
  • beschrijven van diensten en berichten;
  • publiceren en vinden van beschreven Web Services.


Voor het invullen van deze drie functies zijn technische standaarden (WSDL, SOAP en UDDI) ontwikkelt die hieronder uitgewerkt worden.

De componenten binnen de architectuur van Web Services bevatten, naast de genoemde onderdelen, ook aspecten op het gebied van beheer en beveiliging van de diensten. De Web Services specificaties die betrouwbaar berichtenverkeer regelen – met belangrijke faciliteiten als 'gegarandeerde aankomst van berichten' - zijn in ontwikkeling. Het gaat hierbij om een samenhangend geheel van een aantal specificaties. In de (SOA) praktijk is daardoor ook een tweedeling te zien in technologie families. Voor berichtenverkeer wordt veelal de ebXML familie van standaarden wordt verkozen.

De interactie van en met services (zie onderstaand figuur) binnen een Web Services omgeving gebruikt de genoemde architectuurcomponenten en standaarden. UDDI is de technische standaard die een register biedt voor het registreren en zoeken van services. De [(WSDL standaard wordt gebruikt om de Web Services te definiëren en vast te leggen. De SOAP laag wordt gebruikt als communicatie standaardisatielaag.


Architectuur componenten web services.PNG


WSDL

Het gebruik van diensten door anderen en dus ook het gebruik van Web Services valt of staat met de link tussen vraag en aanbod. Net als in het normale zakendoen geldt ook hier: het vinden van een afnemer voor je aangeboden diensten of producten. Binnen het speelveld van Web Services wordt de basis hiervoor gevormd door Web Services Definition Language (WSDL). Dit is de taal waarmee de aangeboden service kan worden beschreven. Deze beschrijving bevat zowel technische, functionele als businessgerichte informatie. De huidige vorm van WSDL richt zich overigens voornamelijk op het technische en functionele vlak. WSDL biedt nog niet de mogelijkheid om een specifieke webservice aan te prijzen en duidelijk te positioneren voor een doelgroep als een soort reclame voor de dienst.

WSDL maakt gebruik van XML om de berichten die worden uitgewisseld tussen de biedende en vragende partij te beschrijven. De berichten zelf worden vervolgens gekoppeld aan een netwerkprotocol en berichtformaat. De WSDL structuur laat zich het best omschrijven als een set componenten die elk een deel van de Web Services laag beschrijven en gezamenlijk een volledige definitie vormen. De berichtdefinities gaan niet verder dan het beschrijven van de parameters en het resultaat dat een bepaalde functie nodig heeft of levert. Elk bericht heeft een naam waarmee het uniek kan worden geïdentificeerd binnen de WSDL.

De beschreven lagen zijn:

  • Berichten - Individuele berichtendefinities gekenmerkt door een naam en parameter of resultaten die het bericht verwacht of levert.
  • Port types - Het samenvoegen van de individuele berichten definities tot een functie die bestaat uit een input en outputbericht.
  • Type definities - Bieden de mogelijkheid om specifieke extern gedefinieerde datatypes toe te voegen aan de WSDL definitie.
  • Element beschrijvingen - Bieden de mogelijkheid om specifieke externe structuren toe te voegen aan de WSDL definitie. Een WSDL kan door het importeren van externe XML schema definities modulair worden opgebouwd.
  • Bindingen - Beschrijft de concrete koppeling van een port type en de hieraan gekoppelde functies aan een specifiek berichtformaat en transmissie protocol.
  • Services - Beschrijft welke port types een service levert en hoe deze dienst communicatietechnisch wordt aangeboden.


SOAP

Simple Object Access Protocol (SOAP) is ontwikkeld om het uitwisselen van informatie in gedistribueerde omgevingen te standaardiseren en te vereenvoudigen. SOAP is daarmee goed vergelijkbaar met de reeds aanwezige componentstandaarden als Component Object Model (COM) en CORBA. Het is echter een protocol dat XML gebruikt om het berichtformaat te beschrijven. Daarnaast maakt het gebruik van HTTP, het standaard Internet communicatie protocol, om de berichten tussen systemen te versturen.


SOAP is in eerste instantie ontwikkeld door Microsoft om data-uitwisseling via de internetstandaarden mogelijk te maken. De bedoeling was om een nieuwe, open en op XML gebaseerde standaard te ontwikkelen en zo het bestaande, proprietary DCOM te verlaten. Na aanvankelijke scepsis vanwege de vermoede Microsoft marketinggedachte achter SOAP is op een gegeven moment ook IBM achter de standaard gaan staan. Beide bedrijven, met daarbij nog enkele anderen, hebben vervolgens de SOAP specificatie ter standaardisatie aangeboden aan het Worls Wide Web Consortium (W3C).


SOAP is een RPC-achtig (Remote Procedure Call) mechanisme: er wordt een vraag gesteld en er volgt direct een antwoord, waarna de verbinding verbroken wordt. SOAP biedt daarmee toegang tot een functieop een standaardmanier en kan dan ook het beste worden gezien als een schil die rond een ontwikkelde functie wordt aangebracht. De implementatie van de functie, ofwel de code, zorgt dat de aangeroepen service doet wat hij moet doen. Zo’n functie kan zowel een nieuwe als bestaande functie zijn. Ook legacy systemen die voorzien zijn van een wrapper kunnen dus met SOAP berichten worden aangesproken. De informatie die nodig is om de functie aan te roepen en het resultaat dat terugkomt van de functie wordt in een XML structuur geplaatst, het zogenaamde SOAP-bericht. De SOAP schil is generiek en kan worden gebruikt om alle types van componenten op elkaar aan te sluiten.


De structuur van SOAP
Communicatie gebaseerd op SOAP is goed vergelijkbaar met het normale briefverkeer. Een brief wordt opgesteld. Er is een envelop, waar het adres van de bestemming op staat. In de envelop zit de brief waarvan de kop de exacte bestemming aangeeft, noemt voor wie de brief bestemd is en die de datum en aanhef bevat. De rest van de brief is de boodschap die moet worden overgebracht. Deze drie onderdelen komen ook terug in een SOAP bericht.

  • De enveloppe is het buitenste gedeelte van het bericht waarmee de bestemming wordt aangegeven. De envelop moet aanwezig zijn.
  • De kop kan aanwezig zijn en wordt gebruikt om verdere routering bij de bestemming aan te geven
  • De body bevat het feitelijke bericht en moet aanwezig zijn. De body wordt gebruikt om de eventueel opgetreden fouten te vermelden, als het om een antwoord gaat.


Service registers

Om hergebruik binnen een servicegerichte architectuur context mogelijk te maken, of beter te stimuleren, is het noodzakelijk dat de aangeboden diensten op eenvoudige wijze geregistreerd en gevonden kunnen worden. Hiervoor wordt gebruik gemaakt van zogenaamde service registers: dit is een digitale gouden gids. Binnen de geografische wereld wordt voornamelijk gebruik gemaakt van een eigen door OGC ontwikkelde interface, CSW, terwijl in de servicegerichte architectuur en Web Services omgeving gebruik gemaakt wordt van UDDI of ebRIM (dat in een CSW applicatieprofiel ook ondersteund wordt).


Feitelijk maakt het niet uit welk type register gebruikt wordt. Het is zelfs mogelijk een register op basis van een standaard filesysteem op te zetten, te laten indexeren en beschikbaar te maken door een zoekmachine, zoals Google. Het gaat om de functionaliteit die de registers moeten bieden. Het is echter belangrijker tot een eenduidige omschrijving van een service te komen, los van een technische invulling zoals een register.


Een voorbeeld: iemand biedt een service aan waarmee je koffie kan bestellen. Als er niet meer dan deze informatie wordt verstrekt over de service, dan kan dit tot verassende resultaten leiden. Iemand die denkt een kop koffie te bestellen kan een complete bootlading koffie geleverd krijgen.


Als de service eenduidig beschreven is in de juiste context, dan maakt het zoek en selectiemechanisme niet meer uit. Zo ontstaat de mogelijkheid om bijvoorbeeld klein te beginnen met een website met HTML pagina’s die services beschrijven en in een latere fase de servicebeschrijvingen in een register onder te brengen.


BPEL

Web services wordt gezien als de technische standaard om de servicegerichte architectuur services te realiseren. Web services is een open standaard die vanuit elke Software ontwikkelomgeving en techniek gemaakt en toegepast kan worden. Het maakt daarbij niet uit of het een Microsoft, SAP, Cobol of Java omgeving betreft. Een interessante uitbreiding op Web services is de toevoeging van een specifiek gedeelte om processen te definiëren, modelleren en managen.


Deze toevoeging Business Process Execution Language (BPEL) definieert een standaard taal om processen te modelleren. Dit wordtook wel orkestreren genoemd. Leveranciers van workflow- en BPM-oplossingen leveren applicaties die deze BPEL taal interpreteren en de gemodelleerde processen uitvoeren. Hierdoor wordt het mogelijk processen te modelleren en uit te wisselen met relaties, los van de eis van specifieke Software installaties.
Een BPEL proces is opgebouwd uit één of meerdere services, en is daarnaast zelf ook aanroepbaar als een service.



previous Services Oriented Architecture (SOA) next