Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 111: JavaTM Services Framework

This JSR has been Withdrawn
Reason: Withdrawn with the agreement of the Expert Group.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Hewlett-Packard Company

Name of Contact Person: Bob Bickel

E-Mail Address: bickel@bluestone.com

Telephone Number: +1 856 727 4600 x1210

Fax Number: +1 856 787 9395


Specification Lead: Jonathan Maron

E-Mail Address: jonathan_maron@hp.com

Telephone Number: +1 856 638 6013

Fax Number: +1 856 787 9395




Section 2: Request

2.1 Please describe the proposed Specification:

The specification proposes a framework for hosting Java service components. It will define the methodology, APIs, and lifecycle for creating software services that can be hosted by a compliant services framework and assembled into Java server applications.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java 2 Platform, Standard Edition

Java 2 Platform, Enterprise Edition

Java 2 Platform, Micro Edition

2.3 What need of the Java community will be addressed by the proposed specification?

The Java Community Process is quickly yielding multiple APIs that end users wish to leverage in a timely fashion. However, there is currently no standard for defining how these new services are to interoperate with each other or with legacy service components. In addition, no specification currently defines an approach for embedding into legacy applications the services defined by these evolving specifications. A framework promoting code reuse and sharing, simplicity of development, and a uniform approach to the lifecycle, management, and configuration of application services would yield the development environment to meet these concerns. The Java Services Framework will define a common life cycle for all server components (e.g. naming, logging, security, session, etc.). Service implementations will be portable across applications allowing the assembly of servers optimized for end-user needs. In addition, the Java Services Framework will reduce the effort involved in implementing evolving APIs through the sharing of resources amongst services i.e. common resources can be shared or duplicated amongst cooperating services.

2.4 Why isn't this need met by existing specifications?

The current specifications do not specify the lifecycle of Java services in a common way nor is the interoperability of services generally addressed. It is thus not possible to create a portable Java service. In addition, the current APIs do little to promote the reuse of common resources amongst service implementations.

2.5 Please give a short description of the underlying technology or technologies:

The Java Services Framework will present a design methodology and the supporting infrastructure definitions (APIs, guidelines, etc.) that will allow:

1) Specification of a common life cycle for services.

2) Decoupling a service

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.services

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

No.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

In the short term there will be no need to modify the existing specifications. However, as this effort evolves and the specification is released, existing and evolving specifications would ideally be revised to reference the Java Services Framework.

2.11 Please describe the anticipated schedule for the development of this specification.

Community Draft Q4 2001
Public Draft Q1 2002





Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

There are currently two open source service framework initiatives:

1)Avalon on java.apache.org (http://jakarta.apache.org/avalon/index.html).

2)The Open Services Gateway Interface (http://www.osgi.org/about/spec1.html).

3)Core Services Framework developed at the HP Bluestone facilities.

3.2 Explanation of how these items might be used as a starting point for the work.

The three implementations above represent Java service framework efforts of varying maturity. The merits of each can be analyzed and the results of such an analysis can form the basis for a unified approach to defining the services framework.



Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

The Java Services Framework Reference Implementation (RI) will be submitted with an Apache Source license.

A white paper is available with some additional information concerning the Java Services Framework at http://developer.bluestone.com/jsf/WhitePaper.doc.