Collaborative computing enables different users to share data and programs over a network. In each case, the user runs special programs (including Web browsers) on his or her own computer. Communication with other computers occurs but only to access specific data or to send some new data to a server. Sometimes, however, what is required is the ability for a single user to execute programs on other computers across the network. For example, computationally intensive tasks such as computational fluid dynamics or rigorous simulation may require access to a supercomputer. Or it may be that certain packages can only run on specific hardware. In these cases, it may be inefficient or infeasible to provide the required hardware or even the software to each person that may, possibly infrequently, have need of it. It's often easier to provide a central resource which can be shared by the users that need it.
SunSoft have introduced several initiatives directed at enterprise-wide computing. Amongst these are the Java Database Connectivity (JDBC) protocol, the Remote Method Invocation (RMI) toolkit and the Java Beans component architecture ( Sun Microsystems, 1997). The former enables Java applications to retrieve and store data in remote databases. The latter two are closely linked in that the Java Beans technology is based on the RMI toolkit. RMI allows Java applications (or applets) to communicate with a Web server. The Web server can execute, on demand, specific Java applications which could be wrappers for legacy code (simulators, CFD codes, etc). Java Beans provides a component architecture similar to that proposed by Microsoft with OLE/COM (now known as ActiveX). The difference is that Java Beans components are not tied to a specific operating system and hence are truly portable. The purpose of this architecture is to allow the creation of components which can be used within and together with other components to create full applications. Components provide public interfaces and encapsulate methods and can be used in different applications. The use of components increases the reuse of software leading to more robust code and hopefully results in shorter development times.
The ECOSSE group at the University of Edinburgh have developed a distributed and portable object oriented environment specifically for process engineering ( Costello et al, 1996). This system as originally designed had two goals:
Recently, the épée system has been extended to provide full Java support. Figure 4 shows a Web browser displaying the objects in the user's épée database. The épée system incorporates some of the ideas behind the three Sun initiatives discussed above. It provides a mechanism for access to data on remote servers, remote methods can be accessed, and it encourages the development of self-contained components.
The advantage of linking Java with épée is that the user is automatically provided with access to tools available on other platforms. The interface to these tools is through a Java application or the Web browser which means that they are available on most computer platforms. As an example, we have written an épée method which interfaces with the Aspen PLUS simulator (
Ballinger et al, 1995). Applying the method Simulate.Separation.Sequence to a process flowsheet object sends the object to the server, starts up Aspen PLUS on that server, simulates the process, and returns a new process object with updated streams. The computationally intensive task of simulation is performed on the remote computer which is hopefully better suited to the task than the engineer's own PC. The graphical display of the results, however, is the responsibility of the user's PC, handled by the Web browser.
