jini-1.ppt

Nov 6, 2000 CS851 Ubiquitous Computing 1
The Jini Architecture
Speaker: Weisheng Si
Dept. of Computer Science
University of Virginia

Outline
• What is Jini?
• Jini architecture overview
• Service lookup process
• Distributed events
• How is Jini related to the RMI
• Comparison with HAVi
• Comparison with CORBA
• My example

What is Jini?
• Jini is a distributed system architecture
developed by Sun Microsystems, Inc.
• Its main goal is “network plug and play”.
• Jini is not an acronym, it’s coined by one of
its designers--Bill Joy.
• You can think it as standing for “Jini Is Not
Initials”.

Architecture Overview
Jini Services
Remote Method Invocation
TCP/IP
The Jini Architecture
Java Virtual Machine
Data Link Layer

Basic Components of Jini
• Service : entity that can be used by a person, a device,
or another service, for example, printing a document,
displaying videos, etc.
• The lookup service : providing a central registry of
services; and the clients use it to locate a service that he
wants.
• Proxy object and its attributes : the object implements
all the interfaces provided by the remote service; and
attributes are used to distinguish the object from other
objects of the same type.
• Client : entity who requests services.

A simplified example :
A Printer
Proxy Object
Printer Attributes
The Lookup Service
A Camera
The Lookup Service
Proxy Object
Printer Attributes
A Camera
Proxy Object

The more complete scenario
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.

What happens in a Jini environment?
For a service:
Discovery : sends a “looking for lookup services” message to all the local lookup
services and downloads their proxy objects.
Join : uses the downloaded proxy object to register its proxy object and attributes
with each lookup service.
Renew : renews its registration at the lookup services. (talk about later)
For a client:
Discovery : sends a “looking for lookup services” message to all the local lookup
services and downloads their proxy objects. Then it picks
up the service that it wants by using the proxies of the lookup services.
For a lookup service:
Here I am : sends a “Here I am” message periodically to the local network in case
that some services maybe fail to register previously due to the network
failure or some other reasons.

The Service Lookup Process
• Service ID: each service, including the lookup service, has
an ID that is unique in the Jini environment.
• Group : a group can be represented by any arbitrary string.
• A client can use group to identify a set of services that it
wishes to look up.
• The lookup service can use group to filter the lookup
requests.
• A group with an empty string as name means “public
group”, which will actually match all groups.

The Service Lookup Process(cont’d)
• The Discovery Protocols : are used by a client or a
service to find out the lookup services and
download their proxy objects.
• The Leasing Mechanism : a lease is a period of
time during which the service is registered. If the
lease expires and the service doesn’t renew it, the
service will be discarded by the lookup service.
• The Join Protocol : is used by the service to
register itself with a lookup service.

The Discovery Protocols
• Multicast Request Protocol
• Unicast discovery protocol
• Multicast Announcement Protocol
Three Protocols are used in the discovery phase:

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 Discovering Entity The Lookup Service
2. The discovering entity first
sets up a TCP server.
The multicast response service
1. Construct a multicast UDP
socket, listening to the multicast
request.
3. Constructs a multicast UDP
socket, then sends its request
for lookup services to the network.
4. If the DE’s groups match the
groups to which it provides services,
it connects to the DE’s multicast
response server, and passes its proxy
object to the DE.
The multicast response 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.

The Discovering Entity The Lookup Service
1. Establishes TCP unicast
discovery server.
The unicast discovery server
2. Constructs a UDP multicast
socket, periodically sends out
the “Here I am” message.
1.Establishes a set of service IDs
of lookup services from which it
already heard, then constructs
socket waiting for the arriving of
the multicast announcement.
Service IDs
2. For each announcement received,
it determines whether the service ID
is already in the set and whether it is
interested in the groups of the lookup
service.
3. If the service ID isn’t in the set
and it is interested in the groups, it
connects to the unicast server to get
the proxy of the lookup service and
then add the new ID into the set.
The unicast discovery server

• When a service registers with a lookup service, it gets back a lease
on its presence in the lookup service.
• If a service wants to maintain its presence, it must periodically
renew the lease at the lookup service.
• Any network or host failure will force the removal of the
unreachable services, which guarantees that the status of the
network is almost always current.
• It’s a self-healing mechanism. For example, when a network
failure isolates a service from a lookup service, the service will be
evicted from the lookup service because it can’t renew its lease.
And when the network is fixed, the service will receive a “Here I
am” message, and then it can join the lookup service again.
The Leasing Mechanism

The Join Protocol
A service must maintain certain items of its state. These items are
as follows:
1. Its service ID : A new service will not be assigned a service ID until it is
started for the first time. After a service has been assigned a service ID, it
must continue to use it across all lookup services.
2. Set of attributes : used to distinguish the service from other services.
3. Set of groups : the groups that this service wishes to participate.
4. Set of specific lookup services : the lookup services that this service has
registered with. (by remembering their service IDs)

The Join Protocol(cont’d)
3. The Join Protocol happens after the discovery process, and is
accomplished by using the downloaded proxy of the lookup service.
2. 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.
1. 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.

• Though the Jini specification doesn’t explicitly say that Jini
relies on the TCP/IP, but actually it does.
• The Jini specification says:
Some Network Details
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
number for Jini.

• Network delivery is unreliable: messages may be lost. Synchronous methods
requiring a reply may not work here.
• Network delivery has indefinite delay: messages may arrive at different times
to different listeners. So the state of an object as perceived by a listener at any
time may be inconsistent with the state perceived by others.
• A remote listener may have disappeared by the time the event occurs.
Listeners have to be allowed to ``time out'', like services do.
Distributed/Remote Event
Remote Event is different from the local event, in that:
Jini makes no assumptions about guarantees of delivery and
delivery in order. The event generator supplies a sequence
number that could be used to construct state and ordering
information. And the Leasing mechanism of event is also used.

• Unlike the large number of event classes in the AWT and Swing,
Jini typically uses event of only one type, the RemoteEvent and
a small number of its subclasses.
• A RemoteEvent is serializable and can be moved around the
network to its listeners.
• The RemoteEventListener is the receiver of RemoteEvents. A
RemoteEventListener is defined by an interface that contains a
single method, “notify”, which informs interested listeners that
an event has occurred.
Distributed/Remote Event(cont’d)

Registration and notification of Events
Registrant Event
Generator
Remote
Event
Listener
1. Registrant registers the
remote event listener with
the event generator
2. Event generator returns
an event registration for the
remote event listener to the
registrant
4. Event generator fires
a remote event to the
listener to indicate the
kind of event occurred
3. Registrant returns the
event registration to the remote
event listener.

Two examples of using events
• Service starting or closing : A client can
know if a service is available immediately
by registering the corresponding events,
without checking with the lookup services.
• Email notification : Once new emails arrive,
the email service will fire an event to the
email client, such that the email client
needn’t poll the email server.

How is Jini related to the RMI
• RMI stands for Remote Method Invocation,
first introduced in JDK 1.1.
• You can think RMI is the RPC of Java, but
it has many enhanced features.
• The most fundamental enhancement is that
RMI supports the passing of the whole
object over the network, which is employed
by Jini.

RMI Architecture
Client Program Server Program
Stub Skeleton
Java Remote Method Protocol
Transport Layer
Java Remote Method Protocol

Running a typical RMI Application
rmiregistry
Application
Client
Application
Server
Appl_Stub.class
Web
Server
Appl_Stub.class
Naming.
rebind()
Naming.
lookup()

Retrospect to the Jini
A Printer
Proxy Object
Printer Attributes
The Lookup Service
The Lookup Service
Proxy Object
Printer Attributes
A Camera
Proxy Object Any protocol is OK.
1. Proxy must be implemented by
the programmer, while stub is
automatically generated by the RMI
compiler “rmic”.
2. Proxy can communicate with the
service using its own protocol, and
the client doesn’t need to know about
it.
3. Proxy is the key role to achieve the
spontaneous use of the network.

Where is RMI used?
Service
Lookup Service
Registrar
1. The proxy object of the lookup service is called Registrar.
2. After the discovery phase, the Registrar is downloaded to the Service.
3. The service uses the Registrar to register with the lookup service, and the protocol
used is the RMI in Sun’s implementation(Jini1.1 Starter Kit).
4. In Sun’s implementation of Jini, the lookup service is named “Reggie” and it needs
“rmid” and a web server as the support services.
Discovery
Service
Registrar
Lookup Service
Join, using RMI
Service
Registrar
Lookup Service
Proxy of the Service
rmid Web Server
Stub used by Registrar

Comparison with HAVi
1. HAVi is constructed on the IEC
61883.1 function control protocol and
the IEEE 1394 bus standard.
1. Jini relies on TCP/IP as its lower
layer.
HAVi messaging
IEC 61883 FCP
IEEE 1394
Standard
Jini Services
RMI
TCP/IP
The HAVi Architecture The Jini Architecture
JVM
Data Link Layer

Comparison with HAVi(Cont’d)
2. HAVi works under a fully
distributed peer-to-peer fashion. Each
Full AV device possesses all the
software elements such as DCM
manager, registry, and messaging
system. There can be no central
controller.
3. HAVi’s “Discovery” means to
detect that a device is added or
removed from the network.
HAVi’s “Lookup” means to search
each device’s registry to find out the
service it wants, the same meaning as
“discovery” in Jini.
2. A Jini environment must have at
least one lookup service to serve as
the central registry.
3. Jini’s “Discovery” means to
discover the lookup services.

Comparison with HAVi(Cont’d)
4. The IEEE 1394 supports the
dynamic device actions such as hot
plugging and unplugging. When the
1394 bus detects a topology change, it
will transmit a bus indication to all the
devices in the network. Then the
Communication Media Manager of
each device will handle such an
indication.
4. Jini uses the Leasing mechanism as
well as the lookup service to achieve
the dynamic change of the network.

Comparison with CORBA
1. CORBA is language independent. It
uses OMG IDL, and has IDL
compilers for most of the popular
programming languages.
2. The current version of CORBA
doesn’t support object serialization,
but it soon will.
3. CORBA uses the Naming/Directory
service to obtain the reference to the
remote object.
4. It uses unicast for the service
lookup.
1. Jini relies on Java. It uses Java
“interface” to describe the interface to
the remote services.
2. The capability of “moving code” is
one of the most important features of
Jini.
3. Jini uses the lookup services to
obtain the proxy to interact with the
remote service. It searches not only by
the type but also by the attributes.
4. It multicasts its service lookup
request to the local network.

Comparison with CORBA(cont’d)
5. CORBA has no Leasing
mechanism.
6. CORBA focuses on “Object”.
7. CORBA uses the GIOP to define
the format of the messages, and IIOP
to define the exchanging process of
these messages. GIOP adopts the
CDR representation. All these enable
that ORB can be developed
independently by any vendor.
5. Jini uses the Leasing mechanism as
well as the lookup service to achieve the
“network plug and play”.
6. Jini focuses on “Service”. This is
because the designers of Jini believe that
the distributed object transparency is
impossible.
7. Jini employs a variety of protocols:
multicast UDP, RMI over JRMP,etc. And
any other protocol can be used by the
“proxy” and “service” communication.
JRMP is only partially specified, and the
next version RMI, called “RMI-IIOP”,
will use IIOP instead.

Comparison with CORBA(cont’d)
8. In CORBA, a programmer only
need to develop the client and the
server program. The stub and skeleton
are automatically generated by the
IDL compiler. No transmission of stub
is required.
8. In Jini, a programmer needs to
develop the client, the proxy, and the
server. In RMI, the stub is generated
by the RMI compiler using the server
source code and needs to be
transmitted to the client side.

The Smart Olsson Hall
Lookup Service A
Proxy of CS-BW1
Proxy of CS-BW2
Lookup Service B
Proxy of CS-BW1
Proxy of CS-BW2
CS-BW1 CS-BW2
Evans Knight
Lookup Service A
Proxy of CS-BW1
Lookup Service B
Proxy of CS-BW2
Lookup Service A
Proxy of CS-BW1
Proxy of CS-BW2
Lookup Service B
Proxy of CS-BW2
Proxy of CS-BW1
Visitor
Visitor
Proxy of CS-BW1

Thank you!

jini-1.ppt

More Related Content

Similar to jini-1.ppt

More from KalsoomTahir2

Recently uploaded

jini-1.ppt