1206-1208

Previous Table of Contents Next

Page 1206

Using the Employee example presented in the RMI discussion, it might seem logical to define the interface as follows :

 module Scott { interface Employee {         attribute long empno;               attribute string ename;               attribute string job;               attribute long mgr;               attribute string hiredate;               attribute double sal;               attribute double comm;               attribute long deptno;              void fetch();         void insert();         void update();         void delete();     }; }; 

You do not need to declare methods to get and set attributes. They are generated automatically by the idltojava tool, which is the next step. You can generate the Java interfaces and classes to support the implementation of this interface with the following command:

 idltojava -fclient -fserver Scott.idl 

This generates source code for the Java interface, stub, implementation base, helper and holder classes in the Scott directory, and package. You should compile these .java files before creating the implementation class. (See Chapter 54 for additional details on code generated by idltojava.)

The implementation class must extend _EmployeeImplBase (generated by idltojava.exe) and implement the _Employee interface, which was generated as

 package Scott; public interface Employee     extends org.omg.CORBA.Object {     int empno() throws org.omg.CORBA.SystemException;     void empno(int arg) throws org.omg.CORBA.SystemException;     String ename() throws org.omg.CORBA.SystemException;     void ename(String arg) throws org.omg.CORBA.SystemException;     String job() throws org.omg.CORBA.SystemException;     void job(String arg) throws org.omg.CORBA.SystemException;     int mgr() throws org.omg.CORBA.SystemException;     void mgr(int arg) throws org.omg.CORBA.SystemException;     String hiredate() throws org.omg.CORBA.SystemException;     void hiredate(String arg) throws org.omg.CORBA.SystemException;     double sal() throws org.omg.CORBA.SystemException;     void sal(double arg) throws org.omg.CORBA.SystemException;     double comm() throws org.omg.CORBA.SystemException;     void comm(double arg) throws org.omg.CORBA.SystemException;     int deptno() throws org.omg.CORBA.SystemException;     void deptno(int arg) throws org.omg.CORBA.SystemException;     void fetch();     void insert();     void update();     void delete(); } 

Page 1207

Note that get and set methods were generated for each attribute and must be implemented. These methods are provided because clients access a reference to the remote object, so they are unable to access fields directly. This can have a significant impact on performance because a method is invoked on the remote object each time a property is accessed. A better approach is to define the interface as

 module Employee {     struct EmpData {         long empno;               string ename;               string job;               long mgr;               string hiredate;               double sal;               double comm;               long deptno;     };     interface EmpControl {              EmpData fetch(in long empno);         void insert(in EmpData theEmp);         void update(in EmpData theEmp);         void delete(in long empno);     }; }; 

Note that an IDL struct is also mapped to a Java class. The difference is that a struct does not define an interface, so properties can be set and retrieved directly, no additional implementations are required, and the resulting EmpData class can be constructed directly by the client.

Like RMI, JavaIDL provides a name service and a means for developing and deploying distributed applications with Java. This example is provided to demonstrate that, in the context of developing JDBC applications, you can also use JavaIDL to isolate JDBC calls to server-based implementations. As a result, you can minimize client platform dependencies, configuration efforts, and maintenance requirements. For more information on Java programming with JavaIDL, consult Chapter 54 and the documentation provided with JavaIDL from JavaSoft.

Applets Versus Java Application and Security Considerations

The preceding sections discussed thin client and fat client designs without regard to the actual implementation of the client software. This information provided a foundation for a discussion of the issues related to deploying fat client and thin client JDBC applets and stand-alone Java applications.

Pure Java thin client configurations can be distributed to more client platforms and are typically easier to distribute, configure, manage, and maintain. The power of Java's "write once, run everywhere" promise can be realized only when client applications have no binary code dependencies external to the Java VM. As the network computer, JavaStation, and other thin client hardware platforms gain market share, only pure Java implementations will thrive.

Page 1208

Perhaps the only potential advantage to fat client configurations is better performance. Native compiled code runs faster than interpreted byte code and under some circumstances, fat client configurations can minimize server round-trips. However, there is little doubt that a client application's reliance on several layers of binary code limits portability and increases the complexity and cost of installing, configuring, and maintaining an application.

Fat client browser-based applets, in particular, can be extremely difficult to deploy. Browser security managers typically prevent untrusted applets from loading binary libraries. Each browser's VM is slightly different, and some combinations of partly Java drivers and browsers require additional components , such as a Netscape plug-in. Although the browser-based applet is loaded from the server, consider the amount of software that must be installed and configured on the client workstation to support the partly Java JDBC driver.

Attempting to use RDBMS-specific network software (such as SQL*Net) over the Internet presents a potential security risk. You might need to encrypt user IDs, passwords, data, and even the SQL statements themselves . If the RDBMS-specific network software does not support encrypted connections, it might not be possible to adequately secure this information. Additional security measures typically add complexity to the configuration of the network software, such as when the database must be accessed through a firewall.

JDBC applets using pure Java drivers are much easier to deploy because all required software can be downloaded at runtime and run under the Java VM. However, there is no guarantee that the driver will provide adequate security measures. Consult the driver documentation to determine the level of encryption, whether secure sockets are supported, and so on. If you develop your own thin client accessing server-based JDBC components, consider encrypting all data and SQL passed between the two. The JDK provides an implementation of public-private key encryption that should be adequate for most purposes.

When distributing JDBC applets, remember that browser-based virtual machines lag behind the latest developments from JavaSoft, which can cause compatibility problems. For example, drivers developed for JDK 1.1.x and JDBC 1.2x might not work under a 1.0.2 VM.

Java applications are installed locally and run under a standalone virtual machine. Standalone Java applications are far more flexible than applets and are generally preferable for intranet development.

Pure Java applications are supported only by a compatible Java runtime environment and any additional application-specific classes. This allows developers to take full advantage of the latest features of AWT, JDBC, and other APIs. The primary disadvantage of deploying standalone Java applications is that all classes must be installed locally, so if the client application is modified, all affected classes must be redistributed. Applets downloaded from the network, on the other hand, can be maintained centrally on the server.

In general, JDBC applets are most suitable for processing simple requests over the Internet, such as online product registration or order status inquiries, whereas it might be necessary to deploy standalone JDBC applications on corporate intranets to meet complex business requirements. In either case, a pure Java client provides the greatest long- term benefits.

Previous Table of Contents Next