Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 8: Open Services Gateway Specification

Stage Access Start Finish
Withdrawn   10 May, 1999  
CAFE   29 Mar, 1999 10 May, 1999
JSR Approval   22 Mar, 1999 29 Mar, 1999
Status: Withdrawn
Reason: Withdrawn because work moved to Open Services Gateway consortium (www.osgi.org) where the specification will be completed.
JCP version in use: 1.0
Java Specification Participation Agreement version in use: 1.0


Description:
This JSR was going to develop the Open Services Gateway (OSG) Specification and describe an extensible Service Gateway.

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
  Xander Bighorn Trangadst Shipping Services
  Robert Mines Sun Microsystems, Inc.
Expert Group
  Sun Microsystems, Inc. Trangadst Shipping Services  

This JSR has been Withdrawn
Reason: Withdrawn because work moved to Open Services Gateway consortium (www.osgi.org) where the specification will be completed.

Original Java Specification Request (JSR)

Identification | Request | Contributions

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