The Jini Architecture

1. The Jini Architecture

2. Outline • What is Jini? • Jini architecture overview • Service lookup process • Distributed events • How is Jini related to the RMI

3. 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?

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

5. Jini History • Fulfillment of original Java goals of an environment for embedded systems (Oak, 1990) • The word “Jini” does not stand for anything

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

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

8. Installing Jini • The install has become fairly easy • Building applications requires a bit of work. • Software development after the first few applications looks like it becomes easier.

9. 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”.

10. Jini • Simple infrastructure to provide services in a network • Services can join and leave the network • Clients interact with services through an object provided by the service. • The object is downloaded into the client program so the service can be communicated with even if the client had never seen this kind of service before.

11. Architecture Overview Jini Services Remote Method Invocation Java Virtual Machine TCP/IP Data Link Layer The Jini Architecture

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

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

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

15. 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. For a lookup service: Here I am : sends a “Here I am” message periodically to the local network in case some services might have failed 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.

16. 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. • Groups passively partition the physical Jini network for multicast reasons.

17. The Service Lookup Process(cont’d) • Groups are not the same as federations • A federation is a temporary union of Jini clients and services that come together to get work done. • Federations can transcend group boundaries and discover boundaries imposed by lookup service availability. • Clients can move between federations obtaining services as needed.

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

19. The Discovery Protocols • Multicast Request Protocol • Unicast discovery protocol • Multicast Announcement Protocol Three Protocols are used in the discovery phase:

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

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

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

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

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

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

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

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

28. Some Network Details • Though the Jini specification doesn’t explicitly say that Jini relies on TCP/IP, it actually 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.

29. Events • The event consumer registers an interest with the producer, (i.e. button state change) • The producer tracks state changes • When the appropriate change takes place the producer notifies the consumer (callback)

30. Events • For local event, such as those occurring in a GUI the process is reliable. • For remote events the unreliability of the delivery mechanism adds some interest.

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

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

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

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

35. Dealing with remote event Problems • Batch events together if many event occur between a producer and consumer • Build a reliable event mechanism on top of the basic Jini event infrastructure.

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

37. RMI Architecture Server Program Client Program Skeleton Stub Java Remote Method Protocol Java Remote Method Protocol Transport Layer

38. Running a typical RMI Application Naming. lookup() Naming. rebind() Appl_Stub.class Appl_Stub.class Web Server rmiregistry Application Client Application Server The web server is used to access the codebase. For small services rarely used rmid can be used to activate the service.

39. 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. (reggie) The Lookup Service A Printer Proxy Object Printer Attributes Any protocol is OK.

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

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

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

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

44. RMI • To use Jini a good understanding of RMI is required. • RMI or Remote Method Invocation is much more than RPC.

45. RMI vs RPC

47. Traditional Model • Client translates a request to an intermediate transmission format and sends request to server. • Server parses the request, computes a response, formats the response for transmission • Client receives response, parses response, provides response to user.

48. Java • Java Supports basic socket communications • See code SockServer.java and SockClient.java in code directory • To run example • javac SockServer.java; java SockClient.java • Java SockServer • Java SockClient

49. Java Communications • Although socket communications is available the preferred method is via RMI.

50. Remote Method Invocation • RMI is a method of doing client-server communications via proxy. • The client has a server proxy that it makes calls to, the client’s proxy then makes calls to the server’s proxy which handles regular method calls to the server. • CORBA supports method calls as well between objects.