380 likes | 606 Views
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.
E N D
The Jini Architecture Speaker: Weisheng Si Dept. of Computer Science University of Virginia CS851 Ubiquitous Computing
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 CS851 Ubiquitous Computing
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”. CS851 Ubiquitous Computing
Architecture Overview Jini Services Remote Method Invocation Java Virtual Machine TCP/IP Data Link Layer The Jini Architecture CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
A simplified example : The Lookup Service Proxy Object Printer Attributes A Camera Proxy Object The Lookup Service A Camera A Printer Proxy Object Printer Attributes CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
The Discovery Protocols Three Protocols are used in the discovery phase: • Multicast Request Protocol • Unicast discovery protocol • Multicast Announcement Protocol CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
2. The discovering entity first sets up a TCP server. The multicast response service 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 Discovering Entity The Lookup Service 1. Construct a multicast UDP socket, listening to the multicast request. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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. 1. Establishes TCP unicast discovery server. The unicast discovery server 2. Constructs a UDP multicast socket, periodically sends out the “Here I am” message. Service IDs 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 The Discovering Entity The Lookup Service 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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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) CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
Distributed/Remote Event 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. CS851 Ubiquitous Computing
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 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. CS851 Ubiquitous Computing
Registration and notification of Events 1. Registrant registers the remote event listener with the event generator Event Generator Registrant 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 Remote Event Listener 3. Registrant returns the event registration to the remote event listener. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
RMI Architecture Server Program Client Program Skeleton Stub Java Remote Method Protocol Java Remote Method Protocol Transport Layer CS851 Ubiquitous Computing
Naming. lookup() Naming. rebind() Appl_Stub.class Appl_Stub.class Web Server Running a typical RMI Application rmiregistry Application Client Application Server CS851 Ubiquitous Computing
Retrospect to the Jini The Lookup Service Proxy Object Printer Attributes A Camera Proxy Object 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. The Lookup Service A Printer Proxy Object Printer Attributes Any protocol is OK. CS851 Ubiquitous Computing
Where is RMI used? rmid Web Server Stub used by Registrar Discovery Lookup Service Registrar Lookup Service Service Service Registrar Lookup Service Proxy of the Service Service Registrar Join, using RMI 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. CS851 Ubiquitous Computing
Comparison with HAVi HAVi messaging IEC 61883 FCP IEEE 1394 Standard 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 RMI JVM TCP/IP Data Link Layer The HAVi Architecture The Jini Architecture CS851 Ubiquitous Computing
Comparison with HAVi(Cont’d) 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. 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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
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. CS851 Ubiquitous Computing
Comparison with CORBA(cont’d) 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. 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. CS851 Ubiquitous Computing
Comparison with CORBA(cont’d) 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. 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. CS851 Ubiquitous Computing
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 Lookup Service A Proxy of CS-BW1 Lookup Service A Proxy of CS-BW1 Proxy of CS-BW2 Lookup Service B Proxy of CS-BW2 Lookup Service B Proxy of CS-BW2 Proxy of CS-BW1 Visitor CS-BW2 Knight CS-BW1 Evans Visitor Proxy of CS-BW1 CS851 Ubiquitous Computing
Thank you! CS851 Ubiquitous Computing