Flexible Cohesive Three to n-tier distributed computing Architecture
The motivation for this design was to solve the short comings I came across on two commercial Frameworks. Short comings were load balancing , connection pooling , imperfect database design.
Java RMI Remote Method Invocation was my first interaction of distributed programming and I have been fascinated with distributed or network programming ever since. From that moment I knew the type of programming I want to specialise.
Simple Industrial Strength System
(cohesion) retval =
One of the most significant capabilities of the Java™ platform is the ability to dynamically download Java software from any Uniform Resource Locator (URL) to a virtual machine (VM) running in a separate process, usually on a different physical system. The result is that a remote system can run a program which has never been installed on its disk.
if you think of CLASSPATH is your "local codebase" , java.rmi.server.codebase is a "remote codebase".
How it works
If the location of your downloadable classes is on an HTTP server named "webvector", in the directory "export" (under the web root), your codebase property setting might look like this:-Djava.rmi.server.codebase=http://webvector/export/
Note: When the codebase property value is set to the URL of a directory, the value must be terminated by a "/".If the location of your downloadable classes is on an HTTP server named "webline", in a JAR file named "mystuff.jar", in the directory "public" (under the web root), your codebase property setting might look like this: -Djava.rmi.server.codebase=http://webline/public/mystuff.jar
Now let's suppose that the location of your downloadable classes has been split between two JAR files, "myStuff.jar" and "myOtherStuff.jar". If these JAR files are located on different servers (named "webfront" and "webwave"), your codebase property setting might look like this:-Djava.rmi.server.codebase="http://webfront/myStuff.jar http://webwave/myOtherStuff.jar"
Remote Method Invocation, RMI is a container managed remote objects framework offering distributed compute engine. Exactly same as stateless EJB , although the description of stateless EJB is usually different. Stateless EJB is described as conversational state this description is relative to Stateful EJB. For persistence I would use a database. This is because as the database grows the application may become sluggish over time. Database is a complex Data Management System. To remedy the sluggish behaviour one can tune the database without affecting the functionality. Tuning is an administrative task and the instructions for tuning can be found in the Database product documentation.
There seems to be different definitions of the Java Bean depending on who you ask. My introduction to a Java Bean is from reading the code used in a JSP :
< jsp:useBean id= "instanceName" scope= "page | request | session | application"
class= "packageName.className" type= "packageName.className"
beanName="packageName.className | <%= expression >" >
< /jsp:useBean >
Bean with page or request scope behaves the same as stateless EJB
Bean with session scope behaves the same as stateful EJB
Bean with Application scope behaves the same as Singleton EJB
Mini Major Services
RMI, a client server framework has a small foot print. The server can be deployed on Raspberry PI which can be connected to any sensor through its pins. Those pins of course can be connected to even Car factory Massive Robots. Actually to relays which run servo motors controlling movements in the massive Robots.
In the event you have a sensor which needs to send updates to a web browser Dashboard. Although the HTTP browser is a stateless pull model, this is still possible with the above protoype, One just needs to integrate socket functionality as demonstrated by the Struts 2 chat application.