Gedistribueerd |
maandag, 11 oktober 2004 |
De Java EJB architectuur is me onnodig complex.
- Ja, het is prachtig om processing over diverse machines te
kunnen
verdelen.
- Maar laat
kunnen
geen
moeten
worden.
Voor 99.99% van de systemen is load balancing niet nodig.
Ballast
Het uitgangspunt dat processing gedistribueerd
moet kunnen
zijn maakt Java nodeloos complex:
- Objecten moeten altijd benaderd worden via een
Home interface
en
remote interface.
De programmeur moet 3 classes schrijven in plaats van één, de automatisch gegenereerde stub skeleton classes nog buiten beschouwing gelaten.
- Om de code
generiek en
platform onafhankelijk te houden zijn deployment descriptors ontstaan.
Dat is een soort programmeertaal erbij, met een compleet andere syntax dan Java zelf, een extra bron van fouten.
- We gaan 15 jaar terug in de tijd naar primitief memory management.
Een garbage collect werkt niet lekker over meerdere machines.
De programmeur moet dus weer zelf objecten vrijgeven, een grote stap terug.
Waarom zijn EJB's zo'n succes?
- Managers denken al snel dat hun systeem erg groot is en load balancing nodig heeft.
Ze willen beslist niet voor de concurrentie onderdoen.
- EJB's zijn een status symbool geworden.
Wie mee wil tellen gebruikt EJB's.
- Techneuten zijn dol op techniek, hoe meer hoe beter.
Ze passen EJB's toe, ook wanneer ze geen toegevoegde waarde hebben.
Alternatief
Het kan eenvoudiger.
Het moet simpeler.
Niet vanwege de wedijver om het grootste systeem, maar om de mobiliteit.
Internet wordt mobiel.
Distributed processing heeft de toekomst.
PDA's en telefoons krijgen steeds meer functionaliteit, veel verschillende platforms, perfect voor Java.
Java moet eenvoudiger worden
om een grote groep software ontwikkelaars te kunnen blijven aanspreken.
Nieuwe uitgangspunten:
- Elk object draait maar op één machine.
Objecten op verschillende machines kennen elkaar nooit.
- Een object kan wel een bericht sturen naar een andere machine, maar nooit specifiek aan één object gericht, altijd in de vorm van primitieve data, nooit objecten.
- Het is wel mogelijk om class definities te downloaden van andere machines.
Die class definities staan het liefst maar op één locatie om het software beheer eenvoudig te houden.
Eenvoud
De uitgangspunten leiden tot een verbazingwekkende eenvoud, zonder verlies van functionaliteit of technische mogelijkheden.
- Load balancing distributed processing blijven mogelijk.
- Iedere machine heeft volledig beheer over eigen geheugen.
De garbage collector kan dus weer in volle glorie zijn werk doen.
Automatisch memory management is terug.
- De complexe deployment descriptions zijn overbodig.
Een paar URL's van directories met Java class files volstaan.
- De home remote interfaces zijn niet meer nodig.
Een objectmodel komt daarmee weer dichterbij de werkelijkheid, dichterbij een logisch, conceptueel model.
- De techniek op andere machines wordt prettig irrelevant.
Het wordt net zo makkelijk om te interfacen met een PHP als met een Java systeem.
Praktijkvoorbeeld
Onlangs heeft SUMit een geavanceerde routeplanningsapplicatie gebouwd in Java.
Voorbeeld |
Client |
Server |
Webserver |
Routeplanning in Java
|
1. De client vraagt de server om adres informatie
|
2. De server stuurt de adres info van class files van bulk input parameters.
| |
3. De client laadt de nodige class files van de webserver.
|
|
4. De webserver verzorgt file accessen voor de .class files |
5. De client verzoekt de server om de bulk input, ruwe data voor de routeplanning. |
6. De server haalt ruwe data op stuurt deze in een afgesproken formaat.
|
|
7. De client maakt objecten aan.
Die client objecten voeren een complex routeplanning algoritme uit.
| |
|
8. De client stuurt de gegenereerde routes naar de server.
|
9. De server slaat de route op. |
|
In dit voorbeeld is de client een Java applet die de Java class files van een webserver downloadt. De server side code is in PHP geprogrammeerd, prettig transparant voor de Java client.
Tot
de volgende noot,
Henk Jan Nootenboom