Object mobility in the Jini environment

Reduce the complexity of installation and configuration of complex Jini applications with mobile code

1 2 3 Page 3
Page 3 of 3
public interface Bank {
  /**
   * Deposit the specified amount of money to the specified account.
   * If the specified account does not exist, throw NoSuchAccountException.
     */
   public void deposit(int amount, BankAccount acct, Transaction txt)
     throws RemoteException, NoSuchAccountException, TransactionException;
   /**
    * Withdraw the specified amount from the specified account. If 
    * the account does not exist, throw NoSuchAccountException. If 
    * the balance on the account is less than the amount to be 
    * withdrawn, throw InsufficientFundsException.
    */
    public void withdraw(int amount, BankAccount acct, Transaction txt)
      throws RemoteException, NoSuchAccountException, 
         InsufficientFundsException, TransactionException;
}

A programmer creating an ATM machine's software, for instance, could use this interface between the machine and the bank's account database. The programming language describes syntax, while the human language specification describes the semantics. (See Object-Oriented Software Construction, Bertrand Meyer and "An interview with James Gosling"). The ATM machine's programmer must be familiar with both to effectively use the service. For instance, she needs to consider how to handle the various exception conditions, know what to do if the customer has more than one account, and so forth.

Therefore, Jini encourages the use of well-known service APIs. The idea is that banks, for instance, could get together and agree on the contract that bank account databases would need to guarantee, essentially defining what it means to be a bank account. The Jini Community Process fosters this type of collaboration (see Jini Community Pattern Language). For example, the major printer manufacturers have worked out a Jini Printing API. Printer vendors can independently implement this API, essentially guaranteeing the API-specified contracts in their products. There are similar efforts under way in the automotive, tourism, and insurance industries. Once a service API is defined, the source code and the documentation is available to any implementer, as well as to clients needing the promised functionality.

The consequence of this approach is that the service interface, in the Bank object example, will be available locally to both the client and the service: it is a contract on which both agree. Therefore, the ATM machine can request lookup services to return objects that implement this interface, and it can be certain that any implementation guarantees the contract specified by the interface.

What the ATM machine's programmer does not have to worry about are three things: first, how the service is implemented (i.e., what actually takes place to deposit and withdraw money from the account); second, how the service proxy communicates with the service implementation, since this is a private matter of the service; and third, how the ATM will obtain code for the parameters and return types when calling methods on the service, such as the BankAccountclass, or the exception classes defined by the service.

In addition to the classfile of the service type, the client also needs to have the jini-core.jar file available locally. Both are necessary to initiate the discovery protocol. (For more on discovery, see the Jini Platform Specification, Section DJ2).

What if the client does not know the code for a service API? There is no magic here, and any solution to this problem will likely produce incorrect, and unpredictable, results (see JavaWorld's interview with Jim Waldo). If a human user is looking for a service, and the service provides a serviceUI, then the user could conceivably search a description of the service and obtain a user interface to clarify his choice. For instance, searching for "bank API," a user could be presented with a menu of all available services that have to do with banks or banking. At that point, if the user recognizes a desired service (from a longer description, for instance), he could select and interact with it via its serviceUI. If another piece of software, rather than a person, is looking for a service, you would need much more complex solutions for this type of ad hoc discovery, likely employing some form of heuristics, or other artificial intelligence techniques.

If your service is not implementing a well-known service API, you need one additional step after you register your service and make downloadable code available to clients: you need to publish your interface definition so that client implementers can easily access it. This is another benefit of the Jini Community Website, where anyone can place publicly available code and documentation to define a new service. If the service is of a general nature, you can create a Jini project, which facilitates communication with others using the service.

Summary

Object mobility on the network is the cornerstone of Jini technology, and one of the most powerful ways in which Jini is able to contribute to a more robust, less error-prone computing environment. Jini exploits the JVM's ability to dynamically download and link code from anywhere on the network, and takes advantage of object serialization to transport objects between Java VMs in a distributed Jini federation. To allow both objects and classfiles to independently traverse the network, Jini builds on the codebase annotation technology employed by Java RMI: the codebase URLs for an object's class are annotated to the object's serialized stream. These techniques together allow a client to have only a well-known Java language interface type locally available. The Jini discovery protocols can find lookup services and retrieve any object that guarantees the contract specified by the service interface. Classes required to interact with the service are then dynamically downloaded to the client from the service's codebase URLs.

As for the island of Utopia? Sir Thomas More was imprisoned and executed by Henry VIII in 1532, so he unfortunately won't be able to report on a utopian computing landscape. However, he would certainly see the promise that Jini and mobile code can bring to a more ideal computing world.

Frank Sommersis founder and CEO of AutoSpaces.com, a startup focusing on bringing Jini technology to the automotive software market. He also serves as VP of technology at Nowcom, a Los Angeles-based outsourcing firm. He has been programming in Java since 1995, after attending the first public demonstration of the language on the Sun Microsystems campus in November of that year. His interests include parallel and distributed computing and the discovery and representation of knowledge in databases, as well as the philosophical foundations of computing. When not thinking about computers, he composes and plays piano, studies the symphonies of Gustav Mahler, or explores the writings of Aristotle and Ayn Rand. Frank would like to thank John McClain, member of Sun's Jini development team, for his valuable comments on this article.

Learn more about this topic

1 2 3 Page 3
Page 3 of 3