Introduction
In this article, we take a look at using JDBC to build applications. Internet technology is changing so rapidly that some of the methods used today will become obsolete tomorrow. We are taking an approach that combines Java network programming and JDBC programming. Programming in JDBC is taking a step backward when you have mature 4GL tools like Sybase Powerbuilder. Programming in JDBC is similar to programming in any low level database library like ODBC or Sybase CT-LIB.

There is more than one way to deploy applications and applets using JDBC. The first approach is by using the JDBC-ODBC bridge that is part of JDK 1.1. You have to install ODBC Drivers and set the ODBC datasource in each client. If you are willing to do this existing client server tools will do a better job than Java. The second approach is to use a JDBC driver that is 100 Percent Java compliant. For writing Java applications, this method will work fine, but not for Java applets. Applets can not make arbitrary connection to other servers. You have to run your database server in the same machine where the Web server is running. This article will help you write Java applets or applications using JDBC without any of the above mentioned restrictions.

What are the Advantages?
This implementation follows a 3-tier client-server model. JDBC Client sends a request to JDBC server which processes the request, communicates to the database server and sends back the reply. Compatible with all Java enabled browsers. It's secure because the database server is not exposed. You can configure number of concurrent users allowed at any point of time. With little modification you can dynamically increase and decrease number of JDBC server listening for request or totally redirect the request to a different web server. You can also attach your own encryption and decryption routine before communicating with a remote client. JDBC server runs on the server side so you have total freedom to use any JDK, any ODBC driver and Java native methods. You can batch your request or can have real-time connection like any other client-server application.

There are some limitations in this implementation. If you want to have multiple connection you have to initialize multiple driver's in the client side. It will not handle blob or image data type even though it's very easy to implement one, by saving the image in the server and sending the filename back as URL. You can use the same method to transfer the whole ResultSet.

Architecture
There are three different functional pieces. Port allocator (PA) is a Java based server that listens on a predefined port. JDBC server listens for connection from client. JDBC client which makes the request. When client makes a request to Port Allocator it will send back a JDBC server port that is currently free. From that point onwards, JDBC client talks only to the JDBC server. Client sends a single byte command to server and waits for reply. The server sends back a status code and byte or string value. Commands can have arguments usually a byte or a string. While processing clients request, if server encounters an exception it converts the exception to a string and sends back an error code and the string to the client.

Let us look into the details. There are four client side classes RDriver, RConnection, Rstatement, RResultSet for connecting and fetching data. These are very similar to JDBC interfaces Driver, Connection, Statement, ResultSet. It does not implement these interfaces. JDBC client initializes the RDriver then creates a TCP socket to port allocator (PA) and gets a port to communicate to a JDBC server. It also sends command to initialize DriverManager in the server if everything is successful. This enables the client to connect directly to the JDBC server using RDriver.connect(username, password) and create a database connection. You only need username and password to create a database connection hiding all server details in the JDBC server code. You can call createStatement() method to create a RStatement() after successfully establishing a database connection. Send the SQL string to server using executeQuery function. It will create a ResultSet in the server and RResultSet in the client. Use executeUpdate() function for update and insert SQL statements. Access the ResultSet values using next() and getString() or getInt().

One of the advantages of this architecture is that all conversation between client and server happens as bytes and strings. If the client dies for some reason Driver.detach() will cleanup the connection, but if an exception occurs you have to take care of it. Rdriver has an overloaded finalize method which calls Driver.detach().

The example here shows how to connect to a Sybase SQL server using beta version of Jconnect. Before running the examples you may need to change hostname, port and any other parameters it may need in your environment.

Table 1 shows the commands, arguments and return code.

JDBC Protocol Implementation
JDBC Protocol is a layer above the Java socket layer. It hides the Java socket layer, but you have to still catch exceptions from this layer. Protocol structure follows the same structure as any other standard protocols (FTP, TELNET). JDBC protocol does session control by sending acknowledgment or negative acknowledgment after each request from client. Java takes care of presentation of data. This protocol fits in the top layers of OSI model. Like most other protocols this protocol has series of commands and expected return values. Most importantly these commands are not part of any standards. One other difference is it has only one path to the server, unlike FTP which uses a command port (21) and a data port (20).

All commands are single byte followed by a byte or string. In special cases it is more than one string. For each command sent from client JDBC server replies with a return status of SUCCESS or FAIL. If the return status from the server is SUCCESS it returns either string, byte or no value depending on type of command. If an error occurs in the server the return status is FAIL server then sends a SQLExeption string to the client.

Table 2 explains the protocol implementation.

• Making the Impossible Easy: Failover for Any Application

• Figure 1
• Figure 2
• Source Code
• Figure 3
• Figure 4