Jini is a set of specifications that enables services to discover each other on a network and that provides a framework that allows those services to participate in certain types of operations. For an instance, take a Jini-enabled laptop into a Jini-enabled conference room and the laptop automatically be able to find and use the services of the conference room such as the laptop will automatically find the printer inside the room, seamlessly download any drivers required by the printer and will send its output to the printer. But Jini is not about hardware and devices. Jini is all about services.

A Jini-enabled printer provides a print service to the network; that the particular service is provided by a piece of hardware is irrelevant. There may be a software service on the network that also provides the same print service by accepting print requests, rasterizing them and emailing the rasterized images to a distant recipient. There are many services that are only software.

Thus Jini not only allows hardware and applications to interact but also allows this interaction to happen in a dynamic, robust way. Jini software also gives network devices self-configuration and self-management capabilities. It lets devices communicate immediately on a network without human intervention. And Jini has the potential to radically alter our use of computer service networks, since it allows and encourages new types of services and new uses of existing networks. These networks are self-healing in that devices that leave the network for any reason, such as machine crashes or power surges, do not affect the remaining devices' operation. A Jini client that loses contact with a server can recover and continue processing. It is precisely these features that make Jini technology ideal for embedded systems in a dynamic environment. But network plug-and-play capabilities and self-configuration are also attractive for enterprise systems.

Jini developers intended Jini technology as a sophisticated platform on which to develop network-aware applications. Jini technology provides users access to resources located anywhere on the network. Both user and resource locations can change without affecting the application. Users, devices, and resources can join and leave the network without manual reconfiguration. Jini developers used the Internet as a model for developing their product and sought to take advantage of the Internet's advantages in terms of reliability, scalability, maintenance and administration, and security. Jini is freed from having to deal with specific operating system and hardware requirements by Java technology, while Jini itself frees the client and service to interact without having to concern themselves withe the particulars of the network.

Jini is a distributed computing framework. Hence the participants in the Jini network are called clients and servers. A server has an interface, which is the API that it presents to the outside world. This interface is called the service interface or the service. A server is hence an implementation of a service.

Jini software runs on top of Java Virtual machine and will work in any IP-based network of machines with Java VMs. It is based entirely on Java and depends on Java to function. Jini technology presupposes the existence of network connecting devices and Jini-enabled communicate with each other over this network. A Jini network contains communities, or federations, or clients and services. A Jini service joins a federation, to share its service with clients. A Jini client joins a federation to gain access to services. Federations are dynamic constructs, appearing and disappearing based on the demands of Jini devices.

The Jini Lookup service is the heart of a Jini community. The lookup service is similar in principle to the naming service used in other distributed computing paradigms like CORBA's COS Naming Service. It holds the registrations of all other services available in the Jini community. An application that wants to use a Jini service finds the desired service by looking for the service's registration within the lookup service. A Jini service must register itself with the Jini lookup service in order to be used. The Jini lookup service is just another service. The service interface of the lookup service defines all the operations that are possible on the lookup service. It defines the way in which clients in a Jini community locate services. There may be more than one instance of the lookup service running in the community. This is to provide a certain level of redundancy. Jini lookup services are organized into groups. There is a default group called the public group. One can create groups with any name. When he start a lookup service, he can specify which group it should hold registrations for. When he search for lookup services, he can specify which groups he is interested in.

As part of its responsibility, the Jini Lookup Service is always listening for the discovery-request datagram packets. Once it hears one, the discovery process begins. If the Lookup Service supports any one of the groups requested, the requesting service may be permitted to join. The Jini Lookup Service notifies the requesting service, which responds with the new service's programming interface - a serialized Java object, that the Lookup Service stores. Since a service may join or leave the network at any time, the loose term of federation is given to the Lookup Service and its current set of registered services. The newly registered service is granted a lease for its registration for a duration determined by those who initially configure the system. If the lease is not renewed, the Lookup Service will drop the service from the federation.

A client that wants to use a particular service finds the appropriate server by looking in the Jini lookup service. But before that the client has to locate the Jini lookup service. This can be done by a process called discovery. Jini specification for this defines at the network level the protocol by which clients can find the lookup service. There are two ways in which a client can discover the Jini lookup service:

Multicast discovery - the client sends out a multicast request of a specified format. All Jini lookup services that come across the request will respond to it, and the client is said to have discovered the lookup services.

Unicast discovery - In this, the client should attempt to connect to a lookup server having known the existence and location of the lookup server. This is in a sense not discovery. The discovery protocol uses a combination of both unicast and multicast discovery in order to find lookup servers.

Clients will discover all lookup servers that are within the multicast radius of the network. The multicast discovery packet will be broadcast on the local network. Routers that join two networks may or may not route the multicast packet between the two networks depending upon the rules of the router. Many routers will not pass any multicast packets between networks and for these networks, the multicast radius is equal to the local network. Otherwise, the router will forward the multicast packet based on its time to live (TTL) value, which is decremented each time the packet passes through a router. When the TTL value reaches zero, the packet is no longer forwarded onto new networks.

A service is a fundamental concept in Jini Technology and represents an entity that users can access over a network. Services can be a storage device, software component, printer, home stereo, or satellite navigation system. Basically, they are any item that programmers can abstract through software. services advertise their capabilities through a lookup server, which Jini clients use to discover and access services. Jini devices that advertise services can themselves be clients of other Jini devices, and through the dynamic combination of these services, Jini clients can build complete distributed applications. For these reasons, the Lookup service is key to the Jini network. A Jini server specifies attributes, such as accountingSystem or licenseServer, to facilitate identification of particular services available in it.

The first action of a Jini-enabled device after connecting to the network is locating the Lookup service, which resides on a server in a network. It accomplishes this by using the discovery protocol, which is multicast-based. For this, a device first sends a message to every other Jini device on the network that is within a certain number of network hops. When the Lookup server receives this broadcast request, its returns its address to the Jini client, which stores the address as its link to the Lookup server. The client thereafter sends requests to the Lookup server directly to this address. Similarly Jini servers offering services uses the discovery protocol, which is multicast-based, to find a Lookup Service and then uses the join protocol to register and thus become available to client applications. A Jini client asks the Lookup service for a list of Jini servers that match the requested attributes. It is then up to the Jini client to select the specific Jini server from the returned list. Similarly Jini servers offering services uses the discovery protocol, which is multicast-based, to find a Lookup Service and uses the join protocol to register and thus become available to client applications. Services may join multiple lookup servers for increased reliability. Once clients and services are paired up, they no longer need the Lookup Service's assistance and can work together directly. The primary job of a Lookup service is to act as a central market for Jini services scattered around the network, grouping similar ones together and making them accessible to client application programs. The Lookup service maintains the maps between each Jini service and its attributes

A unique feature of Jini technology is its ability to transfer executable code between Jini devices. This capability is similar to Java applets, which execute on Web browsers. With applets, Web servers download an entire applet executable code to the client, which executes the code. In contrast, Jini software sends only the code for the interface that the client uses to communicate with the server; the rest of the program remains in the server and actually executes there. Thus, in a way, Jini server teaches the Jini client how to communicate with it. This strategy mitigates one of the biggest problems with Java applets: their slow speed. The system downloads less because a Jini network usually only transfers the results of whatever code the server executes.

When the Jini client receives the lookup service reply that responds to its request for a service, it initiates a connection with the server. The Jini specification does not stipulate how an application should implement a service. The only requirement is that a Jini service must implement a specific interface, which the server supplies to the client. The client has no prior knowledge of any server and only knows how to communicate with the server through the given interface.

When a client accesses a resource through a service, it leases that service. A lease is a guarantee that the client may access that resource for a specific length of time. The client has the option of renewing the lease before its expiry. If suppose the service does not receive an extension request within the alloted period of time, the resources may be allocated for other clients. This prevents a network or client failure from keeping an indefinite lock on the resource. A nonexclusive lease permits other clients also to access the service at the same time. A lease could be exclusive, allowing only one client to access a resource at any time.

A distributed environment must provide guarantees because of the vagaries of networks and servers. In this environment. Jini provides a transaction API for clients and services to use. Jini infrastructure helps clients and services adapting to a dynamic environment by deleting or creating references to each other automatically. It however does not address the problem of what to do when an error occurs. This is where a transaction comes in. For instance, a simple transaction entails making a debit in the customer's account while making a credit in the seller's account. This transaction fails if the customer's account has insufficient funds. In a distributed environment, such functions can take place often on different servers. Thus transactions ensure consistency across the network. Jini provides an interface to a transaction manager that knows how to keep track of all the operations and how to manage the parties in the transaction. This allows a series of operations to be grouped into a transaction so that the transaction is either committed or aborted. In a Jini transaction, there are three parties:

1. Transaction client - It initiates and terminates the transaction. It does this by obtaining a transaction object, providing that object to a series of method calls that the client wants treated as an atomic unit, and then committing the transaction. Only the client can commit the transaction; the client, as well as any other party in the transaction, can abort the transaction. Jini provides a set of APIs that we will use to be a transaction client.

2. Transaction manager - It oversees the entire transaction. The transaction manager provides the transaction object to the client and keeps track of all participants. When the client commits the transaction, the transaction manager ensures that all participants update their data correctly. The transaction object is leased by the transaction manager. The client must renew the lease on the object. Failure to renew the lease will cause the transaction manger to abort the transaction

3 Transaction participants - The services to which the client provides the transaction object become transaction participants. Transaction participants have strict requirements with respect to how they must manage data within the transaction. While the client initiates the transaction, it is the transaction participants that allow the use of transactions, because the participants specify in their service interface that the client must provide a transaction object.

The Jini transaction system uses a two-phase commit protocol in conjunction with all the participants. Jini allows nestable transactions. A nested transaction or subtransaction is a transaction that has another transaction as its parent.

Writing a service that participates in a transaction is difficult. While the transaction participant interface is straightforward, the guarantees that are mandated by the transaction framework are difficult to satisfy. Fortunately, few services need to support transactions.

JavaSpaces is a Jini service that builds an maintains a database of Java objects. JavaSpaces allows the storage and retrieval of objects via a standard lookup. In this way, JavaSpaces facilitates group communication through Java object sharing. The database search is similar to a file name search. But the file name search is not descriptive enough and hence in JavaSpaces, one can perform a lookup via a name or any set of attributes, which can vary for each object. The JavaSpaces application programming interface contains three operations:

1. write performs the create and update functions

2. read lets programs get a copy of an object and

3. take combines read and delete.

Apart from these, JavaSpaces also supports notify, which lets a program know when an object that matches some criteria has been written into the space. Towards synchronization, JavaSpaces can take an object. Once taken, the object is not available to any other program. To avoid human intervention for releasing a taken object from the clutches of program, which takes the said object and dies, JavaSpaces add a transaction to the take operation. If the transaction is rolled back, that is , does not succeed, the object automatically reappears in the space. But while the transaction is open, the object remains unavailable to the take operation.

The JavaSpaces programming model typically follows the same pattern of other database programming model. Applications or classes use the write operation to place object into the JavaSpace; they also remove objects from the space for processing using the take operation. When processing completes, using a write operation again returns the resulting object to the space.

Two possible uses for JavaSpaces are as a sharable whiteboard or as a compute server. In the case of the sharable whiteboard, applications or classes write sets, which other programs can share, into the space. As a compute server, the space works as a generic server that allows distributed calculations. Conceptually, the JavaSpace is the repository for work. A master process writes objects into the JavaSpace. Slave processes, running on other systems take objects from the JavaSpace. They perform whatever calculation is needed and write the result back to the space. This system lets several machines solve a single problem, which is broken into smaller chunks, in parallel. This technique is inherently self-load balancing.

For say, a CD-ROM drive, registering itself with a Jini network is essentially a three-step process. When plugged into the network, the drive first looks for a Lookup Service by sending a data packet asking to be registered. Once the Lookup Service accepts it, the drive sends a file with the byte code, a client application will need to establish communication with the drive. The file is stored in a table that contains data on all the services the Lookup service can make available on the Jini network.

For this system to work, the marketplace must first be set up by placing a Jini Lookup Service, a simple piece of application software, on one or more hosts in the network. There can be more than one Jini Lookup Service in a system. Services seeking a market for their wares send discovery requests to multicast request servers for Jini Lookup Services. Upon hearing such a request, an interested Jini Lookup Service initiates a private conversation with the service to establish its joining in the market. When the service and the Lookup Service first converse as part of this joining process, the Lookup Service promises the newcomer space in its market. In return, the service gives the Lookup Service basic information with which client applications can establish a connection to it. The information here is a software interface through which a Jini client can interact with a Jini service.

Client applications ask Jini Lookup Services for certain type of services. The client does this by sending a template file - a generic description of the desired service to the Jini Lookup Service. The Jini Lookup Service responds with a list of candidates that match the template from which the client may select a particular service. Thus Jini supplies the infrastructure for marketing a set of services, as well as provides the programming model by which resources may form impromptu groups called Jini federations and provide their services to users and other resources.

When a Jini-capable program that is a client application needs a service such as, say printing, it requests that the Jini Lookup Service send it a list of potential printer services. From the lists provided, the client selects one or more randomly, algorithmically or even manually through a user interface. For the selected service provider, the Lookup Service delivers the corresponding piece of executable Java byte code. While most typically this byte code would simply implement communications between the service and the client program, it could be the actual service itself.

Jini services currently use the same security model as all Java 2 programs. The Java 2 security model operates only when a security manager is installed into an application. By default, applications do not have a security manager. However, in order for RMI clients to be able to download code from RMI servers, a security manager must be installed. Thus all the Jini services have such a security manager. Also all code is given a set of permissions. This set is determined by a combination of the URL from which the code was downloaded and the entities that signed the jar file containing the class. The set of permissions associated with a particular class is loaded from policy file. Jini policy files are available for all its services.

Jini's promise is not limited to the domain of network devices. It can be expanded to scanners, printers, phones, radios etc. Before Jini can become the basis for such mission-critical applications, its ability to scale up to thousands of network devices and maintain high levels of security needs to be tested under stress and refined. Thus Jini portends the movement of computing from general-purpose machines to specialized processors. In this arising paradigm, the network computer binds specialized resources into general-purpose constructs, and desktop computers will merge into the network. Jini's security framework must still evolve before it reaches the point where it can provide this level of safety.

Although Jini has shortcomings, its potential has galvanized industry. The Jini community , with its many members, has become the forum for moving Jini ahead by consensus, and in January 1999. The current Jini specification, version 1.1, was released in October 2000. Because Jini technology represents a fundamental shift in application development, adoption has been pretty slow, but enthusiastic. Development tools for Jini technology are limited in number and capability. Nevertheless, as information spreads about Jini technology, its usage will improve steadily.