JDBC originally only supported going to the next row in the result set, because this is the most basic functionality that all supported datbaases provide. Currently many databases have a more advanced control structure, so more advanced features are implemented in JDBC 2.1. ResultSets now support moving forward and backward through the results, as well as relative and absolute positioning of the cursor. Also they have the option of being updatable. This means that if you execute a query and then the underlying database changes, the result set changes to reflect it.

The more advanced features like support for JNDI naming, Java Transaction Service (JTS) API, connection pooling, and rowsets are in the optional package (javax.sql).

Pattern Use

The JDBC framework consists of many related objects that are only defined by their interfaces. This requires static methods so that you can create instances of the implementing classes without knowing their actual class.

Abstract Factory (see page 6): Classes that implement the Connection interface use the Abstract Factory pattern. The Abstract Factory provides flexibility. You can write an application without knowing what database has been or will be chosen. You know the Connection interface, and you therefore know how to create statements.

This benefit of flexibility also extends to runtime. The implementing class is determined at runtime, so the application doesn’t need to be changed just because another database or another driver has been chosen.

Factory Method (see page 21): It's easy to see that JDBC uses Factory Methods quite heavily. JDBC was designed to be flexible so that developers could use the framework without knowing the implementing classes. Therefore most of the JDBC API consists of interfaces. Because you can not call the constructor on an interface, Factory Methods are used to create instances of the required type. This is the case with the getConnection method in DriverManager. It instantiates an object that implements Connection and returns that object.

The Factory Methods provide a flexible way of creating objects without having to know their actual type.

Bridge (see page 150): The Bridge pattern underlies the whole JDBC API. JDBC provides a uniform interface to multiple databases. It is this collection of interfaces that provides the decoupling of the implementation from the client, the purpose of the Bridge pattern. The interfaces are the functional abstraction that separates out the implementation.

The application that uses JDBC can change without affecting the implementation of a JDBC driver. The driver—that is, the implementation of the JDBC interfaces—can change its internal workings, and the application that uses the driver can remain unchanged.

202

RMI

Packages

java.rmi, java.rmi.dgc, java.rmi.registry, java.rmi.server, java.rmi.activation

Use: J2SE

Overview

RMI enables you to communicate by making remote method calls. Basically, it allows an application to run methods on objects that are not in the same address space. This enables Java to use the same approach for distributed communication as it does for local communications—the Java client can make a series of simple method calls to a object. Neither the client nor the server needs to write large amounts of code to manage remote communication in RMI—the task is handled behind the scenes by the RMI communications infrastructure.

RMI uses an interface to define the methods which can be called on the RMI server by the client. This interface must extend java.rmi.Remote, which identifies any class that uses the interface as an RMI participant. The interface is used by both the RMI client and server. The server implements the interface, providing the actual functionality. The client uses the interface to identify which methods it can run remotely.

To call methods on an RMI server, a client must get a reference to the remote server object during runtime. The client must obtain an object called a stub which enables it to locate and communicate with a specific remote object running in some other address space. There are two ways to get a stub so that you can make remote method calls. The most common way is to use a naming service, such as JNDI or the rmiregistry. Naming services allow clients to perform lookup operations for remote objects, and to obtain stubs for remote communication. Another way to obtain a stub is to make a remote method call on an object which itself returns a stub.

The stub on the client is responsible for communicating with the remote object on the server. It greatly simplifies the task of remote communication for the client. In client code, a remote method call looks exactly like an ordinary method call. When a client application makes a remote method call, the stub receives the call, communicates with the server, and returns the result to the client.

The stub marshalls arguments used in methods, and the stub unmarshalls the return value before returning it to the client. Marshalling is a specialized form of serialization, where the object is wrapped in a java.rmi.MarshalledObject. The MarshalledObject contains the serialized object URI where the class file of the send object can be located, plus codebase, annotated with a codebase property. The codebase is a String representation of the URL where the object's class file is located.

Creating an RMI application is not complicated. The first thing to do is define the remote interface; that is, the interface that determines what methods are available remotely. It has to extend java.rmi.Remote and all methods have to declare throwing at least a java.rmi.RemoteException.

The remote object implements the remote interface however it sees fit. When a remote object is send across its address space, not the remote object is send, but the stub is. To accomplish this the remote object has to “export” itself, which means that the JVM has to be notified that this is a remote object and it should behave accordingly. An unexported remote object sent across the wire behaves like any other regular (non-remote) object and gets copied across the network. This can lead to unexpected behaviour. There are two ways to export a remote object. The first is to extend java.rmi.server.UnicastRemoteObject. In the constructor of this class, the object is exported. The other way to export the remote object is to explicitly call the exportObject method in UnicastRemoteObject. Then the remote object is not required to extend UnicastRemoteObject.

To make the remote object available to other objects, the remote object can register itself with a name service.

The client looks up a remote object through a name service. It gets an object back, which it can cast to the expected type (remote interface) tied to the name used in the request. From there on, the client uses that object to invoke methods on. The stub forwards the calls to the remote object and waits for the return value. The stub may throw java.rmi.RemoteException to signal that there was a problem in communicating with the remote object.

The stub can be automatically generated by the rmic tool.

203

Pattern Use

Abstract Factory (see page 6): The Abstract Factory pattern is used to create families of related products. In RMI, the RMISocketFactory implements this pattern by defining methods to create the sockets used in RMI communications. The RMISocketFactory defines abstract methods to create the client and server sockets used for RMI communications. On a specific JVM, a concrete subclass of RMISocketFactory will provide the functionality to create the RMI sockets.

Factory Method (see page 21): An Abstract Factory will often use one or more Factory Methods to create its individual products. The two interfaces implemented by RMISocketFactory, RMIClientSocketFactory and RMIServerSocketFactory, define factory methods for the creation of client and server sockets, respectively. These interfaces are implemented in RMISocketFactory as abstract methods, and a subclass supplies concrete implementations of these methods for RMI during runtime.

Decorator (see page 166): The Decorator pattern lets you extend an object's functionality by creating another object. This object has the same interface as the original and references the original object for most operations, but adds some additional features.

RMI uses the Decorator pattern during object serialization. When RMI sends objects to another address space, the objects are marshalled; the java.rmi.MarshalledObject class handles the task of sending and receiving copies of the objects. To do this, the MarshalledObject class uses a sub-class of the java.io.ObjectOutputStream and the java.io.ObjectInputStream during communication. These special subclasses extend the basic functionality of their underlying java.io.InputStream and java.io.OutputStream by allowing two MarshalledObjects to be compared for equality even if they reside on different JVMs.

Proxy (see page 197): The RMI stub, which is used by a client to communicate with a server object, is an implementation of the Proxy pattern. The stub implements the same remote interface as the remote object on the server, so it acts as the remote object for the RMI client. When a client makes a remote call, the stub forwards the method call to the real remote object on the server. The benefit here is that the network communication is hidden from the client. It frees the client from setting up connections, managing a communication session and participating in distributed garbage collection.

204