 The magazine of the Melbourne PC User Group Using Java to implement client-server databases John Grant, Xiaoya Lin and Noel Craske |
Many organisations in the world maintain and collect large amounts of data.
These are held in large databases, often stored in mainframes and managed by a Database Management System
(DBMS). Over the years many organisations have grown and developed or purchased new DBMSs. Often these
systems are incompatible with existing systems and custom programs have been written to interface with the
database. Many organisations find the resulting mix of databases and programs increasingly difficult to keep
track of, and even more difficult to extend. Many of them are turning to Java to develop interfaces with
existing DBMSs and to develop new DBMSs.
What is Java?
Java is an Object Oriented programming language developed by Sun Microsystems. It gained popularity as a
programming language on the Internet, and is now being used in many serious database developments. The
primary reason for its growth in popularity is the fact the language is "hardware independent".
This means, unlike programs written in C++ and other languages, the program can run on many different
hardware platforms without the need to recompile the source code. Another benefit is the language's in-built
networking aspects. Many other languages provide networking support through add-in libraries, but only Java
has this in-built to the core of the language. This results in extremely efficient and easy implementation of
networking programs.
What is a client-server database?
A client-server DBMS has several key differences to standard relational DBMS. The basic setup consists of a
client (or several) making requests for information from a DBMS that resides on a server in the network. The
client will then receive the requested data from the DBMS and present it to the user in some format. The
server handles much of the workload and has to contend with such issues as Concurrency Control, Security,
Data Integrity, etc. Unlike stand-alone databases, the client-server database must deal with a network to
transmit data to users. Other problems occur with data often not being stored in a single location, or even
in the same DBMS. The problems associated with retrieving data from different database systems while
maintaining the transparency of this to the user is currently under research, but the JDBC from Java may
provide some help in solving many of the problems for developers.
ODBC and JDBC
Open Database Connectivity was developed by Microsoft to provide a standard interface to DBMSs. ODBC uses
function calls to allow vendors to access any database that supports the ODBC interface. An ODBC driver that
is written for each database then interprets these function calls. When using ODBC vendors can write
ODBC-enabled or ODBC drivers and DBMS systems that will enable a wide range of products to interact with
them. This results in a greater range of programs available to users for any given DBMS that they use.
When using ODBC three components are necessary:
- The ODBC client used to interact with users
- The ODBC driver, which handles the communication between the client and the DBMS server
- The DBMS server, which manages the data.
To allow vendors and customers to use the existing ODBC-enabled technology the JDBC developers have provided a JDBC-ODBC Bridge that converts the function calls between the two technologies. This means that existing ODBC technology can continue to be used with Java developments.
JDBC, like most driver specifications, is low-level and functional. The basics of the functionality are contained within the java.sql.* classes. The basic JDBC driver is loaded with a java.sql.DriverManager class. Once you have a loaded driver it is possible to open a connection using the java.sql.Connection class. The connection is perhaps the most vital part of the process, as the rest of the procedure centres around the use of the connection object. After the connection is created, most clients will begin to transmit queries. Any return values from queries are stored in a java.sql.ResultSet object. JDBC also allows stored procedures to be called using the java.sql.Statement, java.sql.PreparedStatement and java.sql.CallableStatement classes.
Implementation strategies using Java
Because of the relatively recent development of Java the designers have had to devise ways to make it compatible with existing DBMS systems without the need to re-code servers or drivers. The result is that there are several methods you can use to implement a JDBC solution for database connectivity. When implementing client-derver DBMS systems over networks using Java, developers have three main paradigms to choose from. One Tier, Two Tier or Three Tier systems are the three types of paradigm with the JDBC-ODBC bridge being a popular choice for Two Tier developments.
One Tier systems are only seen when the Database driver is written in Java code. When in use, the One Tier system has the client code, JDBC driver and JDBC driver manager all located on the client machine. They are either stored there or downloaded to the machine (if accessing from the WWW, for instance). The client program then directly interacts with the DBMS through JDBC function calls. While this is the best and easiest system to implement, the reason that this approach is not very common at the moment is that very few JDBC drivers exist, written purely in Java. While this will slowly cease to be a problem, at the moment other methods are needed.
Two Tier systems are seen where the JDBC Driver uses a native code library to translate JDBC functions into the specific DBMSs query language. This system has the client code, JDBC driver and driver manager on the client machine. The system then uses the native code library to connect to the DBMS and begin transactions. The problem with this is that the native code library is platform dependent and therefore negates the benefit of Java's "hardware independence". Therefore, this particular paradigm is unsuitable for WWW applications, as the native code library is not subject to the same security checks that the Java compiler and run-time engine perform on all applets. This approach can be used in a network situation where the platform is the same throughout the entire network.
The Three Tier system has the same components residing on the client system. The difference lies in the server system. In this case the client actually opens a connection (session) to the native code library (gateway). This library then connects to the DBMS and begins transactions. Because the native code library acts like a server, it negates the problem that prevents the Two Tier system from functioning over the WWW. However this approach does present a bottleneck -- as all requests to the DBMS go through the gateway it may become flooded with requests and may slow down performance significantly. Often hosting the gateway on a dedicated server machine can alleviate this. This approach is often used, as it quickly ebables vendors to provide JDBC implementations using existing drivers for their DBMSs.
The JDBC-ODBC bridge is a Two Tier approach that uses JDBC function calls to access the database. However, before these calls are transmitted to the DBMS they are translated to an ODBC function call by the Java JDBC-ODBC bridge. This enables Java client programs to use existing ODBC drivers without any additional effort or cost. Because almost all databases provide ODBC compliance this bridge between standards is a very useful feature in the language. As developers write programs for existing databases they can make use of the JDBC-ODBC bridge and in the future, when they wish to change to pure JDBC drivers, very few changes will need to be made.
Choosing an implementation strategy
When choosing an implementation strategy for your client-server database othere are several considerations that need to be addressed, if you are using Java. The first consideration is which database you are going to be using, and are the necessary JDBC drivers available for your platform. Although Java is "platform independent" many of the existing drivers are merely Java wrappers (interfaces) around existing C or C++ code. The result is a platform-dependent driver. Another consideration is that many DBMSs have extensions to the standard SQL interface in-built to them and if you wish to access these extended features then the JDBC driver will need to support them. The JDBC-ODBC bridge supports many of these features and therefore your driver must support this.
When developing commercial DBMS systems the scalability and performance of the database is an important issue and many Two Tier approaches are inherently inflexible. You may wish to look at a Three Tier approach that enables a server to mediate between the clients and the DBMS.
Java has built-in support for multi-threading applications and taking advantage of this feature can drastically improve the performance of your DBMS. Threads allow the Java program to handle many requests at the same time, with the ability to protect against conflicting operations also possible through synchronisation. Many JDBC drivers that are not written in pure Java may not provide support for multi-threading applications and therefore the benefit will be lost. If your driver does not support threads then you may wish to look at the Three Tier approach as is allows your client programs to use threads to communicate with the gateway, while the gateway handles the single thread interaction with the DBMS.
Other concerns that may be of interest are the security of the data stream and security for individuals. Security of the data stream is commonly implemented by encryption techniques when transmitting the data between the client and the server along a network. Security for the individual refers to the use of passwords to limit access to the DBMS. When potentially dealing with thousands of users, having the DBMS handle these can be wasteful of resources, so it is often better to have a different server handle these features. Both these issues can be handled in a Three Tier approach but may not be supported in a Two Tier approach.
Basic implementation using Java
There are four basic steps to connecting to a database using Java JDBC technology:
- Make a connection to the database
- Send an SQL statement to the database
- Process the return values from the database
- Close the connection to the database.
Connection dbConnect = DriverManager.getConnection ("jdbc:odbc:DB1","scott", "tiger");
This line uses the DriverManager class to open a connection to the database,
in this case an ODBC driver for an Oracle Database, and then returns a connection object which can then be
used by the following steps. The next step is to create a statement object that can then be used to execute
an SQL statement on the database.
Statement dbSelect = dbConnect.createStatement();
This statement actually creates a blank statement that is then used to
retrieve records in the next step. ResultSet dbResults =
dbSelect.executeQuery("SELECT * FROM students");
The returned ResultSet can be stepped through to perform any processing that the user may wish. The final
step of the process is to close the connection to the database. This is done using the following lines
DbSelect.close();
DbConnect.close();
The Java code above assumes that the various networking interfaces have already been implemented. The
DriverManager class can only open a connection to a database that it has a link to. This means that the
database must either be on the local machine or have an open network link to the relevant sever machine.
Conclusion
Using Java to implement DBMS clients and develop DBMS systems has a number of benefits over other conventional program languages. These benefits arise out of the basic features in-built to the Java Language. With the in-built networking features, threading, and the hardware independent nature of its programs, Java is much quicker and easier to write programs in when developing client-server systems, as they need to use these features.
The ability to use One Tier solutions and Three Tier solutions to provide the ability for users to access the database over the World Wide Web is a big advantage as many companies are now looking into the e-commerce market. The ability to access a DBMS from the Web allows companies to provide essential data to customers quickly and easily. It also means that employees could potentially work from home with great ease as Java already solves most of the problems relating to security and transmission of data.
Perhaps the most important benefit of using Java to develop and implement
DBMSs is the ever-increasing number of IT professionals who are able to use it. The increasing numbers of
programmers and analysts who are familiar with the Java language means that developments using Java will not
have problems with qualified staff to manage or support the project.
| References Client/Server Architecture http://www.dgsys.com/~dcasug/sysbintro/csarch.html Choosing a Java Database Connectivity Driver http://www4.weblogic.com/docs/techoverview/jdbc.html Java in the Database http://www.devx.com/upload/free/features/javapro/1999/03mar99/kn0399/kn0399.asp Data Access Roadmap http://ourworld.compuserve.com/homepages/Ken_North/dataacce.htm Overview of JDBC API http://java.sun.com/products/jdbc/overview.html The Future of Enterprise Database access with JDBC http://ww.i-kenetics.com/wp/futurejdbc/futurejdbc.htm JDBC FAQ http://java.sun.com/products/jdbc/jdbc-frequent.html Borland Teach yourself JBuilder in 14 Days Michelle M. Manning, Sams Net Borland Press, 1997 WWW Programming in Java Database Connectivity, Heinz Schmidt, 10/8/1998 http://www.sd.monash.edu.au/sft3200/Lectures/Module11/DBConnectivity.html |
About the authors
John Grant is completing his Bachelor's Degree in Computing at Monash Caulfield, Xiaoya Lin is doing
research
in rule-based systems towards his Doctorate and Noel Craske is a Senior Lecturer at Monash.
Reprinted from the July 1999 issue of PC Update, the
magazine of Melbourne PC User Group, Australia
