The Artima Developer Community
Sponsored Link

Object Mobility in the Jini Environment
Simplify the Installation and Configuration of Jini Applications
by Frank Sommers
First Published in JavaWorld, January 2001

<<  Page 8 of 9  >>


The Client's View

You are now ready to take up the client's view. This article's premise is that code mobility reduces installation and configuration of otherwise complex applications in a Jini environment. Jini clients discover services in a Jini federation based on three possible attributes: the service's unique service ID, the service's programming language type, and any attributes the service may register as Entrys in the lookup service (see the Jini Core Platform Specification, Section DJ.2).

The most important of these is the programming language type. Since the client is another Java program (or a non-Java program that knows how to call methods on a Java object), it needs to know something about the contract the service interface specifies between the client and the server. This contract is expressed in terms of both Java code and that code's semantic definition -- neither of these would suffice alone. You might have a Java interface with this definition:

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 BankAccount class, 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.

<<  Page 8 of 9  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use