OSGi – Open Services Gateway initiative

Open Services Gateway Business Model

The OSGi tries to find a standard way for entire service life cycle management.

This end-to-end architecture includes but is not limited to security, remote

management, service deployment, resource management and accessing local area

network devices. Even though OSGi does not specify any specific business model, the

following roles are anticipated to appear in real life OSGi service business:

·  Service provider

·  Service aggregator

·  Service gateway distributor

·  Gateway operator

·  Wide area network provider

·  Internet service provider

·  Local area network provider.

Naturally any company can play, and probably will do so, more than one role in

OSG business. Figure 2 describes the relationship between different roles.

2.1 Service Provider

A service can be almost anything running inside an OSG. Typically services

residing in such a gateway also need access to at least one (local area network) device

and a remote back-end server. The service itself is an application that the service

operator has downloaded to the gateway. Service code must be tested and verified by

the operator. Back-end servers can be used among other things for billing and service

authorization.

2.2 Service Aggregator

The role of a service aggregator is to bundle services together to build an

appealing package. The earning logic will likely force several types of services to

reside inside one service gateway. However, it is quite possible that several gateways

are located inside the same residence.

2.3 Service Gateway Distributor

Gateway distributor is responsible for delivering the gateway to the end user.

Gateways may be purchased from an ISP provider, electricity company or from a

cable modem provider.

2.4 Gateway Operator

The gateway operator is responsible for maintaining and managing the gateway

and its services. Because the service aggregator bundles the service together, it is

assumed that it will have close relationship with the gateway operator. Some of the

tasks that the gateway operator shall take care of:

·  Deliver, start, stop, update and remove services.

·  Manage the gateway.

·  Provide a secure WAN link.

·  Control gateway resources.

·  Control access rights.

·  Manage services.

The gateway operator may also be the gateway distributor possibly renting or

even giving away the gateway hoping to leverage from service fees.

2.5 Wide Area Network Provider

The wide area network provider takes care of the necessary communication links

from the gateway to the outside world. Again, the roles may be mixed. An ISP may

also provide the WAN.

2.6 Wide Internet Service Provider

The Internet service provider (ISP) gives the end user a mechanism to access the

Internet. If the ISP is different that the WAM provider, managing the necessary IP

addresses is till an open issue.

2.7 Local Area Network Provider

In case the service need to access a local device the local area network provider

must install the network and typically devices too. So far traditional home networks

have not gained large popularity, mostly because there is no compelling reason for

consumer for such an investment. Wireless protocols, such as Bluetooth, have big

expectations to bring the cost down to a level where the business can really take off.

Open Services Gateway Specification

The current version of OSGi is 1.0, which was released in May 2000. It is a java

software API. Java was chosen to make the specification operating system

independent. The current version specifies the following minimum components:

·  Java environment

·  Service framework

·  Device access manager

·  Log service.

In addition to the mandatory component the following optional services are also

defined in the specification:

·  HTTP service

·  Client access service

·  Configuration data service

·  Persistent data service.

3.1 Java Environment

Currently java is the only choice for execution environment. The OSGi

specification has not clearly defined the minimum set of java packages and classes.

The OSGi Core Platform Expert Group is working on the minimum execution profile

for a bundle. This work will likely produce a number of related profiles for minimal,

medium and large gateways. At the moment Java 1.2 or higher is needed to run the

OSGi platform. Necessary java development kit can be downloaded at least from the

following companies:

·  JavaSoft, supports Solaris, Linux and Windows

·  IBM Java implementation, supports AIX, AS/400, OS/2, Linux and

Windows

·  Apple, supports Macintosh

An up-to-date list of java ports is available at http://java.sun.com/cgi-bin/javaports.

cgi.

Naturally OSGi requires hardware and operating system where a Java Virtual

Machine (JVM) can execute. OSGi service framework runs on top the JMV, and

finally bundles get installed dynamically into this framework, as described in the

Figure 3.

3.2 Service Framework

OSGi service framework provides platform independence and dynamic codeloading

capability to make development and dynamic deployment of applications for

small-memory devices easier. Service framework swaps services dynamically in and

out. It provides the context that developers write their code to execute in.

If necessary, service framework can dynamically update a service without stopping

the executing environment. Services are implemented in java and then combined to

form a bundle, which is downloaded to the gateway. A bundle is java jar archive

including java class files and any other necessary data the service might need. The jar

file also includes information about any external resources the service needs. It is then

up to the framework to make required resources available. Optionally a bundle may

contain classes that help the framework to install, configure, activate and update the

service. Finally a bundle declares which class should be used to start or stop a service.

Operating System

Java VM

Hardware

Service Framework

OSGi Defined Services Custom Services

Figure 3, OSGi Architecture

Since an OSGi gateway may be implemented in an embedded system it must be

designed keeping limited memory resources in mind. Also, the framework itself must

scale from embedded devices all the to a full blown PC-based system, such as

Windows NT.

Typically many services run inside the same gateway. Framework is responsible

for coordinating dependencies between services. The framework allows installation of

independent bundles. After installation bundles need a mechanism to communicate

and discover each other. The framework includes a special service registry that fulfills

this need. Each bundle can place objects in the registry and search the registry for

other objects. These objects are also called services. As a service is registered in the

framework, it is registered along with a set of properties, e.g. protocol=https, and a list

of interface names. Searching the services is implemented using a filter capability that

allows checking the values of the properties and the classes that are implemented. All

registration and unregistration actions are published as events to any bundle willing to

receive them. Again, the filter capability can be used to minimize the number of

events received. The service registry is maintained by the framework. As a bundle is

stopped, all services registered by that bundle services will be unregistered

automatically.

3.3 Device Access Manager

OSGi was designed to offer service developers an easy way to access any devices

the service might need. Device manager’s role is to offer a network independent highlevel

mechanism for accessing local devices. Another task for device manager is

automatically discover any new devices. The ultimate goal is to let an end user to plug

his device into a gateway so that all necessary drivers will be installed and possibly

downloaded automatically.

Device manager uses two bundle types. Firstly, network bundles contain protocol

stack, drivers and any other resources the link requires. Secondly, devices bundles

provides resources to access devices.

A drive presents a physical device. OSGi specification defines base and refining

drivers. A base driver discovers physical devices and registers related OSGi Device

services. The discovery process itself is not included in the OSGi specification. A

refining driver provides a more detailed view of a physical device once the

corresponding Devices exists in the OSGi Framework. A refining driver registers a

Driver service with the Framework.

In terms of drivers, it is possible that a device has many presentation of itself. It is

up to the device manager to manage drivers in such a case. Also, a driver may

represent a physical device in multiple ways.

3.4 Log Service

The log service is the only mandatory service. Its purpose is to provide other

service a mechanism to write entries to a log and read entries from a log. Each log

entry can include current system time, a severity level. A text message, an optional

Java Throwable object and the identity of the Java program running in the Framework

that created the log entry. Log service also listens to Framework events and create log

entries representing these events, reads past log entries via an enumeration and

notifies listeners of log entries as the entries are created.

The implementation of a log is a local matter.

3.5 HTTP Service

The HTTP service gives other services an interface to configure the server, publish

static and dynamic content from Java Servlets. The HTTP Service provides the

following capabilities and features:

·  Support for the Java Servlet 2.1, or higher API specification

·  A Java Servlet Engine to provides the runtime environment for Java Servlets

·  Support for HTTP/1.0 or HTTP/1.1 protocol with the recommendation that

implementations of the HTTP/1.0 protocol support the Keep-Alive feature of

HTTP/1.1 as a performance enhancement.

·  An API to allow services to dynamically register and unregister static content,

Java Servlets and other resources into the URI namespace of the HTTP server.

·  An API to allow services which have registered content to verify the identity

of the requestor (HTTP authentication) and if the communication channel is

secure (SSL encryption).

3.6 Client Access

In many cases, the services running on the gateway will need to occasionally

interact with end users. Some of this interaction can be managed from remote servers.

In other cases, a gateway-resident mechanism is needed to allow end users to view

information in the gateway, modify configuration information, receive notifications,

and otherwise interact with services in a uniform way.

The client access service API provides a framework for managing user

interactions that minimizes the work for the service developer and goes beyond the

basic facilities provided by the HTTPService. The client access service provides

automated support for URL name space management and supports data format

negotiation to support access devices ranging from mobile phones to PC browsers.

3.7 Configuration Data Service

Many of the services running in a gateway will need additional configuration

information to perform their tasks. This information can be as simple as a short list of

authorized devices or as complex as user personalization information. The

configuration data service provides a common service API for services to store and

access this data and a means by which a remote administrator can change

configuration information.

3.8 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. Rather than having each service have code to efficiently read and write

information to a file system and recover from errors, a common persistence data

service is provided that can be used by other services to store and retrieve

information. Using this API, a service can make any piece of information persistent, is

able to search the persistent information store using a high level query language, is

able to recover from failure after partial updates, and is able to synchronize the data

with a server database. Implementations of the persistent data service may allow

persistent information to be backed up on a server machine (perhaps one managed by

the gateway operator) as an extra measure of reliability.

References
OSGi Home Page: http://www.osgi.org/
OSGi Service Gateway Specification, Release 1.0: May 2000
Ericsson Residential e-services: http://www.ericsson.com/wireless/products/ebox/
Gatespace: http://www.gatespace.com
IBM VisualAge: www.ibm.com/software/ad/embedded
The Connected Home Powered by Java Embedded Server Software, Sun
Microsystems White Paper, 2001
Acunia: http://www.acunia.com
Sun JES: http://www.sun.com/software/embeddedserver
Sunsoft Java 2 SDK: http://www.javasoft.com/products/jdk/1.2/