Dynamic Code Update in JDRUMS

Pervasive devices get more and more powerful. More powerful devices imply more complex software. In turn this implies bugs and requirements of new features. This paper presents a technique that allows Java programs to be updated during run−time. The Java program needs no preparation to be updateable. The software is updated during normal operation and requires no user interaction. A prototype system that demonstrates the technique is also presented. INTRODUCTION As computers become more and more powerful, their software becomes more and more complex. And as software become more complex, the number of patches increases. This paper introduces a technique, the Java Distributed Run−time Update Management System (JDRUMS), to update Java programs without any need of user interaction. Using JD RUMS, systems can even be updated while they are operating. The software in a cellular phone can for example be updated during a phone call. JDRUMS is not limited to small patches, but can also be used to add functionality, to change the structure or even the architecture of an application. The benefit of a system like this is huge [1]. Instead of collecting all devices, or having service technicians travel around the world to install updates, the update can be distributed, e.g. over the Internet, and installed on every device, without the users knowing about it. JDRUMS uses update servers and client, where the servers provide the updates to the clients, which can be any gadget running the JD RUMS JVM. The JDRUMS JVM does not set any restrictions on Java. A primary goal of JDRUMS is transparency. The programs being update need not be designed for JD RUMS, any Java program can be used (not even the source code is necessary.) We have a prototype implementation of JD RUMS running on several platforms such as Solaris and Windows 2k. UPDATING CODE AT RUN−TIME Several steps have to be taken to update code at run time. First the updated code has to be transferred to the client. If the object representation has changed, the old objects have to be updated. Finally the code can be updated. In most cases the code will be sent over an insecure connection, e.g. the Internet. Clients must be able to protect themselves against malicious persons trying to upload malicious code. Dynamic Deployment The server, the client, or a third part must take the initiative to transfer the update to the client. Most likely you want to keep a third party out for security reasons. One can also question what a third party can contribute with. The server can contact the clients when an update is available. The advantage of this solution is that clients would be updated as soon as the update is available, and it is possible to use broad cast techniques to decrease the use of bandwidth. However, if a client is off−line when the update is distributed the update will not reach the client. A partial solution would be to re−send the update several times, but this would be bandwidth consuming, and clients will still run old code after the update is distributed. The client can also take the initiative. This can be caused by user intervention, or automatically by the application, e.g. as soon as the client goes online. Using this schema the client will always get the update, but the use of bandwidth will increase and the clients will not be updated directly when the update is available. An obvious improvement is to combine these methods, so the server broadcasts the update when it becomes available, and clients check for updates as soon as they come online. This should be enough, but to be sure the user should be able to check for updates if an automatic update fails.