 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 8: Open Services Gateway Specification
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
This JSR has been Withdrawn Identification | Request | Contributions Section 1: Identification
Robert Mines,
Phone: +1 408 863 3557
This JSR is being submitted and endorsed by the following Java Community Process Participants:
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 PlatformThe 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 AddressesThe 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 technologiesThe 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 namesPackage names being considered are:
2.7 Possible platform dependenciesThe 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 implicationsNone. OSG expects to utilize standard JDK security. 2.9 Internationalization implicationsNone. 2.10 Localization implicationsNone. 2.11 Risk assessmentNo expected impact on existing Java technology specifications. 2.12 Existing specifications rendered obsolete or deprecatedNot applicable. 2.13 Existing specifications needing revisionsSection 3: Contributions
Documents describing the OSG can be found at http://www.osgi.org |
|||||||||||||||||||||||||||||||||||||
