Aan het nut van soap (service oriented architecture protocol) wordt niet meer getwijfeld. Het is een op XML gebaseerd berichtenformaat waarmee (web)services aangeroepen worden. Dit formaat is uitermate geschikt voor het ontwikkelen van service oriented architectures (soa), waarbij applicaties onderling gekoppeld worden. In de markt bestaat ook geen tweestrijd over soap, alle belangrijke leveranciers ondersteunen het. En dat kunnen we van maar weinig technologieën zeggen.
Ondanks deze brede acceptatie bestaat er wel kritiek op soap. De meest gehoorde kritiek heeft te maken met netwerkinefficiëntie. Soap leunt zwaar op XML en XML is nogal breedsprakig. Door het opnemen van vele metagegevens worden deze documenten snel omvangrijk. Netwerkbeheerders hebben nachtmerries waarin hun slanke netwerkkabels er uitzien als slangen die varkens in hun geheel doorslikken. Ze verwachten dat straks hun netwerken met soap-berichten zullen vollopen.
Er is echter een grote kans dat we straks wel denken dat we soap gebruiken, maar dat er helemaal geen soap-berichten verstuurd worden en dat dit probleem dus niet zal optreden. Diverse leveranciers zijn namelijk al bezig optimalisaties te bedenken en te implementeren.
Er wordt bijvoorbeeld gewerkt aan binary XML. Dit betekent dat soap-berichten, voordat ze verstuurd worden, gecomprimeerd worden. De ontvangende partij decomprimeert ze na ontvangst. Dit zal de hoeveelheid bytes die door de kabels suizen en door de lucht vliegen verminderen, maar voor het comprimeren en decomprimeren is wel weer processing nodig. We zullen zien of we hier qua performance netto beter van worden, maar het zal zeker de netwerkbelasting verminderen.
Een integratiebroker als InterSystems Ensemble zoekt de verbetering op een andere wijze. Als dit product documenten verstuurt, worden alleen een soort document-identifiers verstuurd. De ware documenten blijven in een database staan en zijn voor elke partij opvraagbaar. In dit geval worden dus alleen hele kleine pakketjes verstuurd, de identifiers. En die zullen het netwerk echt niet volzetten.
Tijdens het verwerken van bedrijfsprocessen gedefinieerd met Bpel (Business Process Execution Language) zullen de orchestration engines continu services aanroepen. Bij elke aanroep wordt een soap-bericht verstuurd naar de betreffende partij. Tenminste, dat is de achterliggende gedachte. Producten als Oracle Bpel Process Manager optimaliseren dit proces. Als we de Bpel-processen ontwerpen en definiëren denken we in termen van soap en XML. De orchestration engine kan er tijdens de verwerking voor kiezen om bijvoorbeeld via RMI (Remote Method Invocation) een Java-component aan te roepen. Er worden dan helemaal geen soap-berichten verstuurd.
Een Enterprise Service Bus (ESB) als die van PolarLake zorgt ervoor dat alleen de relevante delen van XML-documenten werkelijk verstuurd worden. Dus in plaats van het gehele document wordt er een deel van afgesneden. De applicaties hebben hier echter geen weet van.
Indigo van Microsoft, een ESB-achtig (Enterprice service Bus) product dat volgend jaar zal verschijnen, legt een soap-interface over vele bestaande communicatieprotocollen heen, waaronder .Net Remoting, ASMX en MSMQ. De applicaties zien alleen soap en XML. Indigo zal echter bekijken welk protocol werkelijk gebruikt moet worden. Als het bemerkt dat er bijvoorbeeld een lokale component aangeroepen moet worden, dan worden er geen soap-berichten verstuurd, maar wordt de meest efficiënte communicatievorm gekozen.
Kortom, de industrie is al begonnen met het bedenken van creatieve optimalisaties om er voor te zorgen dat al dat soap-verkeer geen problemen gaat geven. In feite ontstaat hiermee een virtualisatie van soap: we denken dat we soap en XML gebruiken, maar onder de motorkap wordt iets anders gehanteerd. En dat zal zeker het genoemde probleem doen verdwijnen.
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
