The Walter Reed Chemical Information System (WRCIS) was conceived in 1991 by Patrick McGreevy, William Ellis and John Notsch to manage the daily operations of the U.S. Army Drug Development Program. This system integrates three types of data into screen displays that satisfy the needs of the research team from the Repository Manager to the Director. The three types of data used in the WRCIS are:
The integration of these data is realized by using a client/server architecture over networks. The central applications that control all integration are provided in TRIMtools and GUItools produced by Trifox Incorporated. GUItools were selected because of their wide flexibility. A summary of this flexibility and its implementation in the WRCIS follows along with the technological details.
Since the integration of textual, chemical and image data in the WRCIS is managed entirely by the GUI application interface, a description of GUItools is germane. GUItools were designed as a three-tiered system: presentation, computation, and data management. This is commonly referred to as "thin-client" and means that the client PC is used simply as a presentation manager. In this mode, GUItools require less than 100kb of disk space on the client PC and runs equally well on 16-bit and 32-bit systems. In addition, the thin-client mode uses several presentation and data caching techniques to minimize the amount of data transmitted to and from the PC. The application's windows and data are presented quickly, even through a 9.6kb modem!
The computation part of the three-tiered architecture refers to the application logic itself. The applications that compose the WRCIS are all stored on the application server machine which can be anything from a Windows NT system to a Unix box to an IBM mainframe. The applications are not stored on the client systems which simplifies the task of keeping users up to date. When new versions or new applications are developed, they are placed on the application server in one place and all users automatically get the upgraded applications! Since all the computational work is done on the server, the client systems do not have to be very powerful at all. In fact, GUItools can run on a 386 Windows 3.1 system with 4Mb of memory. No other GUI provider can make that statement!
The data management portion of the architecture is the actual DBMS. With GUItools, this can be on still another machine or it can be on the application server. As mentioned above, GUItools allow the user to open six concurrent connections to a variety of DBMSs on the same or different machines.
Finally, the technique used to manage image files stored on the optical jukebox bears on the performance of the WRCIS. The traditional method of dealing with BLOBs (Binary Large OBjects) is to store them in the DBMS and retrieve them with SQL. This has several serious drawbacks. All the commercially available DBMSs on the market today have added BLOB handling as an afterthought, not as part of the original design. As such, BLOBs are non-standard and wreak havoc on the normal SQL processing of the DBMS. GUItools' solution is the 'file_copy()' function. This function opens a high-speed connection from the PC to the system where the file is located and copies it to the local machine. This does not affect the DBMS connection(s) and is transparent to the user. Thus, when the user wants a TIFF file, the application moves it to the PC and opens an imager to display it. This is much quicker than using the DBMS to retrieve the BLOB.
For additional information contact mcgreevp@volcano.net or info@trifox.com.