Referee 1 **************************************************************** This a nicely written paper with a clear problem definition and a proposed solution. However, the following issues need to be addressed to make the paper more strong: The motivation for not having the remote interfaces (or proxies) on client's machine are not very convincing. It would have been better if a comparative study was made between the author's approach and other alternatives, such as dynamic invocation (e.g., allowed by CORBA). Various issues such as space, consistency, and performance need to be looked into for such a comparison. The idea of using wrapper is not really new, although, it has been used in different ways than what the paper is proposing. An interesting issue to look into would be the amount of effort needed to create these wrappers for more complex problems than the ones described in the paper. Finally, more details are needed (e.g., performance comparison between the standalone and the distributed case) that can validate the claims the authors are making in the conclusion. Referee 2 **************************************************************** E: Referee Comments (For Author and Editor) I am not sure that the problem posed (i.e. instantiating a remote object and using it in remote or local calls) is a major problem in O-O distributed systems (based on RMI, CORBA or JINI), except where access to the server source code is not available or is in a non-Java language. In RMI, object serialisation allows objects to be passed from client to server and vica versa and in CORBA, object references are available through the Naming Service (also the CORBA 3 Objects-by-value facility will help here). Normally, you would want servers to be instantiated independently of clients, although there are occassions where a client invoked server is very useful. Some of the same functionality presented could also probably be obtained on the client side using the new Java Proxy generator class. However, the techniques presented here are interesting and useful and could simplify the design of some distributed systems. They could also be particularly useful in the design of wrappers for remote non-Java objects. F: Presentation Changes I copied the source code listings and compiled them, but some editing (e.g. of capital P's in Public) is required. It would be useful if the complete code were made available generally (you need authorized login to access it). Referee 3 **************************************************************** Summary ------------ This paper focuses on a problem of object-oriented distributed computing, and demonstrates an approach that solves it. The problem is that of having a class of objects on the server and wanting to instantiate objects of the class on the client. Reasons why a client-server implementation would be desirable are given on page 5. The normal RMI model supported by Java encourages the objects to reside on the server, and access to them from the client to be via method calls. If the objects are indeed to be kept on the client, then both client and server needs to have the complete definition of the class, and even then, not all operations are possible, for reasons summarised on page 3. The solution proposed breaks down into three steps: interfaces implementation (wrapper) classes so-called data classes. Interfaces are standard with RMI and the technology cannot work without them. The implementation classes are there so that objects can be constructed on the client side. The disadvantage of this step is that the naming of all the original classes on the client side must change. These wrappers cannot be made transparent. The purpose of the data classes is to reveal the data structure of the original object, presumably so that it can be manipulated at the array subscript level. Now the name of the original remote object class, when referenced on the client, must also change. The paper explains all the above via a simple to understand example of a matrix class and a class which operates on it. Both of these reside on the server, and the client merely calls them, via the two extra levels, as explained above. Good points of the paper ------------------------------ The author have identified a real problem. The paper is clearly written and easy to read, with accessible examples and figures. The solution is correct and will work (indeed the authors have it up and running). The ability to use array subscripting on a remote object is a significant gain. Constructive criticism ------------------------- The performance of the system is in doubt. The introduction of wrapper and data classes cause disruption to the syntactic structure of the client's program even in simple cases, as well as the loading onto the server of two extra classes for every class that exists. These two extra layers must be traversed in both directions ever time the original remote class is needed. (see Figure 8). The paper merely states, without any analytical or experimental evidence that "network traffic is reduced". But is the overall speed of the system affected? In any work related to numerical computing (as yours surely is) performance is an issue. You need to spend some time on developing the model of your system in a quantifiable way and of developing experiments with more than just one JAMA routine. On page 12, you assume that just because your centralised and distributed programs gave the same answers once, then all is well. This is a naive assumption in a distributed environment. In terms of structure, there are other Java matrix packages available (check google for them) and it may be that what you propose will not work. You (the author) should be able to guide the reader in this regard. The solution proposed here is not the only one and since it is disruptive to the client anyway, it should have been evaluated against alternatives. An alternative would be to add static methods on the server to call the constructors, and to provide access to subscripted variables and so on. The complete data structure can be passed back and forth via RMI (that is what RMI is for). Furthermore, there is a question as to why the system structure should not just let the object reside on the server. In the example given here, this arrangement would be quite suitable. References 2 and 13 and others by these authors (check their web pages) have achieved some impressive performance figures for Java without the somewhat complicated additions proposed here. The introductory sections putting the work in context are weak. We are led straight into one example (ddot) which serves as a justification for what follows, and then have only one other example to illustrate the concept. There is no abstraction of the concepts, or attempts at generalisation. What would happen if LUDecomposition and Matrix were in one class? There is not enough reference to the literature. Only three papers are quoted (the rest are technical web pages which could be omitted). Both CCPE and the Java Grande conferences provide a wealth of literature on this subject. For future reference, the latest CACM (November 2001) is also focusing on Java for High Performance Computing and will address some issues relevant to your work. Evaluation and Recommendation ----------------------------------------- My evaluation is that the paper is too light weight for a journal article. It could be published in something like SIGPLAN Notices perhaps.The ideas presented are not a significant breakthrough, and have probably been used in similar guises by others anyway. The fact that the authors do not give a thorough literature backup for their work lays them open to this opinion. They must be able to say that so-and-so and whats-his-name have done A and B and C, but we have taken the work much further and have achieved D. No such attempt is made. The work is therefore not of sufficient scientific quality to be published. Advice for future expansion ---------------------------------- As mentioned in the above, there are several ways in which the work could be improved and then re-written for publication at a later stage. These are the usual requirements of the scientific method: literature survey, quantitative backup (analytical or experimental), abstraction and generalisation, comparison with other similar solutions. Minor corrections ---------------------- p2 para 3 object-oriented p3 pare -2 explain once what LU means page 5 title of section 4 A better title would be "Interface and implementation classes" page 5 Table 1 swap the client and server around to conform (visually) with Figure 4 page 6 Figure 3 and other figures later: check first letter of public - should not be P page 8 para 3 How likely is it that the client can discover the structure? What happens to your method if they can't? Explain more. page 9 line 6 and Figure 6 title Impl not Imple Figure 6 this not This page 10 line 2 add after matrixMaker() "in the original client from Figure 1" page 12 URL does not work