The service gateway is a key element in making home networking a coherent environment that will facilitate the development and deployment of a wide range of advanced network-based services. The service gateway, which is secure and needs no local administration, serves as a bridge that connects the service provider's network to LAN and client devices within the home or small office/home office (Soho) or remote office/ branch office (Robo). Thus, the service gateway separates the topology of the WAN and the internal network.
Services such as energy management, security and home automation are delivered from the external network to the service gateway or internal clients such as Internet-ready personal digital assistants (PDAs), Web-browsing TV sets, smart phones and other information appliances. For example, energy management services may provide automated metering, remote control and optimized home energy use. In this scenario, the service gateway would act as a coordination point to allow several different device technologies to interact and be managed from a utility's central office.
Security services, meanwhile, would offer remote monitoring and control using the standard Web infrastructure. In this case, the gateway would be the focal point for connecting the central office security systems to the individual equipment on customer premises.
Home automation services, on the other hand, provide a centralized point for automating home entertainment and utility systems. Here, the gateway would provide an integration and management point to deploy and manage devices that potentially have different characteristics. For instance, the Home Audio and Video Interoperability (HAVi) standard defines application programming interfaces that use IEEE 1394 as the connection mechanism, so that HAVi-enabled devices like digital video disks and camcorders can interact with each other. Sun's Jini connection technology also enables the connection of home appliances to the external network. A service gateway can serve as the unified gateway connecting both HAVi-enabled and Jini technology-enabled home appliances to the Internet.
If the concept of the service gateway is to be implemented widely, then industry agreement on a set of standard specifications is required. To this end, the Open Services Gateway Initiative (OSGi) was formed as a cross-industry working group to define a set of APIs and provide a reference implementation for a service gateway architecture. OSGi's Java Expert Group is charged with specifying Java technology-based APIs.
The OSGi specification includes APIs for service cradle-to-grave life-cycle management, interservice dependencies, data management, device management, client access, resource management and security. Using these APIs, clients load network-based services on demand from the service provider. The service gateway manages the installation, configuration, and software and the hardware version control. These APIs are split into a set of core and optional APIs.
Where possible, the OSGi leverages existing Java standards such as Jini technology and Java Database Connection. When the service gateway must interact with devices based on non-Java standards, such as 1394, one approach is to enable effective integration with these standards, for example, via bridging technologies.
Although the exact characteristics of a gateway will vary widely from market to market, a typical service gateway has at least seven essential characteristics. It requires zero administration; it is memory constrained; it has limited compute capability; it typically has no monitor; there is often no end-user interaction; it typically uses a service aggregator as the source for services; and the configuration varies greatly based on target and business model. Just as the configuration of gateways varies, so too does the end-to-end architecture of a complete service delivery solution.
The technical foundation for OSGi is a Java-based lightweight framework called ServiceSpace. Originally developed by Sun Microsystems as part of the Java Embedded Server, this service framework allows programmers to write applications as independent components that can be managed independently of one another and can be dynamically added, removed or updated from within a running application.
The ServiceSpace framework is centered on the dynamic management of software components. The framework allows new components to be downloaded and installed or uninstalled from the network as needed, and it supports dependencies across these components. For example, a component downloaded from a given Web site will be able to interact with a component downloaded from another site. Also, the open framework supports the deployment of any components and therefore does not constrain what these components do. Nevertheless, network and system security are important issues when services can be downloaded from remote sites over unprotected networks.
ServiceSpace uses the notion of interface in the Java programming language to define contracts, so software components with different origins can collaborate with one another in a well-defined manner. In fact, these software components offer services to each other. A service is defined by the set of contracts it honors. If honoring a contract requires supporting another contract, then this second contract is also part of the contracts that the service must honor.
To allow the software to interface, ServiceSpace maintains a service registry in which an application can register those services they provide. Each service is registered with a name that has two parts. One is the fully qualified class name representing the service. The other part uses different names to distinguish multiple implementations of the same service. ServiceSpace uses the concept of bundles as a packaging unit for a service. A bundle is simply a jar file containing a set of service definitions along with their corresponding implementations.
Because a service may use other services, ServiceSpace resolves this dependency by looking for an implementation in its registry for all the services required. There is a programming interface to manage the life cycle of the bundles. For example, using a simple state machine, one can keep track of a bundle's states.
Within a connected home, the service gateway must automatically adjust itself to take into account newly installed equipment, like a recently purchased camcorder. The service gateway supports protocols for device discovery, service lookup, and device configuration and management. When a new device is discovered on the network, a device bundle containing implementations of the services for the device is loaded dynamically. Other bundles such as device drivers are loaded as needed. For networks that do not support automatic device discovery, a bundle with a user interface can prompt a user to manually register the device.
OSGi expects to complete its first official version of the specifications by early 2000.
See related chart