I enclose 3 Referee reports on your paper. We would be pleased to accept it and could you please send me a new version before November 5 99 Please send a memo describing any suggestions of the referees that you did not address Ignore any aggressive remarks you don't think appropriate but please tell me. I trust you! Thank you for your help in writing and refereeing papers! Referee 1 *************************************************** C431: Ajentx: Towards an Envionrnment ... Izatt, et al This paper presents an Ajents system to support Java-compliant parallel, distributed, and mobile applications. The Ajents is essentially a communication infrastructure in support of remote object creation, remote classloading, asynchronous RMI, and object migration. While they are all important, the four features seem nothing new and their implementations are actually demonstrations of Java's RMI and object serialization facilities in some tutorials. Unfortunately, the paper presents no more or deeper information than the tutorials. For example, -- remote object creation is commonplace in any Java-based agent systems. JavaWorld has a tutorial (December 1997) about how to implement it. -- Voyage on-line document has a case study and coverage about object migration based on checkpointing and rollback. -- RMI provides direct support for asynchronous RMI; JavaWorld (December 1998) has an illustration of this. An early coverage about this should be in its tutorial column around 1997. -- Remote classloading based on JAR is also available from Sun's Java tutorial document. The paper presents some experimental results about each individual feature. However, it lacks experiments to show the overall performance of the Ajents. The matrix multiplication is too trivial to show any thing about Ajents' features in support of parallel, distributed, and mobile applications. Referee 2 **************************************************************** Subject: C431 JGSI Review 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? Referee 3 *********************************************************** Subject: C431 JGSI Review a) Overall Recommendation: accept b) Comments to the authors: The paper presents Ajents, a software infrastructure geared to support parallel and distributed Java applications. It is written entirely in Java, thus making it highly portable, and does not modify the language so that specific compilers/preprocessors are not needed. Instead, the design is based on a set of Java class libraries. The paper is easy to understand and well written. The research presented is technically sound and introduces some novel features that distinguishes it from other such systems. For instance, the ability to dynamically create remote objects in Ajents is a big help for programmers, who previously had to statically deploy remote objects before they could invoke remote methods. Also, the asynchronous RMI feature is a big improvement, since it is now possible to overlap communication and computation, thus potentially increasing the performance of an application. Perhaps the most impressive feature of Ajents is its object migration capability. This seems particularly useful in heterogeneous network environments where individual users might reclaim the full use of their workstations at any time, making the retreat of a distributed application running in the background necessary. Ajents permits this kind of graceful retreat without the high cost of losing all previous work. The loss of work is restricted to only the very last remote method invocation, since it is not easily possible to save the state of the currently executing method. The main downside of the authors' choice to provide class libraries is that the standard RMI interface cannot be used with Ajents. Instead, the user must make all RMI calls through the corresponding Ajents methods, which seem slightly less intuitive than plain RMI (the programmer must keep track of remote objects and address them differently, and must provide method names and arguments as parameters to the Ajents.rmi()/Ajents.armi() methods). In light of the additional features gained by Ajents this seems a small price to pay. The authors give performance numbers for their system which indicate that the overhead of using Ajents is mostly negligible. Compared to standard RMI, there seems to be some overhead when small objects are sent as parameters. This seems to go away as object sizes increase, probably due to the fact that the cost of sending large objects is dominated by object serialization. The speedup figures for a simple matrix multiply application are within normal range, thus demonstrating the general usefulness of using Ajents. The cost of migrating an object again increases with object size, which can be attributed to object serialization. However, the overhead can be heavy, which can be prohibitive for some applications, particularly fine-grained ones with a short overall running time. The authors state in their discussion that the system is best suited for coarse-grained applications which run for long periods of time. It would be nice to see how Ajents performs with more applications, perhaps a set of benchmarks with different characteristics. The single matrix multiply benchmark may not be enough to convince some people to use this system. The checkpoint consistency problem mentioned by the authors seems to be difficult and definitely needs looking into. Finally, the authors should update some of their references in the related work section, especially since some of the work was superseded at ACM Java Grande. For example, the Javelin global computing infrastructure now has a successor, Javelin++, which switches from applets to applications and also has remote class loading and (in a limited way) remote object creation capabilities. In addition, the Bayanihan infrastructure is a notable contender in this field. Also, the authors should take note of some recent work at UC Santa Barbara by Murat Karaorman on Active Objects/Active RMI. This work also supports asynchronous RMI and remote object creation, although it does not provide object migration. Active Objects uses a modified RMI stub compiler to achieve its objectives. Here is the complete reference: "Active-RMI: Active Remote Method Invocation System for Distributed Computing Using Active Java Objects." In TOOLS USA '98 Proceedings(August 3-7,1998, Santa Barbara, California.) Copyright 1998 IEEE. pp.414-427.