ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Learning Command Objects and RMI

by William Grosso, author of Java RMI

This is the first article in a three-article series.

In this article, I introduce the basic ideas behind command objects. In order to do so, I drag in an example application that provides a translation service from a remote server. After introducing this application, I will show how to use command objects to structure the remote method invocations (RMI) made from a client program. As part of this article, I will introduce a fairly general framework for encapsulating remote method calls in command objects.

At the outset, you should know that these articles require a fair amount of RMI knowledge and experience. If you're not familiar with RMI, my book Java RMI is a pretty good place to start.

An Overview of the Example Application

This series of articles concerns a fairly advanced idea in distributed programming. In order to do justice to the concepts, we're going to need an example that's somewhat more elaborate than the distributed programming version of "Hello World." However, building a full-scale complex application with transactional logic and a persistent storage mechanism is also inappropriate. For these reasons, this series of articles focuses on a simple translation service.

A translator is an RMI server that implements the following interface:

import java.rmi.*;

public interface Translator extends Remote, Constants {
  public boolean canTranslate(Language sourceLanguage, Language targetLanguage)
    throws RemoteException;
  public Word translate(Word wordToTranslate, Language targetLanguage)
    throws RemoteException, CouldNotTranslateException;

Related Reading

Java RMIJava RMI
By William Grosso
Table of Contents
Sample Chapter
Full Description

That is, a translator has to implement two methods. The first method describes the capabilities of a particular translator and allows a client program to figure out whether it is an appropriate translator for a particular request (or series of requests). The second method actually performs the translation.

Note that this relies on two serializable classes, Word and Language, and a set of global parameters defined in the Constants interface. Language is simply a class that defines a type-safe enumeration of the languages currently supported -- the idea is that we have a predefined list of languages, instead of relying on strings or integer constants. Instances of Word are data structures that hold both a string (the word to be translated) and a language (after all, the string "chat" means very different things depending on whether it is the text of a word in French or the text of a word in English).

You can look at the source code for both Language and Word by downloading the source code for this series.

Download all of the example files discussed in this article.

Comment on this articleWhat's your experience with command objects? If you're learning, send William your questions and feedback.
Post your comments

Caution! This series of articles is about using command objects to simplify the client side of RMI-based applications. In order to write it, I needed to provide places to insert command objects. So I wrote (and you can download) the rest of the code, including the client GUI and a very primitive set of servers. The translator application runs and can easily be adapted to other uses. But it's not completely implemented, it's not bulletproof, and it's not intended to form the basis of your enterprise-grade-serves-ten-thousand-users client-server application.

Pages: 1, 2, 3, 4

Next Pagearrow