Een webservice in 5 minuten

EJB 3.0 en webservice annotations maken het mogelijk om webservices te maken, zonder alle details te kennen van WSDL of binding of wat dan ook. Sterker nog, je kunt in enkele minuten een webservice maken. Het enige dat je nodig hebt is een interface klasse, een implementatie klasse en een paar annotations. Laten we dit eens van dichtbij bekijken met het aloude “Hello World” voorbeeld. Maak een EJB 3.0 project en maak daarin allereerst de interface klasse.

package nl.isaac.ejb.service;

import java.rmi.Remote;

import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style = Style.DOCUMENT)
public interface HelloWorld extends Remote {
String hello(String name);
}

Hierin zie je twee annotations staan. De eerste “@WebService” geeft simpelweg aan dat het om een webservice gaat. De tweede geeft aan welk soort SOAP binding je gebruikt, hierin heb je twee smaken “RPC” en “Document”. In het voorbeeld gebruik ik “Document”, maar in dit geval maakt het niet uit om hier “RPC” van te maken (Het verschil tussen document en RPC is grofweg gezegd dat RPC maar een enkel element als resultaat geeft en document een uitgebreid XML document terug kan geven). In de interface klasse staat verder alleen onze methode gedefinieerd. Let er wel op dat de interface jave.rmi.Remote extend. Nu kunnen we onze implementatie klasse maken.

package nl.isaac.ejb.service;

import javax.ejb.Stateless;
import javax.jws.WebService;

@Stateless
@WebService(endpointInterface = "nl.isaac.ejb.service.HelloWorld")
public class HelloWorldImpl {
public String hello(String name) {
return "Hello " + name;
}
}

Let erop dat, ondanks dat dit de implementatie klasse van een interface is, je deze niet implementeert met de code “implements HelloWorld”. Dit gebeurt in de annotation @WebService, die in deze methode zijn endpoint interface instelt. Deze verwijst naar de interface klasse die we zojuist gemaakt hebben. Onze methode wordt geïmplementeerd en voilá, een webservice is geboren. Deploy je project in JBoss en controleer voordat je een client maakt of je service draait door de WSDL file aan te roepen. Dit kun je doen door de URL van je project in IE in te voeren met daarachter “/HelloWorldImpl?wsdl”, dit zou je een XML document moeten tonen met alle details over de webservice.

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.