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


AddThis Social Bookmark Button

Top Ten Jini Tips

by Scott Oaks, Henry Wong

With all the features of Jini, many programmers may have come to the conclusion that using it is difficult. In reality, the difficulty stems from trying to use all the features at once--instead of using them as necessary. For the new Jini programmer, the key is to use Jini's many features incrementally. Use them as necessary and in a fashion that does not hinder the addition of the other features. Here is our take on how to get started.

  1. Start now. Many developers believe Jini is about device connectivity and are waiting for those Jini-enabled devices. In fact, Jini is about distributed services. The Jini infrastructure provides features of robustness that are just as important to software services as they are to devices. If you are interested in using a service infrastructure that enables automatic discovery of services, that eases the deployment of redundant services, that is robust in the face of network and other failures, and that provides the support services expected of modern application frameworks, then Jini is for you.

  2. Develop on two machines. The steepest part of Jini's learning curve is understanding what client code is, what server code is, and what code is transported between client and server. This may confuse even experienced developers. You will find it much easier in the long run if you take the time in the beginning to set up a distributed environment and actually use that environment in your day-to-day activities. Even if you have only one machine at your disposal, take the time necessary to set up separate directories for client and server, and to run the necessary tools (e.g., an HTTP server, either Jini's or your own) to distribute the code dynamically.

  3. Isolate all interfaces. While RMI may be used in many Jini applications, you should not assume that it is the only object transport. You should write your interfaces to be transport-neutral. While it may take an extra Java class to isolate the RMI stub, it is worth it to provide the flexibility of changing the object transport without affecting existing clients (especially since the extra class will be shipped to the client transparently and automatically).

  4. Implement leasing on your server. The most important feature in Jini's robustness is its ability to clean up after failures. With leasing, you can quickly detect the failure of a client (or a service) and take appropriate action. These actions can include deleting state objects, closing database connections, and otherwise cleaning up all client-related state. The action of maintaining the lease is bidirectional. This means that the client quickly detects the failure of the service when it is not able to renew its lease. The client can then find replacement services automatically, without any impact on the user.

    In a sense, this is one of the keys to Jini's promise. One of Jini's most important features is that it is self-healing: The lookup service detects when other services have left the Jini community and adapts itself. That's an important acknowledgement: that in a distributed computing system, components fail. Jini's leasing infrastructure allows you to bring this self-healing nature to your own services and clients easily. It's well worth taking advantage of.

  5. Implement the Join administration interface. While this interface may not be important to the developer, don't dismiss it: It is invaluable to administrators. When it is time to deploy your Jini services, the Join administration interface can be used to quickly configure how the service is deployed: what groups it belongs to, what attributes it supports, and so on. The ability to change these features while the service is running is very important to a robust Jini community.

  6. Develop smart client-side objects using remote events. In Jini, objects pass freely between clients and services. If those objects contain changeable data, it's important to keep them in sync, no matter who has a copy of them. Use Jini's remote event framework to make this happen. An object representing a printer service may end up being copied to several clients. When the printer is out of paper, each of them must be notified so that the state of their cached object is updated correctly.

  7. Scale and load balance service throughput with JavaSpaces. Clients can ask services directly to perform operations. Alternatively, they can place requests in a JavaSpaces service, and services can process those requests at will. This decoupling has a number of advantages. One key advantage is that to increase service throughput, you simply start more service instances; they will provide quick load balancing, since they'll only request work when they are not busy. The ability to add more services easily to perform more work independently of the clients involved makes the JavaSpaces service a very powerful service within the Jini framework.

  8. Plan for failure. Networks fail. Machines fail. Applications fail. A good Jini service can recover from all of these failures. All state held by the Jini service should be checkpointed to a recoverable location: a database, a Jini-reliable log, or some other persistent store. Jini services should know how to recover that data when they are restarted.

  9. Plan for the future. Jini version 1.1 provides many useful services that enable clients and services to disconnect from the network yet still participate in the Jini community. Automatic lease renewal, lookup service discovery, and event queueing all mean that a service or a client can temporarily go offline while still keeping track of the state of the Jini environment.

  10. Keep it Simple. Jini is designed to be a simple infrastructure, and therein lies its power. Its simplicity makes it easier to recover from network failures, from disconnected clients, and from the introduction of new services. Keep this philosophy in mind when you develop your own Jini programs. Learn each feature incrementally, use them wisely and only when necessary, and you'll develop successful distributed applications.

Read Two Sun insiders talk about Jini to find out what Scott Oaks and Henry Wong say about why Jini demands a whole new approach from developers.

Scott Oaks is a Java technologist at Sun Microsystems, where he has worked since 1987. While at Sun, he has specialized in many disparate technologies, from the SunOS kernel to network programming and RPCs to the X Window System to threading. Since early 1995, he has been primarily focused on Java and bringing Java technology to end users. He is the author of Java Security and coauthor of Java Threads, both from O'Reilly. In his other life, Scott enjoys music, cooking, theatre, and traveling with his husband, James.

Henry Wong is the Chief Architect for SunConnect at Sun Microsystems, where he has worked since 1989. Originally hired as a consultant to help customers with special device drivers, kernel modifications, and DOS interoperability products, Henry has also worked on Solaris ports, performance tuning projects, and multithreaded design and implementations for benchmarks and demos. Since early 1995, Henry has been involved in developing Java prototypes and supporting customers who are using Java. He is a coauthor of Java Threads from O'Reilly. Henry is also an instrument-rated private pilot, who also likes to dabble in archery, cooking, and traveling with his wife, Nini.

O'Reilly & Associates released (March 2000) Jini in a Nutshell.