A Look at Jini
Richard Chapman
Sept. 30, 1999
Jini Motivation
• Why must everyone be a sysadmin?
• Why can’t computers scale like the
phone system: added complexity
without added configuration work?
• Why can’t devices/services enter and
leave the network without explicit
reconfiguration?
Jini Goals
• Very robust software infrastructure
• No configuration/administration
required
• Software must be evolvable
• Devices can form spontaneous
communities
Jini History
• Fulfillment of original Java goals of an
environment for embedded systems
(Oak, 1990)
• The word “Jini” does not stand for
anything
• Went public too soon, NYT reporter
John Markoff broke story in 1998
Jini is intended to be used by:
• Information appliances (thin clients, set
top boxes, PDA’s)
• Desktop machines can benefit from a
reduction in sysadmin duties
• Enterprise systems (servers) also
benefit
Getting Jini
• Source code distributed under Sun
community source license (open source)
• Need Java 2
• Requires web server, RMI activation
daemon, lookup service
• http://www.javasoft.com/products/jini/
Networked vs Distributed
Systems
• Move the data or move the code?
• Conventional wisdom: since code has to
be compiled and installed, move the
data, and call a routine on the remote
machine
• Thus: make the remote function call
look like a local function call as much as
possible (RPC, CORBA, DCOM)
The network cannot be
ignored
• Very high latency (orders of magnitude)
• High variability in latency (has a
component failed or is the link just very
slow?)
• New failure modes that do not exist on
local machine (router down,
nameserver crash, cable came loose)
Handling Partial Failures
• Partial Failures do not exist on local
machines -- you know the state, for
better or worse
• Partial failures arise when some, but not
all hosts, receive a message from a
sender
• May be difficult for sender to detect
which hosts received message
Handling Partial Failures,
Cont’d.
• Even if server can detect which hosts
have not received a message, what
does it do
• Can’t keep trying forever -- you run out
of disk drives storing old messages you
are trying to send
• Don’t want to give up and cut off the
host that failed to get a message
Why CORBA isn’t enough
• Ignores network performance issues
(makes remote call look like local call)
• An add-on to existing languages (not all
machines implement C++ the same
way)
• Example problems: endianness, size of
int, float, char, etc.
Peter Deutch’s Seven Network
Fallacies
• The network is
reliable
• Latency is zero
• Bandwidth is infinite
• The network is
secure
• Topology doesn’t
matter
• There is one
administrator
• Transport cost is
zero
Jini adopts the programming
model of Java
• One lanuage everywhere
• Data in the same format everywhoere
(objects represented by bytecodes)
• Strongly typed interfaces
• Separate interface and implementation
• Plus: a distributed storage model based
on Linda (Gelernter, Yale)
Conventional wisdom is no
longer valid.
• Code can easily move from machine to
machine
• Servers can be dynamically updated
• Systems can evolve by updating
interfaces with new code as needed, no
need for recompilation
Strong typing is important
• In Java, an RMI defines the interface,
while in CORBA, an IDL description is a
wrapper around the interface
• Polymorphism works in RMI -- you can
define subinterfaces; you can pass an
ojbect of a subtype to remote server
and the subtype methods are
appropriately used (doesn’t work in
CORBA).
Jini is built on Java RMI
• RMI = Remote Method Invocation
Public interface RemoteServer extends Remote {
public int getlength(String S) throws
RemoteException;
}
Java RMI, cont’d
• If you change the (Java) interface
declaration in Java, you are really
changing the way the interface works
• If you change the Java interface
declaration in a CORBA system, you just
break the interface, since the Java
interface is generated automatically
from the IDL description
Java RMI, cont’d
• Thus from a software engineering point
of view, the CORBA implementation is
more complicated and error-prone
• However, CORBA outperfromed RMI
empirically (no longer true?)
• For enterprise solutions, CORBA is
essential -- we will always need glue to
connect heterogeneous systems
Strong typing, cont’d
• “Remoteness” is inherently part of the
interface, not an implementation detail
• Every interface must extend
java.rmi.remote
• Permits a reasonable definition of
equality for remote objects -- you care
if the remote objects are the same, not
the local stubs
What Jini is not
• Jini is not a name server: lookup service
is similar, but does more than provide
references to objects
• Jini is not Java Beans: beans
communication based on direct method
invocation, not remote. Also, beans do
not automatically become aware of
each other as do Jini objects
What Jini is not, cont’d
• Jini is not Enterprise Java Beans:
Enterprise Java Beans function across
multiple address spaces well, but they
put Java wrappers around legacy
systems
• Jini is not RMI: built on top of RMI
• Jini is not a distributed OS
Five Key Concepts of Jini
•
•
•
•
•
Discovery
Lookup
Leasing
Remote Events
Transactions
Discovery
• Services=Devices or Software
• Services collect themselves into
communities
• The resources available to a community
are kept track of by a lookup service
• No one-to-one mapping between
communities and lookup services
• Discovery=finding available lookup
services
Discovery, cont’d
• Several discovery protocols
• Multicast finds nearby lookup services
(on the same LAN)
• Multicast Announcement declares that a
new lookup service has started up
• Unicast used to talk to a particular
lookup service
Lookup
• Lookup server does more than
nameserver
• Nameserver provides pointers to objects
when given names
• Lookup server does that also, plus
supports searching for services that
meet certain criteria, e.g. those that
have a particular Java type
Lookup cont’d
• Lookup returns a service item when
queried successfully.
• Service item contains proxy object
(local stub for remote object) and
attributes that describe the service
Lookup, cont’d
Service item
Proxy
attribute
attribute
Lookup service
Service item
Lookup, cont’d
• Downloadable proxy provided with each
service item
• When any entity wants to use your
service it downloads the proxy and runs
it -- the proxy handles sending the
remote server the necessary pieces
• Proxy can be used as a secure,
network-aware device driver
Proxy scenarios
• Proxy may perform the service by itself,
without any remote method invocation
• Proxy may be an RMI stub that knows
how to talk to a remote service (e.g.
IMAP mail server)
• Proxy uses private communication
protocol to talk to legacy (non-Java)
systems.
Using a Jini Service
Lookup service
Downloads proxy
Service
Client communicates
with service via
proxy
Client
“How does client x know to
call method y?”
• Objects must have some understanding
of the services they are going to use
• Industry will have to define a common
set of standards for interfaces to things
like cell phones, printers, scanners,
digital cameras
• My opinion: these interfaces will need
updating, and may prove to be Jini’s
undoing
Leasing
• Suppose a service provider dies at some
point
• How do you keep dead services from
accumulating in the lookup servers over
time
• Solution: a service is only provided for a
certain amount of time unless the
provider re-registers it (renews the
lease)
Leasing, cont’d
• No sysadmin needs to comb through
the lookup service database to remove
long-dead services
• Cleans up partial failures
• Similarly, resource is not granted to a
consumer for indefinite period, but
“leased” for a finite time
Leasing, cont’d
• Consumer must renew the lease if the
resource continues to be needed
• Unreliable code thus does not do
permanent damage -- after a while the
resource is freed automatically
• No maintenance required of persistent
storage
Third party leasing
• Jini leases can be negotiated by a third
party
• Example: long-lived but rarely active
process such as monthly disk backup
routine
• Example: process that does not want to
be bothered with extra code complexity
of lease management
Delegation
• Similar to Java Beans delegation
• Allows events to be handled by a third
party rather than the actual object to
which the event was sent
Lease mechanics
• Discovery returns an object that
implements lookup interface (called
ServiceRegistrar)
• Server calls method register() of
ServiceRegistrar with service item
object as argument -- describes the
service to be registered
Lease mechanics, cont’d
• Client calls ServiceRegistrar lookup()
method to find if a service meeting its’
criteria is registered.
• Service registrar returns a service item
object, whose proxy is then used to
access object
• Lease is handled by an argument to
register, which says how long (long int)
the server plans to provide the service
Lease mechanics, cont’d
• Only one round of negotiation needed
for a lease
• Lease done in terms of duration, not
absolute time
• Leasing is not garbage collection
Events
• Used for asynchronous notification
• Event is an object containing
information about external state change
the recipient may be interested in
• Same as Java Foundation Classes and
Java Beans model of events
Remote Events
• Remote events may not arrive in order
sent
• Remote events may not arrive at all
• Remote events more expensive to send
than local events
• What does sender do if receiver has
crashed -- keep trying? How long?
Remote Events, cont’d
• Example: want to print an image taken
with a digital camera to a printer
• Suppose digital camera is connected to
network and there are no printers (want
to “grey out” the print button on
camera GUI)
• When a printer is connected, the
cameras should be notified
Remote events, cont’d
• RemoteEventListener() is a remote
interface used by objects waiting for
events
• Method notify() invoked via RMI by
objects that want to send events
• Very simple: one class, one interface,
one method. Contrast to Java
Foundation Classes
• Jini can implement generic 3rd party
Remote Events, contd
• Process interested in receving events
leases that service just like any other
• Hence if a service dies, it is not sent
events forever, only until its lease
expires
Transactions
• Used to handle partial failures -- gives a
way of deducing state of the system
after a partial failure
• Used to guarantee data integrity(
atomicity, consistency, isolation,
durability)
Two-phase commit
• Transaction manager collects all
constituent operations of a transaction
• Participants go to pre-commit status
(compute all results they would
compute if transaction were successful,
but do not make them permanent)
• Send acknowledgement of successful
transition to pre-commit status back to
transaction manager
Two-phase commit, cont’d
• If any participant fails, transaction
manager instructs all components to
abort, else notifies all to commit
• State of all components of system is
predictable in the presence of failures
Jini implementation of twophase commit
• All participants implement
TransactionParticipant interface.
• Three methods: prepare(), commit()
abort()
• Jini transaction manager doesn’t care
how the participants implement the
methods, it just steps through the
protocol.