Published on
O'Reilly (http://www.oreilly.com/)
http://java.oreilly.com/news/jini_1000.html
See this if you're having trouble printing code examples
Top Ten Jini Tips
by Scott Oaks, Henry Wong
10/02/2000
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.
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Copyright © 2007 O'Reilly Media, Inc.