While the marriage of Java and database programming is beneficial to Java programmers, Java also helps database programmers. Specifically, Java provides database programmers with the following features they have traditionally lacked:
Easy object to relational mapping
If you are interested in taking a pure object approach to systems development, you may have run into the cold reality that most of the world runs on relational databases into which companies have often placed hefty investments. This leaves you trying to map C++ and Smalltalk objects to relational entities. Java provides an alternative to these two tools that frees you from the proprietary interfaces associated with database programming. With the “write once, compile once, run anywhere” power that JDBC offers you, Java’s database connectivity allows you to worry about the translation of relational data into objects instead of worrying about how you are getting that data.
A Java database application does not care what its database engine is. No matter how many times the database engine changes, the application itself need never change. In addition, a company can build a class library that maps its business objects to database entities in such a way that applications do not even know whether or not their objects are being stored in a database. Later in the book I discuss building a class library that allows you to map the data you retrieve through the JDBC API into Java objects.
Java affects the way you distribute and maintain an application. A traditional client/server application requires an administrator responsible for the deployment of the client program on users’ desktops. That administrator takes great pains to assure that each desktop provides a similar operating environment so that the application may run as it was intended to run. When a change is made to the application, the administrator makes the rounds and installs the upgrade.
The Java language employs the idea of the zero-install client. The object code for the entire application, client and server, resides on the network. Since the JVM provides an application with a guaranteed runtime environment, no administration is needed for the configuration of that environment for individual applications. The users simply use a virtual machine interface such as HotJava to locate the desired application. By clicking on the application icon, a user can run it without even realizing the application was never stored on their local machine.
The traditional application makes a clear distinction between the locations where processing occurs. In traditional applications, database access occurs on the server, and GUI processing occurs on the client; the objects on the client machine talk to the database through a specialized database API. In other situations, the client might talk to the server through a set of TCP/IP or UDP/IP socket APIs. Either way, a wall of complex protocols divides the objects found on the client from those on the server. Java helps tear down this wall between client and server through another piece of its Enterprise platform, RMI.
RMI allows applications to call methods in objects on remote machines
as if those objects were located on the same machine. Calling a
method in another object in Java is of course as simple as the syntax
object.method(arg). If you want to call that
method from a remote machine without RMI, however, you would have to
write code that allows you to send an object handle, a method name,
and arguments through a TCP/IP socket, translate it into an
object.method(arg) call on the remote end, perform
the method call, pass the return value back across the socket, and
then write a bunch of code to handle network failures. That is a lot
of work for a simple method call, and I did not even get into the
issues you would have to deal with, such as passing object references
as arguments and handling garbage collection on each end. Finally,
since you have written this complex protocol to handle method calls
across the network, you have serious rewriting to do if you decide
that a given object needs to exist on the client instead of the
server (or vice versa).
With RMI, any method call, whether on the same machine or across the network, uses the same Java method call syntax. This freedom to distribute objects across the network is called a distributed object architecture. Other languages use much more complex protocols like Common Object Request Broker Architecture (CORBA) and the Distributed Computing Environment (DCE). RMI, however, is a Java-specific API for enabling a distributed architecture. As such, it removes many of the complexities of those two solutions.
For a client/server database application, a distributed architecture allows the various parts of the application to refer to the same physical objects when referring to particular objects in the data model. For example, take an airline ticketing system that allows customers on the Internet to book flights. Current web applications would have a user download a bunch of flight information as an HTML page. If I book the last seat on a flight that you are viewing at the same time, you will not see my booking of that last seat. This is because on each client screen you simply see copies of data from the database.
If you reconstruct this web application so that it uses RMI to retrieve data from a single flight object on the server, you can allow any number of different customers to view the exact same plane objects at the same time. In this way, you can be certain that all viewers see any change made to the plane object simultaneously. When I book the last seat on that flight, the flight object makes an RMI call to all clients viewing it to let them know another seat was booked.
The pieces of the story are now in place. You will be using JDBC for your database access and RMI to distribute the objects that make up your application. This book covers the JDBC API in complete detail and discusses RMI as it pertains to the creation of distributed three-tier database applications. To better use these APIs once you have gone beyond this book, I strongly recommend further reading on these topics: object-oriented design methodologies, patterns in software development, and general database programming.