7. Conclusions and Future Work

Written in Java, to be platform independent, the Abstract Database Viewer (ADBV) has been developed as a solution to certain problems of accessing information contained in databases through the Internet. Currently there are standard mechanisms for gaining access to this information, but no methods in place for actually viewing the information, unless it is in a standard textual, numerical, or graphical format.

The development of the ADBV system has proved that the use of a template mechanism and an API can allow information of any format to be viewed across the Internet by client users through a standard interface. The templates consist of the data to be accessed, along with a viewer application that understands the format of this data. The API then allows the viewer applications to interact with the ADBV system.

The development has also sought to provide the database administrator with a means to set up the templates as quickly and as easily as possible. This is achieved through a management tool that allows the administrator to view a list of the objects contained within a database. Objects can be selected from this list and templates created about them. The viewer application for each template can then be chosen from a simple choice list of those that are currently available on the system.

Through the creation of ADBV, the developer has acquired new skills. These skills include programming Java, both in the learning of the language and in learning the specifics of using network sockets, accessing databases, and loading Java modules dynamically. Experience of IBM DB2 has also been useful, due to its wide use throughout the world of business and across machine architectures. Additionally, the development environments have been relatively easy to use and, both IBM Visual Age for Java and IBM DB2 have provided a stable working environment most of the time. However, both packages were quite memory intensive and the documentation was not as accessible as standard MS-Windows Help.

For enhancement of the ADBV solution, further research must be undertaken. The design of the current system involved some extensions, but the time constraint did not allow these to be implemented. Other ideas for research areas have yet to reach the design stage.


Security Mechanism

Some development of a security mechanism is needed. This should be through client users sending a user name and password combination to the server for verification before they can gain access to the data.

Multiple modules per viewer

Some development of a mechanism by which multiple Java classes can be stored for use by a single viewer is also needed. This could be done in one of two ways

  1. Using separate records in the template database
    Each separate module could be stored in a separate record in the template database. These could be linked to a primary module that would interact with ADBV. The current T_CLASSES table contains this link, and comments in the code show where changes are necessary for this to be implemented.
  2. Using the Java Archive (JAR) file structure
    This structure allows multiple modules to be stored in one flat file. This file could then be loaded into the template database and accessed using a similar mechanism to that currently implemented.

Research Areas

Client / Server interaction through CORBA

Communication between client and server systems in ADBV currently uses network sockets. Alternatively, the Common Object Request Broker Architecture (CORBA) [4, 11] could be used, allowing the viewer applications to be programming language independent. In addition, the client user would not need to enter the physical location of the server program, as the ORB provides the necessary mechanisms for location transparency [4].

Enhancement of template structure and management tool

Currently, the structure of the templates is a very simple link between object and viewer, which has to be created by the database administrator. This is done using the management tool, which displays the available objects, by reading a subset of the meta-data [2] contained within the database. The primary-key and foreign-key meta-data about each table could also be used to display the actual relationships between different tables, leading to a more meaningful representation of the data being created.