Jini Connection Technology Kaushik Lahoti

Jini: A Vision n Areas to focus on –Simplicity –Reliability –Scalability

Areas to focus on ( contd. ) n Simplicity n Jini is Java based. n Jini is about how services connect to one another.

Areas to focus on ( contd.) –Reliability n Jini is similar to LDAP or name server but not the same. n How is reliability achieved ? –Serendipitous interactions among services. –Spontaneous networking with no explicit user involvement. n Self - Healing n Results: –Administration free. –No explicit user involvement. –No need for driver or software installation to use a particular service.

Areas to focus on ( contd. ) –Scalability n Jini services form groups or communities. –How big ? n Scalability issue is addressed through federation. –What is federation ? Ability of Jini communities to be linked together, or federated, into larger groups. Ability of Jini communities to be linked together, or federated, into larger groups. – The use of federation When you need to access a service in another community. When you need to access a service in another community.

The Five key concepts Conceptual Simplicity is Jini’s explicit goal. Jini is based around five key concepts. –Discovery –Lookup –Leasing –Remote Events –Transaction Management

Discovery First a Jini aware entity finds one or more Jini communities. Lookup service keeps track of all the shared resources of that community. So a Jini-aware entity should find this lookup service. This process is called discovery. It is not necessary to have one-to-one mapping between lookup service and a community. Lookup services are started explicitly by the System administrators.

Types of Discovery protocols n Multicast Request. n Multicast Announcement. n Unicast Discovery. Representation of Lookup services Representation of Lookup servicesjini://hostname:port/data The End Result: Object doing discovery is handed out one or more references to Lookup services for the requested community.

The End Result ( contd.) Clients and services use this reference to: Clients and services use this reference to: –Advertise their facilities. –To determine what services are available

Publishing a Service n Think of Lookup service as maintaining a list of “Service Items”. n If a service wants to publish itself, it does so by joining a Lookup services returned from the discovery. –For this purpose, register() method of ServiceRegistrar interface is used. –Invoke register() method by passing service item object as an argument.

Downloadable Proxies n The idea of downloaded proxies is the key idea that gives Jini its ability to use services and devices without doing any explicit driver/software installation. n Service publish the code that can be used to access them.

Scenarios of how the proxy object interacts with your service n The downloaded proxy performs the service completely. n The downloaded object is an RMI stub for talking to some remote service. n The downloaded object uses a private communication protocol for talking to the service. Most commonly used in two cases: –If there is some legacy software involved. –If service is provided by some hardware device, eg. printer.

Finding a Service n After getting a reference to a Lookup service, a consumer can search all the service items to find the service of interest. n Ways to find: –Type of downloaded proxy object contained in a service item. –Unique id of the service. –Attributes of the service items. n Lookup() is used to do this. Once you have specified search parameters and called lookup(), the value that is returned to you is the proxy object from the service item. Once you have specified search parameters and called lookup(), the value that is returned to you is the proxy object from the service item.

Leasing After discovery and Lookup - After discovery and Lookup - n How to ensure that these communities are stable, self-healing and resilent in the face of network failures, software errors and machine crashes. n The issue of reliability is important when the software systems are intended to be long lived. n For example …..

Leasing ( contd.) n This violates everything we want from Jini like: –It does’nt ensure that the system will self- heal. –It requires explicit human intervention to administer the system. n This problem is solved by a technique called Leasing.

Types of Leasing n Time Based Resource Reservation –The resource is “loaned” to a consumer for a fixed period of time rather than granting access for an unlimited amount of time. n Third Party Leasing –What is third party leasing ? –Reasons for having third party leasing. n An application just wants to worry about writing about its services and forget about all of the leasing APIs, lease renewal, expiration and so on. n If a service is extremely long-lived and yet rarely active, for example the service that does monthly backups of disc drives.

Using Leases in Practice n register() method of the ServiceRegistrar interface takes as an argument a long integer representing the number of milliseconds for which a service wants its lease to last. n The Lookup service responds with a result of type ServiceRegistration, which contains information about just-registered service. n Lease object represents lease that Lookup service has granted.

Points to make about Leasing n There is only one round of negotiations. n Leases are always done in terms of time duration ( i.e. described relative to the current time rather than some fixed absolute time.

Remote Events n Jini handles events using asynchronous notification. n Jini’s event model is similar to Java’s event model but there are some differences. Why ? Is the Java event model not good ? The answer for this is “environments”.

Event Programming Model n Jini APIs and Java APIs for event handling are quite similar. n But there are differences, which are: –key interfaces used by objects that wish to receive remote events, RemoteEventListener is an RMI remote interface. The method provided is notify(). –Narrowness of Jini event model. –Important: There is no addRemoteEventListener() method. That is Jini provides no generic way of signaling interest in events.

Generic Third-Party Delegates n Why is event model so sleek ? n Jini remote events also use delegation model like Java but Jini has an ability to create generic third party event listeners that can respond to any event type. n Using generic third-party events, you can add application behavior to event pipeline. Event Generator Logging Delegate Reliable Delivery Delegate Event Consumer

Transactions n Jini uses Two phase commit transactions n How the two phase commit work ? Transaction Manager op1 op2 op3 Ready to commit ready Ready to commit ready Ready to commit

Two Phase Commit ( contd.) Transaction Manager op1 op2 op3 commit

Two-Phase Commit in Jini n Surprising fact is that Jini does’nt really use two-phase commit. n The transaction model takes a very lightweight approach. Jini say that two-phase commit is simply a protocol ( interface ) n Actual particulars of what happens when the protocol is run - when the methods are called - is up to the implementation. n All the participants in Jini transaction implement TransactionParticipant interface. n The mothods provided are: –prepare() –commit() –abort() –prepareAndCommit()

Two-Phase Commit in Jini ( contd. ) n So Jini provides much less restrictive and potentially much less safe notion about what a transaction is. n Jini allows objects to participate, rather than requiring them to. n But in practice, it has an upside.

Discovery In-Depth n Discovery is a process by which Jini applications find the lookup services that serve their community. n Categories of Discovery –Serendipitous –Hard-Wire

What is UDP Multicast n In UDP multicast, a range of special IP addresses are used as multicast groups. n Interested parties can effectively join a group by listening to messages sent to that IP address. n Messages sent to that IP address will be automatically received by all the parties listening to it. n Each message sent via multicast has a “scope” associated with it which is used to limit the distance. n Scoping also allows efficiency in routing ( using TTL value )

Types of Discovery n Service-Initiated Discovery –New services who wish to find all the nearby lookup services uses multicast request protocol. –This protocol uses IP multicast to find the lookup services. –Service sends a multicast message to a well-known multicast address. –The address is agreed upon ahead of time by all Jini lookup services. –Once a lookup service receives multicast discovery request, it responds by connecting directly to the service by sending a unicast ( point-to-point ) message. –This message contains the proxy object that the service uses to contact lookup service.

Types of Discovery ( contd. ) n Lookup service-initiated discovery –The lookup services periodically announce their presence using multicast announcement protocol. –Interested parties listen to a well known multicast address. –All the lookup services send a multicast message to this address. –The message is scoped so that it reaches interested parties on the local area network. –After a service receives multicast message, it contacts the lookup service using a direct unicast connection and then the lookup service replies with the proxy object

Types of Discovery ( contd. ) n “Direct” Discovery –In this case, each lookup service listens on a normal, unicast address. –This protocol is called unicast discovery protocol. –So in this sense, this is not really a “discovery” protocol. –Unicast discovery is based on URL naming scheme. jini://hostname:port/data –Port 4160 is the default port for Jini lookup.

Using Discovery in Applications n The discovery API is based on listener paradigm. n This API model provides common model for multicast request and announcement but is different for unicast discovery.

Basic Interface: DiscoveryListener import java.util.EventListener; public interface DiscoveryListener extends EventListener { public void discovered(DiscoveryEvent ev); public void discarded(DiscoveryEvent ev); } n Any object who needs to find any lookup services must implement this interface.

DiscoveryEvent Class import java.util.EventObject; public class DiscoveryEvent extends EventObject { // …. Few methods public ServiceRegistrar[] getRegistrar(); } n getRegistrars() method returns an array of ServiceRegistrar instances. n Each of these is a service proxy that is used to talk to a particular lookup service

Mechanics of how to start the Discovery public class LookupDiscovery { public static final String[] ALL_GROUPS = null; public static final String[] NO_GROUPS = new String[0]; public static final String[] NO_GROUPS = new String[0]; public LookupDiscovery(String[] grps) throws IOException; public void addDiscoveryListener(DiscoveryListener l); public void removeDiscoveryListener(DiscoveryListener l); public void discard(ServiceRegistrar reg); public String[] getGroups(); public void setGroups(String[] grps) throws IOException; public void addGroups(String[] grps) throws IOException; public void removeGroups(String[] grps); public void terminate(); }

Security and LookupDiscovery n There should be a way to restrict access to particular groups. n Jini provides a way using Java 2 security mechanisms for you to limit what groups a service or application can join. n When a service or an application tries to create a LookupDiscovery object, the code checks to see whether the creator has permission to try to discover each of the sets of the desired groups. n LookupDiscovery will raise a java.lang.SecurityException if the proper privileges are not in place.

Security and LookupDiscovery ( contd. ) n By default, applications are allowed to search no groups. n Permission need to be set for even trusted programs. n Create a policy file and pass the file to JVM via the java.security.policy property. n Jini introduces its own permission class just for granting access to groups. n This class is: net.jini.discovery.DiscoveryPermission and can be used in policy file as: permission net.jini.discovery.DiscoveryPermission “*”; permission net.jini.discovery.DiscoveryPermission “unsafe”; permission net.jini.discovery.DiscoveryPermission “”;

Other Internal Discovery Issues n Multicast Discovery protocols require that all the data fit in packets with the maximum length of 512 bytes. –Reason behind this: Multicast is based on UDP which makes no guarantee that the packets will be received in the order that they are sent or if they will be received at all. n Security ( Be forewarned ) –There is no authentication performed on either discovery requests or responses. –This means that it is impossible to know whether an entity contacting you is a “legitimate” lookup service or other service.

Other Internal Discovery Issues ( contd. ) n Requirements for running a lookup service –Must have a network stack to support multicast TCP and unicast UDP messages. –No need of JVM here. n Requirements for parties that are searching a lookup service –Network stack capable of UDP multicast and TCP unicast messages. –Must have JVM.

The End !!