8.1. Introduction
Before we introduce DA, let's revisit our overall architectural makeup and zoom in on the details made important by accessing devices on the native platform.
8.1.1. The Software Stack in Device Access
To access physical devices, applications written in the Java programming language need to go through several layers of indirection. Through the JNI, they can talk to the underlying operating system, which can communicate with the hardware through device drivers. Figure 8.1 shows a few possibilities for bundles to access the devices in an OSGi framework.
Figure 8.1. Accessing hardware devices from bundles C1 and C2 before DA enters the picture
A client bundle such as C1 can either interact with a device service provided by bundle D1, which turns around and talks to a library L as part of the Java platform, or it may talk to the API exposed by L directly. A typical example of such a library is the standard Java™ Communications API defined in the javax.comm package that allows programs to access the serial and parallel ports. The library has a wrapper interfacing callers from the Java platform on one side and uses the JNI to engage the native driver on the other side.
Another client bundle such as C2 can interact with a device service provided by bundle D2, which includes both the device service written in the Java programming language and the native code to access the driver. This is exactly what we showed in the native code example in Chapter 4.
From the client bundle's perspective, it generally accesses the device through a service provided by another bundle (we show the service as “Device Service” in Figure 8.1; the precise definition is forthcoming). This is highly desirable because it makes accessing a device no more different from getting and calling any service in the OSGi framework.
8.1.2. What Device Access Is Not
To understand what DA is, it may be illuminating first to understand what it is not. The mere name may conjure up misconceptions, which warrant clarification up front.
DA is not about writing low-level device drivers. Device drivers, the software that enables applications to access physical devices, are usually part of the operating system. Because they serve as the bridges between software and hardware, they are highly specific to the native platforms and are mostly written in programming languages such as C or assembly. Additionally, configuration at the operating system level is almost always required to have the newly installed driver take effect. For example, to install an Ethernet card driver on your PC, you usually need to run a setup utility provided by the vendor. The utility probably updates Windows registry entries, installs software files onto system directories, and requires you to reboot the computer.
DA is part of the OSGi solution using the Java platform, and the Java programming language, designed specifically to be platform neutral, is not well suited to deal with the functional and operational aspects just described. Therefore, DA is not designed to facilitate writing or deploying low-level device drivers. Mostly, DA expects the native drivers to have been installed and configured beforehand.
DA is not about programming any particular device interfaces or protocols. Based on your application requirements and hardware capabilities, you may want to write software that communicates with devices through a USB interface, or exchanges data using FireWire, or talks to mobile phones with BlueTooth. DA is agnostic to the particulars of these protocols, and is designed to accommodate them all.
DA is not another Jini technology or UPnP. Jini technology and UPnP are designed to enable interconnectivity and interoperability of any device. They offer mechanisms for a device to discover another's presence and capabilities dynamically, so that they can utilize each other's functionality. DA does not favor one or the other and does not aim to solve as broad a class of problems. Potentially it may take advantage of both or either within its architecture.
The device access emphasizes “access,” and not so much “device.” We already have numerous types of devices as well as interfacing and connecting technologies. DA attempts to integrate them in one coherent framework as specified by the OSGi consortium.