Difference between revisions of "3.3.3 SOA Services"

From Geonovum Wiki
Jump to: navigation, search
(Typering van services)
(BPEL)
 
(4 intermediate revisions by the same user not shown)
Line 22: Line 22:
 
== Web services ==
 
== Web services ==
  
De Web Services architectuur wordt met de dag complexer, waarbij continue nieuwe specificaties gerealiseerd worden die specifieke deelgebieden van web services invullen. Voor het algemene begrip van web services is de initiële opzet, zoals beschreven in het [http://www.w3.org/TR/ws-arch/ W3C web services architectuur document] meer dan voldoende. In dit document worden onderstaande drie functies benoemd:  
+
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 [http://www.w3.org/TR/ws-arch/ W3C web services architectuur document] meer dan voldoende. In dit document worden onderstaande drie functies benoemd:  
  
*Uitwisselen van berichten  
+
*uitwisselen van berichten;
*Beschrijven van diensten en berichten  
+
*beschrijven van diensten en berichten;
*Publiceren en het vinden van beschreven Web Services.
+
*publiceren en vinden van beschreven Web Services.
  
 
<br>Voor het invullen van deze drie functies zijn technische standaarden (WSDL, SOAP en UDDI) ontwikkelt die hieronder uitgewerkt worden.  
 
<br>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 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 waarbij voor berichtenverkeer veelal de [http://www.ebxml.org/geninfo.htm ebXML] familie van standaarden wordt verkozen.  
+
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 [http://www.ebxml.org/geninfo.htm ebXML] familie van standaarden wordt verkozen.  
  
De interactie van en met services (zie onderstaand figuur) binnen een Web Services omgeving maakt gebruik van de genoemde architectuurcomponenten en standaarden. [http://www.uddi.org/pubs/uddi_v3.htm UDDI] is de technische standaard die een register biedt voor het registreren en zoeken van services. De [([http://www.w3.org/TR/wsdl WSDL] standaard wordt gebruikt om de Web Services te definiëren en vast te leggen. De [http://www.w3.org/TR/soap/ SOAP] laag wordt gebruikt als communicatie standaardisatielaag.
+
De interactie van en met services (zie onderstaand figuur) binnen een Web Services omgeving gebruikt de genoemde architectuurcomponenten en standaarden. [http://www.uddi.org/pubs/uddi_v3.htm UDDI] is de technische standaard die een register biedt voor het registreren en zoeken van services. De [([http://www.w3.org/TR/wsdl WSDL] standaard wordt gebruikt om de Web Services te definiëren en vast te leggen. De [http://www.w3.org/TR/soap/ SOAP] laag wordt gebruikt als communicatie standaardisatielaag.
 
   
 
   
 
<br>
 
<br>
Line 41: Line 41:
 
== <br>WSDL  ==
 
== <br>WSDL  ==
  
Het gebruik van diensten door anderen en dus ook het gebruik van Web Services valt of staat met het in contact brengen van vraag en aanbod. Hier geldt net als in het normale zakendoen; het vinden van een afnemer voor je aangeboden diensten of producten. Binnen het Web Services speelveld wordt hiervoor de basis gevormd door Web Services Definition Language (WSDL), de taal waarmee de aangeboden service kan worden beschreven. Deze beschrijving bevat zowel technische, functionele alsook de businessgerichte informatie. De huidige vorm van WSDL richt zich overigens voornamelijk op het technische en functionele vlak. Het aanprijzen en duidelijk positioneren richting een doelgroep van een specifieke Web Service als een soort reclame voor de dienst, daar wordt nog niet in voorzien door 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.
 
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.
Line 48: Line 48:
  
 
*<u>Berichten</u> - Individuele berichtendefinities gekenmerkt door een naam en parameter of resultaten die het bericht verwacht of levert.  
 
*<u>Berichten</u> - Individuele berichtendefinities gekenmerkt door een naam en parameter of resultaten die het bericht verwacht of levert.  
*<u>Port types</u> - Het samenvoegen van de individuele berichten definities tot een functie bestaand uit een input en outputbericht.  
+
*<u>Port types</u> - Het samenvoegen van de individuele berichten definities tot een functie die bestaat uit een input en outputbericht.  
*<u>Type definities</u> - Biedt de mogelijkheid om specifieke extern gedefinieerde datatypes toe te voegen aan de WSDL definitie.  
+
*<u>Type definities</u> - Bieden de mogelijkheid om specifieke extern gedefinieerde datatypes toe te voegen aan de WSDL definitie.  
*<u>Element beschrijvingen</u> - Biedt de mogelijkheid om specifieke externe structuren toe te voegen aan de WSDL definitie. Hierdoor kan een WSDL door het importeren van externe XML schema definities modulair worden opgebouwd.  
+
*<u>Element beschrijvingen</u> - 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.  
 
*<u>Bindingen</u> - Beschrijft de concrete koppeling van een port type en de hieraan gekoppelde functies aan een specifiek berichtformaat en transmissie protocol.  
 
*<u>Bindingen</u> - Beschrijft de concrete koppeling van een port type en de hieraan gekoppelde functies aan een specifiek berichtformaat en transmissie protocol.  
 
*<u>Services</u> - Beschrijft welke port types een service levert en hoe deze dienst communicatietechnisch wordt aangeboden.
 
*<u>Services</u> - Beschrijft welke port types een service levert en hoe deze dienst communicatietechnisch wordt aangeboden.
Line 59: Line 59:
  
 
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.  
 
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.  
<br>SOAP is in eerste instantie ontwikkeld door Microsoft om data-uitwisseling via de internetstandaards 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 aangeboden aan het World [http://www.w3.org/ Wide Web Consortium (W3C)] ter standaardisatie.
 
  
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 op een standaard manier toegang tot een functie. Het kan dan ook het best 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 van zijn 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. <br>
+
<br>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 [http://www.w3.org/ Worls Wide Web Consortium (W3C)].
 +
 
 +
<br>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. <br>
  
 
<br>  
 
<br>  
  
 
'''De structuur van SOAP'''
 
'''De structuur van SOAP'''
<br>Communicatie gebaseerd op SOAP is goed vergelijkbaar met het normale briefverkeer waarbij 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:
+
<br>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 envelope is het buitenste gedeelte van het bericht waarmee de bestemming wordt aangegeven. De envelop moet aanwezig zijn.  
+
*De enveloppe is het buitenste gedeelte van het bericht waarmee de bestemming wordt aangegeven. De envelop moet aanwezig zijn.  
*De header kan aanwezig zijn en wordt gebruikt om verdere routering bij de bestemming aan te geven  
+
*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 bij een antwoord de eventueel opgetreden fouten te vermelden.
+
*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.
  
 
<br>
 
<br>
Line 76: Line 77:
 
== Service registers  ==
 
== Service registers  ==
  
Om binnen een servicegerichte architectuur context hergebruik mogelijk te maken, of beter te stimuleren, is het noodzakelijk dat op eenvoudige wijze de aangeboden diensten geregistreerd en gevonden moeten kunnen worden. Hiervoor wordt gebruik gemaakt van zogenaamde service registers; een digitale gouden gids. Binnen de geografische wereld wordt voornamelijk gebruik gemaakt van een eigen ontwikkelde interface door OGC, [http://www.opengeospatial.org/standards/cat 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).
+
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, [http://www.opengeospatial.org/standards/cat 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).
  
 
<br>
 
<br>
  
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 wat de functionaliteit is die de registers moeten bieden, maar belangrijker is om los van een technische invulling als een register tot een eenduidige omschrijving van een service te komen.  
+
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.  
<br>Neem als voorbeeld iemand die een service aanbiedt waarmee men 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 met koffie geleverd krijgen.  
+
 
 +
<br>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.  
 +
 
 
<br>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.  
 
<br>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.  
  
Line 88: Line 91:
 
== BPEL  ==
 
== 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, onafhankelijk 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.  
+
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.  
<br>Deze toevoeging [http://www.bpelsource.com/ Business Process Execution Language (BPEL)] definieert een standaard taal om processen te modelleren, wat ook wel orkestreren genoemd wordt. Leveranciers van workflow- en BPM-oplossingen leveren applicaties die deze BPEL taal interpreteert en de gemodelleerde processen uitvoert. Hierdoor wordt het mogelijk processen te modelleren en uit te wisselen met relaties, los van de eis van specifieke Software installaties.  
+
 
 +
<br>Deze toevoeging [http://www.bpelsource.com/ 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.  
 
<br>Een BPEL proces is opgebouwd uit één of meerdere services, en is daarnaast zelf ook aanroepbaar als een service.
 
<br>Een BPEL proces is opgebouwd uit één of meerdere services, en is daarnaast zelf ook aanroepbaar als een service.
  

Latest revision as of 10:21, 4 January 2010


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