Het is zeker naar IT-maatstaven al weer een tijdje geleden dat OMG Corba introduceerde. Corba, de standaard voor gedistribueerde objecten, wordt door een groot aantal leveranciers ondersteund, maar bevindt zich nog steeds in de categorie ‘specialistisch’ en is zeker geen gemeengoed. Zal dat ooit het geval zijn, of sluit Corba aan in de rijen van overgedimensioneerde standaarden als X.25, OpenDoc, Xopen en dergelijke?
In tegenstelling tot het component-model is Corba een puur objectgeoriënteerd model. Objecten kennen overerving, polymorfisme en encapsulatie (herbruikbaarheid), terwijl componenten alleen encapsulatie ondersteunen. Het is moeilijk genoeg om een zuiver objectsysteem te implementeren. De grootste successen in de objecttechnologie hebben betrekking op programmeeromgevingen als C++. De output van zo’n ontwikkelomgeving is vaak een conventionele code-module. Tot de komst van Java Virtual Machines waren er maar weinig objectgeoriënteerde runtime-omgevingen.
Als het in zijn algemeenheid al lastig is het objectmodel volledig te implementeren, dan zal dat zeker wel gelden voor een gedistribueerde omgeving. En dat is meteen het eerste nadeel van Corba: het is noodzakelijkerwijs complex.
Corba wordt geïmplementeerd als ‘broker’, zodat elk object een ander object in het systeem kan lokaliseren. Dit gebeurt in runtime, zonder dat er een voorgedefinieerd pad hoeft te zijn. Dit maakt het in theorie eenvoudig om objecten te verplaatsen of de omgeving uit te breiden met behulp van parallelle componenten, zonder dat een aanpassing van de code of de configuratie-instellingen nodig is. Het is ook handig voor ontwikkelaars, die alle objecten op één ontwikkelmachine kunnen bouwen en ze later in een gedistribueerde omgeving kunnen testen. Maar de broker brengt overhead met zich mee en is kostbaar, zeker voor zulke complexe software.
Het eerste Corba-model was bedoeld voor kantoorapplicaties, maar latere releases voegden daar transactiediensten aan toe. Deze waren gericht op robuuste gedistribueerde zakelijke toepassingen. Het complexe model werd nog complexer! Als gevolg hiervan vertoonden verschillende implementaties onderling verschillen, terwijl het model gestandaardiseerd was. Dit betekent dat de oorspronkelijke doelstelling, waarbij elk Corba-compliant systeem met elk ander systeem van elke andere leverancier kan samenwerken, slechts zelden gehaald wordt, tenminste niet zonder problemen. Het model is erg complex geworden; er zijn al meer dan zevenhonderd api’s gedefinieerd! Vergelijk dat eens met de eenvoud van systemen voor transactieberichten, zoals MQ Series, met zijn simpele interfaces.
Microsoft is de grootste speler die Corba niet steunt; het eigen objectmodel heeft een veel praktischer ontstaansgeschiedenis. Het begon met het componentmodel van OLE en ontwikkelde zich geleidelijk tot COM. Voor NT kwam er een gedistribueerde versie, DCOM. Omdat DCOM en nu COM+ simpel begonnen zijn en geleidelijk gegroeid zijn, zijn deze modellen lang niet zo ambitieus als Corba. Ze zijn wel veel praktischer in het gebruik. In het begin was OLE maar armzalig vergeleken met OpenDoc, maar het kreeg de steun van programmeurs omdat het zo simpel was. En net zoals OpenDoc te ambitieus was, zo is Corba te ambitieus vergeleken met DCOM. Dit is gebaseerd op ‘remote procedure calls’ (rpc’s) die niet zo flexibel zijn als een broker maar ook veel minder last hebben van overhead. Het is interessant om te zien hoe praktisch de producten van derden zijn die DCOM op andere platformen implementeren.
Door de ontwikkelingen rond het Web is er nu ook een variant voor Java-applets ontstaan, die binnen de browser onder een Java Virtual Machine (JVM) draaien. Voor client/server-achtige applicaties moet de Java-client daarbij een connectie maken met objecten of componenten op de host, net zoals een Windows-client een host-procedure moet aanroepen. De doorsnee PC-client roept een host-procedure aan met behulp van verschillende rpc-technieken, zoals TP-monitors (Cics-client) of procedures die in de database zijn opgeslagen (SQL*Net, Odbc). Dit zijn connectie-georiënteerde technologieën, die als zodanig veel eenvoudiger zijn dan de enorm veelzijdige object-technologieën. Java zou als objectmodel zo kunnen worden aangepast dat er ook rpc’s worden gebruikt, maar daar is men huiverig voor, omdat het een stap terug is – in de richting van het dikke client-model. Merk op dat er ook een standaard voor rpc’s is ingebouwd in DCE, nog zo’n uitmuntende technologie die nauwelijks wordt gebruikt omdat hij te complex is.
Java-applets hebben toegang tot objecten op de host door middel van twee technieken die tegenwoordig veel in browsers worden toegepast. De eerste is een JVM-specifieke techniek die Remote Method Invocation (RMI) heet. De tweede is een vertaling naar Corba en heet IIOP (Inter-Internet Orb Protocol) waarmee Java-applets Corba-objecten kunnen benaderen. Ook hier is de overhead onoverkomelijk, waardoor de aandacht zich meer richt op eenvoudige Http-interactie tussen de browser (met of zonder Java-applets) en een applicatieserver. Niet de client, maar de server ondersteunt daarbij de interactie met andere systemen, inclusief legacy-systemen.
Martin Healey, pionier ontwikkeling van op Intel gebaseerde computers en c/s-architectuur. Directeur van een aantal IT-bedrijven en professor aan de Universiteit van Wales.
