The Jini Architecture Speaker Weisheng Si Dept of






































- Slides: 38
The Jini Architecture Speaker: Weisheng Si Dept. of Computer Science University of Virginia Nov 6, 2000 CS 851 Ubiquitous Computing 1
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 Nov 6, 2000 CS 851 Ubiquitous Computing 2
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”. Nov 6, 2000 CS 851 Ubiquitous Computing 3
Architecture Overview Jini Services Remote Method Invocation Java Virtual Machine TCP/IP Data Link Layer The Jini Architecture Nov 6, 2000 CS 851 Ubiquitous Computing 4
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. Nov 6, 2000 CS 851 Ubiquitous Computing 5
A simplified example : The Lookup Service Proxy Object Printer Attributes A Camera A Printer Proxy Object Printer Attributes Nov 6, 2000 CS 851 Ubiquitous Computing 6
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. Nov 6, 2000 CS 851 Ubiquitous Computing 7
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 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. 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. Nov 6, 2000 CS 851 Ubiquitous Computing 8
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. Nov 6, 2000 CS 851 Ubiquitous Computing 9
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. Nov 6, 2000 CS 851 Ubiquitous Computing 10
The Discovery Protocols Three Protocols are used in the discovery phase: • Multicast Request Protocol • Unicast discovery protocol • Multicast Announcement Protocol Nov 6, 2000 CS 851 Ubiquitous Computing 11
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. Nov 6, 2000 CS 851 Ubiquitous Computing 12
The Discovering Entity 2. The discovering entity first sets up a TCP server. The Lookup Service 1. Construct a multicast UDP socket, listening to the multicast request. The multicast response service 3. Constructs a multicast UDP socket, then sends its request for lookup services to the network. The multicast response service Nov 6, 2000 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. CS 851 Ubiquitous Computing 13
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. Nov 6, 2000 CS 851 Ubiquitous Computing 14
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. Nov 6, 2000 CS 851 Ubiquitous Computing 15
The Discovering Entity 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. Nov 6, 2000 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. The unicast discovery server CS 851 Ubiquitous Computing 16
The Leasing Mechanism • 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. Nov 6, 2000 CS 851 Ubiquitous Computing 17
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) Nov 6, 2000 CS 851 Ubiquitous Computing 18
The Join Protocol(cont’d) 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. 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. 3. The Join Protocol happens after the discovery process, and is accomplished by using the downloaded proxy of the lookup service. Nov 6, 2000 CS 851 Ubiquitous Computing 19
Some Network Details • Though the Jini specification doesn’t explicitly say that Jini relies on the TCP/IP, but actually it does. • The Jini specification says: 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. Nov 6, 2000 CS 851 Ubiquitous Computing 20
Distributed/Remote Event is different from the local event, in that: • 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. 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. Nov 6, 2000 CS 851 Ubiquitous Computing 21
Distributed/Remote Event(cont’d) • Unlike the large number of event classes in the AWT and Swing, Jini typically uses event of only one type, the Remote. Event and a small number of its subclasses. • A Remote. Event is serializable and can be moved around the network to its listeners. • The Remote. Event. Listener is the receiver of Remote. Events. A Remote. Event. Listener is defined by an interface that contains a single method, “notify”, which informs interested listeners that an event has occurred. Nov 6, 2000 CS 851 Ubiquitous Computing 22
Registration and notification of Events 1. Registrant registers the remote event listener with the event generator Registrant 2. Event generator returns an event registration for the remote event listener to the registrant 3. Registrant returns the event registration to the remote event listener. Nov 6, 2000 Event Generator 4. Event generator fires a remote event to the listener to indicate the kind of event occurred Remote Event Listener CS 851 Ubiquitous Computing 23
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. Nov 6, 2000 CS 851 Ubiquitous Computing 24
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. Nov 6, 2000 CS 851 Ubiquitous Computing 25
RMI Architecture Server Program Client Program Stub Skeleton Java Remote Method Protocol Transport Layer Nov 6, 2000 CS 851 Ubiquitous Computing 26
Running a typical RMI Application Naming. lookup() rmiregistry Application Client Naming. rebind() Application Server Appl_Stub. class Web Server Nov 6, 2000 CS 851 Ubiquitous Computing 27
Retrospect to the Jini The Lookup Service Proxy Object Printer Attributes 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. A Camera A Printer Proxy Object Printer Attributes Nov 6, 2000 Any protocol is OK. CS 851 Ubiquitous Computing 28
Where is RMI used? 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(Jini 1. 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. rmid Lookup Service Proxy of the Service Registrar Nov 6, 2000 Web Server Stub used by Registrar Discovery Join, using RMI CS 851 Ubiquitous Computing Service Registrar 29
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. Jini Services HAVi messaging RMI IEC 61883 FCP JVM IEEE 1394 Standard TCP/IP Data Link Layer The HAVi Architecture Nov 6, 2000 The Jini Architecture CS 851 Ubiquitous Computing 30
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. 2. A Jini environment must have at least one lookup service to serve as the central registry. 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. 3. Jini’s “Discovery” means to discover the lookup services. Nov 6, 2000 CS 851 Ubiquitous Computing 31
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. Nov 6, 2000 4. Jini uses the Leasing mechanism as well as the lookup service to achieve the dynamic change of the network. CS 851 Ubiquitous Computing 32
Comparison with CORBA 1. CORBA is language independent. It uses OMG IDL, and has IDL compilers for most of the popular programming languages. 1. Jini relies on Java. It uses Java “interface” to describe the interface to the remote services. 2. The current version of CORBA doesn’t support object serialization, but it soon will. 2. The capability of “moving code” is one of the most important features of Jini. 3. CORBA uses the Naming/Directory service to obtain the reference to the remote object. 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 uses unicast for the service lookup. 4. It multicasts its service lookup request to the local network. Nov 6, 2000 CS 851 Ubiquitous Computing 33
Comparison with CORBA(cont’d) 5. CORBA has no Leasing mechanism. 5. Jini uses the Leasing mechanism as well as the lookup service to achieve the “network plug and play”. 6. CORBA focuses on “Object”. 6. Jini focuses on “Service”. This is because the designers of Jini believe that the distributed object transparency is impossible. 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. 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. Nov 6, 2000 CS 851 Ubiquitous Computing 34
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. Nov 6, 2000 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. CS 851 Ubiquitous Computing 35
Nov 6, 2000 CS 851 Ubiquitous Computing 36
The Smart Olsson Hall Lookup Service A Proxy of CS-BW 1 Proxy of CS-BW 2 CS-BW 1 Nov 6, 2000 Lookup Service B Visitor Proxy of CS-BW 1 CS-BW 2 Proxy of CS-BW 2 CS-BW 1 Knight Evans CS 851 Ubiquitous Computing CS-BW 2 37
Thank you! Nov 6, 2000 CS 851 Ubiquitous Computing 38