Hoe, leggen we hier uit

Ben je zover gekomen met het lezen van deze XML pagina, dan zla je ongetwijfeld ook geïntereseerd zijn in wat kritische opmerkingen rondom SOAP. Hoewel in een omgeving als .Net het gebruik van SOAP geheel automatisch gaat, kan het nooit kwaad iets te weten van de problemen onder de moterkap.

SOAP is ook een soort mini-hype geweest, bij een hype schrijven mensen dingen van elkaar over, en als maar genoeg mensen iets beweren, gaat iedereen het geloven. Iets dergelijks is ook met SOAP gebeurt. Zoals, SOAP is simpel, stateless, protocolonafhankelijk en ideaal geschikt voor Remote Procedure Calls. Sommige van deze beweringen zijn gewoon onjuist, andere zijn juist het zwakke punt van SOAP.
Wat zijn de problemen  bij het gebruik van SOAP?

SOAP is niet Simpel en is niet Object georiënteerd
Je moet je er allereerst van bewust zijn dat SOAP een heel misleidende naam heeft. SOAP betekent "Simple Object Access Protocol". En in tegenstelling tot wat je zou verwachten  is SOAP  niet simpel, en doet niets met Objecten, en doet ook niet aan Object Access. Alleen de P van Protocol klopt, maar dan helaas is dit de P van een nog niet goed genoeg gestandaardiseerd protocol.

Met een stateless Protocol als SOAP kan je niet zoveel
Stateless houdt in dat je elke keer alle informatie moet sturen, aan de andere kant houdt de Server niet bij wat er gebeurt. Een stateless protocol is heel goed bruikbaar om de krant op Internet te lezen, en ook bij het lezen van deze tekst maak je gebruik van stateless protocollen.
SOAP wordt echter altijd gepositioneerd voor e-commerce, e-business en al deze situaties worden gekenmerkt door een complexe interactie. En hiervoor heb je een statefull protocol nodig.   Aan SOAP heb je daarom niet genoeg.  Elke Web Services is daarom gedwongen om SOAP heen zijn eigen methode programmeren. De state moet bewaard worden tussen twee SOAP boodschappen in.Gebruikers van .Net hoeven zich overigens geen zorgen te maken, Microsoft regelt dit allemaal binnen het .Net framework.  En je raadt het al: dat is niet gestandaardiseerd, en daarom zijn Web Services niet gestandaardiseerd.
Wij lossen dit probleem heel eenvoudig op. Als we Web Services gebruiken tussen twee computers, zorgen we ervoor dat op beide computers een .Net applicatie draait.

SOAP is onveilig.
Het is erg prettig dat SOAP elke firewall passeert, en gewoon via poort 80 binnendringt. Maar doordat SOAP op XML is gebaseerd, vereist dit enorme zorgvuldigheid. De standaard implementaties van XML hebben allerlei enge mogelijkheden, zoals de XML bom. Een XML file die na parsing zichzelf eindeloos herhaalt, zich steeds groter maakt, en uiteindelijk het systeem opblaast. Ook XPATH statements kunnen leiden tot bufferoverflow, waarmee onverlaten zich toegang kunnen verwerven tot interne zwaar beveiligde servers.
Bij Lizatec gebruiken wij om deze reden onze eigen implementatie van SOAP, gebaseerd op onze SimpleXML component. Deze component  is gestript van alle code die XML en SOAP inherent onveilig maakt.

SOAP is niet protocol onafhankelijk
Veel publicaties noemen als kracht van SOAP ook dat het protocol onafhankelijk is. Maar SOAP is afhankelijk van MIME, en is helemaal gebouwd op basis HTTP. Het is moeilijk voor te stellen hoe je ooit een SOAP protocol kan maken rondom bijvoorbeeld SMTP (e-mail). 
Wij spreken hier uit ervaring, wij hebben geprobeerd om een e-mail SOAP te maken, wij zijn een eind gekomen. Maar halverwege hebben we geconstateerd dat het niet mogelijk is. En wij kennen ook geen enkele SOAP implementatie op basis van SMTP.

SOAP with Extensions
Bij grotere bestanden is XML en daarmee SOAP niet zonder meer bruikbaar: de processor op de Server is teveel tijd kwijt met het telkens inpakken van het bestand in XML.
De oplossing is SOAP met extensions: alleen de verwijzing naar het bestand zit in de XML envelope, en het bestand zelf wordt gewoon via HTTP of HTTPS overgezet.  
Dit moet je doen als het aantal gelijktijdige gebruikers vermenigvuldigd met de grootte van het bestand groter is dan 100Kb.
Dit is een voorbeeld van één van de vele performance problemen bij gebruik van XML.

SOAP en Remote Procedure Calls
Als je  de Interface tussen Server en Web Client als een API definieert, moet je gebruik maken van Remote Procedure Calls (RPC), en dan ligt het voor de hand om SOAP te gebruiken. Wij denken zelf dat je RPC's moet vermijden als de pest (Worst practice), het zorgt voor te onveilige en te van elkaar afhankelijke interfaces. Maar het kan wel, en als je het doet maak dan gebruik van SOAP.

In alle andere situaties kan je makkelijker rechtstreeks met XML en HTTP werken.  IBM is daar van een voorstander, zie bijvoorbeeld uit IBM developer Works: Use XML directly over HTTP for Web services (where appropriate)

We gaan nu een zijstapje maken, namelijk naar XBRL, een variant van XML. Dit is instructief, want je kan hierbij weer zien dat de overheid weer jaren achterloopt op het bedrijfsleven. Het soort standaardisatie die binnen grote bedrijven allang is opgegeven, probeert de overheid nu voor heel Nederland door te voeren.