An Architecture to Support Collaborative Distributed ...

An Architecture to Support Collaborative Distributed Heterogeneous Computing Applications Zhikai Chen, Kurt Maly, Piyush Mehrotray, Praveen K. Vangala, and Mohammad Zubair Department of Computer Science, Old Dominion University Norfolk,VA-23529, USA March 16, 1997 Abstract

Distributed heterogeneous computing is being increasingly applied to a variety of large size computational problems. Such computations generally consist of multiple heterogeneous modules interacting with each other to solve the problem at hand. The traditional way of integrating these modules and optimizing them for the overall design is a long and tedious process (typically taking several weeks). Recently, there has been some eort to design and prototype such systems [7,6,8]. However, these systems either are not web-based or lack a collaborative environment. The increasing use of Web technology for Internet and Intranet applications is making the web an attractive framework for solving distributed applications, least of all because the interface can be made platform independent. In this paper, we describe the design of the Collaborative Distributed Computing Environment, CDCE, and the JAVADC prototype we implemented. CDCE is an environment to design, execute, monitor, and control a distributed heterogeneous computing application with the following features: (i) it will allow collaborative design and control, (ii) it is easy to access, (iii) it is easy to use, (iv) it will work on heterogeneous platforms, and (v) it will be exible to adapt to dierent scenarios. JAVADC - JAVA for Distributed Computing, is our rst prototype which supports a user in one Internet domain who wants to con gure a parallel environment on a speci c High Performance Cluster, HPC, in another domain, run an application (which resides in yet another domain), and monitor its progress. All the machines involved in this process are of a dierent platform. We have successfully run scienti c  y

Computer Science Department, Old Dominion University, Norfolk VA 23529 ICASE, NASA/Langely Research center, Hampton, Virginia 23681

1

computations, launched from a PC in the odu.edu domain with all les being located in that domain, run the computation on the HPC in the icase.edu domain and monitored the results on the PC. We did not observe any signi cant performance degradation due to the JAVA server, client communication and execution.

1 Introduction Distributed heterogeneous computing is being increasingly applied to a variety of large size computational problems. Such computations, for example, the multidisciplinary design optimization (MDO) of an aircraft, generally consist of multiple heterogeneous modules interacting with each other to solve an overall design problem [7]. Typically these modules are developed in dierent disciplines and are optimized independently. The traditional way of integrating these modules and optimizing them for the overall design is a long and tedious process (typically taking several weeks). The slowness of this process is mainly due to the absence of a collaborative environment where (i) dierent modules and their interaction can be speci ed, and (ii) testing, monitoring, and steering of the overall design can be done. We currently lack a system that provides a collaborative environment which is easy-to-use and widely accessible. Recently, there has been some eort to design and prototype such systems [7,6,8]. However, these systems lack a web-based collaborative environment for solving large multidisciplinary problems. The increasing use of Web technology for Internet and Intranet applications is making the World-wide Web an attractive framework for collaborating and through the use of JAVA can be made truly platform independent. Hence we set out to develop a web-based collaborative environment to design, execute, monitor, and control a distributed heterogeneous computing application. Our environment design has the following features: (i) it allows collaborative design and control, (ii) it is easy to access, (iii)it is easy to use, (iv) it works on heterogeneous platforms, and (v) it is exible to adapt to dierent scenarios. In this paper we describe the design of a three-tier system, that provides a collaborative environment and reduces signi cantly the overall time for solving a multidisciplinary optimization problem. The front-end, rst tier, of this system is a GUI interface integrated with the Web. It is implemented using Netscape Internet Foundation Classes (IFCs). Integrating the interface in a web browser, e.g., Netscape, will provide users with a familiar interface on desktops ranging from Unix based workstations, to Windows-based PCs, and Macintoshes. The middle tier consists of logic to process the user input and interact with modules running on a heterogeneous set of machines. These modules along with the control processes form the last tier. The overall design is a client-server based architecture. The main advantage of a three-tier system is that the client or the front-end becomes very thin, thus making it feasible to run on low-end machines. We now give a typical scenario of how our system will be used. A project leader, responsible 2

for the overall design problem, will interact with the front-end to set up the project. As the front-end is integrated with the Web, she can do this from any place where she has access to the Internet. The set-up for the project involves: (i) Identi cation of team members and set their privileges to access and modify certain modules during the optimization process. (ii) Speci cations of modules including their interaction. (iii) The set-up of monitoring points and control conditions. Once the project is set up, team members can complete the speci cation for the modules for which they are responsible. Note that a module can consists of several sub-modules interacting with each other. The team member also maps the module to an available hardware resource. Next the application is executed in a distributed environment using a heterogeneous network of workstations and multiprocessor machines. During the execution, team members from anywhere on the Internet monitor, and control the optimization process using a standard graphical web browser. The team members see the currently executing modules at any level of the hierarchy. They also view the intermediate data owing between dierent modules, and in some cases visualize large data sets. A team member responsible for a particular subsystem can change data values under the control of the subsystem in order to steer the computation in the right direction. The team member should also be allowed to dynamically alter the control ow if necessary. For example, in a design cycle of the optimization process, the responsible team member may decide that a particular module is not aecting the optimization and may bypass the module by using old values in each cycle. Similarly, the team could replace a module with a plug compatible module, for example, to use another algorithm. We are using Java as our main programming language to build this system. We understand that currently there are several limitations with the Java environment. The performance of Java code, especially the interpreted Java code, is 10- to 20-fold slower than the native code [10]. However, the just-in-time compilers will alleviate this problem to some extent. The second problem with Java is that it is still not mature. The Java AWT currently is primitive and applications built using it, do not look as nice as native Windows. With all these limitations we still believe Java is a good programming platform because (i) it is portable across heterogeneous platforms, (ii) it integrates easily with the Web, and (iii) it enables construction of a secure system. Further, with the very strong industrial support JAVA has, most of the cited problems with JAVA will probably have been addressed by the time we will have a testable system. The rest of the paper is organized as follows. In the next section we discuss related works by other researchers. Section 3 discuss the issues related to the ideal system which we plan to build. Section 4 discusses JAVADC, the prototype we have built. Finally Section 5 provides a summary of the lessons learned and our plans for the near term future. 3

2 Background In this section, we review related works by other researchers. We have to distinguish between run-time environments which were created to make distributed computing available to the general application programmer. Examples of these environments are PVM [1], pPVM [2], Linda [3], P4 [4], Express [5], they all support distributed computing in varying degrees of generality; however, none of them is web based, lack collaborative features, and are mostly suitable for running SPMD programs. The second category of environments is one we are particularly interested in because the applications they target are also the applications we target for our environment. This category includes FIDO and MIDAS. The Framework for Interdisciplinary Design Optimization (FIDO) is a general computational environment for performing automated multidisciplinary design and optimization using a heterogeneous cluster of networked computers [6]. The current FIDO system has certain limitations: (i) it is hardwired to a speci c problem and is not exible, (ii) all discipline codes exist on the system where FIDO is installed, which causes some inconvenience, as very often codes from dierent disciplines resides on dierent systems, (iii) the GUI interface is not portable across dierent platforms, and (iv) it lacks collaborative feature which allows dierent members in a group to work on their respective tasks in a shared workspace. The Multidisciplinary Integrated Design Assistant for Spacecraft (MIDAS)[7] is to expedite the design process for complex systems. The MIDAS system consists of two main components. The rst component provides the user, a graphical user interface to initialize and control a task. The second component is the central control unit that gathers information from the user interface, spawns processes, and controls data exchange with all processes. Some of the limitations of the current version are: (i) the GUI is not portable, (ii) it is not integrated with the web, and (iii) it lacks collaborative features. The WebFlow provides a coarser grain packaging model, with a user-friendly authoring framework for distributed applications on the Web [8]. It consists of a visual graph editor applet which enables a user to de ne a complex application graphically by inserting, deleting and arranging modules. This is an interesting applet, which we will explore to use in our system. The WebFlow is an attractive working environment for parallel distributed applications written in Java. It is not suitable for integrating legacy applications which are written in Fortran or C. Also, it is not suitable for a collaborative environment where a group needs to work in a shared workspace to solve a multidisciplinary problem. In summary, computing technology, which enables us to solve large multidisciplinary distributed computing applications, is relatively new. Researchers have started looking into automating the solution for large design problems. Most of these systems are either hardwired to a speci c problem or are too restrictive. The other major limitation is that they lack a collaborative environment which allows dierent members in a group to interact with the application at various stages of its execution. 4

3 CDCE Architecture The CDCE system is a three-tier architecture (See Figure 1.) The rst tier consists of a client interface that is implemented using Netscape IFCs as an applet. The client interface has four sub-interfaces, namely application speci cation interface, resource mapping and execution interface, and monitor and control interface. The middle tier consists of a user interface server (UIS), and an execution controller (EC). The third tier consists of a lightweight process along with the application execution modules. Before we describe the complete system, we describe a sample multidisciplinary application. Then, we use this application to explain our design architecture and its motivation. First Tier Client Interface (Applet)

Second Tier UIS & EC

Third Tier Lightweight Process & Modules

Figure 1: Basic system.

3.1 MDO Aircraft Design Scenario

The overall goal is to optimize the design of an aircraft relative to some goal or an objective function, such as minimization of gross weight. This is done subject to constraints, such as speci ed range and payload. The design cycle starts with these constraints and goals, a base geometry and initial values for a set of design variables, such as sweep angle of the wing and thrust of the engines. Then, in each cycle, a program analyzes the current con guration of the aircraft, as speci ed by the design variables, to produce a set of output variables, such as lift and drag. The optimizer then evaluates the objective function for this con guration, to produce new values of the design variables. Eective optimizers are Newton-like methods, 5

which require sensitivity derivatives, the derivatives of the output variables with respect to the design variables. This optimization cycle continues until the process converges to a nal optimized con guration of the aircraft. The analysis phase consists of various discipline codes, such as aerodynamics analysis, structural analysis, control, each module interacting with others to analyze the current definition of the aircraft. Some disciplines, such as aerodynamics or structural analysis, are complex and exhibit a large degree of internal parallelism and thus require substantial physical resources for execution. However, other disciplines are generally simpler and should most likely be executed sequentially. The amount of data exchanged during the analysis phase is dependent on the disciplines involved and ranges from a few bytes to millions of bytes. Sometimes, this data needs to be massaged, or ltered, before it can be used. For example, pressures produced at the aerodynamic grid points by the ow analysis code have to be integrated to produce forces at the structural grid points for structural analysis. The data ow and dependency between dierent components of a MDO application for aircraft design is shown in Figure 2. Here, the analysis phase has been simpli ed to the simultaneous optimization of the aerodynamic and the structural design of an aircraft con guration. Though a realistic multidisciplinary optimization of a full aircraft con guration requires a number of other discipline codes, such as controls, performance analysis, propulsion, this version is sucient to describe how our system works. Optimizer

Dependencies Data

Structure Solver

Surface Geometry

Flow Solver

Sensitivities

Figure 2: A simpli ed MDO application for the aircraft design problem. In the initialization phase, the optimizer module stores the base surface geometry in an intermediate data repository (for our initial prototype we are storing it in a le on a disk). 6

The surface geometry is used for sharing geometry and ow data between the structure solver and the ow solver modules. The optimizer also generates a nite element model to be used by the structure solver and an initial ow solution by the ow solver module. After the initial phase, the two modules, structure solver and ow solver, run in parallel to generate a new de ection of the aircraft con guration and a new ow solution respectively. Both the new solutions are put back in to the surface geometry (See Figure 2). Also, the new values for sensitivity derivatives with respect to dierent design variables are stored back on to the data repository. The optimizer then decides, based on the optimization criteria, whether or not to terminate the program or to produce a new geometry.

3.2 CDCE Overview User 1

User 2

Web Client

Web Server

Web Client

Applet

Java UIS

Applet

Java EC

Lightweight process

Lightweight process

Lightweight Process

Modules

Modules

Modules

Figure 3: Overview of the complete system. The overview of the complete system is shown in Figure 3. The project manager sets up the project with the help of a web-based client interface. Typically, this interface is invoked by downloading a URL document. The Java based applet is downloaded along with the document and opens an interface for the manager after an authentication process. To complete the set-up the manager: 7





use the application speci cation interface to specify visually or otherwise dierent modules and their dependency; in other words, the information, contained in Figure 2, is entered in the system through this interface; set up the privileges of team members involved in the project, providing individual members access to their modules.

For entering this information the manager may need to get some information from remote machines. This is done with the help of the user information server (UIS) running on the same machine as the web server. Also, the information entered by the manager in this phase is communicated to the UIS. Note that UIS needs to run on the web-server machine from where the client interface applet was downloaded. The Java run-time environment imposes this restriction. The team members complete the rest of the set-up. Team members give additional information about their modules (such as the module location, input-output les, etc.,). They also map modules to an available and appropriate hardware resource with the help of the resource-mapping interface. On the completion of set-up, UIS receives all the information regarding the project. Based on this information the UIS creates an intermediate representation, a script that is interpreted by the execution controller (EC). The execution controller requests an appropriate light weight process to run a speci c module. These light weight processes are running on all the hardware resources available for the project. The execution controller also speci es various status variables related to the module execution which need to be updated. The execution controller maintains a database to keep the current status information. The UIS server periodically, or whenever there is a change in status, reads this database. The UIS sends this information to the monitor interface of all the active web clients. The UIS is a Java multi-threaded server that keeps tracks of all active clients. A team member can also change data values for a particular module to steer the computation in the right direction. For example, in a design cycle, the responsible team member may decide that a particular module is not aecting the optimization and may bypass the module by using old values in each cycle. Similarly, the team could replace a module with a plug-compatible module to use another algorithm. We now discuss in some details the implementation issues related to various components of the complete system.

3.3 Client Interface

We are using applets based on Netscape IFCs to implement dierent interfaces. We discuss brie y why we are currently using IFCs rather than the Java AWT. The Java Abstract Window Toolkit (AWT) is a package of classes java.awt which supports creating graphical objects such as buttons, menus, and dialog boxes. These objects can be 8

used to build a complete graphical applications. The AWT classes can be used without any platform-speci c concern. This is made possible by a set of AWT classes known as peers. The peers are native graphical user interface objects which are used by the AWT classes. The Java AWT currently is primitive and applications built using it do not look as nice as native Windows. Also, it lacks objects to support a drag and drop feature. Some of these limitations are addressed by the Netscape Internet Foundation Classes. The Windowing IFC (Windowing Internet Foundation Classes) is a class library written entirely in Java. These classes can be used to build 100 Percent Pure Java applications. The 100 Percent Pure Java certi cation program from Sun is the complement to JavaSoft's program for maintaining compatibility on platform implementations of the virtual machine. The IFC extends the Java Abstract Windowing Toolkit (AWT) library. The IFCs, as do Java AWTs, allow Java applications to be created independent of operating system-speci c windows and user interface controls. The Netscape IFCs consist of objects and frameworks to create applets and applications in Java. The IFC provides the tools to create a complex multiuser client-server application. The IFC framework includes window hierarchies, integrated drag and drop and all-Java user-interface controls. For more details, see http://developer.netscape.com/library/ifc/index.html .

3.3.1 Application speci cation interface

For the application speci cation we use planning to use the front-end of WebFlow [8] which is based on UCI's Graph Editing Framework [9]. (Note that for the rst prototype we are using a simple interface where a user specify the application by typing the information.) The WebFlow front-end provides a visual authoring capability to specify data ow graphs. It allows a user to build a computational graph from a list of prede ned icons. The WebFlow front end is implemented as an applet. We need to modify the applet so that it can communicate with the UIS following a speci c protocol. (At the UIS this information will be converted into an Opus-like representation.). We may also need to extend it to support additional icons and features to represent iterations in computational ow graphs. The overall objective is to provide an easy-to-use and intuitive application speci cation interface.

3.3.2 Execution and resource mapping interface As the application speci cation interface, this is an applet based on IFCs. The interface allows a user to map modules to hardware resources. Our current design for this interface gives visual feedback about the existing loads on the available resources. This helps the user to decide on the mapping. This kind of mapping is particularly bene cial when the hardware resources mainly consist of a general network of workstations. This interface also allows a user to start the execution. 9

3.3.3 Monitor and control interface

As the other two interfaces, this is also based on the IFCs. Whenever a user loads this applet, it registers itself with the UIS. This way UIS can keep track of all active monitor and control interface applets. In general, there are many users actively monitoring the application status. During the execution, team members sitting at their individual workstations may simultaneously monitor the ow of progress of the application. That is, the team members can see the currently executing modules at any level of the hierarchy. They can also view the intermediate data owing between dierent modules including view large data sets using standard visualization tools. The interface should also allow a team member, responsible for a particular subsystem, to change data values in order to steer the computation in the right direction. The team member should also be allowed to dynamically alter the control ow if necessary.

3.4 User Interface Server

There are three major functions of the UIS. These are: interacting with client applets, processing received information from client applets, and interacting with the execution controller. The UIS receives and sends information to all the three types of applets: application speci cation interface applet, resource mapping interface applet, and monitoring and control interface applet. For the rst two applets it is mostly serving requests (See communication protocol section for some of these requests.) The UIS keeps track of all the monitor and control interface applets to inform the applets whenever there is a change in status. This is a server push model as opposed to a client pull model where a client periodically polls servers for update. The client-pull method may generate unnecessary network trac. On the other hand, the server-push method has scalability problems as the number of clients are increased. This is one of the issue we intend to investigate in our work. The UIS also processes the received information from the application speci cation interface applet and creates a script. This script is then passed to the execution controller so it can provide information to monitor and control applets. It also interacts with with the execution controller to provide information to monitor and control applets.

3.5 Execution Controller

The main function of the execution controller is to execute the script received from the UIS. It also interacts with lightweight processes to obtain status updates. The script contains information about the order in which dierent modules need to be executed. A possible high-level representation of such a script for the sample problem is shown below. Initialize Status to NOT converged

10

DO WHILE ( Status NOT converged) SPAWN Optimizer GET Optimizer Status SPAWN Structure Solver and Flow Solver END DO

4 JAVADC Prototype 4.1 Overview

Before we started to design the details of the CDCE, we wanted to gain experience with supporting speci c applications which were actually running under an existing run-time environment. We selected as the existing environment: pPVM an extension of PVM which also supports parallel communication to allow for application with signi cant communication needs. As is typical for existing support environments, pPVM is not web oriented and the user is expected to be part of the cluster on which the application is run. ICASE [11], has a High Performance Cluster(HPC) of 10 workstations connected by 2 FDDI and 1 Ethernet which is being used to run large computational tasks under PVM and pPVM. JAVADC JAVA for Distributed Computing, was our rst attempt to support a user in one Internet domain who wants to con gure a parallel environment on a speci c HPC in another domain, run an application (which resides in yet another domain), and monitor its progress. All the machines involved in this process are of a dierent platform. In conformance with our approach we have implemented JAVADC, illustrated in Figure 4, in ve components:   

Web Client: is a graphical World Wide Web browser, with a runtime Java environment. For our prototype we are using the Netscape browser. Web Server: is a HTTP-server. We are using the public domain apache server. JavaClient: is a Java based graphical user interface which runs under the browser environment. The JavaClient interacts with the user and communicates with the JavaServer over the network. The JavaClient details are discussed in the next section. 11

Host D

pPVM

Host E

Test-Bed Domain

Host C

Host B Master host for pPVM

Host A

1

Web Server

Remote Client

Web Client

9

4 2

Host 4 Host 3

5

CGI Script

3 7

Application Site Host 1

Domain

Java

Java

8

Client

Server

10 6

Host 2

Step 1: User Click the link "Running pPVM Interface" Step 2: Web Server Executes the CGI Script Step 3: CGI script starts the JacaServer (if not running) Step 4: Server sends the pPVM properties file Step 5: Web Client launches Java Client Interface

Step 6: User Interacts with Interface Step 7: Send the properties of pPVM and application details to Server Step 8: Get the application source Step 9: Start pPVM , run the application & get Status/Output Step 10: Send Status/Output

Figure 4: Basic Components of JAVADC. 12





 

JavaServer: is a Java based server which is the main working engine of JAVADC. It collects user preferences regarding the application and pPVM. Next, it starts the pPVM daemon and runs the application on the pPVM HPC For this, it may be necessary to move the application les from a dierent site to the pPVM HPC. This task is also done by the server. The server details are discussed in the next section. CGI Script: It gets executed on the server when a user accesses the JavaClient Interface link from the pPVM home page. The script starts the JavaServer if it is not running already. HPC: It consists of a cluster of workstations where a user runs a pPVM application. Application Site: The pPVM application is started on one of the machines in this domain. In our JAVADC architecture the application site domain need not be same as the pPVM HPC domain.

JavaClient

The JavaClient is build using the IFCs graphical objects and uses Java sockets to communicate with the server. The objective of the interface is to make it easy to use. For this we have used some advanced graphical objects of IFCs. We also wanted to hide the pPVM environment set-up complexity from a typical user. For this reason we have introduced a concept of a default pPVM con guration. The default con guration is loaded from the pPVM HPC site , when the homepage is accessed. A user can run the application on the default con guration by dragging the application icon onto the pPVM icon as shown in Figure 5. The application icon is set up by clicking on the menu button and specifying the source code les, and input/output les using the FileChooser object of IFC. If a user wishes to change the pPVM properties, he can do so by clicking the pPVM icon. Once the application action is dropped on the pPVM icon the application speci cation along with the pPVM properties are sent to the JavaServer.

JavaServer

It is a multi-threaded server to support multiple users. The major tasks of the server are: 

Get Application. Get the application source and input les from the application site domain.



Start pPVM. Start pPVM daemon on the hosts in the HPC speci ed by the con guration le.



Monitor. Monitor the status of the computation running on the HPC and send the information to the client. The JavaClient application monitor window for a sample run is shown in Figure 6. The window is also used to output the results.

13

Figure 5: JavaClient Interface 

Run the Application. Run the application on the HPC.



Send Output. Send the output of the application to the client or save it to a le. (Figure 6 illustrate the case where the output output is send to the client.)



Cleanup. Cleanup all the processes and remove temporary les created.

4.2 Example

We illustrate the working of JAVADC with stepping through the execution of a 3-d FFT application where the code resides in one domain, the application is run on a Unix HPC in another domain and the output data are sent to a PC in another network of that domain. Step1: The user launches the JavaClient using a Netscape browser. We assume a user is already browsing the pPVM home page which contains a link \Running pPVM interface". The link is pointing to a CGI script on the Web Server which, when executed, starts the JavaServer (if not running already). Also, the CGI script sends the default con guration le to the Web Client along with the Java applet. Next the browser starts the applet and opens a graphical interface. The user speci es the application properties such as the location of source code and input/output les. 14

Figure 6: JavaClient Monitor window.

15

Step 2: The user runs the application by dragging the application icon onto the pPVM icon (See Figure 5). We are assuming here that the user is interested in running the application on the default con guration of pPVM. Once the application icon is dropped onto the pPVM icon, the client sends the application information along with the pPVM con guration to the server. Step 3: The server after receiving the con guration and application details le, starts pPVM using the con guration le. It then gets the application from the application domain site, and runs it on the HPC. Step 4: The server monitors the host machines and sends the status to the client. After the application is executed the server sends the output to the client. See Figure 6.

5 Status and Future Work In this paper we investigate various issues in distributed heterogeneous computing in a collaborative environment. We have presented the design of a web-based architecture for an environment to solve large multidisciplinary optimization problems speci cally distributed computational applications in general. We described JAVADC, the rst prototype implementation, which allows users in one Internet domain to con gure a parallel environment on a speci c HPC in another domain, run a distributed application (which resides in yet another domain), and monitor its progress. We have successfully run scienti c computations, launched from a PC in the odu.edu domain with all les being located in that domain, run the computation on the HPC in the icase.edu domain and monitored the results on the PC. We did not observe any signi cant performance degradation due to the JAVA server, client communication and execution. Currently, our JavaClient interface does not provide the facility to access remote le systems, a restriction imposed by the java applet. In most case, les will reside in some other remote systems and it is essential to have a le browser to explore the whole Internet. At this time, JAVADC also is speci c to pPVM and the HPC at ICASE. In the future we intend to generalize JAVADC to work with its own run-time environment to support multidisciplinary applications without modifying codes from dierent disciplines. To complete the CDCE design, we still need to implement: (i) visual based application speci cation interface, (ii) resource mapping interface, (iii) monitoring interface to support visualization of large data sets, and (iv) control interface to allow user to steer the computation, and (v) provide a shared workspace where multiple users can work simultaneously with the application at various stages of its execution. In addition, we will perform studies to give us insights into better interfaces and determine the nature of any bottlenecks. In general, our strategy is to have, at each stage towards the complete implementation of the CDCE, a functional system which can be used in production work. 16

References [1] G. A. Geist, A. Beguelin, J. Dongara, R. Manchek, and V. Sunderam. PVM3 User's Guide and Reference Manual. Technical report, Oak Ridge National Laboratory, TR ORNL/TM-11826, Oak Ridge, TN 37831, May 1993. [2] \Scienti c Computing using pPVM". International Conference on Parallel Processing, August 1994. [3] N. Carrieo and D. Gelernter. Linda in context. Communication of the ACM, Vol 32 No. 4, pages 444-458, April 1989. [4] R. Butler and E. Lusk. User's Guide to the P4 Programming System. Technical report, Argonne National Laboratory, ANL-92/17, 1992. [5] A. Kolawa. The Express Programming Environment. Workshop on Heterogeneous Network-Based Concurrent Computing, Tallahassee, October 1991. [6] Thomas M. Eidson, Robert P. Weston, FIDO - Framework for Interdisciplinary Design Optimization, http://hpccp-www.larc.nasa.gov/ do/homepage.html [7] John C. Peterson, Multidisciplinary Integrated Design Assistant For Spacecraft (MIDAS), http://mishkin.jpl.nasa.gov/Midas Page [8] Dimple Bhatia, Vanco Burzevski, Maja Camuseva, Georey Fox, Wojtek Furmanski and Girish Premchandran, WebFlow - a visual programming paradigm for Web/Java based coarse grain distributed computing, http://www.npac.syr.edu/projects/webbasedhpcc/index.html [9] Jason Robbins, \GEF: Graph Editing Framework", http://www.ics.uci.edu/~jrobbins/GraphEditingFramework.html [10] Gary Cornell, Cay S. Horstmann, \Core Java \, SunSoft Press, 1996 [11] ICASE - "Institute for Computer Applications in Science and Engineering \, NASA/Langley Research Center,Hampton, Virginia 23681-0001

17