Software moet altijd samenwerken met hardware. Deze stelling is misschien niet erg verrassend, maar in de praktijk zorgt het voor verschrikkelijke problemen.
Allereerst moet het besturingssysteem worden afgestemd op de hardware (problemen met de processor, geheugenbeheer, I/O en device drivers, waarna het een standaard API voor de basisfuncties biedt (procesbeheer, filesysteem, I/O en dergelijke). Helaas hebben verschillende besturingssystemen ook verschillende API’s. Unix had de standaard moeten worden, maar helaas waren er in de praktijk ondanks de Spec 1170 ‘Open’-specificatie teveel uitbreidingen. NT heeft zijn eigen API’s, maar dat systeem is er alleen voor de kleinere systemen (in de praktijk Intel-processoren). Linux voegt weer een nieuwe Unix-achtige API toe. En dan hebben we het nog niet eens over OS/400 en OS/390.
Op het besturingssysteem draaien servers. De database-server is de belangrijkste, maar er zijn ook servers voor grafische gebruikersinterfaces (voor werkstations), e-mail, Web, XML, transactieverwerking, beveiliging, communicatie en zo meer. Dit betekent dat de reeks API’s steeds groter wordt, terwijl de standaardisatie afneemt.
Applicaties en ontwikkeltools worden zo ontworpen dat ze precies op de API’s passen. De meeste API-aanroepen zijn voor de servers bedoeld; slechts een klein aantal ‘calls’ heeft betrekking op de lagere functies van het besturingssysteem. Meestal roepen de servers die lagere functies aan in opdracht van de applicatie. Applicaties en tools moeten dus geschikt worden gemaakt voor een groot aantal verschillende besturingssystemen én servers.
Al die complexiteit levert problemen op. De kosten stijgen en er is meer onderhoud nodig. Client/server-architecturen maken het nog een stukje erger, omdat daarbij altijd meerdere besturingssystemen betrokken zijn en de servers ook rekening moeten houden met de eisen van de verschillende communicatie-subsystemen. Tel bij deze complexiteit ook nog eens nieuwe berichtgeoriënteerde toepassingen en web-applicaties op, elk met hun eigen specifieke API’s, en het wordt duidelijk dat de zaken uit de hand lopen.
Hoog tijd dus om weer over standaard API’s te praten. Eén mogelijke benadering daarbij is het selecteren van één systeem ten koste van alle anderen. Dit is de weg die Microsoft, IBM en Oracle bewandelen. Helaas wordt de onderneming daarbij met handen en voeten gebonden aan één leverancier. Hierdoor kan de leverancier de gebruiker in gijzeling houden en alle innovatie stopzetten. Organisaties kunnen ook voor een specifiek pakket kiezen, dat op twee of drie verschillende systemen draait. Ook in dat geval is de gebruiker echter gebonden aan een enkele leverancier. Wat is erger, de leverancier van een besturingssysteem of de leverancier van een applicatiepakket?
De opkomst van client/server heeft geleid tot een reeks middleware-producten, die een uitbreiding op de basisdiensten van het besturingssysteem vormen. Het gaat om API’s voor berichtenafhandeling, processynchronisatie, het aanroepen van procedures op afstand (RPC), directory-diensten, beheerfuncties en nu ook gedistribueerd objectbeheer. Deze middleware-producten maken het ontwikkelen van applicaties eenvoudiger, omdat het niet langer nodig is om de nieuwe, gedistribueerde API’s op de lagere niveaus te gebruiken. Helaas werkt dit maar ten dele. Er zijn immers nog steeds meerdere API’s, zij het aanzienlijk minder dan het grote aantal API’s op de lager niveaus.
Het gevolg is dat er nog steeds behoefte is aan een standaard die alle middleware-API’s harmoniseert. Ook in dit geval zullen de leveranciers concurreren met de standaardisatie-autoriteiten. Historisch gezien mogen de inspanningen van deze laatste partij als mislukt worden beschouwd. Op dit moment echter ondersteunen vrijwel alle leveranciers nieuwe standaarden, met Microsoft als uitzondering. Er is een breed draagvlak voor Java en Corba, terwijl Microsoft zich concentreert op COM+. Java heeft zijn eigen middleware-ontwikkelingen (RMI en EJB), maar er is een gecoördineerd initiatief (ook ondersteund door Sun, zij het met enige tegenzin) om Java met Corba te integreren. IIOP is daarbij de aangewezen manier om Java-applets te verspreiden.
De consequentie is dat Corba langzaam maar zeker is getransformeerd tot de belangrijkste middleware-standaard. Van de oorspronkelijke opzet als standaard voor eenvoudige gedistribueerde kantooromgevingen is Corba langzaam uitgegroeid tot een praktische standaard voor gedistribueerde object-applicaties. In een aantal opzichten concurreert Corba met COM+, maar Corba is veel volwassener. Dat geldt vooral voor de functies ter ondersteuning van volledig gedistribueerde transactieverwerking. Verder omvat Corba nu ook Java. Corba ondersteunt veel meer functies dan COM+ en wordt ondersteund door een groot aantal hardware- en software-platforms. De conclusie luidt dat Corba op dit moment op kop loopt bij het ontwikkelen van een standaard voor alle middleware. Het is eigenlijk een beetje belachelijk om nog een laag op de middleware-laag te stapelen, maar zo is het nu eenmaal. Intussen schuift Corba op van de categorie ‘interessant’ naar de categorie ‘essentieel’. Kijk eens goed naar Corba voordat u zichzelf aan COM+ bindt.
