|
Section 1: Identification
Robert Mines,
Java Software, Sun Microsystems, Inc.
Phone: +1 408 863 3557
E-Mail: robert.mines@eng.sun.com
This JSR is being submitted and endorsed by the following Java Community
Process Participants:
-
Sun Microsystems
-
IBM
-
Nortel
-
Alcatel
-
Cable and Wireless
-
EDF
-
Enron
-
Ericsson
-
Lucent
-
Motorola
-
NCI
-
Phillips
-
Sybase
-
Toshiba
Section 2: Request
This JSR is to develop the Open Services Gateway (OSG) Specification. It
will describe an extensible Service Gateway.
2.1 What is a Service Gateway?
A Service Gateway (SG) is an embedded server that is inserted into the
network to connect the external internet to an internal network. The SG
is inserted between Service Providers and the home or SOHO/ROBO LAN and
client devices. The SG serves to separate your internal network from the
external network you connect to and hence provides gateway and bridging
capabilities between the two networks as well as providing a central management
and access point. Third parties, such as financial institutions, can develop
services and that can be delivered to your SG from a trusted Service Provider
located on the external network. The SG will then make those services available
to your internal clients in a safe and secure way. The SG is intended to
be a secure, zero-administration device. The OSG Specification is expected
to define APIs for "cradle-to-grave" life cycle management of services,
inter-service dependencies, data management, device management, client
access, resource management, and security. Clients on the internal network
will use these APIs to request the SG to make one or more "services" available
for them. The SG will handle all the work of locating the the associated
Service Provider out on the external network and then installing, versioning,
and configuring the services before making them available in a secure way
to the requesting clients. In addition, the Service Gateway is a central
connection point for integrating a wide range of SOHO/ROBO and home automation
technologies, such as bluetooth and HAVi.
2.2 Target Java Platform
The OSG Specification is targeted towards embedded gateways in the home
or SOHO/ROBO environment. These will typically be zero-administration devices
with CPU and memory constraints although they could conceivably be more
complex devices that could implement desktop or even server Java platforms.
To handle this potentially wide range of platforms, the OSG Specification
will seek to provide a useful, common baseline of functionality based on
the EmbeddedJava profile.
2.3 Needs of Java Community this Specification Addresses
The OSG specification defines a set of APIs that will allow for the download
and maintenance of a set of dynamic services to a residential or SOHO/
ROBO gateway. There is need for a well-defined, single Java specification
in this area. The HomeAPI organization, www.homeapi.org,
is developing a proprietary set of specifications that are targeted at
the residential gateway marketplace and are not based on Java technology.
In contrast, the OSG specification will provide a cross-platform solution
that will give ISVs and Service Providers a consistent, open environment
that they can develop and deploy services to.
2.4 The APIs being defined.
The APIs specified by the OSG will be divided into two parts: OSG optional
and OSG required. Required APIs must be implemented by a vendor to be OSG
compliant. Optional APIs are not required to to be implemented to be certified
as OSG compliant. However, vendors implementing an optional API must
use the optional OSG API to implement that capability in order to be OSG
compliant.
The required APIs will provide an application framework for downloading
and running applications in a zero-administration, embedded device based
on existing WWW standards. The required APIs also support the integration
of a wide range of low-level device capabilities, such as bluetooth, HAVi
and others. Basic gateway resource management, such as thread-pool management,
is also part of the "OSG required" APIs.
The "OSG optional" APIs are expected to be based on, and reference,
existing Java specification as much as possible (including, for example,
JDBC, and Servlets). New APIs will likely include those for client access
to the device and a simple persistent object store API. The APIs may also
reference services based on JMS and JNDI.
2.5 Underlying technologies
The OSG specification are expected to be based to a large extent on the
JavaEmbedded Server 1.0 specification. Especially relevant is the ServiceSpace
specification. In addition, the Oracle Persistent Object Store specification
is being contributed.
2.6 Proposed package names
Package names being considered are:
-
javax.osg.servicespace
-
javax.osg.remote
-
javax.osg.service
2.7 Possible platform dependencies
The Reference Implementation will have a dependency on the Embedded Java
Specification and may also reference existing specifications (such as JDBC
and ServiceSpace) if needed.
2.8 Security implications
None. OSG expects to utilize standard JDK security.
2.9 Internationalization implications
None.
2.10 Localization implications
None.
2.11 Risk assessment
No expected impact on existing Java technology specifications.
2.12 Existing specifications rendered obsolete or deprecated
Not applicable.
2.13 Existing specifications needing revisions
Not applicable.
Section 3: Contributions
Documents describing the OSG can be found at http://www.osgi.org
|