Java Technology Home Page

Downloads, APIs, Documentation
Java Developer Connection
Docs, Tutorials, Tech Articles, Training
Online Support
Community Discussion
News & Events from Everywhere
Products from Everywhere
How Java Technology is Used Worldwide

A-Z Index
The Source for Java Technology
JSR HTML Template
Identification | Request | Contributions | Additional Information

General Instructions

This template has been designed to be easily filled out using an HTML editor. Please complete all sections. Don't forget to give the proposed specification a name. 

E-mail the completed JSR to: jsr-submit@sun.com. Don't forget to include the name of the JSR in the subject line. 

As stated in Section 1 of the Java Community Process, JSRs will only be accepted from Members. 


Title: 
Java Daemons

Summary:
The Java Daemon API supplies a small container framework for developing and deploying independently running services in order to fill the gap caused by different handling on existing native platforms. 

Section 1. Identification
Submitting Member: Thomas Kopp
Name of Contact Person: Thomas Kopp
E-Mail Address: Thomas.Kopp@Dialogika.de
Telephone Number: +49,6897,935,0
Fax Number: +49,6897,935,100

Specification Lead: Thomas Kopp
E-Mail Address: Thomas.Kopp@Dialogika.de
Telephone Number: +49,6897,935,0
Fax Number: +49,6897,935,100

Initial Expert Group Membership:
An initial expert group is not yet formed. The expert group should be formed by 

  • participants focusing on server APIs as server tool suppliers,
  • participants focusing on server APIs as container tool suppliers,
  • participants involved in the JDK core APIs and tools for providing a seamless integration with future JDK releases.

Section 2: Request

2.1 Please describe the proposed Specification:

The Java platform has currently no suitable tools for developing and deploying independently running services like UNIX daemons in a uniform cross-platform fashion. System level services, however, are an essential need on each server platform. Developers are left alone when the question arises, how to install Java services on a given platform. This dilemma is caused by differences in handling system level services on the individual platforms, e.g. Unix versa NT. In addition, some platforms, e.g. Windows 95, are completely missing such functionality.

The Java daemon framework should fill this gap. The proposal consists of interfaces and classes for developing and deploying independently running services using the Java language and tools, only. In addition, the framework contains an SPI for providing suitable containers in order to host Java daemons.

Daemon containers may be supplied on both, the Java platform and native platforms.
A simple command line tool should be included in future JDK releases for deploying and managing Java daemons on each platform in a uniform fashion. Third party vendors may supply more sophisticated tools for deploying, hosting, watching and controlling life cycles of Java daemons. 

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

Daemons are required on arbitrary platforms. The server platform would, however, be the typical target environment.

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

The Java community would obtain tools for developing and deploying any kind of platform-independent services without having to integrate the Java application launcher with platform-specific handling routines, e.g. using native scripting and/or other wrapping techniques.

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

Using the current JDK, developers are still forced to deal with platform-dependent interfaces and deployment facilities if they want to establish simple services beyond high-level application container frameworks like EJB.

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

The framework would consist of a common notion of system level services available on each platform. Native platforms, which are completely missing a notion of service, would be equipped with a maximum functionality available on the basis of the tools proposed for hosting Java daemons.

The Java daemon framework would supply classes, interfaces and command line tools

  • for managing daemon context, i.e. runtime parameters, 
  • for controlling a daemon's life cycle, i.e. start, stop, restart functionality,
  • for watching daemon state, i.e. listener functionality,
  • for supplying daemon logging functionality,
  • for deploying daemons using a simple command line style,
  • for developing containers including native ones on the basis of JNI adapter classes.

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

  • java.daemon for the core classes and interfaces,
  • java daemon.pausable for extended classes and interfaces,
  • java.daemon.logging for logging functionality

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?

Existing standard Java internationalization APIs will be sufficient. 

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

No. Current Java tools, however, e.g. rmid may benefit from the new API and could be re-designed for also running as Java daemons.

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

Initiation: November 2000.
Community Review: May 2001 
Public Review: August 2001
Final Draft Proposal: November 2001

Further schedule will depend on the review process.

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.

A first document containing specifications and source code fragments is attached to the JSR as a PDF file. The complete source code is attached to the JSR as a zip archive.

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

The document attached shows a first structural notion of Java daemons. The compiled sources can already be used for implementing samples. This starting point might encourage participants to join the expert group. In addition, the sources form a fully functioning preliminary RI for the NT platform. A Unix RI would result from an analogous mapping of the proposed interfaces to the semantics of  rc init scripts. 
 
See Also
Details of the Community Process
New Specification Proposals
[ This page was updated: 23-Oct-00 ]
Products & APIs | Developer Connection | Docs & Training | Support
Community Discussion | Industry News | Solutions Marketplace | Case Studies
GlossaryFeedbackA-Z Index
For more information on Java technology
and other software from Sun Microsystems, call:
(800) 786-7638
Outside the U.S. and Canada, dial your country's AT&T Direct Access Number first.
Sun Microsystems, Inc.
Copyright © 1995-2000 Sun Microsystems, Inc.
All Rights Reserved. Terms of Use. Privacy Policy