The Jini team at Sun Microsystems has always stated that Jini is not an acronym. Some have joked that it meant Jini Is Not Initials, but it's always been just Jini. The word "Jini" means "the devil" in Kiswahili; this is a loan from an Arabic word for a mythological spirit, which is also the origin of the English word 'genie'.
One of the goals of Jini is to shift the emphasis of computing away from the traditional disk-drive oriented approach, to a more network oriented approach. Thus resources can be used across a network as if they were available locally. Jini is based on Java, and is similar to RMI but more advanced. Jini allows more advanced searching for services, through a process of discovery of published services (making Jini more similar to the SOA concept).
There are three main parts to a Jini scenario. These are the client, the server, and the lookup service.
The service is the resource which is to be made available in the distributed environment. This can include physical devices (such as printers or disk drives) and software services (for example a database query or message service). The client is the entity which uses the service.
When a client wishes to make use of a service, it too uses discovery to find the LUS - either by unicast interaction, when it knows the actual location of the LUS, or by dynamic multicast discovery. After contacting the LUS, the client is returned a Service Registrar object, which it uses to look up a particular service. It does this by consulting the lookup catalogue on the LUS and searching based on the type, name or description of a service. The LUS will return a Java proxy, specifying how to connect directly to the service. This is one of the ways in which Jini is more powerful than RMI, which requires the service to know the location of the remote service in advance.
Using the Proxy, the client may connect directly to the service implementation (without further interaction with the LUS), and use it as if it were a local service. However, there are some differences to the event model, in that the order of events occurring across a network cannot be guaranteed.
Services in Jini will not necessarily be permanently available, which leads to the concept of leasing. When a service registers with a LUS, a lease is granted, with a certain duration. This can be manually decided, or set to a default (such as 'forever'). Leases will need to be periodically renewed, to check a service is still 'alive', which means if a service fails or becomes unreachable, it can be timed out.
Jini uses serialization to send Java objects across the network. This means an entire Java object can be saved and sent, and used remotely as if it were local, as opposed to creating a specific format for sending data in each new implementation.
Jini services can be grouped together, to allow a client to search for specific groups. A group of services in Jini is called a federation.