 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 111: JavaTM Services Framework
Reason: Withdrawn with the agreement of the Expert Group. JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: 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) Team
This JSR has been Withdrawn
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 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. |
|||||||||||||||||||||||||||||||||||||||||||||||||
