Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 111: JavaTM Services Framework

Stage Access Start Finish
Withdrawn   19 Aug, 2003  
Expert Group Formation   03 Apr, 2001  
JSR Review Ballot View results 20 Mar, 2001 02 Apr, 2001
Status: Withdrawn
Reason: Withdrawn with the agreement of the Expert Group.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

Provide a specification that clearly defines the lifecycle, configuration, and management of software application services. The specification will provide a standard mechanism for assembling service components into Java server applications.

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

Specification Leads
  Berin Loritsch Loritsch, Berin
Expert Group
  Apache Software Foundation Art Technology Group Inc.(ATG) Developmentor
  Echelon Corporation Espial Group, Inc. Hammant, Paul
  IBM Interwoven Loritsch, Berin
  Lutris Technologies Macromedia, Inc. Netdecisions Holdings United
  Sun Microsystems, Inc.

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:

Telephone Number: +1 856 727 4600 x1210

Fax Number: +1 856 787 9395

Specification Lead: Jonathan Maron

E-Mail Address:

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.)

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


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


2.9 Are there any internationalization or localization issues?


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 (

2)The Open Services Gateway Interface (

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