Nov 6, 2000CS851 Ubiquitous Computing1 The Jini Architecture Speaker: Weisheng Si Dept. of Computer...

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 ObjectPrinter Attributes

The Lookup Service

A Camera

The Lookup Service


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 UDPsocket, listening to the multicastrequest.

3. Constructs a multicast UDPsocket, then sends its request

for lookup services to the network.

4. If the DE’s groups match thegroups to which it provides services,it connects to the DE’s multicastresponse server, and passes its proxyobject 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 multicastsocket, periodically sends out

the “Here I am” message.

1.Establishes a set of service IDsof 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 IDis already in the set and whether it isinterested in the groups of the lookupservice.

3. If the service ID isn’t in the setand it is interested in the groups, itconnects to the unicast server to getthe proxy of the lookup service andthen 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 ProtocolA service must maintain certain items of its state. These items areas 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 EventGenerator

RemoteEvent

Listener

1. Registrant registers theremote event listener withthe event generator

2. Event generator returnsan event registration for theremote event listener to theregistrant

4. Event generator firesa remote event to thelistener to indicate thekind of event occurred

3. Registrant returns theevent registration to the remoteevent 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

ApplicationClient

ApplicationServer

Appl_Stub.classWeb

Server

Appl_Stub.class

Naming.rebind()

Naming.lookup()


Retrospect to the Jini

A Printer


The Lookup ServiceThe Lookup Service


A Camera

Proxy Object Any protocol is OK.

1. Proxy must be implemented bythe programmer, while stub isautomatically generated by the RMIcompiler “rmic”.2. Proxy can communicate with theservice using its own protocol, andthe client doesn’t need to know aboutit.3. Proxy is the key role to achieve thespontaneous 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.

DiscoveryService

Registrar

Lookup Service

Join, using RMI

Service

Registrar

Lookup Service

Proxy of the Service

rmid Web ServerStub 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-BW1Proxy of CS-BW2

Lookup Service B


CS-BW1 CS-BW2Evans Knight

Lookup Service A

Proxy of CS-BW1

Lookup Service B

Proxy of CS-BW2

Lookup Service A


Lookup Service B


Visitor

Visitor Proxy of CS-BW1


Thank you!

Nov 6, 2000CS851 Ubiquitous Computing1 The Jini Architecture Speaker: Weisheng Si Dept. of Computer...

Documents

Transcript of Nov 6, 2000CS851 Ubiquitous Computing1 The Jini Architecture Speaker: Weisheng Si Dept. of Computer...