SOA in een web 2.0 omgeving

Software ontwikkelaars komen steeds vaker de term SOA of WebServices tegen. Deze twee termen zijn erg vergelijkbaar. SOA is misschien een wat ruimer begrip, maar hierover zijn de meningen verdeeld. Wat vaak niet wordt begrepen is dat SOA een essentieel onderdeel is van de zogeheten web 2.0 hype. Er wordt onder de noemer web 2.0 vaak veel gewerkt met technieken om rijke webapplicaties te ontwikkelen, maar er wordt vaak niet gedacht aan de gegevensbronnen die deze technieken moeten aansturen. Deze gegevensbronnen zijn het kloppend hart van de web 2.0 applicaties. In het komende artikel wordt dit verduidelijkt en wordt een introductie gegeven op SOA en WebServices.

Web 2.0

Het is de IT eigen om vage termen te bedenken. Web 2.0 is daar misschien wel het beste voorbeeld van. Er is niet echt een vaste definitie van web 2.0 te vinden, maar het baseert zich op het idee van bijdrage van gebruikers en het delen van data op het internet. Websites die onder de noemer web 2.0 vallen, zoals wikipedia of flickr, bieden de gebruiker meer dan alleen harde data, ze bieden de gebruiker de mogelijkheid om hun eigen inbreng aan deze data toe te voegen.

SOA

Wanneer men spreekt over web 2.0 wordt de term AJAX vaak gretig aangehaald. AJAX, ofwel Asynchronous Javascript and XML, is bedoeld om van de “ouderwetse” websites, rijke applicaties te maken, door zonder een browser refresh data van de server te halen. De term SOA is daarbij lange tijd ondergesneeuwd geraakt door de vele technieken om schitterende applicaties te maken. Toch is SOA de spil rond web 2.0. SOA staat voor Service Oriënted Architecture en slaat op de gedachte die ook achter web 2.0 staat, het delen van data. Of, iets gedetailleerder, het aanbieden van data in een uniforme wijze. Dit kan op allerlei manieren, denk aan XML, SOAP, kommagescheiden bestanden, dynamic link libraries, etc. Hierdoor kan de data hergebruikt worden en gedeeld worden (met bijvoorbeeld businesspartners, of zelfs de hele wereld). Vanuit een bedrijfsvoeringaspect kan men op deze manier ook dynamischer werken en sneller reageren op wat de concurrent doet. Vooral dit laatste heeft ervoor gezorgd dat de term SOA aan populariteit wint.

De opbouw van een webservice

Bij een service zijn drie partijen gemoeid, de requestor, de provider en de broker. De requestor is de cliënt die gebruik gaat maken van de service. De provider is de partij die de service implementeert en de verzoeken van de cliënt verwerkt. De broker kan worden gezien als een makelaar waarbij de cliënt terecht kan om de juiste service te vinden. In grote settings kan dit middels een UDDI register, maar vaak ontbreekt dit onderdeel.

Een WebService is opgebouwd uit een aantal componenten. Het contract, de implementatie en de interface. In het contract staat beschreven hoe de webservice is opgebouwd, welke techniek gebruikt wordt en hoe de service kan worden aangeroepen. De implementatie is de daadwerkelijke code die de verzoeken van clients verwerkt en beantwoord. De interface wordt door de client gebruikt om verzoeken naar de service te sturen.

Belangrijk bij een webservice is de zogeheten “interoperability”. Dit houdt in dat de implementatie van de provider dusdanig moet zijn dat de cliënt altijd hiervan gebruik kan maken, ongeacht de techniek die hij gebruikt. In de mooiste gevallen volgt men de richtlijnen van het Basic Profile, die het gebruik van SOAP en WSDL voorschrijft, maar vaak worden ook JSON (Javascript object notation) objecten, Dynamic Link Libraries of kale XML gebruikt. In deze gevallen zijn er vaak online API beschrijvingen te vinden over de services.

De mashup

Populair op het internet is de mashup. Een webapplicatie die gebruik maakt van verschillende services en gegevensbronnen en deze mengt tot nieuwe informatie. Denk bijvoorbeeld aan het koppelen van bedrijfsgegevens aan de plattegronden van Google Maps. Vaak worden er op internet mashups gemaakt, simpelweg voor de mashup. Zo is er een site waar men op een plattegrond kan aangeven hoe een bepaalde locatie ruikt, waarop men vervolgens kan zoeken waar op deze planeet het zoal stinkt naar rotte eieren. Maar een mashup kan voor een bedrijf van nut zijn. Door gebruik te maken van vrijelijk beschikbare data op het internet kan het zijn eigen data verreiken, of extra diensten aanbieden op zijn website. Denk bijvoorbeeld aan een persoonlijke routebeschrijving van een bezoekers’ thuis adres naar de dichtstbijzijnde bedrijfsvestiging.


ESB

Laten we om te beginnen een kijkje nemen naar een site die op een bescheiden manier gebruik maakt van een webservice. De site climacount.com bevat onder andere informatie over een aantal CO2 reductie programma’s. Hierbij maakt het gebruik van data die vrij beschikbaar is op internet om een kaart te laten zien van de omgeving waar een programma aan het werk is. Dit is natuurlijk maar een kleine invoeging van externe data en hierbij hoeft verder ook niet nagedacht te worden over de implementatie van externe data in de site, maar stel er worden van meerdere bronnen gegevens opgehaald. Het is dan onwaarschijnlijk dat al die bronnen met dezelfde techniek beschikbaar zijn. Zeker wanneer je gaat denken aan e-banking applicaties, waar nog vaak van zeer ouderwetse technieken gebruik gemaakt wordt zoals COBOL. Dan is het verstandig om na te denken over de architectuur van je applicatie om te voorkomen dat toekomstige wijzigingen het risico met zich meenemen dat de hele applicatie op de schop moet. Hier komt de term ESB, ofwel Enterprise Service Bus, in het verhaal. Het klinkt vreemd maar om het eerder genoemde risico te vermijden maak je een applicatie die niks anders doet dan gegevens van derden beschikbaar maken. Een soort service die de andere services omsluit, zeg maar. Je webapplicatie kan op die manier altijd de zelfde techniek gebruiken om gegevens op te halen bij de ESB en de ESB zorgt voor het aanroepen van de daadwerkelijke service. In de onderstaande illustraties zie je vrij duidelijk het voordeel van het introduceren van een ESB.

Situatie zonder ESB


Situatie met ESB

Nadelen van SOA en Web 2.0

De toevoeging van componenten om de services beschikbaar te maken, de XML lagen die over componenten geplaatst worden en de extra beveiliging die nodig is bij openbare services vereisen allemaal extra processorkracht en dus zwaardere servers.

Conclusie

In dit artikel heb je de basisideeën achter SOA en WebServices in een Web 2.0 setting kunnen lezen. Essentieel hierbij is het beschikbaar stellen van data, het gebruiken van data van derden en het letten op de interoperability van de data. Bij het gebruik van meerdere WebServices kan het gebruik van een ESB de architectuur van je software overzichtelijk houden en eenvoudig bij te werken of uit te breiden. Een nadeel is dat het werken met een SOA denkwijze voor overhead in de software kan zorgen die extra processorkracht vereist en de hardwarekosten kan verhogen.

Heb je zin gekregen om zelf aan de slag te gaan met SOA, maar weet je niet goed waar je moet beginnen, neem dan een kijkje op http://www.programmableweb.com waar een opsomming van allerlei API’s en WebServices te vinden is.