Subject: C431 JGSI Review Resent-Date: Thu, 30 Sep 1999 23:18:50 -0400 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Sun, 19 Sep 1999 20:56:44 +0100 (BST) From: Omer F Rana To: gcf@npac.syr.edu (Geoffrey Fox) C431:Ajents: Towards an Environment for Parallel, Distributed and Mobile Java Applications a) Overall Recommendation ====================== A good paper. Provides a good overview of migratable objects, and distinguishes them from Agent based migration in libaries such as Aglets and Voyager. b) Words suitable for authors ========================== 1. Is (1) Remote Object Creation on page 1 completely true? Can Java objects not be created remotely using object-by-value calls? Perhaps, this should be mentioned in the context of other systems (or with reference to other systems), that enable this to be done. 2. What are the limitations of (4) Object Migration (page 2). For instance, thread migration may not be possible, so how is checkpointing achieved in this case. Perhaps limitations should be outlined briefly here. 3. When a comparison is given between Mole, Aglets and Ajents, it is said that remote objects lose ties to the original client who created the object. Is this true? Aglet implements the MASIF/MAF protocol that enables agents to be identified at any point in time (also using Aglets local and remote proxy, and AgletContext()). Moreover, this is essential, as agent migration will require messages to be forwarded to them in the future. Further, there is nothing preventing a Java developing using Aglets to assert as much control as they need. Its just that most of this is not required, but a programmer can still do a lot of clever things with stationary agents in the Aglets framework. I think that since you clearly outline that you are developing mobile objects and NOT mobile `agents', you do not need this type of comparison. 4. There is no mention of the Voyager toolkit -- which clearly identifies that it uses `mobile objects' and not mobile agents. This is perhaps closer to what you are doing. See http://www.objectspace.com/ 5. In section 3.2, does the additional of a different class loader impact the JVM in any way? 6. In section 3.2, the use of JAR files to combine different class files is specified. In web servers there is generally a codebase, and generally the technique uses push. What happens if there are shared JAR files between Ajents? If a client were to download an Ajent object (or if an Aject object were to migrate to another host), what happens if JAR archives share the same files in a directory structure. Is there a problem with this? Can files be overwritten? In general this is resolved through CLASSPATHS in a non-migratable situation, however, since the user does not have CLASSPATH definitions (as you suggest), how is this problem resolved in Ajents? 7. In code sample of figure 1, how does the register() method get updated information about server loads? How often is this done? 8. What happens if an object migrates multiple times. In figure (3) do you need forwarders (as in Voyager) to send messages between moving objects? Or is there a central site that keeps track of which object is where at any given time? 9. In section 5, second column, third paragraph, the granularity of Ajent based computation is commented upon. Is there ever a possibility that the granularity of an Ajent object can be adjusted to make it viable alternative to something like MPI? 10. Is reference 15 correct? I am not sure there was a Java meeting in June? c) Words for Prof. Fox =================== Perhaps the authors would consider writing a paper for the special issue on `High Performance Agent Systems'?