SERVER
corba | rmi | databases | sample | tools
Last updated: April 1998
This section examines technologies useful in situations where a Java client program
(either an applet or application) is communicating with a server application. Java
is an object-oriented language, so rather than using RPCs (remote procedure calls)
it is generally advisable to employ a network architecture which allows objects to
communicate by calling each other's methods. A pure java solution is to take advantage
of the RMI classes which allow objects of any class to be passed around a network.
CORBA is an older architecture for interfacing between objects from any language.
In a three-tier system, the application server gives the client information from a
source which is maintained independently such as a
database. Java servlets are often useful because
they can access both server information and databases, and they can serve web
pages.
corba
CORBA (Common Object Request Broker Architecture) is a standard for allowing
objects created in different languages to communicate, especially on a network.
It is the primary middleware standard outside of Microsoft's propriety
DCOM (Distributed Component Object Model). CORBA is a favorite choice as a
distributed object infrastructure for allowing Java applications to communicate
both with themselves and with legacy applications written in other languages
such as C++. Briefly: where Java is an OS-independent language, CORBA is
a language-independent middleware standard. They are complementary.
CORBA goes beyond the simple client-server model of the eighties,
which was typically 2-tier, limited in operation to a LAN, with no
server-to-server interactions and little support for multimedia objects.
Created and controlled by the OMG (Object Management Group) CORBA allows objects
of any type anywhere to communicate. To achieve this objects bind to one or more ORBs
(Object Request Brokers) which supervise the interaction of the objects. Once an
object is on an ORB it can then call methods in
other objects (a bit like RPC which however just uses function calls). The
methods available to it are defined in a "language-independent language"
called IDL (Interface Definition Language). Here is an example of an
IDL file which defines the relations between a client and a server:
IDL is quite a simple specification language with primitive data types (like string
above) and a basic object-oriented syntax intended to be capable of representing
objects written in any other language. To complement the specification it is necessary to
write Java classes including implementations of the methods defined above.
Here is the code for
the server and here is the code for the client
(OrChatApp includes both the OrChatClient class and some GUI code
generated by the IDE SuperCede).
(Some ideas for the networking code were borrowed from Luke Cassady-Dorion's article in JavaPro
3/98 and Orfali/Harkey's book Client/Server Programming with Java and CORBA).
Essentially each client is registered by the server in a hashtable and whenever
a client sends a message to the server it is broadcasted along with the client's
username to all clients registered with the server.
There are two things to notice about this code:
The extra Java classes used need to be created by an IDL-to-Java converter
such as idltojava from JavaSoft or idl2java from Visigenic. At least four extra
classes are generated for each interface defined in the IDL file. I used Visigenic's
idl2java converter, and what follows is an account of my experiences with Visigenic's
downloadable runtime CORBA environment, VisiBroker (formerly Black Widow).
This system does not seem to provide the org.omg.CORBA classes in a form that can
be imported by a Java file and then compiled ordinarily; instead it is necessary
to use VisiBroker's own compiler vbjc and then VisiBroker's own interpreter
vbj
(though these executables seem to call javac and java internally).
Before running the server and the client it is necessary to set up some environment
variables (on Windows the VisiBroker setup program is a help) and start up the VisiBroker
SmartAgent, an object location service. Some extra tools are provided though these are
not strictly necessary:
After writing and compiling the code, running idl2java, and starting osagent, I then
called vbj OrChatServer from one DOS window and started client sessions in other
windows (vbj OrChatApp columbus and vbj OrChatApp magellan) getting the results shown
in the screenshot below.
module OrChat {
interface OrChatClientI {
void receiveMessage(in string message);
};
interface OrChatServerI {
void addClient(in OrChatClientI client,
in string username);
void sendMessage(in string message);
};
};
OrChatServerIImplBase is the superclass for
OrChatServer.
OrChatClientIImplBase is the superclass for OrChatClient.
OrChatServerIHelper is used in the client to get the server object.
RESOURCES
The Object Management Group (responsible
for the CORBA standard)
CORBA Resources and introductory texts
Visigenic - VisiBroker is downloadable
rmi
RMI (Remote Method Invocation) is a distributed object model specific to Java which allows objects to call methods in other objects across networks without regard for the underlying protocol. In effect you can use remote objects as if they were local. As of JDK 1.1 RMI is a core package of the Java language.
In deciding upon a network architecture for a particular project the developer must choose between CORBA, RMI, or some special commercial framework. RMI is a simpler, more lightweight solution than CORBA, but it is proprietary and limited to Java, so it is not a good choice if the project involves connecting to legacy applications or simply working with objects created in different languages in general. However, to some extent JNI (Java Native Interface) can be used in combination with RMI to utilize the performance advantages of specialized C++ engines. Also, under pressure from other companies, Sun has made it possible for RMI to use CORBA's IIOP (the Internet Inter-Orb Protocol) as its transport layer.
A basic RMI application involves a client and a server. The server code must include an interface (in ordinary Java code) to the class it is making available over the network. The implementation of that interface (typically the class's name ends in "Impl") needs to import the java.rmi.* classes and it will also need the java.rmi.server.UnicastRemoteObject as a superclass. In the main body of the implementation class the security manager is set to the RMI security manager to enable the default Java security restrictions to be relaxed. Furthermore the object must be named in the registry using Naming.rebind. (RMI's registry services are inferior to those of CORBA.) Also a constructor which calls its superclass constructor (UnicastRemoteObject) must be defined, and, of course, the methods of the interface must be implemented.
The client for its part has little to do - if it uses Naming.lookup to get the object registered in the server, it can call any method on that object that has been defined in the interface.
RESOURCES
databases
The JDBC classes are supplied with the JDK 1.1 for interfacing with a database. The JDBC is a flexible abstraction which allows Java code to remain mostly independent of the particular database used and the JDBC driver for it. The JDBC is implemented in two layers: an application-to-JDBC Manager layer, and a Manager-to-Driver layer. Clients can connect to URLs with the jdbc protocol prefix and download the appropriate driver depending on the subprotocol (which might be, for instance, odbc or msql).
There are four types of drivers, of which Type 3 is most commonly used because it is scalable and requires no client-side configuration. Type 4 can also be used for Intranets.
- Type 1 The JDBC-ODBC bridge - requires installed ODBC driver on the client.
- Type 2 Native-API driver - binary code specific to a particular DBMS must be installed on the client
- Type 3 JDBC-Net driver - the driver communicates with a middleware server using networking protocols. The middleware server then communicates with a database. Examples: Visigenic's VisiChannel, Symantec's dbANYWHERE.
- Type 4 Native protocol - DBMS-specific driver which can be downloaded by the client on demand.
RESOURCES
JavaSoft's JDBC page including a link to a list of drivers
WebLogic, creator of Java database middleware products including Tengah and the jdbcKona drivers
sample
A good option for prototyping JDBC code is to use the simple mSQL database and the Type 4 driver provided for it. Here is an example of applet code which can connect to an mSQL database called Glossary and use it to retrieve a list of Terms (keys in a table) and associated definitions on demand. Below is a screenshot of the applet and is the actual applet in action. You will need a strong VM such as Activator for this to work correctly. Note that at the moment an mSQL server is not running on this machine, so the applet simply demonstrates the process using additional code which works with a Java vector of rows.
tools
Visual Café for Java Database Development Edition
BulletProof, makers of JDesignerPro for building Intranet applications with databases
JRun, a tool from Live Software for running servlets.