Java Reference
In-Depth Information
Chapter 8. Jini and J2EE Architectures
Jini
Packages
Core packages:
net.jini.core.discovery, net.jini.core.entry, net.jini.core.event,
net.jini.core.lease, net.jini.core.lookup, net.jini.core.transaction,
net.jini.core.transaction.server
Utilities and helper packages:
net.jini.admin, net.jini.discovery, net.jini.entry, net.jini.event,
net.jini.lease, net.jini.lookup, net.jini.lookup.entry, net.jini.space, com.sun.jini.admin,
com.sun.jini.discovery, com.sun.jini.fiddler, com.sun.jini.lease, com.sun.jini.lease.landlord,
com.sun.jini.lookup, com.sun.jini.lookup.entry, com.sun.jini.mahout,
com.sun.jini.mahout.binder, com.sun.jini.mercury, com.sun.jini.norm, com.sun.jini.outrigger,
com.sun.jini.reggie, com.sun.jini.start
(And you thought the Swing list was long.)
Use:
Jini 1.0
Description
Although many applications claim to use a service-based architecture, Jini truly promotes a service-based
architecture. This is done by creating clear and simple interfaces.
The main assumption in Jini is that the network is an entity to be aware of, and that is unreliable. How often have
you tried to download a file and it failed, or connect to some server and the server was not available. Not to
mention the incredible speed that all users get on the Internet. The network is not just a line in your UML diagram;
it is a very real part of your system. A disconnection can occur (user trips over a wire), the bandwidth can be very
slim, and a multitude of errors can occur on any type of network. The same unreliability holds true for every
network.
Jini forces you to at least acknowledge that the network exists and things might go wrong. And that forced acknowledgement provides
you with the opportunity to handle the errors, before the application blows up in your face or the user's.
The Jini architecture was designed with the following goals:
Enable network plug-and-work
Erase software/hardware distinction
Enable spontaneous networking
Promote service-based architecture
Promote simplicity
Lookup Service
If you want others to use your service in a service-based architecture, you provide them with your interface as
they know how to use your service. Because of this, interfaces are essential to Jini services. Service users are
unaware of the particular implementing class, so they want to be able to search for any implementing class for a
specified interface. This is somewhat similar to RMI.
RMI uses a naming service to bind a name to a particular object. However, using a name is very limiting. If you
don't know the exact name, you're stuck. It makes much more sense to be able to look up something the same
way as in the yellow pages section of the phone book; by capability. And in Java, capability is specified in an
interface. For this purpose, looking up services by interface, Jini introduced
lookup services.
The lookup service
interface is defined in
net.jini.lookup.ServiceRegistrar
.
This
ServiceRegistrar
is the repository for Jini services. Services register themselves with the
serviceRegistrar
and service consumers (users of the service) look up services in it. It supports the lookup
services based on a template
(net.jini.core.lookup.ServiceTemplate)
to retrieve any arbitrary service that
fulfills the template or a collection of services that comply to the template.
