Gedistribueerde verwerking wordt tegenwoordig gelijkgesteld aan downsizing: het vervangen van grote mainframes door kleine afdelingssystemen. Deze wijze van verwerken begon in de jaren tachtig met de groei van Digital en de producten Vax/VMS en Decnet. Inmiddels hebben Unix- en TCP/IP-netwerken van verschillende leveranciers het gedistribueerd verwerken ingehaald.
Er zijn veel voorbeelden waarbij deze aanpak succesvol is gebleken, maar er zijn waarschijnlijk nog veel meer mislukkingen aan te wijzen. Het belangrijkste probleem vormt het gemeenschappelijk gebruik van gegevens. Als elk geografisch gespreide afdeling met haar eigen gegevens kan volstaan, bieden simpele file-transfers van en naar een centrale site een redelijk goede oplossing. Dit eenvoudige concept werd nieuw leven ingeblazen met een iets geavanceerdere techniek, namelijk het robuuste ‘message queueing’. IBM’s MQ-serie domineert deze explosief groeiende markt, maar houdt Microsofts MSMQ (Falcon) voor NT-platforms nauwlettend in het oog.
De onnozelste mislukkingen doen zich voor als men probeert een gedistribueerd systeem in een inherent centralistische omgeving in te zetten. Heeft het bedrijf een gespreid karakter, dan kan gedistribueerde verwerking een optie zijn; wie echter een centraal systeem simpelweg vervangt door een aantal kleinere machines die lokaal aan elkaar zijn gekoppeld, vráágt om problemen. Slechts de kosten kunnen hierdoor toenemen.
Voordat we verder gaan moeten we eerst opmerken dat er één randvoorwaarde is die maar al te vaak over het hoofd wordt gezien: applicaties moeten er speciaal voor ontworpen zijn om in een gedistribueerde omgeving te kunnen draaien. Het heeft geen zin om centrale applicaties te poorten. Als bijvoorbeeld gebruik wordt gemaakt van ‘message queueing’, dan zijn de applicatiefunctie en de database op de gedistribueerde locatie volstrekt anders dan de applicaties en de database op de centrale site.
Het wordt nog ingewikkelder als de gedistribueerde sites niet alleen met de centrale site, maar ook met elkaar moeten communiceren. Een ander verschil zit hem in de toegepaste fundamentele computerarchitectuur. Mainframes ondersteunen een mix van batchverwerking en interactieve verwerking; Unix heeft goede interactieve mogelijkheden maar een zeer magere batchfunctie en NT wordt alleen voor client/server gebruikt! Er bestaan TP-monitors voor Unix en NT, maar hiermee is nog niet zoveel ervaring opgedaan als met Cics. Met deze verschillen moet rekening worden gehouden bij het ontwerp van applicaties en databases.
Centrale sites kunnen vertrouwen op een snel lokaal netwerk, terwijl sites op afstand gebruik moeten maken van openbare netwerken. De laatste zijn trager, minder betrouwbaar en duurder dan lokale netwerken. Dit betekent overigens niet dat een applicatie lokaal sneller werkt dan op afstand, het betekent dat bij het ontwerp van een applicatie rekening moet worden gehouden met communicatiefactoren.
Een andere grote invloedsfactor was client/server-verwerking met PC’s, een van de vele varianten van gedistribueerde verwerking. Deze keer werd het nog complexer dan het al was, omdat client-applicaties grafisch zijn (waardoor ze moeilijker getest kunnen worden dan eenvoudige karaktergeoriënteerde interfaces). Bovendien is er in deze opzet één computer per gebruiker; dit leidt tot een explosie van het aantal computers in het netwerk, met de bijbehorende beheersproblemen en torenhoge kosten. Misschien biedt de volgende generatie NC’s met webbrowser en lan-technologie een oplossing, maar niet binnen afzienbare tijd.
De eerste client/server-applicaties waren gebaseerd op een dikke client, waarbij alle code op de client-PC draaide, met een gemeenschappelijke database-server op basis van relationele technieken en SQL (Odbc).
De onderhoudsproblemen en kosten zijn rampzalig. Nog erger is dat deze architectuur geleid heeft tot ontwikkeltools (hilarisch genoeg ‘rapid’ application development of rad genaamd) die de code voor het grafisch interface vermengden met de logica van de applicatie. Dit heeft geleid tot de huidige legacy-nachtmerrie. Nu zien we de opkomst van het ‘dunne’ client-model dat ik al zo’n twintig jaar geleden heb voorgesteld. In dit model is de presentatiecode gescheiden van de applicatiecode zelf. Door de database-code te scheiden van de applicatiecode, waardoor een drielagenmodel ontstaat, werd dit model verder ontwikkeld.
Het eerste probleem dat het ‘dunne’ client-model oproept is dat slechts weinig ontwikkelaars begrijpen hoe een applicatie in verschillende delen moet worden gesplitst, zodat de presentatiecode is gescheiden van de applicatiecode. We moeten het gebruik van moderne objectgeoriënteerde ontwikkeltools zo veel mogelijk versnellen, omdat de partitionering hierbij automatisch geschiedt. Maar van de molensteen Visual Basic moeten we wel af.
Er is een nieuw tijdperk aangebroken. Dit wordt nog meer benadrukt door het gebruik van webtechnologie met Java en Activex als opties.
