Gespreide verwerking is altijd interactief van aard geweest. Berichtendiensten vormen hierop een welkome aanvulling. De client wordt gekoppeld aan de server voor een sessie met conventionele communicatie-subsystemen. In het algemeen moet de client-applicatie weten waar de server is; dit past goed bij veel nieuwe applicaties maar ontbeert de nodige flexibiliteit, vooral naarmate er meer servers bijkomen en schaalbaarheid belangrijk wordt.
Remote procedure call (RPC) is de geëigende manier om een client aan een server te koppelen. De RPC-software biedt een abstract API aan de programmeur, waarbij details over het onderliggende communicatiemechanisme verborgen worden. Met de juiste RPC-middleware kan dezelfde applicatiecode op verschillende platforms en verschillende communicatie-infrastructuren worden gebruikt. Hiervoor moet de programmeur echter een zekere discipline hebben; lokale technieken, zoals het gebruik van gemeenschappelijk geheugen, zijn in een RPC-omgeving niet beschikbaar.
De voor RPC noodzakelijke discipline is zeer welkom. Het komt de prestatie niet ten goede, maar de noodzaak om het interface ‘schoon’ te houden leidt tot beter onderhoudbare code. Eén groep programmeurs ontwikkelt daarbij de procedures, met slechts één entry point; alle argumenten worden meegegeven in cellen, er zijn geen referenties naar externe gegevens en er is geen toegang tot interne variabelen vanuit andere routines. Deze bibliotheek van procedures wordt op een hoger niveau door andere programmeurs gebruikt. Het probleem hierbij is het houden van toezicht op naleving van dit beleid, waarbij whiz-kids in het gareel gehouden moeten worden. Met primitieve talen als C is dit nog moeilijker.
Een ander probleem is de documentatie. De functie van elke software-component moet duidelijk gedefinieerd zijn, net als de regels voor de programmeurs die deze functie gebruiken. Dit betekent ook dat de functie nauw gekoppeld moet zijn aan het ontwerp, zoals bij case-tools, en dat de technische documentatie en de gebruikersdocumentatie ook bij de invoering van nieuwe versies gesynchroniseerd moet blijven. Conventionele documentatietechnieken maken dit moeilijk, maar niet onmogelijk. We zouden dan ook allemaal de lage profilering van en even lage investering in repositories hartgrondig moeten verwensen.
Er zijn geen speciale tools nodig om met bovenstaande methoden tot herbruikbare elementen te komen, maar er is discipline voor nodig, die gedurende een lange tijd moet worden opgebracht. En dit nu is een belangrijk struikelblok geweest bij eerdere pogingen om software-componenten te ontwikkelen.
Een andere functie van componentontwikkeling is fijnkorrelige modularisatie. Het is relatief eenvoudig om een groot aantal kleine functionele componenten te definiëren en te integreren. Dit moet omwille van een maximale flexibiliteit worden gecombineerd met een run-time omgeving. Voor de meeste transactie-applicaties levert een TP-monitor de noodzakelijke ondersteuning. Maar communicatie tussen verschillende taken via een TP-monitor genereert een enorme overhead vergeleken met een lokale procedure-aanroep.
Ontwikkelaars die componenten gebruikten om relatief kleine transactiemodules te bouwen, liepen al snel tegen prestatieproblemen op. Er was niet veel keus: de transactiemodules moesten worden samengevoegd met behulp van procedure-aanroepen. De performance werd hierdoor verbeterd, maar er ontstonden enorm grote transactieprocessen. Dit is op zichzelf niet zo erg, maar deze grote modules hebben per definitie zoveel kruisverwijzingen dat ze alleen door een team van programmeurs kunnen worden onderhouden. Het verdubbelen van de omvang kan de onderhouds- en testproblemen gemakkelijk verviervoudigen. Dit geldt natuurlijk niet alleen voor mainframe TP-applicaties maar ook voor PC-toepassingen.
Tegenwoordig is alles anders. (Of tenminste, dat zou het moeten zijn.) Hardware bedraagt nog maar een klein deel van de kosten van een applicatiesysteem, ongeveer 10 tot 15 procent. Onderhoud is waarschijnlijk de grootste component; denk eens aan de kosten van het opwaarderen van al die monolithische Visualbasic-software!
Case-tools zijn nu volwassen en de ontwerpfuncties kunnen niet alleen van dienst zijn bij het partitioneren van code voor client en server, maar ook bij modularisatie van code. Case-tools kunnen weer worden gekoppeld aan repositories. Men is echter huiverig voor deze strategische investeringen door eerdere slechte ervaringen met onvolwassen case-tools en de moeilijk meetbare kostenbesparing.
Met case-tools gedefinieerde modules kunnen door programmeurs eenvoudig misbruikt worden. Er is daarom veel te zeggen voor codegeneratoren, vooral met kleine code-modules. Hergeneratie van code kost tijd, maar kan met de tools van tegenwoordig eenvoudig worden gerealiseerd, behalve als de code groot en monolithisch is. Codegeneratoren kunnen ook veel verschillende talen aan, zoals Cobol en C. In deze omgevingen geef ik nog steeds de voorkeur aan Cobol op de server en zo’n beetje alles op een dunne client, zoals Java. Verrassend genoeg kiezen veel organisaties nog steeds voor C++ op de server. Veel organisaties hebben in het verleden slechte ervaringen met codegeneratoren opgedaan; de tijd is rijp om het nog eens te proberen.
Tools zijn nuttig om modulaire applicaties met herbruikbare componenten te bouwen, maar er is een groeiende vraag naar pakketten met standaardcomponenten voor applicatie-ontwikkeling. Dit voert ons in de nieuwe wereld van de objecttechnologie. De vraag is nu: moeten we standaardtechnieken gebruiken om herbruikbare componenten te bouwen, of moet het pure object-oriëntatie zijn?
