MANIPAL INSTITUTE OF TECHNOLOGY

(A constituent Institute of MANIPAL UNIVERSITY)

MANIPAL - 576 104, KARNATAKA, INDIA

Seminar Report

On

The Jini Architecture

Submitted by:
Mohd. Azeem
Roll no. 106
Section-‘B’
Reg. No. 070905172
 Contents

1. Background 1
2. Introduction 2
3. Concepts 3
 Service
 Lookup
 Discovery
 Join
 Lease
4. Using a Service 9
5. An Example 10
6. The Discovery Protocols 11
7. Some Network Details 13
8. Limitations 14

1. Background
Jini provides facilities for dealing with some of the fallacies of distributed computing, problems
of system evolution, resilience, security and the dynamic assembly of service components. Code
mobility is a core concept of the platform and provides many benefits including non-protocol
dependence.

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 Swahili; this is a loan from an Arabic word for a mythological spirit, which is also the
origin of the English word 'genie'. However many Java technologies begin with a capital J, and
therefore such language comparisons may be better applied to only the last three letters ("ini")
instead of the entire name.

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 Java Remote
Method Invocation but more advanced. Jini allows more advanced searching for services,
through a process of discovery of published services (making Jini akin to the service-oriented
architecture concept).

2. Introduction
Jini™ technology is a technology for building service oriented architectures that define a
programming model which both exploits and extends Java™ technology to enable the
construction of secure, distributed systems consisting of federations of well-behaved network
services and clients. Jini technology can be used to build adaptive network systems that are
scalable, evolvable and flexible as typically required in dynamic computing environments.

There are three main parts to a Jini scenario. These are the client, the server, and the lookup
service.[1]

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.

3. Concepts
The Jini Architecture Specification gives an excellent overview of Jini. Important Concepts that
are related to Jini are :-

 Service
 Lookup
 Discovery
 Join
 Lease

3(a) Service
From the Jini Architecture Specification:

The most important concept within the Jini architecture is that of a service. A service is
an entity that can be used by a person, a program, or another service. A service may be a
computation, storage, a communication channel to another user, a software filter, a
hardware device, or another user. Two examples of services are printing a document and
translating from one word-processor format to some other.
Members of a Jini system federate to share access to services. A Jini system should not
be thought of as sets of clients and servers, users and programs, or even programs and
files. Instead, a Jini system consists of services that can be collected together for the
performance of a particular task. Services may make use of other services, and a client of
one service may itself be a service with clients of its own. The dynamic nature of a Jini
system enables services to be added or withdrawn from a federation at any time
according to demand, need, or the changing requirements of the workgroup using the
system.
Jini systems provide mechanisms for service construction, lookup, communication, and
use in a distributed system. Examples of services include: devices such as printers,
displays, or disks; software such as applications or utilities; information such as databases
and files; and users of the system.
Services in a Jini system communicate with each other by using a service protocol, which
is a set of interfaces written in the Java programming language. The set of such protocols
is open ended. The base Jini system defines a small number of such protocols that define
critical service interactions.

In more pedestrian terms, a Jini service is usually code running under some JVM that is capable
of being called remotely, by Jini clients or even by other services. Services that form a
community and are capable of calling each other are said to form a djinn.

A service makes itself available to a djinn through two steps:

 1. Exporting itself. This process creates a proxy object for the service which can be handed
out to remote clients. The proxy encapsulates remote communication with the service,
usually over some port, as well as the specific protocol used, such as RMI or JERI.
2. Joining a djinn by registering its proxy with lookup services such as Reggie. The service
locates lookup services via unicast discovery or multicast discovery and supplies each
one with its proxy. The lookup services are responsible for handing the proxy over to
interested clients so that the service can be found and called.

Services can run under activation using an activation daemon such as Phoenix. Otherwise, they
tend to each run in their own JVM.

3(b) Lookup
Jini services locate each other through specific lookup mechanisms. Lookup centers around
lookup services such as Reggie, which keep track of the services available in a djinn.

Clients discover lookup services through one of two mechanisms:

 Unicast discovery - if the host and port of a lookup service is known, it is called directly
 Multicast discovery - a UDP broadcast is used to find available lookup services on the
network

Once a lookup service is discovered, a client retrieves a proxy from it. The client then uses the
proxy to perform lookups for the services it wants to call.

A client performs a lookup mainly by specifying a Java interface that the desired service must
implement. For example, if a client wants a printer service, it may ask the lookup service for
something that implements Printer. The client can also include entries (attributes) that provide
further details about the desired service; for example, perhaps the Printer service needs to be
able to print in color, or double-sided. It is up to each service, when it registers with a lookup
service, to provide values for entries that clients may use. (Proxies that are exported
automatically implement the same interfaces that their corresponding services implement, so
nothing special has to be done for that.)

In response, the lookup service returns one or more proxies for services that match what the
client asked for. At this point, the client has successfully looked up services and can call them
directly.

3(d) Discovery
Service Discovery is the process that Jini clients use to find Jini Services. The Jini platform includes
multiple mechanisms for Service Discovery. The multicast announcement and multicast discovery
mechanisms allow Jini clients and services on relatively close (related to multicast TTL limits on the
network) network segments to find each other without prior knowledge. The unicast service locator
mechanism allows prior knowledge to be used to directly access a Jini lookup service which can be used
to find services of interests.

3(e) Join
The Join Protocol is used to register/unregister a service with a lookup service, or to maintain
those items of its state, such as changing its groups, attributes, etc.

For example, if a service is asked to change the set of attributes with which it registers itself, it
first modifies the set of attributes in its storage, then it performs the requested change at each
lookup service with which it is registered.

The Join Protocol happens after the discovery process, and is accomplished by using the
downloaded proxy of the lookup service.

3(f) Lease
A Lease is a basic mechanism used for fault-tolerant resource control in Jini. The essential idea
behind a lease is fairly simple. When gaining access to a resource, the party asking for access
makes the request for some interval of time. The grantor of the resource will then give access for
some period of time that is no longer than that requested (although it may be shorter); the period
of time that is actually granted is returned to the requestor as part of the lease object. A holder of
a lease can request that a lease be renewed, or cancel the lease at any time. Successfully
renewing a lease extends the time period during which the lease is in effect. Cancelling the lease
drops the lease immediately. If a lease expires, the grantor of the lease can take an action on the
resource that can free that resource, and the holder of the (now expired lease) can know that the
grantor has taken that action. What the actual action taken on lease expiration should be specified
as part of the description of the method called when the lease was originally given.

There are, of course, many details that have been elided in such a general description. Perhaps
the best way to understand such details is to look at a paticular example.

One of the services that uses leasing is the lookup service. When a service registers with a
lookup service, it requests a period of time for that registration. The lookup service will grant a
lease that is the minimum of the requested time and the maximum lease duration that has been
configured for that particular lookup service. It is then up to the service to renew the lease that is
handed back as a result of the registration call. When renewing the lease, the service will again
ask for a renewal of a particular duration, and the renewal will again be the minimum of the
requested time and the maximum lease duration offered by the lookup service. A well-behaved
lookup service will grant any lease renewal request that it receives. If a service wishes to end its
registration with the lookup service, it will cancel the lease, and the lookup service will then drop
the registration of that service.

The reason that the registrations is leased, however, is to deal with cases where the service
becomes unavailable for unplanned reasons. If the service were to crash, or become unavailable
because of network failure, it would not be able to cancel its registration. In such a case, the lease
for the registration will expire. At that point, the lookup service will drop the registration,
reflecting the fact that the service is no longer available. This behavior is specified by the lookup
service, so if the service becomes available after such a lapse, it knows that it needs to re-register
(rather than try to do a lease renewal) to show its availability.

A somewhat different example of leasing is the use of leases in the transaction interfaces for Jini.
All transactions are leased, and those leases can be renewed. If a transaction lease expires,
however, the result is that the transaction aborts. This allows the transaction manager to deal
with crashed participants; it also shows that the action that is to be taken on lease expiration is
dependent on the semantics of the resource that is being leased.

Leases are like keep-alive messages or heartbeats, but differ in that different resources can be
given different lease durations. Thus the length of time that is allowed before failure is
discovered and corrective action is taken can be determined on the basis of a negotiation between
the client of the service and the service itself, rather than being set on a system-wide basis.

4. Using a service
The first step in creating a Jini service is for the service to find the lookup service (LUS) - a
process called discovery. Once the LUS is found, it returns a Service Registrar object to the
service, which is used to register the service in the lookup (the join process). This involves
providing information about the service to be provided, such as the ID of the service, the object
which actually implements it and other attributes of 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 catalog 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.

5. An Example
1. A new printer is set up in the network.
2. The printer sends a “looking for lookup services” message to the local network.

3. Each lookup service on the network responds with a proxy for itself.

4. The printer registers its proxy object and attributes with each lookup service

using the proxy of each lookup service.

5. A man with a digital camera comes into this network, and he wants to print out

a new picture.

6. The camera sends “ looking for lookup services” messages to the local network.

7. Each lookup service in the network responds with a proxy for itself.

8. The camera searches for types of services it needs using the proxies of one or more

lookup services. The lookup service returns one or more matching proxy objects,

and the client distinguish them further by their attributes.

9. The exactly matched proxy is downloaded to the camera. Then the

camera begins to use the proxy to interact with the printer to print the picture.

6. The Discovery Protocols

Three Protocols are used in the discovery phase:
  Multicast Request Protocol

 Unicast discovery protocol

 Multicast Announcement Protocol

The Multicast Request Protocol

 The Multicast Request Protocol is initiated by a discovering entity(a client or a service) to

locate a lookup service.

 It uses 2 connections: one is the multicast UDP to send the “looking for lookup service”
message to the network, the other is a TCP connection to wait for the lookup service to
connect back.

 It uses the TCP connection to download the proxy object of the lookup service.

The Unicast Discovery Protocol

• By multicast, a discovering entity can only find out the lookup services in the local
network.

• What if a user want to access a Jini service in another network? Use the Unicast
Discovery Protocol!

• The client needs to be told about the location of the remote lookup service.

• Then the client directly establishes the TCP connection to the lookup service and
downloads the lookup service’s proxy object.

The Multicast Announcement Protocol

 • The Multicast Announcement Protocol is initiated by the lookup service to announce its
existence.

• It also uses 2 connections: one is the multicast UDP to send the “Here I am” message to
the network, the other is a TCP connection to wait for the discovering entity to establish a
download connection. In fact, this TCP connection is the same connection as used in the
Unicast Discovery Protocol.

• It uses the TCP connection to transfer the proxy object of the lookup service to the
discovering entity.

7. Some Network Details

  Though the Jini specification doesn’t explicitly say that Jini relies on the TCP/IP, but
actually it does.

 The Jini specification says:

if (TCP/IP is based on)

the multicast request uses the multicast IP address 224.0.1.85 and

UDP port number 4160 by default;

the unicast discovery uses the TCP port number 4160 by default;

the multicast announcement uses the multicast IP address 224.0.1.84

by default;

 Note: They are also called well-known multicast IP addresses and port numbers for Jini.

8. Limitations
Jini uses a lookup service to broker communication between the client and service. This appears
to be a centralized model (though the communication between client and service can be seen as
decentralized) that does not scale well to very large systems. However, the lookup service can be
scaled by running multiple instances that listen to the same multicast group.

Because Jini is implemented in Java, many applications require a Java virtual machine to be
present.

References
1. http://www.google.com.eg/url?sa=t&source=web&cd=1&ved=0CBQQFjAA&url=http%3A%2F
%2Fnews.cnet.com%2FSun-releases-Jini-with-open-source-license%2F2100-7344_3-
5902446.html&ei=T90pTKjSJYKWsQaJ3ZzEBA&usg=AFQjCNFvzQ3QdJk3YmwWewrkpiCHBN8oVA
&sig2=1W4s_8AKKckYsEH95Y2pQg

2. River project depot at Apache.org

3. Taylor, Ian J. From P2P to Web Services and Grids - Peers in a Client/Server World. Springer,
2005

4. http://www.jini.org/wiki/Category:Introduction_to_Jini