Het component-concept is goed op weg. Dat had al jaren geleden het geval moeten zijn. Het is veel te laat, maar beter laat dan nooit. Lang geleden paste de hardware-industrie het principe van inkapseling voor het eerst toe in geïntegreerde circuits. Dit leidde tot de ongelooflijk krachtige microprocessoren, controllers en geheugenchips van tegenwoordig. Een en ander bewijst dat consistentie zowel de betrouwbaarheid verhoogt als de kosten verlaagt.
Jaren geleden slaagden enkele organisatie erin softwarecomponenten voor conventionele gegevensverwerkende applicaties te ontwikkelen. Ze splitsten de ontwikkeling op in verschillende teams, sommige verantwoordelijk voor de primitieve subroutines, andere voor de applicatie zelf. Dit was het begin van component-software. Merk op dat hier geen object-oriëntatie aan te pas kwam, evenmin als speciale tools anders dan Cobol en PL/1. Het geheim was discipline en strak projectmanagement. Documentatie en een goed ontwerp waren essentieel.
Objecttechnologie zou de formele mechanismen moeten bieden voor het creëren en toepassen van herbruikbare componenten, omdat daarbij het gebruik van consistente standaardinterfaces van de componenten kan worden afgedwongen. Toch zien we ondanks alles ontwikkelomgevingen voor component-software die een keur aan programmeertalen ondersteunen, waarvan sommige in het geheel niet objectgeoriënteerd zijn (Visual Basic, Cobol), en die gecombineerd worden met talen die wel objectgeoriënteerd zijn (Smalltalk, Java).
Hoe staan de componenten er op dit moment voor? Dat varieert. Er is een groot aantal verschillende component-bibliotheken nodig; dat de kwaliteit daarvan sterk verschilt is niet verbazingwekkend. De meest volwassen bibliotheken zijn primitieve klassebibliotheken voor C++-compilers die interfaces bieden voor besturingssystemen, randapparaten en dergelijke. Bij de oudere 3GL’s zitten zulke functies in de compilers en de run-time systemen, maar zo’n aanpak is minder flexibel dan een afzonderlijke klassebibliotheek. Andere veelgebruikte bibliotheken zijn Ole-controls (OCX), die met name gericht zijn op componenten voor grafische Windows-displays. OCX-controls vervangen de oudere Visual Basic Controls (VBX). Objectgeoriënteerde producten werden aanvankelijk gedomineerd door Nextstep en Smalltalk, met complete bibliotheken vol object-componenten. Tegenwoordig is Java oppermachtig, samen met de Java Beans component-bibliotheken. Merk op dat deze bibliotheken onderling niet uitwisselbaar zijn. OCX’en zijn niet volledig objectgeoriënteerd; C++-bibliotheken worden gecombineerd met procedure-aanroepen door de compiler, en Java Beans moeten voldoen aan een strikt objectgeoriënteerde interface-specificatie.
Er zijn talloze goed geoutilleerde component-bibliotheken voor het ontwikkelen van grafische client-applicaties, maar dat is voor server-toepassingen wel anders. Waarschijnlijk komt dit doordat de eisen die aan zo’n bibliotheek worden gesteld moeilijker te definiëren zijn. In de praktijk zijn de primitieve componenten voor het besturingssysteem redelijk voldragen. Er is een trend waarneembaar die in de richting van ‘Frameworks’ wijst, ofwel verzamelingen componenten die zijn vastgeklonken aan een specifieke omgeving. Hierdoor ontstaat een consistent beeld van een systeem, dat onafhankelijk is van de onderliggende omgeving.
Voorbeelden hiervan zijn componenten voor database-toegang of geheugenallocatie. Deze moeten worden uitgebreid met componenten voor andere primitieve functies die nodig zijn voor complexe, multitasking, multithreaded applicaties, zoals beveiliging, locking, integriteit, prioriteit en dergelijke. Met name IBM en HP zijn actief op dit gebied. Zo zijn de IBM-frameworks bedoeld om hun compilers consistent te maken in een omgeving met verschillende besturingssystemen. In tegenstelling hiermee heeft Microsoft zich gericht op de grafische gebruikers-interface, dat ligt voor de hand, maar naarmate NT uitgroeit tot een volwaardige transactieserver zullen ook de frameworks voor NT krachtiger en krachtiger worden. Een voorbeeld van deze bibliotheken is er één die programmeurs voorziet van een abstracte vorm van toegang tot de diensten van een TP-monitor, zoals Cics, Tuxedo of MTS. In de Java-wereld is er zelfs een standaard die de TP-monitor onzichtbaar moet maken.
Verschillende talen en compilers gebruiken componenten op verschillende manieren. In sommige gevallen worden de componenten gelinkt met de uitvoer van de compiler tot een complete objectcode. In andere gevallen worden componenten samen met het besturingssysteem geladen, en worden ze tijdens run-time door het programma aangeroepen. Om ervoor te zorgen dat de bibliotheken aanwezig zijn als de applicaties ze nodig hebben, is ‘binding’ nodig; dit kan plaatsvinden als het programma geladen is (dynamic link libraries, DLL) of pas als het programma draait (‘late binding’). Velen van ons hebben problemen gehad met DLL’s, omdat er geen enkele vorm van versiebeheer in zat. OCX’en – die op hun beurt ook weer DLL’s kunnen gebruiken – werden daarom met open armen ontvangen. Op dit moment is hét voorbeeld van ‘late binding’ de run-time omgeving voor Java, die de Java Virtual Machine wordt genoemd. Hiermee wordt bereikt dat Java-applets op de client en servlets op de server consistent zijn. (Servlets bieden toegang tot databases, TP-monitors en andere functies die aan de client-kant niet nodig zijn.)
De ontwikkeling moet dan bestaan uit het uitbreiden van de functionaliteit van server-componenten. Het betreft hierbij objectgeoriënteerde, OCX- en Cobol-transacties die met behulp van frameworks op systeemniveau primitieve applicatiefuncties voor specifieke toepassingen moeten bieden; denk hierbij aan verzekeringen, productie, procesbesturing, financiële transacties en dergelijke. Dit zijn de pakketten van de toekomst, die gebruikt zullen worden om applicaties op client-niveau te bouwen.
