Het succes van SAP R/3 is een sleutelfactor geweest voor het partitioneren van code in meerdere lagen. In feite gaan we weer terug in de tijd, van dikke clients naar klassieke transactie-architecturen. De meeste mainframe-applicaties hebben gepartitioneerde code, bijvoorbeeld transactiecode (Cics-programma’s), presentatiecode (BMS-panels) en gegevens (DB2, Vsam en dergelijke).
Maar terwijl de cirkel gesloten is, is er geen enkele behoefte aan de problemen van vroeger, zoals de enorme transactiemodules en de domme, karaktergeoriënteerde interfaces. De nieuwe 3-tier architectuur werkt grafische interfaces en kleine transactiemodules in de hand. Hierbij worden herbruikbare business-componenten steeds belangrijker; er zullen specifieke front-ends worden ontwikkeld om deze voorgedefinieerde componenten te kunnen gebruiken.
Het concept van herbruikbare componenten, zowel voor de server als voor de gui front-end, is weliswaar zeer wenselijk, maar zal niet van de ene op de andere dag plaatsvinden. In elk geval hebben de ontwikkelaars van deze componenten goede tools nodig. De ontwikkeling van zulke tools moet dan ook doorgaan, of het nu voor eigen gebruik of voor gebruik door softwarehuizen is.
Voor de ontwikkeling van een multi-tier architectuur zijn uiteenlopende vaardigheden nodig. De ontwikkelaar van gemeenschappelijke business-modules moet op de hoogte zijn van transactiediensten, beveiliging, foutherstel en efficiency. De desbetreffende modules moeten door en door getest en gedocumenteerd zijn; als ze eenmaal geïnstalleerd zijn, kan er niets meer aan worden veranderd, omdat alle client-programma’s daardoor aangetast zouden worden. Er moet ook iemand verantwoordelijk zijn voor de database; deze persoon moet samenwerken met programmeurs om specifieke database-functies, zoals opgeslagen procedures, te kunnen realiseren.
Systeemprogrammeurs zullen in trek blijven, vooral bij de leveranciers van tools. Er moeten nu eenmaal mensen zijn die TP-monitors, besturingssystemen, device drivers, programmeertools en dergelijke ontwikkelen. Er zal slechts een geringe behoefte zijn aan interne systeemprogrammeurs. De interne ontwikkeling zal zich steeds meer richten op programmeertools op een hoog niveau, waarbij herbruikbare componenten zoveel mogelijk worden gekocht en, indien nodig, zelf kunnen worden ontwikkeld. Helaas is het nu de trend om lagere talen te gebruiken, waarbij klassebibiliotheken worden gebruikt om de tekortkomingen in de syntax te ondervangen. De belangrijkste talen zijn Visual Basic en C++, maar Java is net zo beperkt. Alleen Cobol en PL/1 (en RPG voor de AS/400) ondersteunen business-code, zonder afhankelijk te zijn van externe procedures. De ontwikkeling van 4GL’s en tools voor codegeneratie was veel beter geweest dan de ontwikkeling van nieuwe 3GL’s.
Klassebibliotheken bieden grote voordelen bij het ontwikkelen van overdraagbare code. De hoofdprogramma’s roepen functies vanuit klassebibliotheken aan. Om een applicatie naar een ander systeem te poorten is een volledige verzameling systeemspecifieke klassebibliotheken nodig. Neem bijvoorbeeld klassebibliotheken voor TP-monitorfuncties voor Cics, Tuxedo en MTS, zodat de programmeur verschoond blijft van specifieke monitor-api’s. Hetzelfde geldt voor andere diensten, maar het wordt moeilijker naarmate de basisfuncties van het besturingssysteem zich op een hoger niveau bevinden.
PC-applicaties in C++ worden dus vaak ontwikkeld met Microsoft Foundation Classes, die niet beschikbaar zijn op een niet-Microsoft besturingssysteem. Met name ondersteuning voor Ole is beperkt tot Windows-systemen.
Om overdraagbaarheid te realiseren, moeten de klassebibliotheken dieper zijn, zodat de platform-afhankelijkheid wordt geëlimineerd. Een voorbeeld is Visix Galaxy, waarmee gui-applicaties kunnen worden gepoort tussen Windows, Unix en Mac. Dit is echter vrij kostbaar. Softwarehuizen zouden moeten investeren in tools als Galaxy, maar interne ontwikkelaars hoeven zelden voor meerdere platforms te ontwikkelen en mogen dus best een specifieke verzameling tools gebruiken.
Java biedt prima mogelijkheden om de eisen te vereenvoudigen, omdat de Java Virtual Machine nu gedefinieerd is en op de meeste platforms kan worden geïmplementeerd – niet alleen voor gui-programma’s, maar – in theorie – ook voor servers. De Java object-bibliotheken (Beans) moeten net zo uitgebreid worden als de huidige Cobol-compilers, 4GL’s en C++-libraries, anders kunnen ze daar nooit mee concurreren. Een en ander gebeurt wel op client-niveau, maar is op server-niveau nog veel minder zichtbaar. Een Cobol-programmeur die een Tuxedo of Cics client-api gebruikt kan bestaande database-, transactie- en beveiligingsfuncties, die al tientallen jaren bestaan, gewoon uitvoeren. Waar zijn nieuwe, concurrerende Java-virtuele machinefuncties en bibliotheken?
Concluderend stem ik nog steeds voor Cobol op de server, met een client tool die remote procedure calls voor de TP-monitor ondersteunt. De gedachte aan Visual Basic of PL/SQL voor de server maakt me misselijk. Geïntegreerde case-tools en codegeneratoren moeten wel volgen, met ontwikkeling voor meerdere platforms in het achterhoofd. Waarom softwarehuizen het op een andere manier doen, is voor mij een groot raadsel.
