DA.2. Basic Device Architecture Examples

NOW we will look at three different approaches for implementing a a Jini technology-enabled service in hardware. Each of the approaches will look the same to a client of the service. Each approach takes a different route to interacting with the Jini lookup service and in providing an interface written in the Java programming language to clients of that service. In each case, a different trade-off was made between the complexity of the device, the flexibility of the device, and the directness of the communication between the client wanting to use the service and the device that implements the service.

All but the first of the examples make use of interposition, that is, the ability of a service to add a proxy between itself and the client of the service. The service can use this proxy as an agent to the Jini technology infrastructure, off-loading from the service some of the work needed to join the federation of Jini technology-enabled services and/or devices.

The examples given in this chapter are not the only options available to the service designer who wishes to produce a service that includes a hardware component. Rather, the examples are meant to show some samples of the range of implementation possibilities that are open to such designers. In effect, this document is meant to show that, within the overall Jini architecture, there is no single Jini device architecture. Instead, the device space is freed up, allowing different services to have hardware implementations with different price, performance, functionality, and flexibility design points.

DA.2.1. Devices with Resident Java Virtual Machines

An obvious design for a device that can become part of a federation of Jini technology-enabled services and/or devices is one that includes the computing power, memory, and nonvolatile store necessary to have a full JVM and those parts of the Java application environment necessary to support the Jini technology infrastructure (in particular, those parts needed for code loading, RMI, and any required security). This would make the device into a specialized computing entity, with part of the device dedicated to the parts of the Java platform required by the Jini architecture. On this approach, the hardware implementation is abstracted behind a device-local software abstraction, which in turn is abstracted behind the proxy code used by the client to contact the service. This sort of architecture is shown in Figure DA.2.1.

Such a device would be able to make full use of Jini technology and Java technology, uploading code that is used to communicate with the device and downloading code that might be needed for the service provided by the device. Such a device can make use of the native RMI protocol for communication over the network, and has a loose tie between the communication protocol and the particular software protocol governing the running of the device itself. On this approach, the device becomes a specialized network appliance offering a particular service (or set of services) via an embedded Java platform.

In effect, this approach uses a hardware implementation for the local implementation of an RMI server, isolating the hardware behind two levels of indirection. The first is that provided by the local proxy code that is uploaded into the Jini lookup service and then downloaded into the client of the service. Additionally, the local JVM and code written in the Java programming language resident on the service device allow mediation between the client proxy and the hardware itself.

A device that took this approach could easily have multiple services implemented on the device in a way that was mediated by the JVM on the device. Further, such a device could be evolved with no impact on the client or the network protocol used between the client and the service, since any change in the hardware would be seen only by the JVM and any server-side code that talked directly to the hardware.

While simple and flexible, this approach does add some cost to the device. In particular, the device would need to have a microprocessor capable of running the JVM, some memory in which to create and store classes, and some nonvolatile store (either disk or NVRAM) from which to load the JVM and Java class files. All of these are in addition to the hardware needed to implement the a Jini technology-enabled service that the device provides. This extra hardware will increase the cost of producing the device.

Meeting these requirements does not call for a hosted version of the JVM or a full version of the Java platform running on the device. The JVM could run on any form of microkernel or directly on the hardware of the device. Further, there are large parts of the Java platform that would not be required for the minimal device—such things as the graphics and user interface classes, which form a significant chunk of the current release, would not be needed. Other parts of that release could also be dropped, allowing a stripped-down Java platform to suffice for Jini technology-enabled devices. It would be worthwhile to determine the exact definition of such a subset of the Java platform and size that component; it would be something close to the definition of embedded Java technology with the additional classes needed to support RMI.

What is important for this kind of approach is for the device to be able to download any code written in the Java programming language (although whether that code is run could depend on the local security manager), utilize the RMI communication system, and handle the requirements of a general virtual machine. By presenting a standard JVM, the device gets full membership in a federation of Jini technology-enabled services and/or devices and complete flexibility in the ways in which the machine communicates between the proxy it provides other members of the federation and the device itself.

DA.2.2. Devices Using Specialized Virtual Machines

We can lower the barrier to entry for a device manufacturer if that manufacturer is willing to give up some of the flexibility provided by the Jini architecture. This can be done by allowing the device to become part of a Jini system of services and/or devices using Jini technology with a specialized virtual machine that is tuned to allow only those operations needed by the Jini discovery protocol and Jini lookup service.

To do this, the device manufacturer would need to implement the interfaces to the Jini discovery and Jini lookup service in the device itself, include specialized knowledge of the kind of leases that are handed out by the Jini lookup service and be able to renew those leases directly, and have sufficient functionality to download and use the stubs for these services. This is a particular set of functionalities that is considerably smaller than that required by the whole of the JVM, and should be possible to implement in much less code. For example, such a JVM would not need to contain a security manager, a code verifier, or a number of the other components that are required for a full JVM.

Such a device would contain a JVM specialized for the application environment for Jini technology, allowing the Jini discovery and Jini lookup services to be accessed and leases of a particular sort to be renewed. This would limit the flexibility of such a device, as the device would not be able to have software changes made over time to the protocol used by the proxy for the device. The specialized knowledge of the kind of lease that is handed out by the lookup service would also tie such a device to a particular implementation of the lookup service. However, this penalty in serviceability might not outweigh the simplicity of the overall device.

DA.2.3. Clustering Devices with a Shared Virtual Machine (Physical Option)

A third approach uses a full JVM, but amortizes the cost of the JVM (both software and hardware) over a number of different devices. In this approach, a group of devices each uses a physically co-located JVM as an intermediate layer between the device and the system of services and/or devices using Jini technology. The device loads code written in the Java programming language into this local virtual machine, allowing that local machine to interact with the device, and then delegates to the local JVM the requirements of interacting with the Jini lookup service, Jini discovery, and Jini leasing.

This approach is very much like the first one discussed in this section, except that the JVM used by the devices is shared. It is still a full JVM, allowing the downloading of code and complete Java platform functionality. However, the most likely implementation of such a device would allow multiple (and perhaps different) kinds of physical devices to be plugged into the overall device to get the sharing of the Java application environment.

Such a device might best be thought of as a “Jini device bay.” This bay could provide power, a network connection, and a processor running a JVM and appro priate parts of the Java platform. Physical devices that are used to provide a particular kind of Jini technology-enabled service could be plugged into the device bay and announce themselves to the bay in whatever way the two decided was appropriate. This could be using a proprietary protocol (allowing a device manufacturer to produce both the basic device or devices and the device bay) or some other industry standard, local-device identification scheme.

As part of the local announcement, a new device would tell the device bay where to find the code written in the Java programming language that is needed by a client of the service, and (possibly) where to find code that would allow the device bay to interact with the device. This allows devices to carry their own “drivers,” both for the local machine and at the network level.

Upon detection of the new local device, the Jini technology-enabled device bay would register the services provided by the new device (previously known by the device bay) with the Jini lookup service. It would be the role of the device bay to renew leases on the Jini lookup service entries, and to detect removal of any of the devices for which it was acting as proxy. The device bay would provide the Jini lookup service with the code handed to it by the device so that service clients could download that code.

The client of the device service would believe that it is talking to the device registered in the Jini lookup service, but would actually be talking to the device bay. The device bay would act as a dispatcher to the particular device for which it was acting as a proxy, along with any translation of protocol between the network protocol used by the service proxy and the protocol used between the device bay and the actual device. Graphically, the architecture of such an approach is shown in Figure DA.2.2.

The savings for the device manufacturer in this case comes from the ability of multiple physical devices to share a device bay, which contains the intelligence, memory, and perhaps other components (such as the power supply). By sharing these resources among multiple devices, the extra cost and engineering needed to interact with a system of services and/or devices using Jini technology can be amortized over a large number of devices.

The cost of this approach to the device manufacturers is that the protocol between the device acting as the Jini technology-enabled device bay and the devices that are placed in that bay must be defined in advance and cannot change over time. Because there is no way of introducing dynamic behavior in the particular devices, the pairing of device and Jini technology-enabled device bay must be controlled and known beforehand.

It should be noted that the Jini technology-enabled device bay itself is a Jini technology-enabled device, which can be thought of as providing services to those devices housed within it. As such, it could be a revenue item in its own right. Variations in the implementation could be provided to support various internal announcement protocols (device bay, jetsend, etc.) or hardware buses (including network-like buses such as firewire).

DA.2.4. Clustering Devices with a Shared Virtual Machine (Network Option)

A variation on the device bay approach uses the network rather than a physical enclosure and backplane. On this alternative, a proxy for the JVM used by the various service devices would exist on the network. Service devices could be added to the network, discover the existence of such a proxy device, and register with that proxy. Such a registration could include the code written in the Java programming language needed by a client of the device (either directly or as a URL to use to obtain the code) and code needed by the proxy to communicate with the service device.

When a service device registers with such a network proxy, the proxy device would register with the Jini lookup service on behalf of the service device, thus allowing the service device to become a part of the federation of Jini technology-enabled services and/or devices. Requests to the new service would go first to the proxy for that device, which could then forward the requests (after appropriate protocol translation) to the particular service device. In addition, the proxy could handle the Jini technology-specific tasks such as renewing leases for the service. This alternative is shown in Figure DA.2.3.

This alternative requires somewhat more hardware for the individual device, as it requires each service device using such a proxy to be able to be placed on the network and have its own power supply and network connection. However, the devices would not need individual CPUs, memory, or persistent store; all of that would be provided by the networked proxy for the Jini technology-enabled device.

Devices using this option would need to have a protocol parallel to the Jini discovery protocol between the individual service devices and the network proxy for those devices. This could be a specialized code on the network, known in advance, that the devices can use to identify themselves to the network proxy. This will have to be particular to the device and the proxy for that device. However, once this protocol has been decided upon, no other intelligence needs to be built into the device. All of the intelligence can be built into the network proxy, perhaps uploaded into the proxy by the service device (which could easily carry code written in the Java programming language, even though it cannot execute that code). The protocol the network proxy uses to talk to the devices for which it is a proxy also needs to be statically defined in advance and cannot be changed. However, it can be any protocol the particular device needs.

In this approach, the individual devices will be more complex than they would be in the Jini technology-enabled device bay approach. However, the number of devices that can be served by a network available proxy is not limited by the physical constraints of the proxy device. Nor is there any requirement that the devices and the proxy device be co-located, which is a requirement on the physical clustering scheme.

This is also the approach that can be taken to build “gateways” between the Jini technology-enabled devices and other network-managed devices. Such devices, which already speak a particular protocol, can be spliced into the system of Jini technology-enabled services and/or devices by providing a network proxy that speaks the Jini technology protocols on behalf of such devices, and the existing specialized protocol to such devices. This is the approach that can be used to add consumer electronic devices, factory controls, or home environment controls into the system of Jini technology-enabled services and/or devices.

DA.2.5. Jini Technology-Enabled Software Services over the Internet Inter-Operability Protocol

A final method for connecting devices or services that are not purely based on Java technology software into a system of Jini technology-enabled services and/or devices, centers on using the Object Management Group (OMG)’s Internet Inter-Operability Protocol (IIOP). This protocol defines a standard for data transmission that will be supported by a subset of RMI.

This approach relies on the ability of a device to read an IIOP stream directly, either because the device includes an implementation of a Common Object Request Broker Architecture (CORBA) Object Request Broker (ORB) or because the device knows what IIOP streams to expect and can interpret streams of these known forms directly.

This approach requires the Jini lookup service to supply implementations of its interfaces over both the native RMI protocol and the IIOP protocol. This is supported by RMI over IIOP as long as the interfaces conform to any subsetting requirements established by the OMG. At the present time it appears that the Jini lookup service interfaces are in conformance with the RMI over IIOP subset.

Devices that contain a CORBA ORB could directly interact with the Jini lookup service using the IIOP protocol. The fact that the Jini lookup service gener ated this protocol via RMI would be transparent to the service itself, and the fact that the service was using a method other than RMI to reply to the Jini lookup service (to renew leases, for example) would be transparent to the Jini lookup service. Current differences between the RMI programming model and the CORBA programming model would need to be dealt with by the device itself; for example, the device would not be able to download the implementation of the stub for the Jini lookup service, and would need an implementation of the Lease class used by the Jini lookup service.

Devices that do not include a CORBA ORB could directly interpret the IIOP stream and attempt to interact with the Jini lookup service. This approach requires very little software support on the side of the device (since the bitstream from the wire is being directly interpreted). However, it is an approach that will work only with known versions of the Jini lookup service that exports known implementations of a lease. Any alteration of either the lease implementation or the protocol used by the Jini lookup service, even those that would be invisible to other clients of the service, would make it impossible for the device directly interpreting the IIOP protocol to interact with the new version of the service. Hence this alternative, while lowest in cost with respect to the hardware and software needed by the device, is also the least reliable in the face of implementations that can change over time or that are open to alternate implementations.