1. Introduction
2. System Architecture
3. JavaBeans Front-end
4. JDBC/Servlets Backend
5. Conclusion

Repository in a Box (RIB), developed by the National HPCC Software Exchange (NHSE) program, is a toolkit for creating and maintaining software repositories. RIB uses the Basic Interoperability Data Model (BIDM) which is an IEEE standard for software cataloging on the Internet. Current RIB implementation is in perl and is built on top of flat-file systems. The BIDM standard is an object-oriented data model that uses the concepts of objects, with some attributes or properties and some relationship between them. Examples for such objects are Assets and Organization etc. The configuration file uses three type of tags namely <class>, <attribute>, and <relationship> for describing the structure of the repository. The HTML binding of the BIDM is used to generate an HTML file and are called the object description file. A web interface is present using CGI scripts for the various repository administration utilities.

The project goal was to implement a RIB system on top of existing databases using Java Beans front-end and JDBC and Java backend. This system should support distributed and heterogeneous databases commercially available now and should be easy to install, maintain and use. Also another consideration was that this system should interoperate with the existing RIB implementations and the users should be able to move assets and other contents between repositories without difficulty. The following sections gives details about our architecture and implementation in brief. The last section gives our conclusions and future plans for the system.

We developed a RIB implementation in Java using a three-tier model with JDBC and servlets at the backend and Javabeans and HTML at the front-end, thus making the system more flexible and distributed and evolving towards OMG's Corba Object Trader Service. The use of Java itself brings all the advantages of Java like portability, multithreaded etc. into the system. JDBC makes it possible to have heterogeneous databases at the backend which can all communicate with the middle layer servlets in the same way. Javabeans was chosen to develop customizable user interface components. The three-tier architecture makes it possible to switch between various combinations of front-ends, backends and middle-tier server. For e.g. instead of Java Web Server as the middle-tier server once could use a custom server or a CORBA server without changing much of the code.

For this project we developed two prototypes for front-end, one using Javabeans and another one using HTML and JavaScript. These two front-ends communicate to the same middle-tier servlet and gets the data from the servlet. Thus it's possible to use the system in a wide variety of browsers without any problem. For the middle-tier we used the Java Web Server and servlets API. This is a very useful and powerful combination of software for developing server side applications easily.

The servlets uses JDBC to actually connect to the database and retrieve the data. This layer encapsulates the data from the presentation layer and thus the presentation layer need not know anything about the underlying database. As we are using JDBC any JDBC complaint database can be used with our system. Currently we are using the Oracle database for data storage.

We used the Beans Development Kit from Javasoft for developing our Beans front-end. An HTML generator package was used to develop various HTML pages. Each page is represented as a class and thus management of the systems becomes easy. Implementation details about these two layers are provided in the next two sections.

JavaBeans Front-end

Functionality and Components

(All bean components are packed into several jar files and distributed when invoked)

• Rep_interf_bean ( DB handler)

• Rep_admin_bean ( Repository name /id , DB handler)

• Rep_delete(Repository name/id)

• Asset_create ( Repository name/id )

• Asset_view(Repository id)

• Asset_edit(Repository id)

• Organization_create (Repository name/id)

• Organization_view (Repository id)

• Organization_edit (Organization id )

• Catalog_header_create ()

• Catalog_footer_create()

• Domain_header_create()

• Domain_footer_create()

 

 

 

The various components of the JDBC /Servlet middle-tier are

• RIBServlet :

The gateway servlet for the RIB System. Various parameters are passed to this servlet from the user-interfaces. This servlet uses the State class to maintain some of them and passes on to its sub-ordinates. Two parameters that must always be present are "action" and "mode" for determining the action to be performed and whether the access is for an HTML interface or not.

• RIBManager :

This class routes the various requests to the appropriate sub-classes. It checks for the action parameters and identifies the class to be invoked. Currently it uses the four managers defined below.

• RepositoryManager :

This class deals with creation, deletion and management of repositories. Repository names are first send out to the user interface for a user to manager as soon as the user accesses the page. Once a repository has been selected all the subsequent operations are done on that repository. Functions of this class include create, list, edit and deletion of repositories.

The additional classes that the RepsositoryManager uses are RepositoryPage, to display information about a repository, RepositoryCreatePage for creating a repository etc. These page classes are template classes wherein the actual values from the database are put.

• AssetManager :

This class deals with only assets. It handles listing of assets, asset creation and modification and deletes functionality. It also does some error checking to validate the contact organization and domain names. An Asset can be created only if the organization and the domain entered in the Asset Creation form are valid; i.e they must already be present in the repository. This class also handles multiple values for certain parameters. The classes that this manager uses are AssetPage, AssetCreatePage, etc.

• OrganisationManager :

This class deals with creation and management of Organisations in a repository. It also has the capability of handling multiple parameter values. This class also uses various page classes to display HTML information and Organization description files.

• DomainManager

This class deals with creation and management of Domains in a repository. This class also uses several Page classes to display HTML contents and domain description file.

• CatalogServlet

This servlet is used for dynamic generation of catalogs. Also this servlet has the methods for installing and viewing various catalog headers and footers. The search interface for the database is also present in this servlet. The searching can be done on any fields in the database and can do complex searches like using keywords like æANDÆ and æOrÆ.

• NavigBarServlet

This servlet is used for printing the Navigation Bar for the search interface. It prints various JavaScript buttons and the action routines for these buttons. The State class is used for maintaining the state information about the current set of records or record.

• DBsql

This is a database utility class that does all the actual database operations on behalf of various managers. This class is database- and table- independent. It receives certain strings and Hashtables and returns back Hashtables and Vectors of results. The methods in this class include getRecord, getMultiRecords, getSeq, setInsert etc. Also, this class keeps the connection to the database open .So several clients can use the same database connection to communicate with it. This makes the database access faster. This class also uses some generic methods for retrieving the correct value types from the database.

• Text

All the HTML page classes extend this class for printing various HTML tags. The methods in this class are overloaded to print various types of tags with and without parameters.

• DataBase Tables

We used around 10 database tables to store the various classes and attributes of the system. There are five main tables for each of the main categories like repository, asset, organization domain and catalog tables and some other tables for storing multiple values for certain fields.

Conclusion

The RIB implementation in Java using JDBC and Java Beans has a flexible and extensible architecture that can be adapted to various user needs. Although the prototype was developed with an Oracle Database, it should work well with other JDBC complaint databases as well.

The front-end can be either Javabeans or HTML depending on whether the browser supports Javabeans or not. Since HTML seem to be the basic standard that is supported by all browsers and since the current RIB implementation uses HTML for transferring object description files among repositories, we prefer to have an HTML interface for this system. Moreover Javabeans applet takes more time to load than a dynamic HTML page in the web browsers.

In our implementation, all the contents are stored in the database tables and pages are generated dynamically, unlike NHSE's RIB where all the information was static. Advantage of storing the contents itself in a database is that all the fields can be manipulated easily and queries can be made on any of the fields in the database. This makes the searching the catalog easier and more productive. NHSE's RIB uses a search engine that is to be downloaded separately for use with the system. Our implementation eliminates this by providing a search interface along with the system. Also, complex searches can be performed against the database with our search interface.

The catalog generation part is also dynamic in our implementation. In NHSE's implementation, every time an asset is added to the repository the administrator needs to regenerate the catalog in order for the new asset to show up in the catalog. Our system eliminates this by generating catalog dynamically whenever user requests for one and thus will show the latest version of the catalog.

This system is extensible for e.g. by using CORBA middle-tier the repository could be distributed among heterogeneous databases and locations. Storing the actual reference to the object instead of just the metadata about the software would make it a step closer to the CORBA object trader service.