De risico’s van webservices

donderdag 26 mei 2016

“Het testen van interfaces wordt een stuk eenvoudiger nu wij een ESB (Enterprise Service Bus) met webservices krijgen. Alle services worden loosely coupled door middel van onze SOA (Software Oriented Architecture). Inkomende berichten zullen door de XSD (XML Schema Definition) gevalideerd worden, zodat er geen foutieve data in ons systeem komt. Point-to-point interfaces zijn voorgoed verleden tijd. En je hebt alleen maar de wizdel (WSDL) nodig om het te kunnen testen.”

Met open mond zat ik te luisteren toen dit bij mijn eerste kennismaking met webservices werd verteld. Kon het zo eenvoudig zijn? Al snel wist ik beter. Webservices, hoe innovatief ook, brengen risico’s met zich mee. Hierover vertel ik je meer in deze blog.

Complex landschap

In de echte wereld is het landschap van webservices complex. Een webservice kan data tegelijkertijd ophalen uit meerdere systemen en dit samenvoegen tot een bericht. Ook kan het verstuurde bericht meerdere webservices passeren waarbij de data in het bericht wordt aangepast voordat het uiteindelijk aankomt bij het doelsysteem. Je moet dus goed nadenken over de te volgen teststrategie:

  • Welke risico’s moet ik afdekken?
  • Hoe ga ik deze risico’s afdekken?
  • Zijn alle ketens die ik moet testen beschikbaar of heb ik stubs of drivers nodig?
  • Welke tools kan ik gebruiken bij het testen?

Note: Over het 'hoe een webservice te testen' zal mijn volgende blog uitgebreider op in gaan.

Non-functionals

De af te dekken risico’s met betrekking tot de non-functionals, zoals performance, onderhoudbaarheid en betrouwbaarheid, verdienen extra aandacht tijdens het opzetten van je teststrategie. Deze worden vaak vergeten omdat de business vooral in functionaliteit denkt. Als er bijvoorbeeld via een webservice door een derde partij patiëntengegevens worden opgevraagd, wil je dat niemand anders toegang heeft tot deze data.

Het IPS-model (Informatie-, Proces- en Softwarekwaliteit) helpt je controleren of alle risico’s met betrekking tot de non-functionals zijn afgedekt. Veel voorkomende non-functionals voor webservices zijn:

  • Beveiligbaarheid: zijn de webservice en de berichten van buitenaf toegankelijk?
  • Tijdsbeslag: kan de webservice te allen tijden binnen één seconde antwoord geven?
  • Middelenbeslag: zijn er voldoende resources (bijvoorbeeld geheugen) beschikbaar indien de webservice 1000 keer per minuut wordt aangeroepen?
  • Traceerbaarheid: zijn de herkomst van het bericht en de verwerking van het bericht herleidbaar?
  • Herstelbaarheid: kunnen de berichten opnieuw aangeboden worden als er storingen zijn?
  • Foutbestendigheid: blijft de webservice functioneren als verkeerde berichten binnen komen of het doelsysteem niet beschikbaar is?

Miscommunicatie

Non-functionals worden vaak vergeten door miscommunicatie tussen de betrokken partijen. Daarom is het belangrijk dat de bouwteams van de bronsystemen, doelsystemen en de webservices expliciete afspraken maken over:

  • Welke gegevens moeten worden doorgestuurd?
  • Welke waardes mogen deze gegevens bevatten?
  • Wat is de reden dat deze gegevens worden doorgestuurd?
  • Hoe worden de gegevens getransformeerd naar andere waardes?
  • Hoe worden de gegevens opgesplitst naar verschillende berichten?
  • Wat moet er gebeuren als een bericht wordt afgekeurd omdat het niet voldoet aan de afgesproken standaard?

Laatste tip

Wees betrokken en sluit aan bij de afstemming of neem het initiatief om zo’n vergadering te organiseren. Controleer of de verschillende bouwteams elkaar echt begrijpen. Werk je in een Agile omgeving, dan is de refinement een goed moment om elkaar scherp te houden en kritisch te zijn. Nu je inzichtelijk hebt welke risico’s je wilt gaan afdekken, kan je gaan bedenken hoe je je teststrategie gaat inrichten. In mijn volgende blog ga ik hier uitgebreider op in.