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/
