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