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