1203-1205

Previous Table of Contents Next

Page 1203

Figure 53.3.
Common JDBC thin
client configuration.

Recently, RDBMS and third-party vendors have begun providing pure Java drivers that convert JDBC calls to the RDBMS-specific network protocol directly (JDBC to SQL*Net, for example). This eliminates the need for a server-side driver component and improves performance. This configuration is most suitable for intranet applications with demanding performance requirements.

The configuration of a specific JDBC driver doesn't necessarily dictate the way it is deployed. JDBC is considered a low-level call interface. Most applications provide additional layers to encapsulate JDBC calls within higher-level classes and interfaces. Using the Oracle scott schema as an example, it might be useful for an application to define an Employee class. This class can have fields that correspond to the columns of the emp table and methods to perform operation on a single employee, such as fetch(), insert(), update(), and delete(). The JDBC calls to perform the actual database operations can be encapsulated within these methods . Regardless of the type of JDBC driver used, you can develop a pure Java client by moving the classes that interface with JDBC to the server. This can be accomplished using RMI, JavaIDL, or a protocol and server of your own design.

Page 1204

Using RMI

RMI is a Java-centric distributed computing tool that ships with the JDK. Developing RMI objects is a straightforward process. A full discussion of RMI is beyond the scope of this chapter, but in the context of JDBC, you can use it to isolate JDBC calls to server components . Using the Employee class as an example, I can describe the steps in RMI-enabling the existing class as follows :

1. Split the class into two: one class (EmpClient, for example) to hold the data and another (EmpControl) to implement the methods on the server.
2. Define a remote interface. This interface (EmpInterface, for example) defines the methods to be implemented by EmpControl and must extend the java.rmi.Remote interface. The interface must be public, and each method must declare java.rmi.RemoteException in its throws clause.
3. Develop the EmpControl RMI component. This class will implement EmpInterface and must extend java.rmi.server.UnicastRemoteObject. You must define a public constructor to throw RemoteException and contain a call to super() to construct the UnicastRemoteObject.
4. Compile the EmpControl class.
5. Generate the RMI skeleton and stub. Use the rmic compiler to generate EmpControl_Stub.class and EmpControl_Skel.class.
6. Implement EmpClient; this class will hold the data and ( optionally ) the remote object reference and wrappers for the remote methods.

There are at least two basic approaches to designing the client and server components. One method is to store the remote object reference within the client component and wrap the remote invocations. EmpClient then obtains a reference to EmpInterface in its constructor and stores it as an instance variable. The fetch(), insert(), update(), and delete() methods of EmpClient are then implemented to wrap the remote invocations of these methods on EmpControl.

Alternatively, EmpClient can hold the data only, and an instance is passed to the insert() or update() methods of EmpControl. Objects passed as arguments to remote methods must implement the java.io.Serializable interface, so in this case, it must be implemented by EmpClient. Consult the JDK documentation for additional information on Serializable.

The server application must also register a SecurityManager and bind RMI objects with the name service. The RMI name service, rmiregistry.exe, must be running before you start the server. Using the RMI security manager provided with the JDK, you can bind an instance of EmpControl as illustrated by the following code segment:

 // within a server application System.setSecurityManager(new RMISecurityManager()); try { EmpControl ecserver = new EmpControl();     Naming.rebind("rmi://hostname:port/EmpControl", ecserver); 

Page 1205

 // create and bind other objects with the name server } catch (Exception e) {     // do something with the exception } 

The rebind() method accepts a standard URL with RMI as the protocol and a reference to the object to be bound. A client application can then obtain a reference to the remote object via EmpInterface as follows:

 EmpInterface remoteEmpControl = (EmpInterface)Naming.lookup     ("rmi://hostname:port/EmpControl"); 

Note that the lookup() method of the name service (accessed via the Naming class) returns a reference to a Remote interface, so the return must be explicitly cast to EmpInterface.

You can develop larger distributed applications by creating a class that provides information on the locations of all other objects. An instance of this class can be bound with the name service on a well-known address and port, serving as a request broker for other objects.

In this simple example, RMI was used to remove all JDBC calls from the client application. This results in a pure Java client and allows n- tier deployment of JDBC applications, regardless of the JDBC driver used. Any binary libraries required by the driver need to be compatible only with the server platform, regardless of the client platforms running the application. This approach can simplify application maintenance and enhance portability because the client has no knowledge of the database. As a result, the driver, transport, or even the database accessed can be changed only through modifications to the server implementations . As long as the interface is consistent, these modifications are completely transparent to the client application.

Using JavaIDL

JavaIDL provides similar opportunities for developing distributed JDBC applications. Although it is in pre-release 1.1 form as of this writing, its future looks promising . Although RMI is a completely Java-centric implementation, JavaIDL is based on the CORBA (Common Object Request Broker Architecture) standard, which is language-neutral by design. This allows Java-based CORBA clients to communicate with other CORBA-compliant ORBs, which can be written in C++ or some other language.

JavaIDL has the additional advantage of IIOP (Internet Inter-ORB Protocol) communication, which is rapidly gaining acceptance as the Internet protocol of choice for distributed object systems.

CORBA implementations are based on IDL (interface definition language). The interface definition constitutes a "contract" between the client and server. The underlying implementation of the interface is transparent to the client. The first step in creating a distributed object with JavaIDL is to define the interface in an IDL file. (See Chapter 54, "Putting an Application on the Web," for additional details on IDL and its mapping to Java.)

Previous Table of Contents Next