In principle, Jini provides a protocol for things -- computers, printers, toasters, cash registers, whatever -- to build peer-to-peer networks automatically. It is also meant to make remote access to information very convenient.

Jini is a technology built on top of Java and RMI to ease development of software component collectives. It was designed to be a self-organizing, resilient, zero-administration community of distributed Java objects.

The key concept of a Jini network is the federation.
The Jini protocol allows clients to advertise their services ("Hi! I'm a printer"), and more importantly, to locate each other without the need of a central server/ single point of failure (a la Napster, for example).
Sun seem to be aiming this at embedded devices , mobile phones in particular.

A lot of earlier Java innovations ( mobile code objects a.k.a. applets, RMI) seem to have been designed with this in mind.
Bill Joy in particular sees the Jini federation as a 'network BIOS' for devices to find each other, and James Gosling has confessed to have had Jini in mind back in 1995 when the Java language was created.

Either Sun are very lucky, or they are a lot more cunning than people give them credit for.

In its core Jini is a communication middleware for distributed systems. For this it facilitates the following services

Service Discovery and Registration:
A new client in the network tries to discover one or several Lookup Services and registers its services there. For this the client broadcasts to a known port in the network to which all Lookup Services listen. The Lookup Services will each send a Service Proxy of itself to the client. Using this proxy of the Lookup Service, the client can register its own services by sending its own Service Proxy and a description of itself.
Service Lookup:
A client wanting to use a service uses the Lookup Service to search for an appropriate service (query language: key-value pairs). It will receive a Service Proxy for that service from the Lookup Service which it then uses to access the intended service.
Event Handling:
Client can subscribe to events sent by other clients. They can also add objects to hooks in the event pipeline which can manipulate passing events (e.g. filter or queue them).
Error Handling:
Jini has unified the handling of all kinds of network and service errors with the concept of a lease. Each time a client requests (exclusive) access to a service it is only granted a lease, which must be renewed periodically . If it fails to do so or if the renewal is not granted (decision of the service), the client looses access. This scheme is also used to remove Lookup Service entries of services which are no longer reachable, so a client will always get a halfway up-to-date picture of the available services.
In principle Jini has something called transactions, but, uh, the only thing you get there are some interfaces and some warm words.

Jini is heavily based on the concept of the already mentioned Service Proxies, which are Java objects send to a client to act as a stub which communicates with the real service (the specification suggest a RMI stub, but a stub can use any communication method it wants). This results in a nice, unified programming paradigm (get the proxy of the service, than call the methods) where each service brings its own 'drivers' (namely the Service Proxies). On the downside it also results in the need to run Java anywhere, since each service has to become active to be entered into a registry. Due to this the usage of Jini in the home networking area is somewhat hampered, since you either need a JVM in each device you want to control (including the light bulb ;-) . Alternatively one has to add adapters to the devices, run a JVM on the adapters and let the devices be controlled by the adapters by other means (e.g. switching off power).

Jini has a second problem since it is still in the phase of defining standardized services (e.g. for printing or controlling the VCR) while other approaches (e.g. HAVi) already have that standards. But Jini can not only used for home networking/embedded devices but also just for plain communication within distributed software systems, where none of the two mentioned problems holds.

Other approaches to similar problems are: CORBA, UpnP, HAVi

Log in or registerto write something here or to contact authors.