UNDER THE HOOD
The first release of the OSGi specification is a Java-based application layer framework that gives service providers, network operators, device makers, and appliance manufacturers vendor-neutral application and device layer APIs and functions. The main reason for choosing Java is because it is an open technology that can run on multiple platforms including services gateways, consumer electronics equipment, household appliances, communications appliances, computers, and more. The following sections provide additional technical details on key entities of the OSGi framework.
Java
To ensure a large target market for third-party service developers as well as a large selection of compatible services for gateway operators, OSGi specifies API standards for the gateway platform execution environment. Gateways must support these API standards in order to be compliant with the OSGi specifications. For a Java-based gateway, the APIs are based on the Java 2 package and class definitions. The goal is to allow implementations of service gateways to be based on Personal Java (PJava) as well as on versions of Java 2 Micro Edition (J2ME) and other compatible Java runtime environments. The following sections provide additional technical details on these two runtime environments.
Personal Java
Personal Java, or PJava, is an application development and middleware environment developed by Sun Microsystems. It is designed for a myriad of consumer devices, such as network computers, smart telephones, game consoles, and TV set-top boxes. It executes software written in the Java programming language. PJava comprises a lightweight version of the JVM, a set of core libraries, and optional libraries that may be used as needed.
J2ME
J2ME is a new edition of the Java 2 platform targeted at consumer electronics and embedded devices. J2ME consists of a virtual machine and a minimal layer of APIs targeted at providing only enough functionality to securely and safely download Java classes to a device and configure the Java environment. J2ME comes in two flavors, called configurations, that are targeted at two broad categories of devices: (a) those with 128 to 512 KB of memory available for the Java environment (and applications) and (b) those with 512 KB+ available for the Java environment (and applications).
If you are looking for more technical detail on both of these environments, we suggest visiting Sun's Web site at http://www.sun.com.
Services
A service is a self-contained component, accessible via a defined service interface. In the OSGi model, an application is built around a set of cooperating services. The framework maintains a set of mappings from services to their implementations and has a simple query mechanism that enables an installed service to request and use the available services. After a service is published, other services can use it to accomplish their tasks. From a development perspective, the OSGi specification has decoupled a service's interface from its implementation. This point is critical for the development community because OSGi is designed to run in a variety of different gateway devices. Each one of these gateways will have different hardware characteristics, which could affect many aspects of the service implementation. The availability of a stable interface to developers will ensure the overall stability of the software system running on the device.
Bundles
Service implementations are packaged into bundles. A bundle is a file that:
Contains the resources implementing zero or more services. These resources may be class files for the Java programming language, as well as any other data (such as HTML help files, icons, and so on)
Contains a manifest file with headers specifying various parameters so that the Java environment can correctly install and activate the bundle
When the OSGi framework is started on the gateway, an initial bundle that usually assumes administrative roles must be created, installed, and activated; it in turn manages the lifecycle of other bundles, which can be installed, started, updated, stopped, and uninstalled. The relationship between the OSGi framework and its installed bundles is captured by the notion of a bundle context. Each time a bundle is installed, a unique bundle context is created for it.
Events
The OSGi framework is capable of generating three different kinds of events:
The ServiceEvent is used to report registration, unregistration, or property changes for services
The BundleEvent report changes in the life-cycle of bundles
The FrameWorkEvent reports that the framework itself has started and lists any errors that were encountered during the starting process
For each kind of event, there is a corresponding listener interface.
Java-Embedded Server (JES)
JES is a small-footprint application server for use within remote networkable devices. It allows devices to upload, download, activate, and deploy customized home services and applications on demand. From a technical perspective, JES consists of two primary components: a servicespace framework and a number of modular in-home services that are executed within this framework. The relationships between these two JES components are shown in Figure 17.2, and explained in the following subsections.
Servicespace
Originally developed by Sun Microsystems, this service framework allows programmers to write Java-based applications as independent components that can be managed independently of one another and can be dynamically added, removed, executed, or updated from within a running application. The framework provides a rich and structured development platform for component-based software architectures and takes advantage of Java's ability to download code from a broadband or dial-up network.
The servicespace framework requires only 100KB of memory and a Java runtime platform such as PJava.
Figure 17.2. JES Technology architecture
Services
Home Applications that run in the JES are called application services. JES comes with a set of prebuilt services that address a variety of common requirements for networked homes. Core services include:
HTTP Service
The Internet homes of the future will allow consumers to activate their gateways from anywhere in the world. Such an environment will be based on Web protocols, so an API has been defined by OSGi for an HTTP-based Web server that runs as part of the services gateway device. This lightweight HTTP service provides a complete embedded Web server, which may be used by developers to build a Web interface to devices on a home network. Additionally, this HTTP API provides consumers with the ability to publish content on the Web.
Servlets
Servlets can be thought of as server-side versions of Java applets that extend the functionality of Web servers. JES provides support for execution of Java servlets.
Remote Management
The remote management service supports remote management of application services resident on the device. The remote management service can be integrated with enterprise management systems, such as IBM Tivoli and CA Unicenter.
SNMP
The Simple Network Management Protocol (SNMP) agent service facilitates management and monitoring of the gateway device.
Scheduler
The time-based scheduling service can be used to automatically activate an application service to run at a particular time of the day or night.
Logging
The logging service defines a standard API that allows OSGi home networking services to write events to a log file on the gateway. The facility of a log file helps developers and service providers to resolve gateway problems. Following are some of the features of the OSGi:
Records the current system time in the log entry
Records a severity level in the log entry
Records a text message in the log entry
Records an optional Java object in the log entry
Records the identity of the Java program running in the service framework that created the log entry
Listens to Framework events and creates log entries representing these events
Reads past log entries via an enumeration
Notifies listeners of log entries as the entries are created
Gateway implementers are free to construct the log service in a variety of ways depending on the capabilities of the gateway, including spooling to a local log file on a hard disk or transferring to a remote management server.
Remote Method Invocation (RMI)
RMI is a set of protocols being developed by Sun's JavaSoft division that enable Java objects to communicate remotely with other Java objects.
Console
The console service provides an administrative console for JES. This console could appear on any type of display unit such as a television screen or a standard PC monitor.
Device Access Systems
The OSGi device access system has a number of goals, including:
It must support plugging and unplugging of home networking devices at any time
It must cope with device technologies that do not support automatic detection
It must be capable of loading new device drivers on demand with no prior specific knowledge
It needs to support mixed network technologies
It needs to support multifunction devices and devices that have multiple configurations
The device access system consists of a set of drivers and a device manager.
Device Drivers
The OSGi device access system is independent of home network infrastructures and in-home devices. New devices or network topologies will simply require new device drivers. Device drivers are third-party software and are typically provided by device manufacturers. Device drivers fall into two different categories: (a) those that directly manage native hardware on the gateway, and (b) those that connect to other device services.
When a driver is started by a gateway it immediately registers a service and remains registered with the OSGi framework for as long as the driver is running. Each device driver has a unique identification number.
Device Access Manager
One of the device access manager's primary functions is to dynamically load services for appliances that are connected to the services gateway. In addition to controlling drivers, the device access manager, where possible, is able to detect the addition of new in-home devices, and then locate and load supporting software modules with a minimum of user interaction. Finally, the device manager can be configured to support devices that do not contain OSGi specific functionality (i.e., appliances that were designed prior to the OSGi specification release). It is also worth noting that the device access system is an optional component of OSGi. The easiest way to understand how the device access manager works is to look at a short example. Let's take a simple device discovery system, such as attaching an IEEE 1394-enabled camera to the gateway. In the following scenario, we can assume that the 1394 driver is fully operational. When a consumer attaches their IEEE 1394-enabled camera to their gateway the following sequence of events takes place:
The camera is connected to the gateway and the IEEE 1394 detects the new hardware device
It queries the camera to obtain a 1394 descriptor
It registers a 1394 device service together with the properties describing it
The device manager detects the camera through its service listener
The device manager then queries all running drivers trying to identify a driver that matches the digital camera
The level of suitability is collected by the device manager and selects the driver that returned the highest value
The new driver than calls the camera service and attaches to it
If no driver is available for the camera, the device manager displays a message informing the user that the gateway does not support connectivity with the digital camera.
Optional Services
In addition to the required services, OSGi is also defining a number of optional services. We briefly explore these forms of communication in the following subsections.
Client Access Service
In a live home networking environment, there will be occasions where family members will need to interact with the gateway. The client access service API provides developers with a framework for managing these interactions. Typical interactions between a home network user and the gateway range from viewing operational information to making modifications to configuration parameters. This advanced API supports URL name space management, which goes beyond the basic facilities provided by the HTTP service. Other features include full support for negotiation of different types of data formats ranging from mobile phones to standard PC browsers.
Configuration Data Service
Many of the services loaded and running in a gateway need additional information to perform their day-to-day tasks. This information can be as simple as a list of authorized appliances or as complex as personalized user profiles. To access this information, OSGi has defined a common service API for services to store and access this data. This allows the gateway operator or service provider to remotely change the configuration of the in-home gateway.
Persistent Data Service
Many of the services running on a gateway will need to store and retrieve information that persists beyond the life of the service and that can be shared with other services. So rather than developing code for reading and writing information to the file system for each in-home service, OSGi provides a common persistent data service that can be used by other services to store and retrieve data. This API has a number of features, including:
A high-level query language to search the persistent information store
Recovery from partial updates
Ability to synchronize the data with databases located on servers