Van ruilen komt huilen

Component Based Development (CBD), zoals het zo mooi heet in het Nederlands, biedt diverse, zeer praktische voordelen. Elk boek en artikel over dit onderwerp begint met het opsommen van al deze voordelen, dus ik zal ze hier niet herhalen. Maar één ervan is steevast dat we componenten zo eenvoudig kunnen vervangen. We kunnen applicaties veel makkelijker onderhouden en uitbreiden, omdat we een component kunnen inruilen voor een snellere, een veiligere, of een betere. Deze beoogde uitwisselbaarheid is een zeer essentieel voordeel, en niet alleen omdat een aantal andere voordelen van CBD hierop gebaseerd is.

Omdat een component niet direct door applicaties of andere componenten wordt aangeroepen, maar via een laag software (die we voor het gemak maar even componentenlijm noemen) genaamd de interface, is het relatief eenvoudig een component te vervangen. Wat dat betreft vertoont een component veel overeenkomsten met een gloeilamp. Aan een gloeilamp zit een stuk schroefdraad waarmee ze in de fitting gedraaid kan worden. De fitting en de schroefdraad moeten aan dezelfde standaard voldoen om te kunnen samenwerken. Er geldt dus dat verschillende gloeilampen met dezelfde schroefdraad in dezelfde fitting gedraaid kunnen worden. 

Fitting en schroefdraad vormen samen de lijm. Voor softwarematige componenten bestaat ook dit soort lijm, zoals ActiveX en JavaBeans. De aanroepende applicatie (of component) bevat een deel van de lijm en de aan te roepen component het andere deel. 

Nu wordt er soms heel gemakkelijk gedaan over het ontkoppelen van oude en aankoppelen van nieuwe componenten. Sommigen hebben zelfs het idee dat als componenten maar voldoen aan een standaard, zoals JavaBeans, ze automatisch vervangbaar zijn. Dit is uiteraard niet het geval. Het is niet voldoende als de applicatie en de component dezelfde taal (zoals JavaBeans) spreken, de een moet ook woorden gebruiken die voor de ander begrijpelijk zijn. 

Bij eenvoudige componenten zal dit geen rol spelen, maar bij de complexe varianten wel. Een eenvoudige component kan bijvoorbeeld een pushbutton zijn. Indien u uw knoppen ineens saai vindt en wilt overstappen op een modieuzer soort, dan zal dat waarschijnlijk slechts een kwestie van uitzoeken, kopen, installeren en hercompileren zijn. Alles draait daarna weer als vanouds, maar nu met flitsende buttons. Dat het vervangen hier een triviale exercitie is, komt omdat de interface van een button-component zeer simpel en voorspelbaar is. Twee, door verschillende leveranciers ontwikkelde button-componenten zullen dus dezelfde interface hebben en daardoor vervangbaar zijn.

Maar de kans is klein dat u even eenvoudig een component genaamd 'Klant' of 'Product' kunt vervangen. Deze componenten zullen een zeer uitgebreide interface hebben bestaande uit vele methoden en parameters. Dus de kans dat twee Klant-componenten, ontwikkeld door verschillende leveranciers, automatisch uitwisselbaar zullen zijn, is zeer klein. De ene leverancier heeft bijvoorbeeld de methode Geef-contactpersoon, terwijl de andere deze heeft weggelaten.

Dat we uitwisselbaarheid op dit niveau van componenten nodig hebben, staat buiten kijf. We kunnen echter niet luchtig over dit onderwerp heenstappen. Om uitwisselbaarheid op dit niveau te realiseren zijn standaarden nodig. In deze standaarden staat dan beschreven wat bijvoorbeeld een klant- of product-component als interface heeft. Deze standaarden zijn een vereiste om CBD financieel te kunnen rechtvaardigen. Anders zou de toekomst van CBD er wel eens minder rooskleurig kunnen uitzien. Hier en daar wordt al gewerkt aan dit soort standaarden, dus laten we hopen dat ze op zeer korte termijn beschikbaar zullen zijn.