In deze blog beschrijf ik een aantal andere architectuur stylen dan reactive die er zoal zijn geweest in de tijd. In een andere blog kunnen we die dan eens vergelijken met Reactive.
Batch
In de tijd dat computers verschrikkelijk duur waren en goed opgesloten in airconditioned ruimtes was batch de dominante stijl van verwerking. Je levert een doos met ponskaarten in bij het rekencentrum. Het rekencentrum verwerkt de input, en de (meestal de volgende dag) kun je een pak papier, de output weer ophalen, en dan blijk dat de compiler een fout in je (COBOL) programma heeft gevonden, de run niet is doorgegaan, en de volgende keer beter.
Dit klinkt niet erg agile, maar batch verwerking heeft wel degelijk voordelen.
- Een run heeft een gecontroleerde begintoestand en eind toestand. Het is makkelijk te corrigeren (databases waren er nog niet), je leest een input tape en schrijft een output tape.
- Het is allemaal goed te plannen en te beheerbaar.
- Throughput is optimaal. (De response tijd niet)
Timesharing
Meerdere gebruikers delen dezelfde machine. Dit was kostenbesparend in de tijd dat computers kostbaar waren, en gebruikers kunnen sneller werken. In deze tijd van Cloud computing is dat allemaal vervallen als voordeel. Een dingetje is nog van belang:
- Gebruikers kunnen gegevens delen.
Real-time systemen.
Een systeem om een staalwals te besturen bijvoorbeeld. Een plaat staal begint zijn leven als enkele decimeters dik, en vele honderden graden heet. Langzaam rolt het de wals-straat binnen en wordt uitgerold tot minder dan een millimeter dikte. Dan gaat het allemaal loeihard, en dan moet een staalwals binnen enkele milliseconden bijgestuurd kunnen worden om een gelijkmatige dikte te kunnen krijgen.
- Het reageert op tijd. Er geldt een exacte tijd die altijd gehaald moet worden. Dan is het snel genoeg of anders te traag, en dan werkt het niet.
- Het is dus niet zo snel mogelijk, nee binnen de gespecificeerde tijd is goed genoeg.
- En die gespecificeerde tijd kan ook minuten of uren zijn, een chemisch proces is iets anders dan straaljager. Beide hebben realtime besturing nodig.
Transactie monitor.
Grote aantallen gebruikers bedienen gaat niet met een timesharing systeem. Iedere gebruiker heeft een eigen proces en dat schaalt niet. We moeten meer gebruikers met minder processen laten werken. Dus wat nieuws uitgevonden, een transactiemonitor, die kan 1000 gebruikers bedienen met 50 processen.
De gebruiker vult een formulier in, en drukt op “transmit”. De TP monitor plaatst het bericht een queue, en zodra een proces beschikbaar is wordt het bericht verwerkt en een response gegeven. Omdat het gaat om korte transacties, worden de queue’s niet al te lang, en zo kunnen we goede responsietijden halen.
Dit best wel mooie technologie. Het had grote voordelen.
- Het dwong programmeurs om programma’s als kleine modules te ontwikkelen. Alleen al hierdoor werd de productiviteit zodanig verbeterd, dat COBOL projecten soms beter scoorden dan 4Gl’s.
- Die 50 server processen kunnen optimaal getuned worden op de achterliggende database structuur. Je doet niet 50 processen die allemaal hetzelfde kunnen doen, nee vijf processen die updates doen en 45 die lezen. Minder kans op database locking of resource contention. Nog subtieler om lees processen te specialiseren naar database gebieden. Zo kun je de hardware naar de limieten pushen.
- Goede grip op prestaties, beschikbaarheid, failover mogelijkheden. Goed beheerbaar.
- Sommige TP-monitors hadden messaging faciliteiten, waarmee transacties in persistente queues konden worden gezet, waardoor efficiency en loose coupling kon worden bereikt.
Appservers en Object-oriëntatie
Het OO paradigma leek een veelbelovend concept. De eerste pogingen om tot OO middleware te komen zoals CORBA en J2EE hebben nog niet veel bruikbare middleware opgeleverd. Gedistribueerde objecten bleken kwetsbaar, en niet schaalbaar. J2EE was ook nog gebaseerd op deze concepten, het was bewerkelijk om applicaties te bouwen, en transacties lekten dirty data via beans.
Inkapseling was een belangrijk principe dat voor ogen stond. Tja, als je een database met goede prestaties en goede transactie isolatie gaat inkapselen dan kun je eindigen met een database die slecht presteert en gegevens corrumpeert. De praktijk is dat ik vaker heb gemigreerd naar een andere appserver, dan naar een andere database.
Maar goed, inmiddels zijn we door deze kinderziektes heen. Dankzij opensource Spring en Hibernate is er een werkbare standaard ontstaan. En met een moderne appserver kun je goede applicaties bouwen. De eigenschappen zijn:
- Standaards. Http, Webservices, REST, Xml, Json, Html JEE, het werkt allemaal behoorlijk op dezelfde manier. Daardoor is makkelijk kennis, componenten en frameworks te hergebruiken.
- Productiviteit. Het is niet zo heel veel minder werk om een functie te bouwen op een appserver als op een TP-monitor, maar het functioneert allemaal in veel complexere wereld, met ajax, rich clients, apps, tablets, devices, e-commerce en Ldap servers. Dat is wel iets anders dan een character-cell terminal met forms pakket.
- Beheerbaarheid. Ook appservers hebben faciliteiten voor failover loadbalancing, clustering, waardoor hoge service niveau’s kunnen worden gehaald.
- Threading en garbage collection. De processen van de TP-monitor zijn vervangen door threads binnen een proces. Dat is efficiënter, maar als programmeur moet je er wel rekening mee houden.