UKu | Computing Centre | R & D | FixIT | Web-FixIT
Mikko Korpela
|
UKu | Computing Centre | R & D | FixIT | Web-FixIT |
6 Oct 1998
Mikko Korpela |
If you are using M Technology, especially VA's FileMan and Kernel, then do consider the following alternatives for migrating to graphical user interfaces (GUIs), client/server architecture, and ultimately Java and distributed objects. The message is:
The higher level components you use, the less "spaghetti programming" you will need.
There are basically two ways of migrating to the client/server architecture from traditional M:
If you wish to have a straightforward solution and you don't bother about being dependent on a single vendor, then select InterSystems' Visual M with Microsoft's Visual Basic.
If you wish to have a higher level of vendor independence at the client end, or especially if you are currently using the FileMan and Kernel software of the U.S. Department of Veterans Affairs (VA), then select VA's Remote Procedure Call (RPC) Broker (figure above).
VA's RPC Broker technology is designed to call M routines from Windows client software across a TCP/IP network. The client software can be programmed in any language or visual programming environment which supports Dynamic Link Libraries (.DLL files). You can use it even if you are currently not using FileMan and Kernel at the M server side, but then you will not be able to benefit from the productivity gains described in the next sections.
VA's FileMan Data Base Management System (DBMS) radically outperforms commercial relational DBMSs like Oracle and Ingres, especially if you consider the cost as well - FileMan is available in the public domain. Its Data Dictionary and Database Server Call (DBS) interface provide the programmer with the means to dramatically decrease "spaghetti programming" on the M side and to encapsulate the M globals under a self-documenting and easy-to-manage logical database structure. Thus, if you have been using FileMan and VA's system management software (Kernel) before, you will wish to retain this valuable heritage when migrating to new technologies.
The VA has developed a set of components for the Delphi programmer, the FileMan/Delphi Components (FMDC) package, to facilitate the programmer on the client side. Each FMDC component provides a visual representation of one field in one file entry in a FileMan file which resides on the M server. Although these "data-aware visual components" automatically make use of much of the logic embedded in the Data Dictionary, the programmer still needs to write a lot of Delphi Pascal code to tie them up into logical transactions.
The Delphi-FixIT toolset developed by the University of Kuopio, Finland, includes a set of data-aware visual components equivalent to that of the FMDC package. However, each visual component does not operate individually. Instead, all visual components dealing with the same FileMan file are linked to an invisible data source component which synchronizes all data retrieval and filing transactions having to do with one specific file (or subfile). The data source component has methods like GotoRecord, Next, Validate and Save, which can be connected to file-aware standard pushbuttons. For instance, when the user hits the Save pushbutton, the respective method of the data source component gathers the values of all the saveable visual components, checks that all values have passed the validation logic of the Data Dictionary and that all required fields have a value, and finally passes on the values to FileMan through the Broker.
Because of the generalized functionality embedded in the data source methods, the amount of "spaghetti" needed on the client side is radically reduced.
There are three major enhancements in the FixIT toolset compared with FMDC, in addition to several smaller ones. Firstly, the Find pushbutton and the invisible Finder component, linked with the Name (.01) field of the respective file, provide a generalized functionality for the user to select a file entry to be displayed on the form (compare with FileMan's DIC routine). For instance, if the user enters DO in the name field of a person form and hits the Find button, the finder component will open up a dialogue box displaying the identification information of all the persons whose surname starts with DO; e.g.
If there are more valid entries than go into the box, the user can get the next batch by hitting a More button on it. He or she can also hit an Insert button to indicate that the person is not currently on file and the person's data will now be entered. The user can sort the entries according to any column by clicking the column header. All valid (cross-referenced) index fields of the file in question can be searched for matches - eg. if the date of birth is defined as an index field, then the user can find DOE,JOHN also by entering JUL 18, 1934 at the name field (a dialogue box of all persons born on that day would pop up, if necessary). Of course the programmer can in many ways modify the way the Finder dialogue works in each case.
Secondly, the pointer field component also displays a similar dialogue box of those entries in the pointed-to file which match with the value entered by the user, in case the value is not unique. For instance, if there is a file of towns and a Town of residence field (pointer) on the person form, a non-unique value entered on it by the user might open up the following dialogue box:
Again all the necessary identification fields can be displayed, not just the Name field as with the respective FMDC component. Furthermore, if the user has the required access rights, the dialogue box can be designed to contain Zoom and Insert pushbuttons, through which the user can open up an entire form to edit an existing entry in the pointed-to file, or to add a new one on the fly (compare with Fileman's "Learn-As-You-Go (LAYGO)" functionality).
Thirdly, FixIT includes components for report generation. FileMan's sort and print templates can be called from the client side, and the output can be directed either to one of the server's printers or to the client's display, Windows printer, or file. Existing or new hard-coded sorting and printing routines can be called in the same way, if they are declared as remote procedures. What the programmer needs to do is to design a form for the user to enter the parameters required by the template or routine, if any.
Other enhanced functionality of the FixIT components includes automatic generation of file and field level help forms from the Data Dictionary, automatic generation of a history of most recently used records for a pull-down menu, dynamic disabling or enabling of buttons and fields depending on the FileMan access codes and Kernel keys the user has, etc. The language used in the pushbuttons and dialogues is automatically changed according to the language of the database (Kernel's language setting).
In straightforward cases FixIT can be used on a higher level still. The toolset contains form templates which make it possible to develop a one-to-one visual interface for any FileMan database structure. That is, for each possible FileMan database structure (except for variable pointers) there is a pre-designed visual presentation using tabbed notebook components.
For each master file (a file which the user can access directly) you will need a basic form. For instance for a file of laboratory tests, you might design the following form (first page):
If there are hierarchical subfiles (multiple-valued fields) or logical subfiles (files with a cross-referenced pointer field pointing to the master file), then you will need a grid form for each subfile (see the diagram above). Each grid form is another tabbed page on the notebook and presents a list of the (hierarchical or logical) subfile entries linked with the master entry which has been selected for display on the first page. For instance, if each laboratory test has a list (subfile) of wards which are allowed to order that test, then you would need a grid form like the following one:
One of the subfile entries at a time can be displayed, edited and entered on an edit box on top of the grid form. Alternatively, if the subfile itself has further subfiles or if a logical subfile is another master file in its own right, then the edit box must be replaced by Zoom and Insert buttons which open up ("zoom into") an entire new tabbed-notebook form for the selected subfile entry. Through these visual structures and the Zoom buttons, a user can "jump in" to the database through one master file, and then "navigate" through the entire database along forward or backward pointers, as far as he or she has the required access rights. The navigational functionality of stand-alone FileMan can thus be fully presented by visual elements.
FixIT's form templates provide the system developer with "semi-cooked", pre-fabricated forms for each of the file types described above. The forms have the necessary data source components in place (master and subfile components linked with each other for automatic synchronization), Name field component with the Find button, the other standard buttons (Save, Save New, Next, Previous, First, Last, Clear, Delete), the grids, etc. Quite a lot of generalizeable logic has been embedded in the forms. What the system developer needs to do is to select which file is to be managed through the form, and then to drag and drop respective visual components from a palette (see figure below) for each additional field onto the form. A purposely built property editor allows the system developer to select the values for the properties from FileMan's Data Dictionary, instead of entering them by hand.
Using the form templates the system developer can quickly create a complete data entry, edit and browsing interface with no Delphi Pascal programming at all in the best case - that is, simply through "dragging and dropping" pre-designed components onto the form and editing their properties. Often times the bulk of the user interface of an application package consists of such straightforward forms. Application-specific programming on the client side is required for validation checks across the fields, non-standard functionality, etc. The most critical parts of the application may still require a form or set of forms which do not follow the structure of the database one-to-one. These parts will need to be programmed in the traditional way.
The "fat client" architecture of Delphi and Windows has the drawback that the client software has to be installed on each PC where it is needed, and each new version has to be distributed in the same way. Furthermore, the client software is platform-dependent - what runs on Windows 95 does not run on Macintosh or Linux, and so on. These drawbacks are addressed by the "thin client" architecture, in which all the software needed at the client side is a web browser, which loads automatically the latest application software in the form of small "applets" from anywhere in the Internet, in principle.
Besides the fat-client Delphi version of the FixIT toolset, a thin-client Java/JBuilder version of it is at a prototype stage. The Web-FixIT toolset contains the same building blocks (components) with the same functionality (methods) as the Delphi version, so the system development procedure and the functionality of the user interface are almost the same. The same Kernel log-in and security functions, tabbed-notebook forms, selection dialogue boxes, Zoom buttons, etc. as in the Delphi/Windows environment, are available anywhere, provided that the user has a Java-enabled web browser or a Network Computer (NC). VA's Broker Client for Windows is replaced by a "Java bean" version of the Broker Client component. The components are platform-independent, provided that a visual programming environment (eg. JBuilder) is available for the platform in question.
To convert an application from Delphi to Java, the system developer needs to re-compose it from equivalent building blocks, setting the same values to the same properties, using the Delphi application as a model. If the Delphi application did not contain any hand-written "spaghetti" code, then there is no need for any hand-written Java programming, either. That is, the more you embed your logic into FileMan's Data Dictionary (in the object-oriented way of combining data with methods!), the easier it will be to migrate from Delphi-FixIT to Web-FixIT.
So far the experience with Web-FixIT's prototype version confirms the maxim above. However, we assume that it will be necessary to allow for some degree of discrepancy between Delphi-FixIT and Web-FixIT, to benefit from the new potentiality of hyperlinks and other aspects of the Network-Oriented User Interface (NUI). We are also working on the security issues and hardware capacity requirements related with the Java technology.
After further development and testing in pilot projects in Finland, we expect that the Web-FixIT toolset is ready for commercial distribution during the latter half of 1999.
In conclusion, the same FileMan database and M server application software can be utilized through dumb terminals (eg. through VA's ScreenMan forms), "fat" Windows clients and "thin" Java applet clients simultaneously. Thus you can transform your existing terminal-based systems to Delphi and further to Java in a bit-by-bit mode, rather than being forced to switch over from terminals to PCs or NCs overnight in a "Big Bang" mode.
Currently the fat client technology is so mature and the Delphi-FixIT toolset so productive that intra-institutional applications should be developed in that technology. The browser-based technology, especially the existing implementations of the Java Virtual Machine by Netscape and Microsoft, still has some way to go to reach the same level of reliability and cost-efficiency. We expect that the technology will be mature enough for the extranet parts of applications to be developed on it by the turn of the millennium. Currently it is too early to predict whether the "thin" technology will replace the "fat" technology in intra-institutional use as well, or if the two will have their separate but overlapping domains of applicability. Certainly the thin client technology is a sine qua non for widely distributed extranet applications.
The best way of being prepared for the future is to start migrating from the terminal-based to the fat-client technology today, but to do it in such a way which will make it as easy as possible to take the next step to the thin client technology where and when required.
In the further development of FixIT, database operations will be encapsulated in such a way that they implement the distributed objects architecture, specifically CORBA. If the need arises in the future, this will make it possible to replace or supplement even the FileMan DBMS on the bottom by another DBMS, specifically an Object-Oriented DBMS, without changing the other software layers.
The University of Kuopio is searching for increased cooperation with the VA and other interested parties in order to ensure the sustainability of the migration path.