Jini Connection Technology
Kaushik Lahoti
Jini: A Vision

Areas to focus on
– Simplicity
– Reliability
– Scalability
Areas to focus on ( contd. )

Simplicity


Jini is Java based.
Jini is about how services connect to one
another.
Areas to focus on ( contd.)
– Reliability




Jini is similar to LDAP or name server but not the same.
How is reliability achieved ?
– Serendipitous interactions among services.
– Spontaneous networking with no explicit user
involvement.
Self - Healing
Results:
– Administration free.
– No explicit user involvement.
– No need for driver or software installation to use a
particular service.
Areas to focus on ( contd. )
– Scalability

Jini services form groups or communities.
– How big ?

Scalability issue is addressed through
federation.
– What is federation ?
Ability of Jini communities to be linked together, or
federated, into larger groups.
– The use of federation
When you need to access a service in another
community.
The Five key concepts
Conceptual Simplicity is Jini’s explicit goal.
Jini is based around five key concepts.
–
–
–
–
–
Discovery
Lookup
Leasing
Remote Events
Transaction Management
Discovery
First a Jini aware entity finds one or more Jini
communities. Lookup service keeps track of all the
shared resources of that community. So a Jini-aware
entity should find this lookup service. This process is
called discovery.
It is not necessary to have one-to-one mapping
between lookup service and a community.
Lookup services are started explicitly by the System
administrators.
Types of Discovery protocols



Multicast Request.
Multicast Announcement.
Unicast Discovery.
Representation of Lookup services
jini://hostname:port/data
The End Result:
Object doing discovery is handed out one or more
references to Lookup services for the requested
community.
The End Result ( contd.)
Clients and services use this reference to:
– Advertise their facilities.
– To determine what services are available
Publishing a Service
 Think of Lookup service as maintaining a list

of “Service Items”.
If a service wants to publish itself, it does so
by joining a Lookup services returned from
the discovery.
– For this purpose, register() method of
ServiceRegistrar interface is used.
– Invoke register() method by passing service item
object as an argument.
Downloadable Proxies
The idea of downloaded proxies is the
key idea that gives Jini its ability to use
services and devices without doing any
explicit driver/software installation.
 Service publish the code that can be
used to access them.

Scenarios of how the proxy object
interacts with your service



The downloaded proxy performs the service
completely.
The downloaded object is an RMI stub for talking to
some remote service.
The downloaded object uses a private communication
protocol for talking to the service.
Most commonly used in two cases:
– If there is some legacy software involved.
– If service is provided by some hardware device, eg. printer.
Finding a Service
 After getting a reference to a Lookup service, a

consumer can search all the service items to find the
service of interest.
Ways to find:
– Type of downloaded proxy object contained in a service item.
– Unique id of the service.
– Attributes of the service items.

Lookup() is used to do this.
Once you have specified search parameters and called
lookup(), the value that is returned to you is the proxy object
from the service item.
Leasing
After discovery and Lookup  How to ensure that these communities are
stable, self-healing and resilent in the face of
network failures, software errors and machine
crashes.
 The issue of reliability is important when the
software systems are intended to be long
lived.
 For example …..
Leasing ( contd.)


This violates everything we want from Jini
like:
– It does’nt ensure that the system will selfheal.
– It requires explicit human intervention to
administer the system.
This problem is solved by a technique called
Leasing.
Types of Leasing

Time Based Resource Reservation
– The resource is “loaned” to a consumer for a fixed period of
time rather than granting access for an unlimited amount of
time.

Third Party Leasing
– What is third party leasing ?
– Reasons for having third party leasing.


An application just wants to worry about writing about its services and
forget about all of the leasing APIs, lease renewal, expiration and so
on.
If a service is extremely long-lived and yet rarely active, for example
the service that does monthly backups of disc drives.
Using Leases in Practice



register() method of the ServiceRegistrar
interface takes as an argument a long integer
representing the number of milliseconds for
which a service wants its lease to last.
The Lookup service responds with a result of
type ServiceRegistration, which contains
information about just-registered service.
Lease object represents lease that Lookup
service has granted.
Points to make about Leasing


There is only one round of negotiations.
Leases are always done in terms of time
duration ( i.e. described relative to the
current time rather than some fixed absolute
time.
Remote Events


Jini handles events using asynchronous
notification.
Jini’s event model is similar to Java’s event
model but there are some differences. Why ?
Is the Java event model not good ? The
answer for this is “environments”.
Event Programming Model


Jini APIs and Java APIs for event handling are
quite similar.
But there are differences, which are:
– key interfaces used by objects that wish to receive
remote events, RemoteEventListener is an RMI
remote interface. The method provided is notify().
– Narrowness of Jini event model.
– Important: There is no addRemoteEventListener()
method. That is Jini provides no generic way of
signaling interest in events.
Generic Third-Party Delegates



Why is event model so sleek ?
Jini remote events also use delegation model like Java but Jini
has an ability to create generic third party event listeners that
can respond to any event type.
Using generic third-party events, you can add application
behavior to event pipeline.
Event
Generator
Logging
Delegate
Reliable
Delivery
Delegate
Event
Consumer
Transactions


Jini uses Two phase commit transactions
How the two phase commit work ?
op1
Ready to commit
ready
Transaction
Manager
Ready to commit
ready
Ready to commit
ready
op2
op3
Two Phase Commit ( contd.)
op1
commit
Transaction
Manager
commit
op2
commit
op3
Two-Phase Commit in Jini





Surprising fact is that Jini does’nt really use two-phase commit.
The transaction model takes a very lightweight approach. Jini
say that two-phase commit is simply a protocol ( interface )
Actual particulars of what happens when the protocol is run when the methods are called - is up to the implementation.
All the participants in Jini transaction implement
TransactionParticipant interface.
The mothods provided are:
– prepare()
– commit()
– abort()
– prepareAndCommit()
Two-Phase Commit in Jini ( contd. )



So Jini provides much less restrictive and
potentially much less safe notion about what
a transaction is.
Jini allows objects to participate, rather than
requiring them to.
But in practice, it has an upside.
Discovery In-Depth


Discovery is a process by which Jini
applications find the lookup services that
serve their community.
Categories of Discovery
– Serendipitous
– Hard-Wire
What is UDP Multicast





In UDP multicast, a range of special IP addresses are
used as multicast groups.
Interested parties can effectively join a group by
listening to messages sent to that IP address.
Messages sent to that IP address will be
automatically received by all the parties listening to
it.
Each message sent via multicast has a “scope”
associated with it which is used to limit the distance.
Scoping also allows efficiency in routing ( using TTL
value )
Types of Discovery

Service-Initiated Discovery
– New services who wish to find all the nearby lookup services
uses multicast request protocol.
– This protocol uses IP multicast to find the lookup services.
– Service sends a multicast message to a well-known multicast
address.
– The address is agreed upon ahead of time by all Jini lookup
services.
– Once a lookup service receives multicast discovery request,
it responds by connecting directly to the service by sending
a unicast ( point-to-point ) message.
– This message contains the proxy object that the service uses
to contact lookup service.
Types of Discovery ( contd. )

Lookup service-initiated discovery
– The lookup services periodically announce their presence
using multicast announcement protocol.
– Interested parties listen to a well known multicast address.
– All the lookup services send a multicast message to this
address.
– The message is scoped so that it reaches interested parties
on the local area network.
– After a service receives multicast message, it contacts the
lookup service using a direct unicast connection and then
the lookup service replies with the proxy object
Types of Discovery ( contd. )

“Direct” Discovery
– In this case, each lookup service listens on a
normal, unicast address.
– This protocol is called unicast discovery protocol.
– So in this sense, this is not really a “discovery”
protocol.
– Unicast discovery is based on URL naming
scheme. jini://hostname:port/data
– Port 4160 is the default port for Jini lookup.
Using Discovery in Applications


The discovery API is based on listener
paradigm.
This API model provides common model for
multicast request and announcement but is
different for unicast discovery.
Basic Interface: DiscoveryListener
import java.util.EventListener;
public interface DiscoveryListener extends EventListener
{
public void discovered(DiscoveryEvent ev);
public void discarded(DiscoveryEvent ev);
}

Any object who needs to find any lookup services
must implement this interface.
DiscoveryEvent Class
import java.util.EventObject;
public class DiscoveryEvent extends
EventObject
{
// …. Few methods
public ServiceRegistrar[] getRegistrar();
}


getRegistrars() method returns an array of ServiceRegistrar
instances.
Each of these is a service proxy that is used to talk to a
particular lookup service
Mechanics of how to start the Discovery
public class LookupDiscovery
{
public static final String[] ALL_GROUPS = null;
public static final String[] NO_GROUPS = new String[0];
public
public
public
public
public
public
public
public
public
}
LookupDiscovery(String[] grps) throws IOException;
void addDiscoveryListener(DiscoveryListener l);
void removeDiscoveryListener(DiscoveryListener l);
void discard(ServiceRegistrar reg);
String[] getGroups();
void setGroups(String[] grps) throws IOException;
void addGroups(String[] grps) throws IOException;
void removeGroups(String[] grps);
void terminate();
Security and LookupDiscovery




There should be a way to restrict access to particular
groups.
Jini provides a way using Java 2 security mechanisms
for you to limit what groups a service or application
can join.
When a service or an application tries to create a
LookupDiscovery object, the code checks to see
whether the creator has permission to try to discover
each of the sets of the desired groups.
LookupDiscovery will raise a
java.lang.SecurityException if the proper privileges
are not in place.
Security and LookupDiscovery ( contd. )





By default, applications are allowed to search no groups.
Permission need to be set for even trusted programs.
Create a policy file and pass the file to JVM via the
java.security.policy property.
Jini introduces its own permission class just for granting access
to groups.
This class is: net.jini.discovery.DiscoveryPermission and can be
used in policy file as:
permission net.jini.discovery.DiscoveryPermission “*”;
permission net.jini.discovery.DiscoveryPermission “unsafe”;
permission net.jini.discovery.DiscoveryPermission “”;
Other Internal Discovery Issues

Multicast Discovery protocols require that all the data
fit in packets with the maximum length of 512 bytes.
– Reason behind this:
Multicast is based on UDP which makes no guarantee that the
packets will be received in the order that they are sent or if
they will be received at all.

Security ( Be forewarned )
– There is no authentication performed on either discovery
requests or responses.
– This means that it is impossible to know whether an entity
contacting you is a “legitimate” lookup service or other
service.
Other Internal Discovery Issues ( contd. )

Requirements for running a lookup service
– Must have a network stack to support multicast TCP and
unicast UDP messages.
– No need of JVM here.

Requirements for parties that are searching a lookup
service
– Network stack capable of UDP multicast and TCP unicast
messages.
– Must have JVM.
The End !!