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.

207