De meeste organisaties beschikken over een mengeling van oude terminal/batch-applicaties en PC-applicaties met dikke clients op basis van relationele databases. Door het Jaar 2000-probleem heeft iedereen nu wel in de gaten dat oude monolithische applicaties verouderd zijn. Ook is duidelijk dat applicaties met dikke clients het legacy-probleem alleen maar erger maken.
De meeste organisaties hebben gekozen voor een oplossing op lange termijn door hun systemen te vervangen door standaardpakketten, met name Sap en Baan, op basis van dunne clients. Deze oplossing omvat doorgaans echter maar een deel van de applicaties; er blijft nog zo’n 20 tot 40 procent aan zelf ontwikkelde software over.
Een andere invloedsfactor is het kantoorsysteem. Deze worden gedomineerd door enorme dinosaurusachtige applicatiepakketten met dikke clients. Het Internet en met name het Web hebben de knuppel echter met kracht in het hoenderhok gegooid.
Java en browsers vormen een bedreiging voor de dominantie van Microsoft en scheppen massale verwarring. Desondanks zullen Java-applicaties de komende jaren nog geen echt gevaar voor Microsoft Office vormen, zodat de eigendomskosten van dikke clients voorlopig nog wel torenhoog zullen blijven. Dit geldt zelfs als dunne client-applicaties worden ingevoerd, omdat gebruikers zowel dunne clients als kantoorapplicaties moeten draaien.
Gegeven al deze verandering en verwarring is een ander, meer revolutionair alternatief zeker het overwegen waard. Dat is het objectmodel, en dan met name het gedistribueerde object-component model (Doc). Dit model zal zeker terrein winnen, al zij het langzaam; deze opkomst wordt op het moment geïllustreerd door de snelle opkomst van Java. Het conflict tussen Microsoft en de wereld van de objecttechnologie (OT) kan niet worden genegeerd.
De eerste ronde werd gemakkelijk gewonnen door Microsoft, omdat zij het besturingssysteem voor de desktop in handen hadden. Geavanceerde OT-producten als Smalltalk, Opendoc, Som en zelfs de Macintosh werden gesmoord door Ole. Ole gaf ons applicaties. Spreadsheets konden worden geïntegreerd met tekstdocumenten; Ole ‘controls’ (OCX) boden krachtige herbruikbare gui-componenten voor Visualbasic-programmeurs.
Het feit dat Opendoc samengestelde documenten opleverde en dat prototype-applicaties vier maal zo weinig geheugen gebruikten als Ole-applicaties werd tenietgedaan doordat niemand er in slaagde een bruikbare applicatie in de markt te zetten.
Vandaag de dag weet niemand, zelfs Microsoft niet, wat Ole precies is. Het oorspronkelijke Ole bood applicaties de mogelijkheid om gegevens te registreren, zodat het aanklikken van een Word-icoon automatisch leidde tot het opstarten van Word en het openen van het document – precies wat de gebruiker wilde. Meer konden we ook niet verwachten in Windows 3.1. Na de opkomst van multitasking in Windows 95 en vooral het veel betrouwbaarder Windows NT kon echter veel meer worden bereikt: Ole 2. Hiermee kon een applicatie een andere applicatie opstarten, waarbij de uitvoer van de twee applicaties geïntegreerd werd. Zo kun je vanuit Word Excel opstarten, waarbij het spreadsheet in het Word-document wordt ingebed. Het probleem is dat de Office-producten niet modulair zijn, zodat je vanuit Word meteen alle Excel-functies moet laden – een enorme overhead.
Merk op dat Office 97 een betere modulaire structuur heeft dan zijn voorgangers, zodat slechts delen van applicaties hoeven te worden opgestart. Het geheugengebruik neemt hierdoor af, tot groot verdriet van Intel: wie overstapt van Office 95 naar Office 97 hoeft zijn PC niet te upgraden.
Toch is dit nog lang geen componentmodel. Microsoft wordt daardoor nog steeds bedreigd door een nieuwe generatie Java-applicaties die op componenten gebaseerd zijn. En deze zijn dus veel aantrekkelijker voor de gebruiker.
Om inkapseling van programma’s te realiseren, heeft Microsoft Ole uitgebreid tot Ole Automation. Programma’s worden aangepast aan de Automation api’s, zodat ze een ander programma kunnen aanroepen (een container), zelf aangeroepen kunnen worden (een server), of allebei. Deze nieuwe architectuur werd het Component Object Model (Com) gedoopt. Merk op dat Ole en Ole Automation verschillend zijn en beide door Microsoft worden ondersteund. Verwarrend genoeg noemt de OT-wereld buiten Microsoft het oude Ole nu Com, terwijl Ole Automation gewoon Automation wordt genoemd. Om alles nog ingewikkelder te maken bevat de gedistribueerde versie van Com (DCom) zowel Com als Automation.
Gebruikers van DCom zullen hierdoor in verwarring worden gebracht. Nog meer problemen zijn te verwachten als beide producten moeten voldoen aan een industriestandaard, zoals Corba.
De Java Virtual Machine (JVM) in Internet Explorer is een bron van nog meer verwarring, omdat de IE-uitbreiding, in tegenstelling tot een pure Java-omgeving, is geïntegreerd met Ole en Ole Automation. Hierdoor kunnen Java-applets OCX’s aanroepen en kunnen Ole-applicaties weer Java-applets aanroepen. Het doel hiervan is de gebruiker aan de PC te binden en de migratie naar NC’s te frustreren. Dit brengt ons op een andere kreet: Activex. Op de server, zonder Java, heet Com ook Activex. Snapt u er nog iets van? Microsoft in elk geval niet.
