Om machinecode te schrijven voor omvangrijke en ingewikkelde projecten zijn software-ontwikkelaars aangewezen op specialistische hulpmiddelen. Zette de auteur in de eerste aflevering de tekortkomingen van object-oriëntatie af tegen de zegeningen van de softwarecomponenten-technologie, in deze tweede aflevering gaat hij daar nog nader op in. Tevens zet de systeemarchitect van Philips Semiconductors uiteen in hoeverre deze technologie haalbaar is. Ook vermeldt hij enkele reële bezwaren, die echter slechts van tijdelijke aard zijn. En – wanneer kan toepassing van deze technologie in ingebedde systemen tot succes leiden?
De vorige aflevering werd afgesloten met de constatering dat; als de te ontwerpen toepassing niet op een platform draait dat Active-X ondersteunt, dan moet het ontwerp- en bouwsysteem zelf de infrastructuur voor de ondersteuning van COM (Component Object Model) leveren. Daarom eerst nog even een nadere beschouwing van bestaande hulpmiddelen.
Softwarecomponenten met de hand bouwen is vrij moeilijk en het inpassen in een ondersteunende infrastructuur is nòg moeilijker. Om deze reden zijn er hulpmiddelen ontwikkeld die dat probleem oplossen. Deze hulpmiddelen lokken de gebruiker echter binnen in een eigendomsrechtelijk beschermde infrastructuur. In geval van Javabeans is dat Java en in geval van Active-X is dat het Windows-platform van Microsoft. Iets wat niet altijd wenselijk is. Men zou dus willen beschikken over methodieken die een open en onafhankelijke en tegelijk platform-onafhankelijke infrastructuur bieden.
Alleen hulpmiddelen die zelf de noodzakelijke infrastructuur kunnen genereren, zijn in staat een multi-SW-technologie-, multi-platformimplementatie van software te ondersteunen. Ook hier levert COM een oplossing. COM is door Microsoft uitgebracht en levert de basis voor diens Active-X-technologie. Deze technologie blijkt voor Microsoft van essentieel belang.
Toch wordt tenminste een deel van deze technologie publiekelijk verspreid. Een groot aantal boeken en geschriften omschrijft hoe men op COM gebaseerde softwarecomponenten moet construeren. Microsoft heeft inmiddels een deel van zijn Active-X-technologie ter beschikking gesteld van de Open Group. Helaas heeft dat nog niet geleid tot het ter beschikking komen van een op COM gebaseerde open infrastructuur. Het ìs echter haalbaar om deze infrastructuur door het ontwerp- en bouwgereedschap te laten voortbrengen.
‘Component Based Development’
Een aantal voorvechters van het gebruik van softwarecomponenten bezigen de term Component Based Development. Het doelgebied is daarbij meestal de ondersteuning van de bedrijfsvoering. Deze groep wijdt het succes van de softwarecomponenten-technologie voor een deel aan het feit dat de objectgeoriënteerde technologie niet aan de hooggespannen verwachtingen bij het optimaliseren van hergebruik van programmatuur heeft voldaan. Het blijkt dat bij gebruik van de klassen van een klassenbibliotheek een hoge expertise op programmeergebied vereist wordt. Dat geldt voor componenten in veel mindere mate.
Bovendien zijn het uitbreiden van een klassenbibliotheek en het debuggen van programma’s die met een klassenbibliotheek gebouwd zijn, haast onmogelijk zonder dat toegang tot de broncode van de bibliotheek gegeven worden. Ook hier figureren componenten veel beter. Commercieel aangeboden softwarecomponenten hebben één of meer hard gedefinieerde interfaces en bieden een gegarandeerd foutvrije werking. Vaak is een debug-versie beschikbaar die allerlei testen op de toegestuurde opdrachten en gegevens uitvoert.
Inmiddels is een aantal ontwikkelingshulpmiddelen beschikbaar, waarmee snel en zonder veel diepgaande programmeerkennis bruikbare toepassingen gebouwd kunnen worden, waarin componenten de ingewikkelde taken oplossen. Zo is het bijvoorbeeld mogelijk softwarecomponenten in te zetten om het volgen van de bedrijfsregels en bedrijfsstrategieën af te laten dwingen.
Dergelijke op COM gebaseerde componenten kunnen de broncode effectief beschermen. Dit is een van de belangrijkste redenen dat een snel groeiende markt van door onafhankelijke partijen geproduceerde en verhandelde softwarecomponenten ontstaan is.
Nogmaals object-oriëntatie
Het voorgaande houdt geenszins in, dat de objectgeoriënteerde technologie nu afgedaan heeft. Zoals aangeduid zijn zowel C++ als Java zeer geschikt om er softwarecomponenten mee te bouwen.
Daarnaast is de objectgeoriënteerde techniek een uitstekend middel, wanneer een samenhangende groep programmeurs een relatief groot systeem moet bouwen. Dit geldt vooral als voor het betreffende toepassingsgebied reeds een uitgebreide klassenbibliotheek en een bijpassende geïntegreerde bouwomgeving bestaat. De objectgeoriënteerde technologie is onverslagen in het optimaal hergebruik van eigen ontwikkelingen en levert daardoor de meest flexibele en snelste aanpassingsmogelijkheid.
Haalbaarheid
De snel groeiende toepassingen op de desktop, op Internet en bij de ondersteuning van de bedrijfsvoering bewijzen duidelijk dat softwarecomponenten-technologie zin heeft. Dat deze technologie ook werkt op tot nu toe onontgonnen gebieden wijst op de haalbaarheid van een geïntegreerde ontwerp- en bouwomgeving die zich op deze doelgebieden richt. Er bestaan afzonderlijke ontwerphulpmiddelen en geïntegreerde bouwomgevingen voor dit doel, maar die richten zich meestal op de objectgeoriënteerde technologie. Het is mogelijk om deze hulpmiddelen om te vormen, zodat zij ook componenten ondersteunen.
Het integreren van de ontwerp- en bouwhulpmiddelen vormt echter een veel ingrijpender proces. Deze integratie moet namelijk resulteren in een generatie van precies op zijn taak toegesneden infrastructuren en in zoveel mogelijk op elkaar aangepaste softwarecomponenten. Alleen dan kan toepassing van deze componenten in ingebedde systemen tot succes leiden. Daar waar al een ondersteunende infrastructuur voorhanden is, moet de geïntegreerde ontwerp- en bouwomgeving softwarecomponenten produceren en samenvoegen met bestaande componenten, zodat efficiënte toepassingen ontstaan. In beide situaties moet het ontwerpen en bouwen zodanig gebeuren, dat onafhankelijke derde partijen bij de aanlevering betrokken kunnen worden. Dit laatste houdt in, dat de infrastructuur die softwarecomponenten ondersteunt open (= toegankelijk) moet zijn voor bijdragen van derde partijen.
Er bestaan nog geen repositories waarin herbruikbare ontwerpelementen voor de softwarecomponenten-technologie publiekelijk geadverteerd worden. Bovendien zijn er nog geen hulpmiddelen die dergelijke repositories kunnen ondersteunen of er gebruik van kunnen maken. Het is echter niet al te moeilijk om deze functionaliteit aan een geïntegreerde ontwikkelomgeving toe te voegen.
Systemen met componenten
Systemen bouwen die nagenoeg geheel uit softwarecomponenten bestaan is mogelijk, maar dit zal in de praktijk echter weinig voorkomen. Vaak zal een systeem slechts voor een deel uit componenten bestaan. Dat betekent dat de ondersteunende infrastructuur tezamen met de ingekapselde softwarecomponenten een onderdeel van het totale systeem vormt.
Het betekent tevens dat het andere deel op meer conventionele wijze gebouwd wordt. In feite gebeurt iets dergelijks ook wanneer Java of Active-X aan een toepassing of werkomgeving worden toegevoegd. De diensten die de sub-infrastructuur moet leveren, worden ontleend aan het omhullende systeem. De sub-infrastructuur verbergt het omhullende systeem voor de ingekapselde softwarecomponenten. Omgekeerd verbergt deze structuur de componenten voor het omhullende systeem.
Een voordeel van softwarecomponenten is, dat zij relatief gemakkelijk aan een bestaand systeem kunnen worden toegevoegd of uit een systeem kunnen worden verwijderd. Dat kan statisch, als het systeem niet draait, of dynamisch, tijdens het draaien. Voor dit laatste moeten dan wel de nodige voorzorgsmaatregelen getroffen worden.
De COM-specificatie biedt voldoende ruimte om de ondersteunende infrastructuur een geheel eigen karakter te geven. Wel moet opgepast worden, wanneer softwarecomponenten zowel in de zelf ontworpen infrastructuur als in de Active-X-infrastructuur moeten kunnen functioneren. Of wanneer Active-X-softwarecomponenten in de zelf ontworpen infrastructuur moeten kunnen functioneren. De beste oplossing is om een welgekozen en goed omschreven sub-set van de Active-X-functionaliteit in de zelf gegenereerde infrastructuur te ondersteunen. Op deze wijze wordt het makkelijker om op den duur ook gedistribueerde componenten (op basis van DCOM – Distributed Component Object Model) te ondersteunen.
Hybride componenten
Tussen softwarecomponenten en geïntegreerde schakelingen bestaat een grote overeenkomst. Bovendien komen de interfaces van deze componenten verregaand overeen met de hardware-bussen die geïntegreerde schakelingen verbinden.
Geïntegreerde schakelingen worden steeds vaker begeleid door aanzienlijke hoeveelheden specifieke software. Voorheen betrof dat voornamelijk de drivers, maar in toenemende mate betreft dat ook software uit hogere architectuurniveaus. Softwarecomponenten zijn bij uitstek geschikt om deze specifieke software te omvatten. Op die wijze ontstaan hybride componenten, die opgebouwd zijn uit een hardwaredeel en een daarbij passend softwaredeel. Om deze ontwikkeling een kans te geven, moet allereerst de softwarecomponenten-technologie voor ingebedde systemen op gang komen.
Bezwaren
Voordelen van softwarecomponenten zijn inmiddels uitgebreid aan bod gekomen. Om een afgewogen oordeel te kunnen vellen moeten ook de nadelen belicht worden. Het succes van de softwarecomponenten-technologie is sterk afhankelijk van het succes van de met deze technologie samenhangende standaarden.
De COM-specificatie beschrijft het onderliggende objectmodel en de bijbehorende communicatieprotocollen. Ook wordt aangegeven hoe relatiebeheer en geheugenbeheer geregeld moeten worden. De COM-specificatie geeft weinig aanknopingspunten voor synchronisatie en taakbeheer. Een registratie van veelgebruikte interfaces op publiekelijk toegankelijke repositories is essentieel voor het succes van de technologie. Helaas is dit nog niet in een praktische, automatisch verwerkbare vorm beschikbaar. Hetzelfde geldt voor de registratie van herbruikbare componenten.
Softwarecomponenten zijn niet op simpele wijze te bouwen. Het bouwen van systemen die een groot aantal van dergelijke componenten bevatten, kan alleen met ondersteuning van krachtige hulpmiddelen. De noodzakelijke ondersteuning door een passende infrastructuur eist een niet geringe overlast. Deze is vooral groot als van distribueerbare softwarecomponenten gebruik gemaakt wordt. Daarnaast verbiedt de toepassing van deze componenten het gebruik van macro’s en andere trucs om de werking te versnellen. Dat mag alleen binnen de softwarecomponent. Zo’n component is alleen te benaderen via de officiële weg en die loopt uitsluitend via een indirecte functie-aanroep. Aan deze beperking hebben softwarecomponenten een groot deel van hun robuustheid te danken. Bovendien wordt op deze wijze hun interne samenstelling op effectieve wijze verborgen.
De component-technologie is vrij nieuw en daarom bestaan er nog niet voor alle doelgebieden voldoende hulpmiddelen. Ook zijn er nog weinig experts die softwarecomponenten kunnen bouwen of die hiervan uitgaande complete systemen kunnen genereren.
Belofte inlossen
De meeste van deze bezwaren zijn van tijdelijke aard. Het ligt dan ook in de verwachting, dat de softwarecomponenten-technologie een gedeelte van de belofte die de objectgeoriënteerde technologie heeft laten liggen zal kunnen inlossen.
Softwarecomponenten zijn heel goed te vergelijken met IC’s en interfaces vertonen grote overeenkomst met hardware-bussen. Daardoor zal in de toekomst de software- systeemontwikkelaar over gelijksoortige technieken beschikken als waar nu de hardware-ontwikkelaar over beschikt. Dit zal de tijd om een product op de markt te brengen aanzienlijk bekorten.
Hans van Leunen is senior system software architect bij Philips Semiconductors
Deel 1
In het eerste artikel (Computable, 22 januari) behandelt de auteur uitgebreid de voordelen van de softwarecomponenten-technologie ten opzichte van object-oriëntatie. Hij spreekt de verwachting uit dat de markt voor dergelijke componenten een grote vlucht zal nemen en vindt dat deze componenten bij uitstek geschikt zijn om een open markt te bedienen.
Bovendien maakt hij duidelijk waaraan een toekomstig ontwerp- en bouwsysteem voor toepassingen op basis van softwarecomponenten moet voldoen. En naast een heldere beschrijving van de techniek doet hij ook enkele suggesties welke doelgebieden voor softwarecomponenten-technologie in aanmerking komen.
