A Look at Jini

1
A Look at Jini

• Richard Chapman
• Sept. 30, 1999

2
Jini Motivation

• Why must everyone be a sysadmin?
• Why cant computers scale like the phone system
  added complexity without added configuration
  work?
• Why cant devices/services enter and leave the
  network without explicit reconfiguration?

3
Jini Goals

• Very robust software infrastructure
• No configuration/administration required
• Software must be evolvable
• Devices can form spontaneous communities

4
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

5
Jini is intended to be used by

• Information appliances (thin clients, set top
  boxes, PDAs)
• Desktop machines can benefit from a reduction in
  sysadmin duties
• Enterprise systems (servers) also benefit

6
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/

7
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)

8
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)

9
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

10
Handling Partial Failures, Contd.

• Even if server can detect which hosts have not
  received a message, what does it do
• Cant keep trying forever -- you run out of disk
  drives storing old messages you are trying to
  send
• Dont want to give up and cut off the host that
  failed to get a message

11
Why CORBA isnt 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.

12
Peter Deutchs Seven Network Fallacies

• The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure

• Topology doesnt matter
• There is one administrator
• Transport cost is zero

13
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)

14
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

15
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 (doesnt work in CORBA).

16
Jini is built on Java RMI
Public interface RemoteServer extends
Remote public int
getlength(String S) throws
RemoteException

• RMI Remote Method Invocation

17
Java RMI, contd

• 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

18
Java RMI, contd

• 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

19
Strong typing, contd

• 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

20
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

21
What Jini is not, contd

• 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

22
Five Key Concepts of Jini

• Discovery
• Lookup
• Leasing
• Remote Events
• Transactions

23
Discovery

• ServicesDevices 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
• Discoveryfinding available lookup services

24
Discovery, contd

• 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

25
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

26
Lookup contd

• Lookup returns a service item when queried
  successfully.
• Service item contains proxy object (local stub
  for remote object) and attributes that describe
  the service

27
Lookup, contd
Service item
Proxy
attribute
Service item
attribute
Lookup service
28
Lookup, contd

• 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

29
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.

30
Using a Jini Service
Lookup service
Downloads proxy
Client communicates with service via proxy
Service
Client
31
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 Jinis undoing

32
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)

33
Leasing, contd

• 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

34
Leasing, contd

• 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

35
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

36
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

37
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

38
Lease mechanics, contd

• 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

39
Lease mechanics, contd

• Only one round of negotiation needed for a lease
• Lease done in terms of duration, not absolute
  time
• Leasing is not garbage collection

40
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

41
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?

42
Remote Events, contd

• 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

43
Remote events, contd

• 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 event
  listeners (hard in JFC).

44
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

45
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)

46
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

47
Two-phase commit, contd

• 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

48
Jini implementation of two-phase commit

• All participants implement TransactionParticipant
  interface.
• Three methods prepare(), commit() abort()
• Jini transaction manager doesnt care how the
  participants implement the methods, it just steps
  through the protocol.