The framework Manager is a middleware software component that manages module information on behalf of the GUI front-end. In particular, the Manager handles module resource queries, requests for module creation, and module interaction.
In its current incarnation, the Manager delegates resource management to a centralized database management subsystem based on mSQL. This subsystem is used to maintain lists of available host machines, available modules on a given machine, and to aid in performing authentication. In a typical scenario, the GUI front-end first registers itself with the Manager. The GUI then makes a resource query to the Manager which is forwarded to the mSQL process and eventually the mSQL results are returned back to the GUI through the Manager. Although the Manager is a single point of failure this distributed setup, significant care has been made to add as much fault-tolerance to both the Manager and the modules as possible. Moreover, since the mSQL subsystem is loosely-coupled to the Manager, both processes may be run on different host machines, and the failure of one does not immediately affect the status of the other. Finally, database information in the mSQL subsystem may be dynamically updated, but requires the GUI to re-request resource information.
Eventually, we plan to replace the mSQL subsystem with the more powerful Globus metacomputing software infrastructure. The Globus system will allow for better distributed resource management, and more robust/secure authentication.
Process management is shared between the Manager and the GUI. Since the Manager handles process creation, it is able to assign unique identifiers for each module instance that gets created. These module IDs are used by the GUI front-end to map a module process to its graphical representation (e.g., an icon) in the workspace. Since both the Manager and the GUI front-end are multithreaded, each module icon can be operated on independently from the others. All process deadlock detection/recovery is performed by the GUI. After a module process performs an action, the Manager forwards the return status (and other information) to the GUI. In this way, the GUI is able to "virtually" manage the group of module processes in the workspace based the states of those processes.
The collaborative aspect of the PSE LSA is not yet implemented. However, we have designed the Manager in such a way that a "collaborative subsystem" could be added in between the Manager and GUI. One such subsystem that we are currently investigating is the Java-based Infospheres distributed component system from CalTech. This layer would act as a session "muliplexer", allowing multiple peer GUIs to share the same view.
Last updated: Tue Jan 26 12:06:27 1999