SOAP: de CORBA killer

Voor het bouwen van gedistribueerde applicaties hebben we er weer een nieuwe technologie bij. Maar wel een met een schone naam: SOAP (Simple Object Access Protocol). Hopelijk zal SOAP de rommel aan verschillende API's voor het ontwikkelen van gedistribueerde applicaties gaan opruimen. Als het een succes wordt, zou het wel eens het einde van standaarden als CORBA kunnen betekenen.

De essentie van een gedistribueerde applicatie is dat verschillende machines verschillende delen van een applicatie draaien. Om toch een geheel te vormen roepen deze delen elkaar aan over een netwerk. Dit doen zij door parameters en antwoorden uit te wisselen. Toen ik nog jong was, gebeurde dat met behulp van API's op netwerk-laag - lees mensonvriendelijk - niveau. Tegenwoordig kan een gedistribueerde applicatie bestaan uit een JavaBean die binnen een browser draait en via CORBA een Java-servlet start op een Unix-server, waarbij het Internet als netwerk gebruikt wordt.

In het begin hadden we niet veel keus, er moesten laagniveau-API's gebruikt worden - deze waren ook allemaal leverancierafhankelijk. Het bouwen met deze API's wordt ook wel de Arnold Schwarzenegger-methode genoemd. De programmeur bepaalde eigenlijk alles, tot en met het interne formaat van de pakketjes waarmee de data over het netwerk verstuurd werd: heerlijk primitief met send- en receive-instructies bitjes over het netwerk smijten. Als de applicatie draaide, en je legde je oor op de netwerkkabels, dan hoorde je de bits voorbijrazen. Dat waren nog eens tijden. 

Deze fase heeft echter maar kort geduurd, want al snel kwam elke platformleverancier met een API die gemakkelijker in gebruik was. Daarmee werd tevens het interne protocol, dus de vorm waarin de data wordt verstuurd, afgeschermd. Voor de oudere generatie programmeurs was hiermee de lol er af. Deze API's waren wel proprietary, maar dat werd opgelost toen de DCE (Distributed Computing Environment) geïntroduceerd werd: een taal- en platformonafhankelijke, gestandaardiseerde API voor het aanroepen van remote applicatielogica.

Maar ja, de API van DCE was niet gebaseerd op OO-concepten, dus werd ze niet geaccepteerd door de nieuwe generatie programmeurs. En we kregen CORBA en Java RMI om gedistribueerde applicaties te maken. Natuurlijk vergeten we COM+ niet. Deze technologie, die intern veel van DCE-technologie herbergt - volgens de puristen niet echt OO - is desondanks een zeer actuele API om remote applicaties aan te roepen. Tot voor kort ging de strijd voor het bouwen van gedistribueerde applicaties dan ook tussen deze drie.

De API's van deze middleware-standaarden zijn zeer zeker veel krachtiger dan wat we ooit gehad hebben, maar bij allemaal is het interne protocol een beetje onduidelijk. Dit creëert een aantal problemen. Onder andere hebben ze allemaal moeite hun berichten door een firewall te sturen, want de meeste firewalls accepteren alleen tekstgebaseerde berichten. Ten tweede, een product gebaseerd op CORBA kan niet zomaar berichten uitwisselen met COM+. Het probleem is dat de interne protocollen afwijken. 

Al deze problemen kunnen we in één klap oplossen met SOAP. Ieder product dat gebaseerd is op deze - door onder andere Microsoft ontwikkelde - standaard, stuurt de berichten als kleine XML-documenten over het netwerk. De documenten bevatten zaken zoals de naam van de component die geactiveerd moet worden, de invoerparameters en de uitvoerparameters. Omdat deze berichtjes met XML gedefinieerd zijn, zijn ze te lezen door iedereen, ook door een firewall. 

SOAP is simpel en biedt een aantal zeer praktische voordelen. SOAP heeft dus veel toekomst, mits de interesse in gedistribueerde applicaties blijft bestaan. 

Maar wat zal het effect zijn op COM+, Java RMI en CORBA? Het zal geen concurrent van COM+ worden, want het gehele Windows-platform is op COM+ gebaseerd. We gebruiken het bijna allemaal - dikwijls zonder dat te weten. Trouwens, COM+ ondersteunt SOAP vandaag al, en wat het gebruik van COM+ alleen maar zal bevorderen. Ook Java RMI zal geen last krijgen van SOAP. Java RMI is een onderdeel van het Java-platform en vele Java-programmeurs gaan er van uit dat alle applicatiedelen in Java geschreven zijn. De toevoeging van SOAP biedt hen weinig voordelen, tenzij ze een COM+-component willen aanroepen.

Maar voor CORBA gelden andere argumenten. CORBA is geen platform, zoals Windows of Java. Het is voornamelijk middleware om remote componenten te activeren. Daarvoor gebruikt het zijn eigen API. Met SOAP zouden we deze API kunnen afschermen, waardoor het niet meer duidelijk is dat een CORBA-component aangeroepen wordt. Het wordt dan ook eenvoudiger om CORBA door Java RMI of COM+ te vervangen. Dezelfde redenering gaat niet op voor de platformen Windows en Java, omdat zij veel meer bieden en daarom niet zo eenvoudig te vervangen zijn. Het is dus niet ondenkbaar dat op de lange termijn SOAP de CORBA-killer wordt. Jammer, maar wel begrijpelijk.