Bright Answers

Bright Answers biedt branchespecifieke ICT oplossingen en maatwerk aangepast op jouw bedrijfsvoering. Wij helpen bedrijven op het gebied van:

Vijf punten die je moet weten om webservices te begrijpen

Dit artikel is gepubliceerd op: 15-09-2015

[Laatste update: 13-01-2017] Het razendsnel opzoeken van wisselende aandelenkoersen, op een efficiënte manier online het perfecte cadeau vinden of het ontwikkelen van de allernieuwste applicaties? Voor al deze handelingen wordt dagelijks gebruik gemaakt van webservices. Maar wat zijn deze webservices precies en hoe worden ze gebruikt?

1. Communicatie van cliënt naar server


De officiële definitie van een webservice is: een softwaresysteem ontworpen om interoperabele 'machine-to-machine' interactie te ondersteunen via een netwerk. Het zijn de middelen waarmee apparaten en applicaties communiceren via het wereldwijde web.

Een softwareapplicatie bestaat uit een databaselaag en een business logica laag. De business logica laag zorgt ervoor dat als we data invoeren via de schermen dat dit dan op de juiste manier gebeurd. Bijvoorbeeld als je de leeftijd van een medewerker aanpast omdat deze verkeerd was ingevoerd worden er checks uitgevoerd of dit gevolgen heeft voor vakantiedagen, pensioenpremie etcetera.

Je kan dus niet zomaar een dataveld in de database aanpassen zonder de businesslogica laag te passeren. Voor applicaties die open gesteld worden aan de buitenwereld worden eigenlijk kleine stukjes functionaliteit beschikbaar gesteld middels webservices.

Een webservice zorgt ervoor dat data volgens de regels van de applicatie wordt opgehaald of ingevoerd. Of het nu gaat om een mobiele applicatie, een zoekmachine of een Enterprise Resource Planning (ERP) systeem, het cliënt-gedeelte van de applicatie is zichtbaar op een device, maar de gegevens en de business rules staan ergens op het netwerk. De manier waarop het cliënt-gedeelte communiceert met het servergedeelte, dat is de rol van webservices.

Om deze twee werelden met elkaar te kunnen laten communiceren, moet er een overeenkomst zijn tussen het format en de structuur. De ene kant moet begrijpen wat je wil en de andere kant moet begrijpen wat je nodig hebt, om dat vervolgens te kunnen versturen, zodat iedereen tevreden is. Dat is waarop Appbuilder gestoeld is. De AppBuilder begrijpt verschillende formaten webservices en genereert op basis hiervan webapplicaties.

2. De taal van webservices


"Om überhaupt te kunnen communiceren moet je een gemeenschappelijke taal spreken. De meeste systemen zijn geschreven in Web Service Description Language (bron: W3schools), kortweg WSDL (spreek uit als wizdel)."

WSDL zet de binnenkomende informatie, zoals vragen, op voor de service-applicatie en structureert de uitgaande gegevens zodat de vragende-applicatie het begrijpt.

Extensible Markup Language (XML) slaat die structuren op. XML is een formele opmaaktaal waarmee je gestructureerde gegevens kunt weergeven in de vorm van platte tekst.  Deze manier van gegevens opslaan is leesbaar voor mens en machine. 

Een gemeenschappelijke structuur voor WSDL-informatie is het Simple Object Access Protocol (SOAP), een computerprotocol van regels en afspraken waardoor computers snel met elkaar kunnen communiceren. SOAP is een protocol dat XML-berichten stuurt.

3. Opstapelen van informatie tussen webservices


Nadat duidelijk is welk protocol je gaat gebruiken en wat de datastructuur is tussen de servers, kunnen de webservices onderling informatie uit gaan wisselen. Die informatie moet betrouwbaar zijn en niet te veel servercapaciteit opslurpen.

Bij het zogenaamde State-Model Webservices is de huidige interactie afhankelijk van de voorgaande interacties. De server onthoudt alle keuzes die de gebruiker heeft gemaakt; in welke regio van de wereld bevindt de gebruiker zich, welke type kaart gebruikt hij en welke beelden krijgt hij te zien. Je kunt het State-Model gebruiken als er veel inconsistente informatie beschikbaar is of als de gebruiker meer informatie nodig heeft om tot een nauwkeurige keuze te kunnen komen.Het probleem met dit model is, dat er behoorlijk wat overhead nodig is, om alle interacties te onthouden op de server.

Dit zou je kunnen tegengaan door cookies te gebruiken, wat de belasting van het geheugen van de server beperkt. Of je kunt een specifieke verbinding maken tussen de cliënt en de server, waardoor hij altijd communiceert met dezelfde server. Het gebruik van cookies is onbetrouwbaar, bijvoorbeeld omdat sommige cliënten het gebruik van cookies weigeren, of je moet dan echt kiezen voor een cookiewall. Het gebruik van een specifieke server is wel betrouwbaar, maar slurpt enorm veel servercapaciteit op en zorgt er uiteindelijk voor dat servers moeilijk schaalbaar kunnen worden gemaakt. 

4. Informatie uit het verleden uitschakelen

"Opgeblazen servers en onbetrouwbare informatie is niet wat je wilt en dat hoeft ook niet. Je kunt ook informatie verzenden zonder dat de server de vorige uitwisseling onthoudt."

Het Stateless-Model Webservices communiceert onafhankelijk van de vorige uitwisseling. Ook tussen computers kan dan alle informatie die een aanvraag betreft in één bericht worden verzonden. Van de server naar de cliënt-applicatie of andersom. Deze uitwisselingen kunnen worden uitgevoerd met behulp WSDL of SOAP. Je kunt sinds kort ook gebruik maken van het meest recente architecturale proces: Representation State Transfer (REST) 

5. Het World Wide Web voorbij


Het REST-model is een software architectuur stijl om schaalbare webservices mee te bouwen. Het model is een uitbreiding van de manier waarop het web zelf ook werkt, met dezelfde HTML GET, POST en PUT aanvragen, een REST-ful webservice retourneert de gevraagde informatie met behulp van HTML of XML. Dit stelt ontwikkelaars in staat om webservices direct online te zetten en geen interface te ontwikkelen. Een andere site kan dan de webservice ontvangen en op basis van een interpretatie van deze service kan een ontwikkelaar een interface ontwikkelen.

Met het ontwikkelen via de AppBuilder heb je dit model nu ook niet meer nodig, want dit instrument interpreteert webservices zodat er vanzelf interfaces ontstaan. Lees de webservices in in je eigen App, genereer schermen op basis van de beschikbare webservices en finetune deze naar inzicht met het geintegreerde CMS. 

 

Bent u toe aan een digitaliseringsslag en heeft u daar ondersteuning bij nodig? Wij nodigen u graag uit voor een vrijblijvende kennismaking. 


Andere artikelen over Architectuur

Andere artikelen over Front-end services

Andere artikelen over Apps bouwen


 

Reacties

Er zijn nog geen reacties.

 

Plaats nieuwe reactie

Velden met een gemarkeerd met een * zijn verplicht.
 
 
 
­