Each and every computer system in the world needs a database to store/retrieve the information. Without a database, a computer can become useless. The primary reason you use the computer is to store, retrieve and process information and do all these very quickly, thereby saving you time. At the same time the system must be simple, robust, fast, reliable, economical and very easy to use. The most popular database systems are based on the International Standard Organization (ISO) SQL specifications which are also based on ANSI SQL (American) standards. Current specifications generally used are ANSI SQL 92 and ANSI SQL 89.

Now the main thing is to make this database available for users all over the world. This paper concentrates on this aspect of it, means integrating it on WWW.

There are a lot of options available for integrating a database on WWW. But, in our case due to the volume of database and resources available for exploring it make it an interesting and unique case. I will first start with introduction of MidAS.

There are 16 node beowulf type cluster with 1 server node and 15 point nodes mainly for storage.

Hardware: (Present configuration)

Server:

CPU: Dual 400 MHz Pentium-II

RAM: 512 MB

HD : 4 16 GB IDE drives total 64 GB

NIC: Integrated Fast Ethernet

Client Node:

CPU: Dual 233 MHz Pentium-II

RAM: 128 MB

HD : 4 16 GB IDE drives total 64 GB

NIC: Integrated Fast Ethernet

Total HD capacity: 1024 GB or 1 TB

Software:

Extreme Linux from Red Hat Software is going to be used for both the clusters. Plans are to support PVM and MPI as the two promary message passing libraries. Negotiations are on with the Portland Group to obtain high performance FORTRAN, C and C++ compilers.

NFS is less preferable because of the CWS bottleneck and having a parallel FS like Clemson Parallel File System is advantageous. The clusters also have SMP (Symmetric Multi Processing), which cost around $ 800/node. This secures faster processing and also makes it unique in that no body is using SMP with Beowulf currently.

There are a lot of options available for integrating the MidAS on WWW. But, since it has already been decided to use PostgreSQL, only those options which can run on top of PostgreSQL will be discussed. These options and brief discussion of them are as follows:

1. Perl Database Interface (DBI):

The Perl Database Interface (DBI) is a database access Application Programming Interface (API) for the Perl Language. The Perl DBI API specification defines a set of functions, variables and conventions that provide a consistent database interface independent of the actual database being used. DBI, the Database Interface for perl5, is an ongoing effort to design and implement a database-independent interface for database connectivity which abstracts the complexity of understanding the low-level 'guts' of database technologies away from the programmer. With the explosion in popularity of perl as the most used language for CGI programming, a simple, and standard, connection interface to databases is imperative.



Figure 1: The Architecture of DBI

The architecture of DBI is an elegant one. By the very concept of the interface that we are trying to define, we are channeled towards the solution. However, perl, as usual, helps us along the way by providing powerful syntactic constructs and regular expression handling capabilities that are core to the usability and simplicity of data processing on the scale required by large database applications. The DBI interface is the term used to describe both the interface specification, ie, the methods with which we write programs and the software modules that comprise the system.

DBI is a current and living organism and, coupled with perl's current popularity as a CGI scripting language and rapid development tool, is set to become a more important factor in decisions to use perl as a ``serious'' programming language. DBI is simpler thanODBC. DBI will run immediately on more platforms than ODBC. DBI is free. DBI is currently being redesigned to allow you to write ODBC-compliant code, which DBI will translate for you at run-time. Further it is database independent.

 

2. AppGEN:

AppGEN is a high level fourth generation language and application generator for producing World Wide Web (WWW) based applications. These applications are typically used over the internet or within a corporate intranet. AppGEN applications are implemented as C scripts conforming to the Common Gateway Interface (CGI) standard supported by most Web Servers. To use AppGEN, basic need is Postgres 95, relational database management system , a CGI compatible web server such as NCSA's HTTPD and an ansi C compiler such as gcc.



Figure 2: AppGEN system

AppGEN consists of the following Unix (Linux) executables:

defgen, which produces a basic template application from a logical data structure. The applications are capable of adding, updating, deleting and searching for records within the database whilst automatically maintaining referential integrity.

appgen, the AppGEN compiler which compiles the appgen source code into CGI executable C source and HTML formatted documents ready for deployment on a web server.

dbf2sql, a utility for converting dBase III compatible .dbf files into executable SQL scripts. This enables data stored in most DOS/Windows based database packages to be migrated to a SQL server such as Postgres95. In addition, AppGEN comprises of a collection of HTML documents, GIF files and Java applets, which are used at runtime by the system. And of course, like all good software, the full source code is included.

3. "Easily Adjustable Response Program" (EARP)

EARP is a Web Database Design/Implementation tool, built on top of the PostgreSQL database system. The main implementation of EARP is a CGI binary which runs under the http daemon to provide access to the database server. All of the design tools are built into the driver, no design takes place over anything but the web. The tools themselves require a graphical browser, the compatibility of objects designed with the tools is implementation independent, based on designing individuals preferences.

One of the main features of EARP is that it uses an Object Oriented approach to produce html pages which interface to the database. Most pages will consist of several objects. Each object is produced by some sort of tool and given a name, objects are then linked together in a callable sequence by the page tool. Objects are also reusable across multiple pages. Basic tools exist for HTML, Querys, Grabbing input from forms, Extendable Formatting of Query and Input objects, and Linking together of objects into other objects. More advanced tools include the mail tool and the multithreaded query tool.

Another feature of EARP is advanced security. Access to various areas of the EARP system can be limited in a variety of ways. To facilitate its advanced security, EARP performs checks for each connection to the system, determining what ids and groups the connecting agent belongs to. Access to areas is defined seperately, and the combination decides if access to a specific area of Earp is allowed. Moreover, all that is required to implement the security features is an http server that supports basic (or better) user authentication.

4. PHP/FI:

PHP/FI is a server-side html-embedded scripting language. It lets you write simple scripts right in your .HTML files much like JavaScript does, except, unlike JavaScript PHP/FI is not browser-dependant. JavaScript is a client-side html-embedded language while PHP/FI is a server-side language. PHP/FI is similar in concept to Netscape's LiveWire Pro product. If you have the money, you run Netscape's Commerce Server and you run one of the supported operating systems, you should probably have a look at LiveWire Pro. If you like free fast-moving software that comes with full source code you will probably like PHP/FI.

Standard CGI, FastCGI and Apache module Support As a standard CGI program, PHP/FI can be installed on any Unix machine running any Unix web server. With support for the new FastCGI standard, PHP/FI can take advantage of the speed improvements gained through this mechanism. As an Apache module, PHP/FI becomes an extremely powerful and lightning fast alternative to CGI programmimg.

5. HEITML:

Tool HEITML is another way to interface postgres with the world wide web. HEITML is a server side extension of HTML and a 4GL language at the same time. People can write web applications in the HTML style by using new HTML-like tags. HEITML (pronounced "Hi"-TML) is an extension of HTML and a full-featured 4th generation language that enables Web-based Applications to interact with data stored in SQL databases, without resorting to complex CGI scripts.

HEITML extends HTML on the server side, dynamically converting ".hei" files to HTML format and so is compatible with any web browser. It embraces the familiar, easy-to-use HTML syntax and provides a large assortment of pre-developed Tags and Libraries to take care of tasks that formerly required CGI. As XML, it provides user defined tags. With HEITML the user defined markup can be translated to HTML and send to a browser.

For programmers heitml embeds a complete forth generation language in HTML (e.g. <if>, <while>, and <let> Tags), plus powerful expression evaluation with integer, real, boolean, string, and tuple data types. HEITML runs on Linux with any Web Server using the CGI interface, and is especially fast, avoiding the CGI overhead. Currently MSQL (Version 1 and 2), PostgreSQL (Version 6), mysql, and the yard databases are supported. It also works on Linux, BSDi, Solaris and SunOS, as well as Windows NT with CGI and ISAPI and ODBC and Windows 95.

6. Python Interface for PostgreSQL:

Python is an interpreted programming language. It is object oriented, simple to use (light syntax, simple and straightforward statements), and has many extensions for building GUIs, interfacing with WWW etc. An "intelligent" web browser (HotJava like) is currently under development, and this should open many doors. Python is freely distributable. PyGres95 is a python module that interfaces PostgreSQL database. It embeds PostgreSQL query library to allow an easy use of powerful PostgreSQL features

cooperatively with all the other python modules. It has been developed on a Linux 1.3 system, but have been tested on a Solaris 2.4 platform. Anyway, it should work on any platform where python and postgreSQL are available.

It is often compared to Tcl, Perl, Scheme or Java. Python combines remarkable power with very clear syntax. It has modules, classes, exceptions, very high level dynamic data types, and dynamic typing. There are interfaces to many system calls and libraries, as well as to various windowing systems (X11, Motif, Tk, Mac, MFC). New built-in modules are easily written in in C or C++. Python is also usable as an extension language for applications that need a programmable interface. The Python implementation is portable: it runs on many brands of UNIX, on Windows, DOS, OS/2, Mac, Amiga.

7. Gateway between PostgreSQL and the WWW - WDB-P95:

WDB is a software toolset that tremendously simplifies the integration of SQL based databases into the World Wide Web. WDB lets you provide WWW access to the contents of databases without writing a single line of code.

All there is needed to use WDB is the WDB script, which is written in Perl, and a set of high-level form definition files, each describing a different view on the database. WDB automatically creates HTML forms, on-the-fly, to allow the users to query the database, and given the users query constraints it will query the database and present the result to the user. WDB even comes with a utility to automatically extract information about a table from the database and create a working template form definition file.

A number of conversions are possible on the data coming from the database before they are shown to the users. The most noticeable feature are the possibility to convert data from the database into hyper-text links -- and as it is possible through WDB to access any database element directly via a WWW URL - The entire database can be turned into a huge hyper-text system. These hyper-text links can be links to other elements in the database - so providing a simple way of jumping between related information. They could also be links to other documents on the Web - so providing easily integration between data in the database and related documents on the Web. Or it could be links to other databases with a WDB or similar interface - so providing a simple mechanism for cross-database links. The recent version provides a gateway to the WWW for PostgreSQL.

8. WWW Web interface for PostgresSQL - DBENGINE:

9. JDBC: This will be discussed in detail on following pages.

Open Database Connectivity or ODBC is Microsoft's standard for vendor-neutral database access. Its specification provides a low-level API for executing SQL statements.

Java Database Connectivity (JDBC) is the Java API for executing SQL statements and provides a low-level API to do this.

If both sound similar, they are. Having concurred with the ODBC principle and all the good things about ODBC, JDBC is Javasoft's ODBC-inspired connectivity standard for the Java generation.

In principle, most people agree Java is a good language. It offers client and server platform 'independence'. With the emergence of network computers and heterogeneous client environments that include everything from digital mobile phones to full-blown Windows 95 PCs, that can only be a good thing. Java applets are very downloadable and Internet friendly which again is good news. Javasoft has designed it for this for a network-oriented environment, with portability and security high on its agenda. As organizations are increasingly looking towards the Internet and the Intranet as a serious way to deploy, maintain and control applications and data, Java is increasingly seen as a real industrial-strength language. Javasoft anticipate that a new generation of tools (or Integrated Development Environments) will emerge that emit good JDBC code (just like tools like Delphi and Visual Basic emit ODBC code right now).

JDBC has been inspired by and therefore built on the best principles of ODBC, with attributes like DB independence; ease of implementation and so on. Its gestation has happened very quickly, but Javasoft have been diligent to involve database and database tool vendors. The initial specification was released in March 1996 as a draft for open analysis.

The JDBC API is natural and clean; the specification encourages applications and applets that 'read well' which is a very Java way of working. The approach is to specify multiple methods, rather that multi-purpose methods that can take flag arguments (as in ODBC which is C++ oriented). The simple tasks have been separated into simple interfaces, and there are other separate interfaces for what Javasoft call the 'weird stuff'. This addresses a criticism of ODBC where the complex and simple tasks were perceived as being mixed together. Also, the specification concentrates on simple, common tasks like SELECT, UPDATE, INSERT AND DELETE as opposed to uncommon cases like metadata access and dynamically typed statements. Javasoft's policy is to keep common cases simple and have uncommon cases "do-able" (as Javasoft puts it). All this is moving fast. It has to; companies like Weblogic have already developed proprietary interfaces between Java and database management systems. Javasoft are keen to avert a whole raft of proprietary mechanisms like this. In summer 1996, an official ODBC/JDBC bridge has become available for people who can't wait to get Java applets talking to relational databases.

Java Database Connectivity (JDBC) is Sun Microsystems' standard SQL database access interface, providing uniform access to a wide range of relational databases. It consists of a set of classes and interfaces written in the Java programming language. The diagram below shows components of the SCO JDBC model. See below the diagram for an explanation of each component.

Various parts are:

JDBC-Aware Java applet. A Java applet that uses the JDBC API can manipulate a database. This will typically be downloaded over the Internet.

JDBC-Aware Java application. A Java application that uses the JDBC API can manipulate a database. This will be installed on the client device.

JDBC driver manager. The JDBC API defines Java classes to represent database connections, SQL statements, result sets, database metadata, and so on. The JDBC API is implemented via a driver manager that can support multiple drivers connecting to different databases. This must be installed on the client device. The driver manager is provided by Sun Microsystems.

JDBC driver. The driver is a set of Java classes that processes JDBC calls and returns results to the applet or application. The JDBC driver is a JDBC-Net pure Java driver. This will typically be downloaded over the Internet.

Server module. The JDBC driver has a component based on the client device and a server module that is connected through a RPC mechanism built into the driver.

MidAS can use one of these multitier system for optimum performance. As a result of the complexities of serving executable content over an insecure network, developers have struggled with system architectures to provide efficient and convenient access to databases, while still maintaining system security and stability. In providing database access through JDBC, either from a stand-alone application or a World Wide Web applet, three major paradigms are generally followed: one-tier, two-tier, or three-tier systems.

One Tier Systems:

The one-tier system is only seen when the JDBC driver is completely written in Java code.

Standalone Application: The Java client code, the JDBC Driver Manager, and the JDBC Driver(s) are all contained in one tier, on the client machine. The database client may then connect to any host on the network and begin accessing information in the remote database (see Figure below).

Figure: One-Tier Standalone Application

World Wide Web Applet: The Java client code, the JDBC Driver Manager, and the JDBC Driver(s) are all downloaded from the WWW server, onto the client machine. The database client may then connect to a remote database on the same host from which the classes were loaded from (the WWW server) and begin accessing information (see Figure below).

Two Tier Systems:

The two-tier system is applicable when the JDBC driver requires a native code library to translate JDBC functions into the DBMS's specific query language.

Standalone Application: The Java client code, the JDBC Driver Manager, and the JDBC Driver(s) are all contained in one tier, on the client machine. In addition, the

JDBC Driver (written in Java) requires a native code library to translate its JDBC functions into a language specific to one DBMS. This native-code library, specific to

one DBMS and one operating system, is contained in the second tier. The database client may connect to any host on the network, and begin accessing information, via

the native code library, in the remote database (see Figure below).

World Wide Web Applet: This architecture is not possible for WWW applets. The Java client code, the JDBC Driver Manager, and the JDBC Driver(s) can be downloaded from the network, but the required native code library cannot be retrieved and used on the client machine. The library is platform-specific, and is not subject to the normal safety checks that the Java compiler and run-time engine impose on Java applets.

Three Tier Systems:

Three-tier systems are being developed by companies like WebLogic and Visigenic because of their support for database access from WWW applets. The JDBC drivers typically require a native code library for translations.

Standalone Application: The Java client code, the JDBC Driver Manager, and the JDBC Driver(s) are all contained in one tier, on the client machine. The native code library is housed on a second host, and serves as a gateway to a third tier, the DBMS. The database client may instantiate a 'session' with the native code library gateway, which in turn connects to the remote database system. As the client access data, the gateway negotiates the flow of information to and from the database system. This allows a centralized point of administration for systems personnel, simplifying upgrades and protocol changes. It also creates a bottleneck situation if the gateway to flooded with requests simultaneously.

World Wide Web Applet: The Java client code, the JDBC Driver Manager, and the JDBC Driver(s) are downloaded from the host server to the client machine running a Java enabled WWW browser (e.g. Netscape Navigator 2.x or later). The native code library is housed on that same host server, and serves as a gateway to a third tier, the DBMS. The database client may instantiate a ``session'' with the native code library gateway, which in turn connects to the remote database system. As the client access data, the gateway negotiates the flow of information to and from the database system.

This architecture works around the browser policy restrictions of connecting only to the applet's ``home'' server. The web server from which the applet was retrieved serves as a proxy gateway, by which applets can in fact communicate with any remote hosts the proxy allows. Once again, this architecture offers a centralized point of authentication and access control for systems personnel, rather than trying to maintain the access control restrictions in the code of many software programs distributed throughout an enterprise (see Figure below).

JDBC drivers fit into one of four categories:

A. The JDBC-ODBC bridge provides JDBC access via most ODBC drivers. Note that some ODBC binary code and in many cases database client code must be loaded on each client machine that uses this driver, so this kind of driver is most appropriate on a corporate network, or for application server code written in Java in a 3-tier architecture.

B. A native-API partly-Java driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.

C. A net-protocol all-Java driver translates JDBC calls into a DBMS-independent net protocol which is then translated to a DBMS protocol by a server. This net server middleware is able to connect its all Java clients to many different databases. The specific protocol used depends on the vendor. In general, this is the most flexible JDBC alternative. It is likely that all vendors of this solution will provide products suitable for Intranet use. In order for these products to also support Internet access they must handle the additional requirements for security, access through firewalls, etc., that the Web imposes. Several vendors are adding JDBC drivers to their existing database middleware products.

D. A native-protocol all-Java driver converts JDBC calls into the network protcol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is a practical solution for Intranet access. Since many of these protocols are proprietary the database vendors themselves will be the primary source for this style of driver. Several database vendors have these in progress.

In an effort to standardize an interface to DBMS's, Microsoft created Open Database Connectivity (ODBC), based on the X/Open definitions of SQL CLI (Call Level Interface). ODBC is an API in which application developers can code their programs using ODBC function calls, and each DBMS vendor can provide an ODBC driver for their specific DBMS. An application written for the ODBC API can be used to access any DBMS, given the appropriate ODBC drivers.

ODBC is a specification to which developers write either:

An ODBC-enabled ``front-end'' or ``client'' desktop application, also known as an 'ODBC Client'. This is the application that the computer-user sees on the computer screen, or

An ODBC Driver for a ``back-end'' or ``server'' DBMS (Database Management System). This is the DBMS application that resides on a computer that is used to store data for access by several users. This application is not what is loaded on the end user's computer. This server application is usually more robust (faster, with centralized security, and backups of data, and so forth) than the client application. The ODBC Driver resides between the ODBC Client and the DBMS; however, it is loaded on the front-end computer.

To use ODBC, the following three components are required:

ODBC CLIENT

an ODBC-enabled front-end (also called ODBC client) - Examples: Access, an application created with Access, or ODBC-enabled applications from other vendors.

ODBC DRIVER

an ODBC Driver for the ODBC Server. Any ODBC client can access any DBMS for which there is an ODBC Driver.

DBMS SERVER

a back-end or server DBMS - Examples: SQL Server, Oracle, AS/400, Access, or any DBMS for which an ODBC driver exists.

ODBC Over a Network

Some DBMS vendors provide a transport mechanism for client applications to access the database server over a network. A three-tier architecture can be used to develop ODBC clients in a TCP/IP network. The client application is written to the ODBC specifications, and compiled with the ODBC and DBMS transport libraries. The client binary is now equipped to communicate with a DBMS server remotely, and the source code is portable among other DBMS's.

The JDBC-ODBC bridge provides JDBC access via most ODBC drivers. Some ODBC binary code and in many cases database client code must be loaded on each client machine that uses this driver, so this kind of driver is most appropriate on a corporate network, or for application server code written in Java in a 3-tier architecture.

MidAS configurations suit JDBC API very well. Specially, using PostgreSQL along with JDBC is a better tool than any other option. The JDBC API defines Java classes to represent database connections, SQL statements, result sets, database metadata, etc. It allows a Java programmer to issue SQL statements and process the results. JDBC is the primary API for database access in Java.

The JDBC API is implemented via a driver manager that can support multiple drivers connecting to different databases. JDBC drivers can either be entirely written in Java so that they can be downloaded as part of an applet, or they can be implemented using native methods to bridge to existing database access libraries.

JDBC API is expressed as a series of abstract Java interfaces that allow an application programmer to open connections to particular databases, execute SQL statements, and process the results.

The most important interfaces are:

java.sql.DriverManager which handles loading of drivers and provides support for creating new database connections

java.sql.Connection which represents a connection to a particular database

java.sql.Statement which acts as a container for executing a SQL statement on a given connection

java.sql.ResultSet which controls access to the row results of a given Statement

The java.sql.Statement interface has two important sub-types java.sql.PreparedStatement for executing a pre-compiled SQL statement, and java.sql.CallableStatement for executing a call to a database stored procedure.

JDBC drivers simply need to provide implementations of the abstract classes defined as in JDBC API.

JDBC Interfaces

Driver

Connection

Statement

ResultSet

PreparedStatement

CallableStatement

ResultSetMetaData

DatabaseMetaData

JDBC Classes

DriverManager

Types

DriverPropertyInfo

Date

Time

Timestamp

JDBC Exceptions

SQLException

SQLWarning

DataTruncation

Manage JDBC drivers.

Load the driver classes referenced in the "jdbc.drivers" system property .

This allows a user to customize the JDBC Drivers used by their applications.

For example in your ~/.hotjava/properties file you might specify-

jdbc.drivers=foo.bah.Driver:sybase.sql.SybDriver:oracle.sql.OraDriver

A program can also explicitly load JDBC drivers at any time using

Class.forName("my.sql.Driver");

getConnection()

JDBC URL has the format - jdbc:subprotocol:subname

Like - jdbc:sybase:Tds:144.14.2.1:2001

Specific for a particular DBMS

acceptsURL(String)

connect(String url,Properties info)

getPropertyInfo()

jdbcCompliant()

getMajorVersion

getMinorVersion

Represents a session with a specific database

createStatement()

prepareStatement()

prepareCall()

getMetaData()

Default auto commit

Execute a SQL statement without parameters and obtaining the results produced by it.

executeQuery(String)

executeUpdate(String)

execute(String)

getResultSet,getMoreResults,getUpdateCount

setCursorName(String)

setMaxRows(int)

ResultSet provides access to a table of data generated by executing a Statement.The table rows are

retrieved in sequence. Within a row its column values can be accessed in any order.

next()

getABC(int) and getABC(String)

getCursorName()

getMetaData()

With the growing popularity of Java, the network programmers on both the public Internet and private intranets desire to write one common interface for all of their organization's databases, portable to many platforms. C, C++, Perl, Tcl and proprietary protocols are the present solution; Java and the JDBC API is the future solution.

The Java language is evolving very quickly, and new Java products are appearing each day. At the current rate of Internet growth, no one can predict where their organization will technologically stand in the next twelve months. Chances are, however, Java will continue to be a driving force in application development, and JDBC will be the connectivity API of choice for robust database systems.

JDBC follows an established specification and tried implementation for database-neutral communications from applications. The bridging solution to current ODBC systems allow users to maintain compatibility with older systems that may not have JDBC counterparts. Leading vendors are working very actively on getting JDBC components for their databases out to market in a relatively short period of time.

The problem of platform neutrality is clearly evident in that solution. Enterprise-level components like JDBC may be among the deciding factors when software development firms are faced with this new race.

So, the MidAS can use this solution with efficient performance. Further, JDBC is PostgreSQL compliant and hence suitable for MidAS.

As MidAS continue to grow, the need to organize, maintain, and access electronic data increases. Database solutions not only have to provide a means to data access, but they must also ensure efficiency, superior performance, reliability, and easy user interface development.

When we analyze various options available to integrate the MidAS on WWW, JDBC comes out as the best due to its very approach of dealing with big databases over high speed networks. Further, PostgreSQL works well with JDBC, which has been taken into consideration for MidAS.

So, with all the above advantages and comparing with other configurations available it can be concluded that JDBC is the best solution available in current context.

• Data Base Management Systems by Raghu Ramakrishnan
• Data Base Management Systems by Elmasri & Navathe.
• Dr. Perrizo's class notes Fall 1998
• Sun Microsystems JDBC Home Page, http://java.sun.com/products/jdbc/
• Open Link software company Homepage, http://www.openlinksw.com
• "Integrating Databases with Java via JDBC" By Rawn Shah

• SCO’s JDBC driver Homepage, http://www.sco.com/vision/products/jdbc/
• Communication of the ACM sep 98, vol 41, no. 9, Special issue on recent trends in database connectivity
• Communication of the ACM, Oct, 98, vol 41, no. 10
• Beowulf cluster Home Page, http://beowulf.gsfc.nasa.gov
• IBM’s database connectivity HomePage, http://www.software.ibm.com/data/
• "Analysis of Java Database Connectivity and its Application in a Multi-Platform, Multi-DBMS Environment" by Jerrid Haman