Een veelvoorkomende en een beetje ergerlijke vergissing is dat mensen die het over Service-Oriented Architecture (SOA) hebben al snel overwippen naar het onderwerp web services. Zo’n beetje alsof SOA gelijkstaat aan web services.
Wat minder technisch aangelegde deelnemers aan de conversatie raken daar de draad al kwijt, zeker als weinigzeggende acroniemen als SOAP en WSDL in het gesprek belanden. En als deze afkortingen er eenmaal inzitten, krijgen we te maken met UDDI, WS-AtomicTransaction, WS-BusinessActivity, WS-Policy, WS-ReliableMessaging. En daarmee zijn we er nog niet. Er zijn zoveel standaarden, en rondom die standaarden weer allerlei details, dat ze nu kortweg bekend staan als WS-*. Waar het sterretje, net als bij MS-DOS uit het begin van de jaren negentig, staat voor ‘vult u zelf maar in.’ SOA heeft niets van doen met Web Services: SOA is bedoeld om uw applicatie naar een hoger niveau te tillen, zodanig dat de organisatie zonder investeringsverlies nieuwe functionaliteit kan invoeren.
Maar achter die gordijnen blijft een deel van de oplossing binnen de SOA nog steeds connectiviteit. Ik wil om het niet te ingewikkeld te maken twee mogelijkheden behandelen: de verbinding is real-time (synchroon) of per event (asynchroon). Ik geef een voorbeeld: in een ‘real-time-situatie’ koopt u online uw nieuwe MP3-speler en krijgt op het moment van de order meteen de prijs en de beschikbaarheid te zien. In de ‘per event-situatie wordt uw order automatisch doorgestuurd naar de pakketdienst. De pakketdienst controleert niet op nieuwe orders, het bestelsysteem publiceert de order als het ware naar de pakketdienst.
Het zo veel mogelijk ondersteunen van het ‘per event’-model is wenselijk, omdat daarmee meer flexibiliteit en schaalbaarheid tussen de softwarecomponenten wordt bereikt. Niettemin zijn er ook gevallen waar het real-time-model wenselijk is, zoals in het bovenbeschreven voorbeeld.
Sinds de komst van SOA is de enige technologie voor het real-time-model die van Web Services, met (daar gaan we) SOAP en WSDL. Wat is SOAP? Het is een technologie om het te ontvangen of te versturen bericht als het ware van een envelop te voorzien. En wat is WSDL? WSDL definieert de structuur van het bericht. U stuurt een brief naar een vriend. De envelop waarin de je brief steekt is SOAP en de structuur van de tekst van de brief is WSDL.
Web Services zijn geen succes geworden. Anderen zeggen, het is een mislukking. En waarom? Omdat Web Services te complex zijn. Het was een hype zonder enige volwassenheid te hebben bereikt en zonder een echte standaard te zijn geworden. Dat was het gevolg van voortgaande discussies die meer het eigen belang dienden dan het belang van openheid en standaardisatie.
Maar hebben we dan een alternatief? Ja, dat is er: REST gebaseerde diensten (Representational State Transfer) bieden de kans om op eenvoudige wijze de real-time-uitvoering van connectivity te realiseren. Hoewel het acroniem misschien lastig is, gebruikt REST het World Wide Web (WWW) dat iedereen kent om toegang te krijgen tot informatie. In plaats van de data in enveloppen te stoppen en heksentoeren te moeten uithalen om de gegevens te bereiken, doet REST dat met een URL. Opnieuw een voorbeeld: uw bedrijf wil een MP3 catalogus uitbrengen. Toegang tot die catalogus krijg je via de browser: http://myco/catalog/mp3. Als je op zoek bent naar een specifieke MP3 en diens prijs, zou de link er zo uit kunnen zien: http://myco/catalog/mp3/price/modelXYZ. REST kan uit de voeten met verschillende formaten zoals XML, HTML, net zoals het web dat tegenwoordig kan.
Het feit dat REST gebruik maakt van de eigenschappen die het World Wide Web succesvol hebben gemaakt en de wetenschap dat die technologie beschikbaar is, makkelijk en open voor iedereen, is het zeker een model om in overweging te nemen wanneer het aankomt op real-time connectiviteit
Massimo, hoe gaat REST om met asynchrone communicatie?
In een asynchrone communicatie, blijft het concept hetzelfde alleen de implementatie is wel verschillende. Bijvoorbeeld, als je orders wilt publiceren naar pakketdienst, dan is het van belang om de orgin aan te geven, zoals ://ordersystem/POST/Order/XYZ. Protocol en transport zouden ook met JMS met content type in XML geimplementeerd kunnen worden. Als je naar OAGIS kijkt, worden Orders als ://ordersystem/synch/Order/XYZ. Synch is dan het werkwoord in de OAGIS taal.
Ik ga niet mee in de veronderstelling dat webservices een voorbije hype is, ik zie webservices nog in opkomst. Wel mee eens dat de open standaarden uit WS-* behoorlijk complex zijn, maar zaken als bijvoorbeeld security, reliability en transactions zijn ook complex.
Daar wil je je niet in verdiepen en daarom moeten de leveranciers van ontwikkeltools hiervoor de componenten en frameworks leveren die je deze technisch complexe details uit handen nemen. Microsoft bijvoorbeeld implementeert inmiddels een deel van WS-* in het WCF framework.
REST is heel geschikt als het gaat om publieke diensten als de genoemde webwinkels. In private situaties zijn veiligheid en betrouwbaarheid van cruciaal belang, een bank wil bijvoorbeeld dat een overboeking exact eenmaal plaatsvindt en dat er onderweg niet geknoeid kan worden met de opdracht. Hier zijn open standaarden als WS-* onmisbaar.
REST is niet de heilige graal al geloven de Restafarians van wel. Wat ‘de BEST’ is is een keuze, die laat je afhangen van wat je wil bereiken.
Wat ik mis bij rest is: hoe weet ik wat ik terug ga krijgen (het contract). Voor SOAP is dit WSDL voor rest krijg ik het gevoel dat het meer van trial-and-error wordt (tenzij je WSDL2 met REST bindings gebruikt maar dan kun je net zo goed SOAP gaan doen).