Embed Size (px)
Citation preview
CS 550-395COMPARATIVE OPERATING
SYSTEMS
FALL 2001
PALKI CHAKRABARTI
ID # 999-29-0211
2
Email: [email protected]
TABLE OF CONTENTS1. Introduction
(3)1.1.What is JINI Network Technology?……………………………………….. (4)
2. Components of a JINI Federation(5)
2.1. Service Registration…………………………………………………………
(6)2.2. Client
Lookup………………………………………………………………..(7)2.3.
Proxies……………………………………………………………………….. (9)
2.4. Partitioning an application…………………………………………………(10)
2.5. Support Services……………………………………………………………..(10)3. JINI Architecture (11)4. Troubleshooting JINI (14)5. Discovering a Lookup Service (15)
5.1 Lookup Service……………………………………………………………….(15)
5.2 Unicast Discovery……………………………………………………………(15)
5.3 Broadcast Discovery…………………………………………………………(16)
Groups……………………………………………………………………(16)6. Entry Objects
(17)
3
6.1 Entry Class……………………………………………………………………(17) 6.2 Restrictions on Entries……………………………………………………….(17)7. Service Registration
(17) 7.1 Service Entries………………………………………………………………...(17) 8. Client Search
(19)9. Leasing a Service
(19) 9.1 Leases…………………………………………………………………..(19) 9.2 Granting and Handling Leases……………………………………...(20)
Abstract Lease…………………………………………………….(21) Landlord Lease…………………………………………………………..(21)
9.3 Lease Policy…………………………………………………………………...(21)10. Join Manager
(22)11. Security
(23)11.1. Quick
Fix…………………………………………………………….(23)
11.2. Why All Permission is Bad………………………………………...(23)
11.3. Removing AllPermission…………………………………………..(24)
11.4. JINI with Protection………………………………………………...(24)12. JINI and CORBA
(26) Conclusion (27) References
(28)
4
1. INTRODUCTION
Over the last quarter century, network technology has evolved rapidly and in some unexpected ways. Client/server and multi-tier models operating within a single business enterprise have given way to an Internet/Web environment where services are provided by nodes scattered over a far-flung network.
Today, the next generation of network interaction is emerging that will place unprecedented demands upon existing network technologies and architectures. For example, participants in one network will need to directly access and use the services provided by participants in another network. It is in this network environment - one of mind-numbing complexity driven by geometric increases in scale, rate of change, and multiplicity of participant interactions - that the simplicity of the JINI architecture clearly wins.
Network-Centric Computing refers to balance the requirements of the user with those of the organization. The organization's need to create a highly manageable, cost-effective environment must not be achieved at the expense of the users' fundamental business needs. It needs appropriate, controlled client access, information integrity, investment protection, manageable cost of ownership, and extremely high levels of service are key elements that will result in the success of a network-centric computing environment. This trend in the hardware environment, from disk-centric to network-centric, will affect how we organize our software -- and that's where JINI comes in.
Jini has grown from early work in Java to make distributed computing easier. It intends to make network devices and network computing into
5
standard components of everyone's computing environment. Homes, offices and factories are becoming increasingly networked. Current twisted pair wiring will remain, but will be augmented by wireless networks and networks built on your phone lines and power cables. On top of this will be an infrastructure to allow devices to communicate. TCP/IP is a part of this, but it is not enough. There will be need for service discovery, for negotiation of properties, and for event signaling. Jini supplies this higher level of interaction.
There are a large number of scenarios where this would be useful:
A new printer can be connected to the network and announce its presence and capabilities. A client can then use this printer without having to be specially configured to do so.
A digital camera can be connected to the network and present a user interface that will not only allow pictures to be taken, but it can also be aware of any printers so that the pictures can be printed.
A configuration file that is copied and modified on individual machines can be made into a network service from a single machine, reducing maintenance costs.
1.1. What is JINI Network Technology?
JINI network technology provides a simple infrastructure for delivering services in a network
6
and for creating spontaneous interaction between programs that use these services regardless of their hardware/software implementation. Any kind of network made up of services (applications, databases, servers, devices, information systems, mobile appliances, storage, printers, etc.) and clients (requesters of services) of those services can be easily assembled, disassembled, and maintained on the network using Jini Technology. Services can be added or removed from the network, and new clients can find existing services, all without administration, which ensures reliability and compatibility.
JINI is a distributed computing network environment that offers, “Network plug and play”- to form an impromptu community -- a community put together without any planning, installation, or human intervention. The Jini system or federation is a collection of clients and services communicating by Jini protocols. The areas where Jini can be implemented are home networks, small networks, large networks, and mobile networks. Current implementation is in small home networks that include integration in consumer electronics.
The Java programming language is the key to making Jini technology work. Devices in a network employing Jini technology, are tied together using Java Remote Method Invocation (RMI). By using the Java programming language, Jini network architecture is secure. The discovery and join protocols, as well as the lookup service, depend on the ability to move Java objects, including their code, between Java virtual machines. Jini is written in pure Java but the clients and the services are not constrained to be in java. They may include native code methods, that act as wrappers around java objects. Jini also supplies a middleware layer to link services and clients from a variety of sources.
Jini is an attempt to rethink computer architecture. These devices, which will come from many different vendors, will need to interact over a network. The network itself will be very dynamic and devices and services will be added and removed regularly. Jini
7
provides mechanisms to enable smooth adding, removal, and finding of devices and services on the network. It provides a programming model that makes it easier for programmers to get their devices talking to each other. Building on top of Java, object serialization, and RMI, which enable objects to move around the network from virtual machine to virtual machine, Jini attempts to extend the benefits of object-oriented programming to the network.
2. Components of a JINI Federation
JINI is one of a large number of distributed systems architectures, including industry-pervasive systems such as CORBA and DCOM. It is distinguished by being based on Java, and derives many features purely from this Java basis. Jini is only one competitor in a non-empty market. There are other Java frameworks from Sun, which appear to overlap Jini, such as Enterprise Java Beans (EJBs). EJB's make it easier to build business logic servers, while Jini could be used to distribute these services in a “network plug and play” manner.
Jini is a set of APIs and network protocols that can help you build and deploy distributed systems that are organized as federations of services. A service can be anything that sits on the network and is ready to perform a useful function. Hardware devices, software, communications channels, even human users themselves can be services.
In a running Jini system, there are three main players. There is a service, such as a printer, toaster etc and a client, which makes use of this service. Thirdly, there is a lookup service (service locator), which acts as a broker/trader/locator between services and clients. There is an additional component, and that is a network connecting all
8
three of these, and this network will generally be running TCP/IP.
Code is around between these three pieces, and marshalling the objects does this. This involves serializing the objects in such a way that they can be moved around the network, stored in this “freeze-dried” form, and later reconstituted by using included information about the class files as well as instance data. This is done using Java's socket support to send and receive objects.
In addition, objects in one JVM (Java Virtual Machine) may need to invoke methods on an object in another JVM. Often this will be done using RMI (Remote Method Invocation), although the Jini specification does not require this and there are many other possibilities.
TCP/IP
Fig 2.1: Components of a Jini system
2.1. Service Registration
A service is a logical concept, which will be defined by a Java interface and the service itself will be identified by this interface. Each service can be implemented in many ways, by many different vendors. A service provider creates a service. A service provider plays a number of roles:
It creates the objects that implement the service.
Client Lookup Service
Service
9
It registers the service object with lookup services. The service object is the visible part of the service, and is downloaded to clients.
It stays alive in a server role, performing various tasks such as keeping the service alive.
In order for the service provider to register the service object with a lookup service, the server must first find the lookup service. This can be done in two ways: if the location of the lookup service is known, then the service provider can use unicast TCP to connect directly to it. If the location is not known, the service provider will make UDP multicast requests, and lookup services may respond to these requests. When the lookup service gets a request on this port, it sends an object back to the server. This object, known as a registrar, acts as a proxy to the lookup service, and runs in the service's JVM. Any requests that the service provider needs to make of the lookup service are made through this proxy registrar. Registering the service involves taking a copy of the service object, and storing it on the lookup service. Lookup service Service provider
Fig 2.2: Querying for a service locator
Lookup service Service provider
Service object
Service object
Registrar
10
Fig 2.3: Registrar returned. Lookup service Service provider
Fig 2.4: Service uploaded
2.2. Client Lookup
The client on the other hand, tries to get a copy of the service into its own JVM. It goes through the same mechanism to get a registrar from the lookup service. But now it requests the service object to be copied across to it.
Client Lookup service
Fig 2.5: Querying for a service locator
Client Lookup Service
Service object
Service object
Registrar
Service
object
11
Fig 2.6: Registrar returned. Client Lookup service
Fig 2.7: Registrar requests for a service from the service provider
Client Lookup service
Fig 2.8: The service object is returned.
At this stage there is the original service object running back on its host. There is a copy of the service object stored in the lookup service, and there is a copy of the service object running in the client's JVM. The client can make requests of the service object running in its own JVM.
The components of the Jini system can be segmented into three categories: infrastructure, programming model, and services. The
Service
objecRegist
rar
Registra Service
objec
Service object
Registra
Service
object
12
infrastructure is the set of components that enables building a federated Jini system, while the services are the entities within the federation. The programming model is a set of interfaces that enables the construction of reliable services, including those that are part of the infrastructure and those that join into the federation. These three categories, though distinct and separable, are entangled to such an extent that the distinction between them can seem blurred. Moreover, it is possible to build systems that have some of the functionality of the Jini system with variants on the categories or without all three of them. But a Jini system gains its full power because it is a system built with the particular infrastructure and programming models described, based on the notion of a service. Decoupling the segments within the architecture allows legacy code to be changed minimally to take part in a Jini system. Nevertheless, the full power of a Jini system will be available only to new services that are constructed using the integrated model.
2.3. Proxies
A single object, the service object, can implement some services. The implementation of the service is made up of at least two objects, one running in the client and another distinct one running in the service provider.
The service object is really a proxy, which will communicate back to other objects in the service provider, probably using RMI. The proxy is the part of the service that is visible to clients, but its function will be to pass method calls back to the rest of the objects that form the total implementation of the service.
When a service object needs to control a remote piece of hardware that is not directly accessible to the service object, it need not be hardware: there could be files accessible to the service provider that are not available to objects running in clients. There are applications local to the service providers that
13
are useful in implementing the service. It is easier to program the service in ways that involve objects on the service provider, with the service object being just a proxy. The majority of service implementations end up with the service object being just a proxy to service backend objects, and it is quite common to see the service object being referred to as a service proxy.
The proxy has to communicate with other objects in the service provider. The proxy can be primed in the following ways: an RMI naming service can be used such as rmiregistry, where the proxy is given the name of the service. The proxy can also be implemented without any direct use of RMI, and can then use an RMI exported service or some other protocol altogether such as ftp, http or a homegrown protocol. The proxy needs to communicate with other objects in the service provider. When the proxy is created it is “primed” with its own service provider's location so that when run it can find its own home.
Figure 2.9: A proxy service2.4. Partitioning an Application
JINI uses a “service” view of applications. This is in contrast to the simple object-oriented view of an application. A Jini application is made up of objects,
14
but these will be distributed out into individual services, which will communicate via their proxy objects. In many monolithic applications there are one or more services waiting to be released, and making them into services increases their possible uses.
For example, a smart file viewer, which is an application that will be given a filename, and based on the structure of the name, will decide what type of file it is. Using this classification it will then call up an appropriate viewer for that type of file, such as an image viewer or document viewer. There are a number of services in this. Classifying a file into types is one. This service can be used in lots of different situations, not just viewing contents. Each of the different viewer classes is another. They are reusable, and this is makes them suitable for services. They do not require high-bandwidth communication, and are not completely trivial.
Each service may be running on a different machine on the network. Each exports a proxy to whatever service locators are running. The Smart Viewer application finds and downloads whatever services it needs, as it needs them.
2.5. Support Services
The three components of a Jini system are clients, services and service locators, which may run anywhere on the network. These will be implemented using Java code running in Java Virtual Machines. Jini also relies heavily on the ability to move objects across the network, from one JVM to another. In order to do this, particular implementation make use of support services such as RMI daemons and HTTP servers. The particular support services required depend on implementation details, and so may vary from one Jini component to another.
15
A Java object running as a service has a proxy component exported to the service locators and then onto a client. It passes through one JVM in a passive form and is activated in the client's JVM. Essentially, a snapshot of the object's state is taken using serialization, and this snapshot is moved around. An object consists of both code and data, and it cannot be reconstituted from just its data, the code is also required. The code is not likely to be on the client side. If it were required to be on the client side, then Jini would lose almost all of its flexibility because it wouldn't be possible to just add new devices and their code to a network. The class definitions are most likely on the server, or perhaps on the vendor's home Web site.
3. JINI Architecture
A JINI system consists of the following parts: A set of components that provides an
infrastructure for federating services in a distributed system
A programming model that supports and encourages the production of reliable distributed services
The architecture of a single Jini system is targeted to the workgroup. Members of the federation are assumed to agree on basic notions of trust, administration, identification, and policy. It is possible to federate Jini systems themselves for larger organizations.
Service:
The most important concept within the Jini architecture is that of a service. A service is an entity that can be used by a person, a program, or another service. A service may be a computation, storage, and a communication channel to another user, a software filter, a hardware device, or another user. Two examples of services are printing
16
a document and translating from one word-processor format to some other.
Members of a Jini system federate in order to share access to services. A Jini system should not be thought of as sets of clients and servers, or users and programs, or even programs and files. Instead, a Jini system consists of services that can be collected together for the performance of a particular task. Services may make use of other services, and a client of one service may itself be a service with clients of its own. The dynamic nature of a Jini system enables services to be added or withdrawn from a federation at any time according to demand, need, or the changing requirements of the workgroup using it.
Jini systems provide mechanisms for service construction, lookup, communication, and use in a distributed system. Examples of services include devices such as printers, displays, or disks; software such as applications or utilities; information such as databases and files; and users of the system. Services in a Jini system communicate with each other by using a service protocol, which is a set of interfaces written in the Java programming language. The set of such protocols is open ended. The base Jini system defines a small number of such protocols, which define critical service interactions.
Java Remote Method Invocation (RMI™):
Communication between services can be accomplished using Java Remote Method Invocation (RMI™). The infrastructure to support communication between services is not itself a service that is discovered and used but is, rather, a part of the Jini technology infrastructure. RMI provides mechanisms to find, activate, and garbage collect object groups.
Fundamentally, RMI is a Java-programming-language-enabled extension to traditional remote
17
procedure call mechanisms. RMI allows not only data to be passed from object to object around the network but full objects, including code. Much of the simplicity of the Jini system is enabled by this ability to move code around the network in a form that is encapsulated as an object.
Transactions:
A series of operations, either within a single service or spanning multiple services, can be wrapped in a transaction. The Jini Transaction interfaces supply a service protocol needed to coordinate a two-phase commit. How transactions are implemented and indeed, the very semantics of the notion of a transaction is left up to the service using the interfaces.
Events:
The Jini architecture supports distributed events. An object may allow other objects to register interest in events in the object and receive a notification of the occurrence of such an event. This enables distributed event-based programs to be written with a variety of reliability and scalability guarantees.
A Jini system can be seen as a network extension of the infrastructure, programming model, and services that made Java technology successful in the single machine case. These categories along with the corresponding components in the familiar Java application environment are shown in the figure below.
18
Infrastructure:
The Jini technology infrastructure defines the minimal Jini technology core. The infrastructure includes the following:
A distributed security system, integrated into RMI, which extends the Java platform’s security model to the world of distributed systems.
The discovery/join protocol, a service protocol that allows services (both hardware and software) to discover, become part of, and advertise supplied services to the other members of the federation.
The lookup service serves as a repository of services. Entries in the lookup service are objects in the Java programming language; these objects can be downloaded as part of a lookup operation and act as local proxies to the service that placed the code into the lookup service.
The discovery/join protocol defines the way a service of any kind becomes part of a Jini system; RMI defines the base language within which the Jini services communicate; the distributed security model and its implementation define how entities are identified and how they get the rights to perform actions on their own behalf and on the behalf of others; and the lookup service reflects the current members of the federation and acts as the central marketplace for offering and finding services by members of the federation.
Threads:
Jini uses many threads in its internal workings. The two types of threads used in Jini are as follows:
Lookup Discovery threads A multicast request is made by creating a new Lookup Discovery object with a non-empty set
19
of groups, or by calling set Groups (). This is the broadcast the service, looking for service locators. This is done using a thread of type Requestor. This creates a Multicast Socket, sets its time-to-live field and sends out a number of announcements. A class Response Listener is used to handle replies. This runs as its own thread. It listens on a socket for responses and adds them to a list of service locators. If a new locator is found, then it calls each Discovery Listener. Both of these run as daemon threads. That means they run as background threads. A user thread is needed to keep the application alive: an application will terminate if there are only daemon threads alive.
LeaseRenewalManager threads A LeaseRenewalManager uses a thread of class Renew Thread. This thread looks after all aspects of renewal.
4. Troubleshooting Jini
A device or a software service can be connected to a network and announce its presence, and clients that wish to use such a service can then locate it and call it to perform tasks. Jini can be used for mobile computing tasks where a service may only be connected to a network for a short time, but it can more generally be used in any network where there is some degree of change. Although Jini is written in pure Java, neither clients nor services are constrained to be in pure Java.
20
Some of the problems that can arise in a Jini system are configuration problems of some kind. Most of them are configuration problems of some kind. One of the main problems is getting the right files in the right places with the right permissions.
Jini Versions:
There are currently two versions of Jini: 1.0 and a version of 1.1 in alpha. Jini version 1.1 (beta) is coming up too. The core classes are all the same. Only changes in version 1.1 for the programmer are that some classes from Jini 1.0 have been specified better and are in different packages, and that some classes are new. There are also changes between 1.1 alpha and 1.1 beta.
Debugging:
Debugging a Jini application is difficult because there are so many bits to it, and the bits run separately: the server for a service, the client, lookup services, remote activation daemons and HTTP servers. There are a few errors within the Jini objects themselves and many of these objects are implemented using multiple threads and the flow of the execution is not always clear. Most of the code is organized into packages. To run the examples the classes must be accessible from your class path. The Jini class files are all in jar files. The Jini distribution has them in a subdirectory lib when it is unpacked.
On either the client or service side, a debugger such as jdb can be used to step through or trace execution of each one. They do not give complete information.
21
5. Discovering a Lookup Service
5.1. Lookup Service
Services are found and resolved by a lookup service. The lookup service is the central bootstrapping mechanism for the system and provides the major point of contact between the system and users of the system. In precise terms, a lookup service maps interfaces indicating the functionality provided by a service to sets of objects that implement the service. In addition, descriptive entries associated with a service allow more fine-grained selection of services based on properties understandable to people.
Objects in a lookup service may include other lookup services; this provides hierarchical lookup. Further, a lookup service may contain objects that encapsulate other naming or directory services, providing a way for bridges to be built between a Jini Lookup service and other forms of lookup service. Of course, references to a Jini Lookup service may be placed in these other naming and directory services, providing a means for clients of those services to gain access to a Jini system. A service is added to a lookup service by a pair of protocols called discovery and join—first the service locates an appropriate lookup service and then it joins it.
A client locates a service by querying a lookup service (service locator). In order to do this, it first locates such a service. On the other hand, a service must register itself with the lookup service, and in order to do so it must also first locate a service. The initial phase of both a client and a service is thus discovering a lookup service. The search for a lookup service can be done either by unicast or by multicast. In fact, the lookup service is just another
22
Jini service, but it is one that is specialized to store services and pass them on to clients looking for them. A LAN may have many lookup services including ‘Reggie’ supplied by Sun Microsystems. Reggie requires a HTTP daemon (Apache server) and an RMI daemon server, ‘rmid’. Jini also supplies its own server. There may be many lookup services in a network. Some even act as back-up service lookup.
The types of Lookup Discovery are as follows. Unicast discovery is a synchronous mechanism. Multicast discovery is an asynchronous mechanism that requires use of a listener to respond when a new service locator is discovered.
5.2. Unicast Discovery
Unicast discovery can be used when the client already knows the machine on which the lookup service resides, so it can ask for it directly. This is used for a lookup service that is outside of your local network, which one knows the address.
5.3. Broadcast Discovery
If the location of a lookup service is unknown, it is necessary to make a broadcast search for one. UDP supports a multicast mechanism, which the current implementations of Jini use. Because multicast is expensive in terms of network requirements, most routers block multicast packets. This usually restricts broadcast to a local area network, although this depends on the network configuration and the time-to-live (TTL) of the multicast packets.
There are a number of lookup services running on the network accessible to broadcast search. On a small network, such as a home network, there may be just a single lookup service, but in a large network there may be many - perhaps one or two
23
per department. Each one of these may choose to reply to a broadcast request. Services and clients search for lookup locators using the multicast protocol, by sending out packets as UDP data grams.
Groups:
Some services may be meant for anyone to use, but some may be more restricted in applicability. For example, the Engineering Dept may wish to keep lists of services specific to that department. This may include a departmental diary service, a departmental inventory, etc. The services themselves may be running anywhere in the organization, but the department would like to be able to store information about them and to locate them from their own lookup service. So there could be lookup services specifically for a particular group of services such as the Engineering Dept services, and others for the Publicity Dept services. Some lookup services may cater for more than one group - for example a company lookup service may want to hold information about all services running for all groups.
When a lookup service is started, it can be given a list of groups to act for as a command line parameter. A service may include such group information by giving a list of groups that it belongs too.
24
6. Entry Objects
6.1. Entry Class
When a service provider registers a service, it places a copy of the service object on the lookup service. This copy is an instance of an object, albeit in serialized form. The server can optionally register sets of attributes along with the service object. Each set is given by an instance of a type or class. So what is stored on each service locator is an instance of a class along with a set of attribute entries.
6.2. Restrictions on Entries
Entries are shipped around in marshaled form. Exported service objects are serialized, moved around and reconstituted as objects at some remote client. Entries are similarly serialized and moved around. However, when it comes to comparing them, this is usually done on the lookup service and they are not reconstituted on the lookup service.
7. Service Registration
A server for a service finds a service locator using unicast lookup with a Lookup Locator or multicast search using Lookup Discovery. In both cases, a Service Registrar object is returned to act as a proxy for the lookup service.
25
The registration object is created by the lookup service and is returned to run in the service provider. The registration acts as a proxy object to control the state maintained about the exported service object stored on the lookup service. Actually, this can be used to make changes to the entire Service Item stored on the lookup service. The registration maintains a field service ID, which is used to identify the Service Item on the lookup service. This can be retrieved by getServiceID () for reuse by the server if it needs to do so.
Lookup service Service provider
Figure 7.1: Objects in service registration
The major task of the server is then over. It will have successfully exported the service to a number of lookup services. If the exported service can do everything that the service needs to do, and does not need to maintain long-term registration, then the server can simply exit. More commonly, if the exported service object acts as a proxy and needs to communicate back to the service then the server can sleep so that it maintains existence of the service. If the service needs to be re-registered before timeout occurs then the server can also sleep in this situation.
7.1. Service Entries
Service object
Registration
Registrar
26
A service is unique in the world. It runs on a particular machine and performs certain tasks. However, it registers itself with many lookup services but it should have the same “identity” on all of these. In addition if either the service or one of these locators crashes or restarts, then this identity should be the same as before.
The ServiceID plays the role of unique identifier for a service. It is a 128-bit number generated in a pseudo-random manner. Services do not generate this identifier, as the actual algorithm is not a public method of any class. Instead, a lookup service should be used. When a service needs a new identifier, it registers with a lookup service using a null service id. The lookup service will then return a value. The first time a service starts, it asks for a service id from the first lookup service it registers with. It reuses this for registration with every other lookup service from then on.
8. Client Search
A client gets a Service Registrar object from the lookup service. Although each service is assigned a serviceID by a lookup service, a client may not know this. The serviceID is set to null in this case. If the client does know the serviceID then it can set the value to find the service.
If a client wishes to search for more than one match to a service request from a particular lookup service, then it specifies the maximum number of matches it would like returned by the max Matches parameter of the second for lookup () method. It gets back a Service Matches object. The number of
27
elements in items need not be the same as total matches. If the client is repeating a request, then it records the serviceID from an earlier request. The serviceID is a unique identifier so can be used to identify a service unambiguously. The service locator as a filter to quickly discard other services can use this. A client may want to find a service satisfying a number of interface requirements at once. If the match is successful, an object is returned that can be cast into the class required. Service methods can then be invoked on this object.
9. Leasing a Service9.1. Leases
Access to many of the services in the Jini system environment is lease based. A lease is a grant of guaranteed access over a time period. Each lease is negotiated between the user of the service and the provider of the service as part of the service protocol: A service is requested for some period; access is granted for some period, presumably taking the request period into account. If a lease is not renewed before it is freed—either because the resource is no longer needed, the client or network fails, or the lease is not permitted to be renewed—then both the user and the provider of the resource may conclude the resource can be freed. Leases are either exclusive or non-exclusive. Exclusive leases insure that no one else may take a lease on the resource during the period of the lease; non-exclusive leases allow multiple users to share a resource.
Leases are requested for a period of time. In distributed applications, there may be partial failures of the network or of components on this network. Leasing is a way for components to
28
register that they are alive, but for them to be timed out if they have failed, are unreachable, etc. In Jini, one use of leasing is for a service to request that a copy be kept on a lookup service for a certain length of time for delivery to clients on request.
The lookup service acts as the granter of the lease, and decides how long it will actually create the lease for. Once it has done that, it will attempt to ensure that the request is honored for that period of time. The lease is returned to the service, and is accessible through the method getLease () of the Service Registration object.
Locator Service
Figure 9.1: Objects in a leased system.
A service can cancel its lease by using cancel(). The lease communicates back to the lease management system on the lookup service, which cancels storage of the service.
When a lease expires, it does so silently. The lease granter (the lookup service) will not inform the lease-holder (the service) that it has expired. The service is in milliseconds. The expiration time is since the epoch, whereas the duration time is from the present. Leases are renewed and the manager functions quietly. However, the lookup service may decide not to renew a lease and will cause an exception to be thrown. This will allow the application to take corrective action if its lease is denied.
Exported
Service
Registra
Registrar
Lease
29
9.2. Granting and Handling Leases
A lease can be granted for almost any remote service, any one where one object wants to maintain information about another one which is not within the same virtual machine. Being remote, there are the added partial failure modes such as network crash, remote service crash, timeouts and so on. An object will want the remote service to keep “pinging” it periodically to say that it is still alive and wants the information kept. Without this periodic assurance, the object may conclude that the remote service has vanished or is somehow unreachable, and it should discard the information about it.
Leases are a very general mechanism for one service to have confidence in the existence of the other for a limited period. Being general, it allows a great deal of flexibility in use. Because of the possible variety of services, some parts of the Jini lease mechanisms cannot be given totally, and must be left as interfaces for applications to fill in. A lease is given as an interface and any agent that wishes to grant leases must implement this interface. Jini gives two implementations, an Abstract Lease and a subclass of this, a Landlord Lease.
A main issue in implementing a particular lease class lies in setting a policy for handling the initial request for a lease period, and in deciding what to do when a renewal request comes in. Some simple possibilities are
Always grant the requested time Ignore the requested time and always grant a
fixed time
Any particular lease will need a time-out mechanism. A group of leases can be managed together, and this can reduce the amount of overhead of managing individual leases.
Abstract Lease
30
An abstract lease gives a basic implementation of a lease that can almost be used for simple leases. This class, and those that depend on it are still not fully specified, and may change in future versions of Jini.
Landlord Lease
The “landlord” is a package to allow more complex leasing systems to be built. It is not part of the Jini specification, but is supplied as a set of classes and interfaces. The set is not complete in itself - some parts are left as interfaces, and need to have class implementations. These will be supplied by a particular application.
A landlord looks after a set of leases. Leases are identified to the landlord by a “cookie”, which is just some object that uniquely labels each lease to its landlord. A landlord does not need to create leases, as it can use a landlord lease factory to do this. When a lease wishes to cancel or renew itself, it asks its landlord to do it. A client is unlikely to ask the landlord directly, as it will only have been given a lease, not a landlord.
9.3. Lease Policy
A lease policy is used when a lease is first granted, and when it tries to renew itself. The time requested may be granted, modified or denied. A lease policy is specified by the Lease Policy interface. The operations that can be carried out on a lease are creation, renewal and cancellation. There may be many leases for a resource, or even many resources with one or more leases. Leasing allows resources to be managed without complex garbage collection mechanisms. Leases received from services can be dealt with easily using LeaseRenewalManager. Entities that need to hand out leases can use a system such as the landlord system to handle these leases.
31
10. Join Manager
Finding a lookup service involves a common series of steps. Subsequent interaction with them also involves common steps. A join manager encapsulates them into one convenience class for services.
Both services and clients need to find lookup locators. Services will register with these locators, and clients will query them for suitable services. Finding these lookup locators involves three components:
A list of Lookup Locators for unicast discovery. A list of groups for lookup locators using
multicast discovery. Listeners whose methods are invoked when a
service locator is found.
Jini 1.1, this has been extended to handle a set of unicast lookup services and a set of multicast lookup services. Jini 1.1 Helper Utilities defines three interfaces
DiscoveryGroupManagement which looks after groups and multicast search
DiscoveryLocatorManagement which looks after unicast discovery
Different classes may implement different combinations of these three interfaces.
An application (client or service) that wants to use a set of lookup services at fixed, known addresses and also to use whatever lookup services it can find by multicast can use the utility class LookupDiscoveryManager.
A service needs to locate lookup services and register the service with them. Locating services
32
can be done using the utility classes of “Discovery Management”. As each lookup service is discovered, it then registers, and the lease is maintained. The class Join Manager performs all of these tasks. There are a number of other methods in JoinManager, which allow one to modify the state of a service registration. A version of JoinManager was present in Jini 1.0. In moving from Jini 1.0 to Jini 1.1 the JoinManager classes are specified and moved to a new package. There are a number of possible constructors for JoinManager. It would appear to be unhelpful in supplying information about the lookup locators it finds. It is available, but by a slightly circuitous route.
A JoinManager can be used by a server to simplify many of the aspects of locating lookup services, registering one or more services and renewing leases for them.
11. SecurityThe design of the security model for Jini technology is built on the twin notions of a principal and an access control list. Jini services are accessed on behalf of some entity—the principal, which generally traces back to a particular user of the system. Services themselves may request access to other services based on the identity of the object that implements the service. Whether access to a service is allowed depends on the contents of an access control list that is associated with the object.
Security plays an important role in distributed systems. The Jini security model is based on the JDK 1.2 security system.
33
11.1. Quick Fix
Security for Jini is based on the JDK 1.2 security model. This makes use of a Security Manager to grant or deny access to resources. A few of the examples may work fine without a security manager. Most will require an appropriate security manager in place or RMI will be unable to download class files.
The security manager will need to make use of a security policy. This is given in policy files, which are in default locations or are specified to the Java runtime.
A totally permissive policy file can contain
grant { permission java.security.AllPermission "", "";};
This will allow all permissions, and should never be used outside of a test and development environment.
11.2. Why All Permission is Bad
Granting all permissions to everyone is a very trusting act, in the potentially hostile world of the Internet. The client is vulnerable to attack because it is downloading code that satisfies a request for a service, and then executing that code. The checks that it is a genuine service are really non-existent: it has to implement the requested interface, and maybe satisfy conditions on associated Entry objects. If it passes these, then it can do anything.
At the moment, there are no standard interfaces, so this may not be a feasible way of attacking many clients.11.3. Removing AllPermission
34
Setting the security access to AllPermission is easy and removes all possible security issues that may hinder development of a Jini application. But it leaves the system open, so that a more rigorous security policy at some stage is used, before others have damaged the system. The problem with moving away from this policy is that permissions are additive rather than subtractive. That is, one can't take permissions away from AllPermission, but have to start with an empty permission set and add to that.
Not giving enough permission can result in at least three cases:
A security-related exception can be thrown. This is comparatively easy to deal with, because the exception will tell what permission is being denied.
A security-related exception can be thrown but caught by some library object, which attempts to handle it. This happens within the multicast lookup methods, which make multicast requests. If this permission is denied it will be retried several times before giving up. This leads to a cumulative time delay before anything else can happen. The application may be able to continue, and will just suffer this time delay
A security-related exception can be thrown but caught by some library object and ignored. The application may be unable to continue in any rational way after this, and may just appear to hang. This may happen if network access is requested but denied, and then a thread waits for messages, which can never arrive. Or it may just get stuck in a loop...
35
11.4. JINI with Protection
The safest way for a Jini client or service to be part of a Jini federation is through abstinence: that is, refuse to take part. The JDK 1.2 security model allows a number of ways in which more permissive activity may take place:
1. Grant permission only for certain activities, such as socket access at various levels on particular ports, or access to certain files for reading, writing or execution grant {
permission java.net.SocketPermission "224.0.1.85", "connect, accept"; permission java.net.SocketPermission "*.edu.au:80", "connect";}
2. Grant access only to particular hosts, sub-domains or domains grant codebase "http://sunshade.dstc.edu.au/classes/" {
permission java.security.AllPermission "", "";}
3. Require digital signatures attached to code
grant signedBy "sysadmin" { permission java.security.AllPermission "", "";}
For any particular security access, one has to decide which of these is appropriate. This will depend on the overall security policy for the organization - and if the organization doesn't have such a policy that can be referred to then systems should not be exposed to the Internet.
36
In order to partake in a Jini federation, a service must become visible. A service needs to find a service locator before it can advertise its services. This can be by unicast to particular locations or by multicast. Unicast discovery does not need any particular permission to be set. The discovery can be done without any policy file needed. For the multicast case, the service must have Discovery Permission for each group that it is trying to join. The client is most at risk in the Jini environment. The service exports objects; the lookup locator stores objects, but does not “bring them to life” and execute any of their methods; but the client brings an external object into its address space and runs it using all of the permissions that it has as a process running in an operating system. So it runs under the permissions of a particular user, in a particular directory, with user access to the local file system and network. It could destroy files, make network connections to undesirable sites and download images from them, start processes to send obnoxious mail to anyone in the address book, and generally make a mess of someone’s electronic identity. A client using multicast search to find service locators will need to grant discovery permission and multicast announcement permission, just like the service. In addition to these, class definitions will probably need to be uploaded so that services can actually run in the client. This is the most serious risk area for the client, as the code contained in these class definitions will be run in the client, and any errors or malicious code will have their effect because of this.
A service is specified by an interface. In many cases, an RMI proxy will be delivered to the client, which implements this interface. Depending on the interface, this can be used by the client to attack the service. The security problems of the last section have been partly addressed by a tighter security mechanism introduced in JDK 1.3. These restrict what active services can do by using a security mechanism that is under the control of whoever starts rmid. This means that there has to be cooperation between whoever starts rmid and
37
the person who starts an active service that will use rmid. The simplest mechanism is to just turn the new security system off.
12. CORBA and JINI
CORBA is also an infrastructure for distributed systems. It allows specification of objects, which can be distributed. CORBA implements distributed objects rather than distributed services like Jini. The features of CORBA are
1. CORBA is language-independent, using an Interface Definition Language (IDL) for specification of interfaces.
2. CORBA objects can be implemented in a number of languages, including C, C++, Smalltalk and Java
Current versions of CORBA pass remote object references, rather than complete object instances. Each CORBA object lives within a server, and the object can only act within this server. This is more restricted than Jini, where an object can have instance data and class files sent to a remote location and execute there. This limitation in CORBA may change in future with pass by value parameters to methods
IDL is a language that allows the programmer to specify the interfaces of a distributed object system. The syntax is similar to C++, but does not include any implementation-level constructs. So it allows definitions of data types (such as structures and unions), constants, enumerated types, exceptions and interfaces. Within interfaces it allows declaration of attributes and operations (methods).
A Jini service exports a proxy object that acts within the client, on behalf of the service. On the service provider side there may be service backend objects, completing the service implementation. The proxy may be “fat” or “thin”, depending on circumstances. The proxy has to be thin, since all it does is pass on
38
requests to the service backend, which is linked to the hardware device. The service cannot move since it has to talk to a particular serial port, so the proxy is thin. Proxy objects created, as RMI proxies are similarly thin, just passing on method calls to the service backend, implemented as remote objects.
CORBA services can be delivered to any accessible client. Each service is limited to the server on which it is running, so they are essentially immobile. They can be found by a variety of methods, such as a CORBA naming or trading service. Any client, anywhere can run these search methods. A search will return a reference to a remote object, which is essentially a thin proxy to the CORBA service. Similarly, if a CORBA method call creates and returns an object, then it will return a remote reference to that object which will continue to exist on the server where it was created. The simplest way to make a CORBA object available to a Jini federation is to build a Jini service that is at the same time a CORBA client. The service acts as a bridge between the two protocols.
ConclusionSun’s Jini technology provides open, end-to-end solutions for creating dynamically networked products, services, and applications that scale from devices to the enterprise. This technology enables developers, service providers, and content creators to gain a competitive business advantage and capitalize on new revenue streams, by rapidly and cost-effectively developing and deploying compelling new applications and services for their customers worldwide. All of Sun’s technologies, including Jini, are developed with industry collaboration, allowing more widespread innovation and providing a standards-based platform.
39
Because Jini technology addresses problems that only some companies are experiencing, the requirement for this technology is not always readily apparent. For the increasing number of companies that are already hitting the problems of scale, component integration, and ad-hoc networking, especially in the financial, automotive, and telecommunications industries, Jini technology is the premier solution available today.
References
Core Jini. By W. Keith Edwards.
Jan Newmarch's Guide to JINI Technologies
40
The Jini Architecture: Dynamic Services in a flexible network, by Ken Arnold, Annual ACM, IEEE Design Automation Conference, Preceding of the 36th ACM/IEEE conference on Design, June 21-25, 1999.
The Jini Architecture for network centric-computing, by Jim Waldo, Communications of ACM Volume 42, Issue 7, 1999
JINI: Towards Seamless Connectivity of Hardware Devices and Software Services, Gilda Pour, The Proceedings of the: Technology of Object-Oriented Languages and Systems (TOOLS 34’00), IEEE
Sun Microsystems posts product information such as data sheets, specifications, and white papers on its Web site at www.sun.com. For more information on JINI’s architecture, go to www.sun.com/jini.
For additional information on JINI its technology, material is available at:
41
