DA.1. Introduction

The Jini technology infrastructure is built around the model of clients looking for services. The notion of a service encompasses access to information, computation, software that performs particular tasks, and in general any component that helps a user accomplish some goal. Services can themselves be clients of other services, and can be grouped together to provide higher-level functionality.

The Jini architecture requires a service to be defined in terms of a data type for the Java programming language that can then be implemented in different ways by different instances of the service. A service can be a member of many different types, allowing a single service instance to provide a variety of functionality to clients. This is a standard practice in object-oriented software. However, the distributed nature of a system of Jini technology-enabled services and/or devices allows data types for the Java programming language to be implemented in a combination of software and hardware in a way that is unique.

The core of the idea that enables this implementation flexibility is quite simple. Services are defined via an interface, and the implementation of a proxy supporting the interface that will be seen by the service client will be uploaded into the lookup service by the service provider. This implementation is then downloaded into the client as part of that client finding the service. This service-specific implementation needs to be code written in the Java programming language (to ensure portability). However, since this code comes from the actual instance of the service being used, it can know in great detail the specifics of the particular service implementation for which it is the proxy. Not only can the code that is downloaded know about the software used to implement the service, the code can know specifics about the hardware on which the service resides. In the limit case of this, the hardware could be all that there is to the service, and the downloaded software could act as a network-level device driver, taking method calls in the Java programming language from the client and generating specific, hard-coded requests to the hardware on the other end of the network wire.

This approach to services requires that there be a piece of code written in the Java programming language that can be downloaded by the client of the service and some hardware that ultimately runs the service. Between these two points, however, there are a number of options concerning the software structure, hardware structure, and location of components that can be chosen by the service provider. These options allow trade-offs to be made in the functionality provided and the cost of the underlying hardware.

In what follows we begin by discussing in more detail the requirements placed on a service to be part of a system of Jini technology-enabled services and/ or devices. We then discuss some examples of combinations of software and hardware that can be used to implement Jini technology-capable services once the specialized implementations in hardware begin to play a role.

DA.1.1. Requirements from the Jini Lookup Service

The actual offering of a service places very few requirements on the entity that makes the offer; indeed, it is possible to implement a device using a Jini technology-enabled software services that offers a service in such a way that the code written in the Java programming language that is downloaded by the client transmits bit patterns to the hardware that are directly interpreted. In such cases the amount of intelligence needed for a a Jini technology-enabled device is minimal. The code written in the Java programming language could talk directly to the device controller in much the same way that the device would be talked to if it were on the local computer’s bus (with, of course, some modifications for dealing with the network-centric aspects of the communication).

Unfortunately, providing a service is only part of what is needed to be a Jini technology-enabled service. To be part of a system of Jini technology-enabled services and/or devices, a service must also be able to participate in the Jini discovery protocol and register itself into the local Jini lookup service. This is how a service makes itself known to the djinn, and how the service is accessed by other members of the djinn.

These two requirements are intimately connected. The major goal of the Jini discovery protocol is to allow a device or service to obtain a Java Remote Method Invocation (RMI) reference to the local Jini lookup service. Once this reference has been obtained, the service needs to register itself in that Jini lookup service, allowing other participants in the djinn to find and use the service.

The interface to the Jini lookup service is a full RMI interface, and the implementation of that service uses all of the mechanisms of RMI, including the distributed garbage collection and the dynamic downloading of code. As such, there is an implicit assumption that the service that holds a reference to the Jini lookup service lives inside a full Java virtual machine (JVM) that is at least capable of running the full RMI system.

This assumption is most evident if we consider the possibility of alternate implementations of the Jini lookup service, which might support remote interfaces beyond that specified by the Jini lookup service itself (currently the interface net.jini.core.lookup.ServiceRegistrar). Such an implementation would have a different RMI proxy than the current implementation, which would be downloaded if the device had a full JVM and RMI runtime. Devices without a full JVM and RMI runtime would need a different way of dealing with such implementations of the service.

In addition to the need to download the stub code for the Jini lookup service, registering with the service requires the creation of an object of type net.jini.core.lookup.ServiceItem, which is itself made up of a set of objects in the Java programming language. Maintenance of these entries in the Jini lookup service can require the creation of other objects in the Java programming language of the type net.jini.core.entry.Entry. All of these objects are most easily constructed by using a running JVM.

Finally, registrations with the Jini lookup service are leased, with the lease that is returned requiring renewal for the service to continue to be shown in the lookup service. The specification of the lookup service does not include a specification of the lease object that is returned by a registration. All that is specified is an interface written in the Java programming language that must be supported by the (local) object that is returned as the lease. Thus the design of the Jini lookup service requires that the code that implements the class that in turn implements the net.jini.core.lease.Lease interface be downloaded into the service that registers so that the lease can be renewed.