Once the main JWS Online server was established and an increasing number of models were being added to the site, it became essential to streamline the process of translating models into web ready applets. The first steps in this process are performed by my
co-developer (Prof. J.L. Snoep), a model is encoded from literature as a Mathematica model and then translated into a stand alone Java program. This Java program contains the parameter initializations and output options as Java statements and the J/Link code needed to evaluate the model.
7.4.1
From stand alone program to web-ready model
Once the stand-alone Java program is developed it can be broken apart and used to construct the applet/model pairs. Initial versions of the applets had custom built inter- faces whose layout depended on the number of parameters and options that needed to be displayed. Building this applet (and coding the associated model file) was done by hand and took approximately a week to complete . . . clearly too long.
With the redevelopment of the applet and the introduction of Swing tables, a tem- plate based approach could be used which reduced the development time of the ap- plet/model pair to a single day. However, redevelopment of the applet/model pairs was coupled with an increase in their size and complexity which inadvertently lead to many ‘human errors’ slowing down the process. The next logical step was to develop software that could automate this process and reduce the human element.
7.4.2
Generating applet – model pairs
Automating the code generation process turned out to be yet another task to which Python [114] was ideally suited. The first step in the automation process was to develop a Python program that could write out the Java source code of the applet/model pairs using a standard Python based description file (see Appendix 12.1 for an example of this file). Once the Java code was generated, the J/Link code could be extracted by hand from the original Java program, modified so that it was compatible with the model class and inserted into the new model code. Although this significantly speeded up the conversion process, extracting the information needed for the description file and moving the J/Link into the model class, source code was tedious and prone to minor errors that could be difficult to locate.
uses multiple reads of the input source to decompose the program into a set of temporary files. Any code modifications that need to be performed to convert the Java code to the model class format are automatically performed. Although slow, this method of parsing seemed to be robust and required only minor changes to the format of the original Java source. By using constant parts of the Java program as keys, the parser can effectively deal with the large variations in the length and composition of the J/Link parts of the input file.
Finally these two programs could be integrated together to create the jws java generator which only requires the name of the stand alone program, the identifier number and model description (an example session is shown in Appendix 12.2) to be entered man- ually. Once this information has been supplied, the model is parsed and the Python based model description file generated. Subsequently the code generator performs some basic range tests and generates a complete Java model class and applet. A direc- tory is created using the model number and the applet and model files are written as a<model number>.java and m<model number>.java. However, the process of devel- oping a web ready applet does not end with the generation of the Java source. Once the applet is compiled, it needs to be tested and a specially tailored HTML page was developed (see Fig. 7.2) which enables it to be loaded in a web browser. Fortunately, this process can be automated and jws java generator writes a ready to use web page as h<model number>.html. Finally, commands needed to compile the applet/model pair are added to the various batch compiler files.
Each batch compiler file contains all the compiler directives needed to compile either the server and model classes or all the applets for a specific mirror site. Examples of these files can be found in Appendix 12.3. For each mirror site there is an applet compiler file which contains commands to read the server specific source code and compile the applets directly into the correct web site subdirectory.
At this stage the model files are complete and ready to be compiled and used with any JWS Online server. However, for security reasons, the Java Runtime Environment when loaded in a browser will only allow an applet to establish connections to the machine that it was loaded from. Therefore, in order for the applet to connect to a JWS Online server its source code must first be adjusted for a specific server before it can finally
be compiled. In order to streamline this process the JWS Class Management Console, Fig. 7.8 a , was developed.
a
b
Fig. 7.8 Tools for managing the JWS Online system. a , the Class Management Console allows the applet code to be Prebuilt for each mirror site and can compile both the server and applets via buttons which run the various batch compiler files. b , the JWS Online Control Panel, allows remote management of the various mirror sites.
Developed using Python (with a PythonCard14 GUI), the JWS Class Management
Console reads the auto-generated applet code and modifies it for the various mirror sites, after which it writes the processed applet source into the relevant mirror’s subdirectory where it is later read by the batch compiler files. All the batch compiler scripts can be run from the console, which has options to compile either the server or applets for any of the mirror sites. It is also possible to launch the JWS Control Panel, Fig. 7.8 b , a stand-alone Java program which can access any of the JWS Online servers and either restart or stop them.
Although these management tools may seem trivial, they are vitally important to
14
the overall functioning of the JWS Online system. This is especially true as the number of models and mirror sites increases.