Subject: Review of C523 From: Judith Bishop Date: Mon, 22 Oct 2001 17:45:17 -0000 To: fox@csit.fsu.edu X-UIDL: 65f42cbfed220000 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Received: by mailer.csit.fsu.edu (mbox gcfpc) (with Cubic Circle's cucipop (v1.31 1998/05/13) Mon Oct 22 14:10:31 2001) X-From_: fox@mailer.csit.fsu.edu Mon Oct 22 14:03:13 2001 Return-Path: Delivered-To: gcfpc@csit.fsu.edu Received: from dirac.csit.fsu.edu (dirac.csit.fsu.edu [144.174.128.44]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 9F0B823A02 for ; Mon, 22 Oct 2001 14:03:12 -0400 (EDT) Received: from localhost by dirac.csit.fsu.edu (AIX4.2/UCB 8.7) id OAA20486; Mon, 22 Oct 2001 14:03:11 -0400 (EDT) Resent-Message-Id: <200110221803.OAA20486@dirac.csit.fsu.edu> Replied: Mon, 22 Oct 2001 14:02:52 -0400 Replied: jbishop@cs.up.ac.za Delivered-To: fox@csit.fsu.edu Received: from kendy.up.ac.za (kendy.up.ac.za [137.215.101.101]) by mailer.csit.fsu.edu (Postfix) with ESMTP id 1DABC23A02 for ; Mon, 22 Oct 2001 13:38:44 -0400 (EDT) Received: from [137.215.18.21] (helo=hades.cs.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 15vj27-0000dr-00 for fox@csit.fsu.edu; Mon, 22 Oct 2001 19:38:39 +0200 Received: from oasis.cs.up.ac.za ([137.215.18.20] helo=cs.up.ac.za) by hades.cs.up.ac.za with smtp (Exim 3.22 #1 (Debian)) id 15vioD-0007dg-00 for ; Mon, 22 Oct 2001 19:24:17 +0200 X-Mailer: TWIG 2.3.1 Reply-To: jbishop@cs.up.ac.za Message-Id: X-Scanner: exiscan *15vj27-0000dr-00*GxgZZlFgkj.* http://duncanthrax.net/exiscan/ Resent-To: Geoffrey Fox Resent-Date: Mon, 22 Oct 2001 14:03:11 -0400 Resent-From: Geoffrey Fox CandC:PandE Referee Report Form *********************************************** C: Paper and Referee Metadata Paper Number Cnnn:C523: Date:22 Oct 2001 Paper Title:Towards a Common Development Framework for Distributed Applications Author(s):Fethi Rahbi Referee:Judith Bishop Address:University of Pretoria Referee Recommendations. Please indicate overall recommendations here, and details in following sections. reject D: Referee Comments (For Editor Only) This wok is really old. The promise of the title is not fulfilled in what follows. The appendix is a strange add on, but in itself could lead to something. E: Referee Comments (For Author and Editor) This paper has a worthwhile aim: to define a common development framework specifically for distributed applications. On page 1, DAs are defined to include parallel, fault-tolerant, real-time, and web applications. (There is a further category - functional specialisation - which does not seem to have the well-known currency of the others.) The paper introduces the topic, then goes on to look at concurrency, real-time, distributed and parallel systems in detail. The breakdown of the paper in such a way does not match the definition on page 1 (which comes from a 1989 reference), and it would be better to just leave that out, and start with defining the world as it is going to be covered in the paper. Indeed, the breakdown the paper gives is the far more well-known and rational one. Each section looks at specific aspects particular to that area, and in the first three cases reaches a conclusion. There are no conclusions for parallel processing. Section 7 then looks for strengths of each discipline and overlappings, makes a case for integrated approaches and identifies the main problems and future work. There is then an example-based appendix (more of which later). The paper contains nearly four pages of references, which I regard as excessive. Even though the paper has survey tendencies, it should be possible to trim these down to those that are really essential to support the work. The problem with much of the paper is that what is said is already well-known and present in text books on operating systems or distributed systems. There is also a certain datedness associated with some of the subsections, for example 2.3 refers to LANs and WANs, but does not mention middleware or web services. It would only be valuable to restate this information in Section 2 if a framework were then developed for the following four sections to follow. This is not the case. Section 3 discussed the theory that might assist in a common development framework. The discussion relates to work done in the 1980s and concludes that it has had little impact. If this is the case, then this section has a minimal bearing on any proposal. It could be reduced simply to the conclusion. Section 4 is a fairly rich discussion of tools and techniques for real-time development, but once again, goes too far back in history for a research paper (e.g. occam and Chorus are dated at 1988). The reader will be searching for the essence of the discussion that is going to lead to the common framework, but it is not present. The conclusion (4.4) makes some statements which are not defensible. For example, in 4.4 paragraph one, what is wrong with Java or C++ being produced by a tool? And the reference to UML extensions (line -4) has been superceded by events. The compartmentalisation of concurrency and real-time also misses a point. Much of Kramer and Magee's work, as well as that of Durra and Polylith initiatives and other distributed systems (referenced in section 5) has been shown to be directly applicable to real-time systems. Many of the examples were gleaned from this area. Thus it is not true to say that the expressive power of the methodologies for real-time systems is limited to static systems without replication structures. These are available in Darwin and the other notations. If the growth in distributed systems research was explosive before 1997, then it has been doubly explosive since then. Yet page 9 refers only to 1997 and earlier. The middleware discussion is particularly relevant, more so that Section 5.1. However, there are some misconceptions. Figure 2 gives the impression that the client stub and server skeleton in Corba communicate directly. In fact, as stated in para 4, page 10, the communication is always via the ORB. While a section on design patterns is highly topical, the examples given are insufficient and once again old. In the appendix, there is more mention of newer patterns. The conclusion of Section 5 harps again on old work, and should draw in the latest in middleware technologies, from CORBA, all the way up to EJB and .NET. Section 6 on parallel processing is quite extensive and touches on a broader range of topics than the other three sections. The section on skeletons is relevant to the title of the paper, but once again refers to very old work. The real problem with the paper is that it dows not live up to its title. The reader is led at the start to imagine that a proposal will be forthcoming with guidelines for the future development of distributed systems. Instead section 7 makes generalisations and presents limitations. It would seem that Figure 4 is a possible candidate for an integrated approach but it is neither detailed enough, nor all embracing enough to be really useful. Recommendations regarding adaptation and formal notations are made, but there is no direct line between these and what has gone before, so they sound unsubstantiated. Then we come to the appendix. This is much more acceptable and readable. It describes an example of a distributed system and uses modern techniques to illustrate how distributed systems should be developed. How can the paper be improved? ----------------------------- My recommendation is that the paper should be rejected. However, the idea is sound, it addresses a relevant problem - how to develop distributed systems - and is based on considerable background understanding. If better structured, and brought up to date, the work could be publishable. The following could be done: 1. Considerable reduce sections 3-6 by removing material which is well known, and concentrating only on the conclusion subsections. 2. Bring all the references up to date by considering the work from 1998-2001 in CCPE, Parco, Europar, SPE, IEE Computer and IEE Software. 3. Reduce the references to a max of 25 really relevant ones. 4. Draw up a table which will list the proposed essental issues in the development of distributed software and which will show which of these is already covered in the areas surveyed, and which needs more work. 5. Make the example central to the paper and expand it to include an assessment of its actual implementation. F: Presentation Changes The presentation is fine. .