Multiple Servers (Scalability)

The web browser doesn't make it easy for a Java applet (or JavaScript) to talk to more than one server, but it can be done. To allow planOfile to scale for a large number of users, the client has been designed to communicate with a large number of servers when reading data. More servers can be added easily, as required, and used by planOfile clients. planOfile clients can communicate with multiple servers in parallel. The system currently uses two servers.

planOfile also only requires a minimum of HTTP:Get from the read servers. This minimum requirement means that just about any web server on the Internet could provide data for planOfile. It also means that the servers don't need to do much processing to handle a request and consequently should be able to process a higher rate of requests. There is no reason why the planOfile client could not use HTTP:Get to one server and web services or HTTP:Post to another server to retrieve data. Currently planOfile uses different methods to communicate to its two different servers; HTTP:Get to one server and HTTP:Post to the other.

Working past browser security to allow multiple server capability from the client turns out to be relatively simple. There doesn't seem to be a description of how to do this on the Internet so it will be described here. This was found with a few days of trial and error, so there may be a better solution. Since this solution works there has not been any further investigation.

JavaScript and Java can only phone home (if unsigned). Home for JavaScript is the server providing the HTML page. Home for Java is the server providing the Java applet. The important point to note is that a Java applet does not need to come from the same server as the HTML page. In fact, a Java applet that originates from a different server to the HTML page cannot talk to the server providing the HTML page.

So the idea is to have all servers that the planOfile client communicates with provide a small proxy Java applet, which I call a proxlet, that runs on the planOfile client browser and thus is allowed to communicate with the respective server. This actually doesn't break the browser security since the server is providing the proxlet. Thus only servers wanting to receive communication from the planOfile client will provide a proxlet. In fact, the proxlet concept provides some configurable security since the proxlet creator can limit what functionality the proxlet can provide and what parts of the server the proxlet can access. Of course the proxlet (in general) can only access already publicly accessible functionality provided by the server anyway, so there is no additional security issue. The real advantage of the proxlet is that it allows JavaScript and Java applets to work around browser security and communicate with multiple servers.

The proxlet's for all servers need to be included in the web page. This can be done when the page is created or dynamically when communication with that server is required. After all, it' just creating the applet tag with the required applet data for that server.

A Java applet can only talk to other Java applets that originate from the same server. They cannot talk to Java applets from another server. But Java applets can talk to JavaScript and JavaScript can talk to Java applets. Calling JavaScript from a Java applet is done using the JSObject provided eval() function. This runs the given string of JavaScript commands. JavaScript can directly call Java applet functions.

Java security seems to remember the applet calling the function. There were some problems like this that gave permission errors, but the exact reason was not investigated. There was also problems with the threading model on Linux which would lock up if there were not enough events created. The aim is to keep using events so that the owner of the call appears to be lost. So when the planOfile applet wants to send a message to the server it causes a Swing thread event handler to run which then calls the JSObject eval() function with the JavaScript that has message to be sent. This JavaScript then causes an event and the handler calls the proxlet Java applet function to send the message. The proxlet function creates an event on the Swing thread and the handler for this event then talks to the server in a way defined by the proxlet. The aim of all this event calling is to try to change the owner of function call to be the owner of the event handling thread. This seems to work fine whereas trying to call from one applet through JavaScript to another applet did not work reliably.

One of the parameters to the function call of the proxlet is a string containing the callback function for the results from the server. Thus the proxlet's reply just calls JSObject eval() on the callback string with the results appended to it. The proxlet's result handling should be in the Swing thread, the called JavaScript should cause an event handler to consequently call the originating planOfile applet's callback function for this message. Internally that callback function will pass the message to be handled in the Swing thread which will probably pass it to another thread.

At the moment it is not known which event processing could be replaced with a direct function call. Since these messages are only for reading and writing data to the servers, they aren't called very often. So the overhead of causing events isn't considered a significant problem at the moment.