Eén van de belangrijkste concepten van het object-model is een strikte definitie van het interface van het object.
Met een consistent interface is het mogelijk om run-time ondersteuning voor meerdere platforms te ontwikkelen, waardoor de ontwikkeling van herbruikbare componenten wordt bevorderd. In de praktijk is dit niet eenvoudig, omdat er verschillende processoren in omloop zijn. Hierdoor ontstaan meningsverschillen: sommige mensen vinden de Microsoft/Intel-oplossing (Wintel) het beste, omdat er veel PC’s zijn; anderen vinden een overdraagbaar model beter, omdat zo’n model op verschillende platforms draait en een ontsnapping biedt aan de hegemonie van Microsoft. Het is moeilijk te zeggen welke van deze twee opvattingen de juiste is; ze hebben beide hun sterke en zwakke punten.
De virtuele Java-machine (JVM) biedt een nieuw gezichtspunt, omdat deze gebruik maakt van interpretatie. Java-applets draaien op elke machine met een JVM. Het is om het even of de interpreter op een Intel of een Risc-processor draait, of dat hij in een browser of in een besturingssysteem zit.
Performance is een probleem, omdat interpreters een run-time overhead kennen; dit gegeven wordt altijd benadrukt door de Wintel-aanhangers. Just-in-time compilers en de binnenkort te verwachten intelligente selectieve compilatietechnieken zullen performance-verschillen voorgoed uit de wereld helpen. Nu ontstaat weer een debat over Wintel versus Java, ofwel Microsoft versus Sun – Intel blijft neutraal, omdat zowel PC’s als NC’s van hun processoren gebruik kunnen maken.
De meest gebruikte en veelal meest geschikte techniek voor het implementeren van client/server-applicaties is synchrone ‘remote procedure call’ (RPC). Deze techniek is enigszins beperkt, omdat de locatie van client en server gedefinieerd en geconfigureerd moet worden. Daarbij zijn er nogal wat RPC-varianten; de client en de server moeten dus op elkaar worden afgestemd (zo is een Cics client-call niet uitwisselbaar met een Oracle SQL*net server).
Een ‘schoon’ interface, dat onlosmakelijk verbonden is met het objectmodel, biedt vele voordelen. Als een aanroep ‘schoon’ is, kan hij transparant over het netwerk worden verspreid.
Bij het ontwikkelen van gedistribueerde objecttechnologie (ook wel ‘distributed open computing’ genoemd, Doc) loopt de Open Management Group voorop.
De OMG is erin geslaagd om standaarden te definiëren voor een taal om interfaces te definiëren, de ‘interface definition language’ (IDL), en voor een broker-service, de Common Object Request Broker Architecture (Corba).
In tegenstelling tot RPC registreert een Corba-server zijn huidige locatie bij een makelaar (broker); de client vindt het object door diens locatie bij de broker op te vragen. Met deze techniek kunnen objecten altijd worden gevonden, ook als ze van plaats veranderen; aanpassing en herconfiguratie van de client is niet langer nodig.
De hele industrie staat vierkant achter Corba, behalve Microsoft. Het Internet is ook Corba-‘compliant’ geworden met het Inter Internet ORB Protocol (IIOP), waarvoor de laatste JVM’s reeds voorzieningen bieden.
Omdat ze zich in eerste instantie op de desktop richtten, had Microsoft aanvankelijk weinig belangstelling voor gedistribueerde verwerking. Er zijn dan ook twee verschillende deelsystemen in de Com-architectuur, de basis-Ole en het Automation-concept, waarmee de ene applicatie in de andere kan worden ingebed. Daarnaast gebruikt Ole een soort registratie (registry) in de individuele PC, waardoor problemen bij distributie zullen ontstaan.
Microsoft heeft Ole nu uitgebreid tot Distributed Ole, Dcom genaamd; dit is een synchrone techniek die is gebaseerd op het DCE RPC-mechanisme. In tegenstelling tot Corba is Dcom Microsoft-specifiek en in realiteit beperkt tot NT, al duwt Software AG Dcom ook op andere platforms.
Al met al leidt dit tot een heleboel verwarring en onnodige kosten voor de gebruiker. De organisatie die voor de toekomst uitsluitend mikt op NT en daarmee Unix, MVS en andere zogenaamde ‘legacy’-systemen uitsluit is niet goed wijs. Men moet zich concentreren op Java-applicaties in een omgeving die Corba-compliant is. Het liefst voor alle besturingssystemen, maar dat is vandaag de dag niet haalbaar. En zo zitten we weer met de gebakken peren; Dcom en Corba zullen via gateways moeten samenwerken. Het zal niet voldoende zijn om Corba als backbone te gebruik om twee Dcom-systemen op elkaar aan te sluiten. De gateways moeten ervoor zorgen dat de Dcom-applicaties Corba-objecten kunnen gebruiken, en vice versa.
De integratie van Dcom en Corba is nog niet haalbaar, omdat Dcom niet, en Corba wel volledig object-georiënteerd is. Met andere woorden: er zijn Corba-functies die Dcom niet kan gebruiken. Er moeten dus tussenobjecten worden gespecificeerd. Verder zijn er twee gateways nodig: één om Ole op Corba aan te sluiten, en één om Ole Automation op Corba aan te sluiten. Deze gateways moeten dynamisch kunnen samenwerken met de complexe Microsoft Registry-diensten die bij Ole horen.
Het is een ingewikkelde situatie en ik vraag me af of gedistribueerde objecten al deze moeite wel waard zijn. Waarom kunnen we het op korte termijn niet gewoon met RPC en ‘message queuing’ doen?
