The complexity of the Java EJB architecture is way overdone as far as I am concerned.
|Monday, 11th October 2004
- Yes, how nice that you
distribute processing over various machines
- But do not put
99.99% of the systems do not need any load balancing.
The principle that it
should should be possible
to distribute processing, makes Java uncessary complex:
- Objects always must be approached through a
The programmer must write 3 classes instead of one, ignoring the automatically generated stub and skeleton.
- Deploment descriptors were created to keep the code
These deployment descriptors are yet another programming language, with a syntax that differs distinctly from Java, another bug source.
- We step back in time, at least 15 years towards primitive memory management.
A garbage collect does not work well in a distributed environment.
So the programmer has to release objects, a big step backwards.
So why are EJBs a success?
- Managers assume that their system is one of the biggest around and needs load balancing.
The last thing they want is to be overclassed in system size by the competition.
- EJB's have become a status symbol.
To be relevant you have to use EJB's.
- Techical people love technology, the more the marrier.
They apply EJB's, even when not beneficial.
There is an easier way.
It must get simpler.
Not because of the be-the-biggest competition, but for the sake of mobility.
The future of internet is mobile.
Distributed processing is the way to go for the future.
PDA's and phones get more and more functionality, lots of different platforms, perfect for Java.
Java must simplify
to stay popular among a large group of software developers.
- Every object runs on only one machine.
Objects never know any object on another machine.
- Objects can send messages to another machine, yet never addressing one specific object,
Messages always have primitive parameters, never objects.
- It is possible to download class definitions from other machines.
Those class definitions are best on one central location to keep software control simple.
The principles lead to an astounding simplicity, yet without loss of functionality and technical possibilities.
- Load balancing and distributed processing remain possible.
- Every machines has full control over its own memory.
So the garbage collector regains his job in it's full glory.
Automatic memory management is back.
- The complex deployment descriptors are redundant.
A few URL's of directories for Java classes suffice.
- The home and remote interfaces are redundant.
An object model will resemble reality again, close to a logical, conceptual model.
- The technology on other machines nicely becomes irrelevant.
Interfacing a PHP system is just as easy as a Java system.
Real life example
SUMit recently built an advanced route planning application in Java.
In this example the client is a Java applet that downloads Java class files from a webserver.
The server side code is in PHP, pleasantly transparent for the Java client.
Routeplanning in Java
1. The client asks the server for address information
||2. The server sends the address of the class files and bulk parameters.
3. The client loads the required class files from the webserver.
||4. The webserver accesses the .class files
5. The client requests bulk input from the server, raw data for the route planning.
6. The server gets the raw data and sends it in an agreed format.
|7. The client creates objects.
Those client objects execute a complex route planning algorithm.
|8. The client sends the generated route to the server.
||9. The server saves the route.