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. 106Section-‘B’

Reg. No. 070905172

Contents

1. Background 12. Introduction 2 3. Concepts 3

Service Lookup Discovery Join Lease

4. Using a Service 95. An Example 106. The Discovery Protocols 117. Some Network Details 138. 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 Example1. 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