tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Todd <>
Subject config rfd
Date Thu, 22 Jul 1999 08:30:10 GMT

i didn't get as far as i'd have liked. i'm going to try and
focus on the "configuration service" (description, role,
boundaries, etc) next. this is a big piece of work in and
of itself ... its the core. this translates to "i didnt'
touch anything from section 5 and on."

i welcome comments/corrections/mishaps/contributions/etc.
the primary theme with this update is a bit more explicit
entity descriptions and likewise just as explicit implementation
candidates (well, implementation idea candidates) with the
intention being that if this is designed such that extensibility
can thrive than we'll have many more options when it comes
time to try out new ideas.

hope this helps,

- james

-------- Original Message --------
Date: Thu, 22 Jul 1999 01:16:46 -0700 (PDT)
From: James Todd <>

Request for Discussion: 1999.          
Theme: Tomcat Configuration Service

0. Abstract

    This document is a collection of discussion points and prevailing
    decisions to date entailing configuration service management and
    design issues pertaining but not exclusive to HTTP servers
    implemented in Java. As such, this document is evolving at the
    moment to best capture these concepts and is anticipated to continue
    to evolve during the early stages.

1. Terminology

    Following is a collection of terms and associated definitions that,
    while not necessarily comprehensive, should suffice within the
    context of this document.

    Configuration Data (here after known as data)

	Information required by an HTTP server for startup and run time.

	eg: server name, document base, web application

    Configuration Service (here after known as service)

        An entity which provides abstracted configuration data to
        subscribed clients supporting a specified set of protocols
	and api's. A configuration service may provide update
	information to subscribed clients as changes occur to the
	configuration data since a corresponding read has occurred.
	This notification can occur either "passively", that is as
	a result of subsequent client requests, or "actively" as
	dynamic change events occur to the configuration data.

    Configuration Client (here after known as client)

        An entity subscribing to a configuration service in order to
	obtain abstracted configuration data. A configuration client
	may interact with the configuration service in a "read" only
	or a "read/write" write manner.

	eg: http server, administration tool

    Configuration Protocol (here after known as protocol)

        An agreed upon means of communication amongst a configuration
	client and a configuration service.

	eg: http, rmi, ldap, jini

    Tomcat (aka Java Server Web Development Kit, JSWDK)

        An HTTP/1.0 server implemented in 100% pure Java which
        includes reference implementations for the Servlet 2.2 and
	Java Server Pages 1.0 specifications.

2. Objectives

    The intentions of this document is to form some specific design
    decissions concerning a generalized "configuration data" management
    service which can be used by  but is not necessarily restricted to
    Tomcat. With this goal in mind, some fairly concrete initial design
    decissions can be specified including: java packages and protocols,
    simplistic entity defintions, xml utilities, etc of which the
    remainder of this document will expand upon.

3. Configuration Client

    Two predominant configuration clients can readily be described,
    those being an HTTP server and a configuration administration
    tool. Following is a description of Tomcat as a specific
    configuration service client in terms describing the required
    data and some anticipated configuration usage scenarios. Also
    listed is some fictional configuration administration tool
    configuration usage scenarios.

3.1 Tomcat HTTP Server as a Configuration Client

    Following is a listing of the configuration data required by

    HTTP Server

	A collection of web services supporting the HTTP protocol.

	Attributes include:

	    administration port number

	Collections include:

            one or more web services

    Web Service

	An HTTP service unit which has a unique URI identity.

	Attributes include:

	    port number
	    host name
	    internet address
	    document base - the default document base
	    work directory - service work or scratch directory
	    work directory persistence
	    servlet invoker - enables invocation of unmapped servlets

	Collections include:

	    zero or more web applications

    Web Application

	An collection of web components which together form the
	basis of an application.

	Attributes include:

	    path - the application URI relative to the hosted web service
	    document base - application document base
	    maximum innactivity interval - maximum session inactivity interval

3.1.1 Tomcat Present Configuration Service Model

    Upon startup, Tomcat requires access to the configuration data
    discussed in the previous section. This data is presently provide
    as a "webserver.xml" file and associated dtd (included below).
    The locality of this resource is provide to Tomcat as a singular
    URI and as such can reside locally or it can be obtained over the
    wire. If the file cannot be obtained, then a default configuration
    file is created and used by Tomcat. The XML representation is 
    processed by a validating parser and bound to the appropriate
    Tomcat element, namely, AdminPort, HttpServer and Context. Tomcat
    does not reference the configuration data for the remainder of it's
    lifetime except for server shut down which only requires the web 
    server administration port in the event it cannot be determined in
    the default means (via a webserverlog.txt file).

3.1.2 Tomcat Future Configuration Service Model

    With a small amount of rethinking it could be conceivable that
    Tomcat could actively attach to a configuration service at
    startup, during it's life cycle and at shut down. For example,
    it should be possible to add new web applications to a running
    Tomcat server.

    The configuration service could be either a library which is
    could be seen as a framework usable by any single Tomcat
    instance or it could be a remote, from the perspective of
    Tomcat, service which can be accessed by more then one Tomcat
    instance. At the present time, the configuration is a light-weight
    framework usable by an single instance but there are many
    benefits in moving this logic to a service decoupled from an
    single Tomcat instance.

    For the most part, Tomcat would only require read access to
    configuration data and update notifications. These notifications
    could be passive which would require Tomcat to initiate update
    notification requests or active, which would require to register
    as a "configuration update listener."

3.2 Configuration Administration Tool as a Configuration Client

<!-- AN:
    describe an admin tool

3.2.1 Configuration Administration Tool Service Model

<!-- AN:
    add read/write, secure, transactional/data integrity requirements

4. Configuration Data

    The primary issues pertaining to the configuration data include
    the data format, definition, processing and transformation rules
    and transactional processes, basically the answers to who does
    what when and how.

    The consensus is that direct file editing must be allowed. With
    some thought in design, it should be viable to allow for direct
    file editing yet still allow for administration tool manipulation
    of the same data all while capturing and propogating configuration
    update notification events.

4.1 Data Format

    At this time it is felt that the standard configuration format
    must be expressed as XML/DTD. It may be possible to optionally
    aggregate  multiple native format representations (eg property
    files) at some point in time as deemed appropriate.

4.1.1 XML/DTD

    A sample Tomcat XML and associated DTD is provided below and is
    offered as a candiate baseline.

4.1.2 Other XML Formats


<!-- EN:
    serious cleanup/fleshing out required from here on down

5. Configuration Service

<!-- EN:
    key concept is the service is a statefully aware intermidiary
    between config clients and config data ... seperating the details
    of each ... while supporting a number of communications protocols
    and the like

    Configuration data processing design and management is the key
    stone to making this a highly effective and adaptible initiative
    versus one that may work yet becomes encombered over time. As
    such, this is where a good amount of design discussions should
    initially take place.

5.1 Configuration Service

    The notion of a "configuration service" should be such that
    it embodies the contextual premise of the configuration data
    in an expected and natural manner for configuration data
    consumers in a consistent and expected manner while maintaining
    transactional integrity. This service should exert few
    limitations on the intermediation of configuration data and
    must in fact be open to exploring viable and collaborative
    options (note: explictly not alternatives) as they arise.

5.2 Parsing
    In order ensure flexibility and provide end user choices
    it is preferred that open standards and tools be utilized
    as much as possible. To that end, it should be designed
    such that a specific XML parsing implementaion, while
    required, is a pluggable and configurable module.

    this configurable piece is a potential chicken and egg situation

    Viable XML parsing libraries include:

        ProjectX -

<!-- EN:

5.3 Validation

<!-- EN:
    xml parser validation; what is it, pro's, con's

5.4 Certification

<!-- EN:
    public key certification; what is it, pro's, con's

5.5 Persistifying, Serializing, Saving

<!-- AN:
    provide a 50k fly by

5.6 Transfer, Replication

<!-- AN:
    provide a 50k fly by

5.7. Configuration Protocol

    The means by which the configuration service conveys configuration
    data should include but is not exclusive to:

        HTTP/S (hyper text transfer protocol; ssl)

        RMI/IIOP (remote method invocation/internet inter-orb protocol)

        JNDI (Java Naming and Directory Interface)

        LDAP (light-weight directory access protocol)

<!-- RN:
    i believe jndi encompasses ldap

        JINI (jini is not initials)

6. Configuration Management Examples, Scenarios

    Following is a non-exclusive list of possible configuration
    management usage scenarios:

        edit local configuration file

        html form/JSP interacting with a servlet mananged configuration
        http/s service

        applet pushing/pulling serialized objects with a servlet
        managed configuration http/s service

        applet pushing/pulling XML formatted data with a servlet
        managed configuration http/s service

        applet invoking methods via an rmi managed configuration

        application interactint with a jndi managed configuration

        application interacting with an ldap managed configuration

<!-- RN:
    i believe jndi encompasses ldap

        application interacting with a jini managed configuration

<-- EN:

X. Appendix

X.1 Tomcat XML/DTD config

note: the following does not necessarily pass some xml parser

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE WebServer [

<!ELEMENT WebServer (Service+)>
<!ATTLIST WebServer
    adminPort NMTOKEN "">

<!ELEMENT Service (WebApplication*)>
<!ATTLIST Service
    port NMTOKEN "8080"
    hostName NMTOKEN ""
    inet NMTOKEN ""
    docBase CDATA "webpages"
    workDir CDATA "work"
    isWorkDirPersistent (false | true) "false"
    isInvokerEnabled (true | false) "true">

<!ELEMENT WebApplication EMPTY>
<!ATTLIST WebApplication
    maxInactiveInterval NMTOKEN "30">

    <Service id="service0">
        <WebApplication path="/examples" docBase="examples"/>

X.2 RDF (Resource Definition Format)


<?xml version="1.0"?>

<rdf:RDF xmlns:rdf=""

    An annotated example RDF config file for Jakarta

    an object of type Jakarta:Server with port and title properties...

<Server port="80" title="My server">

    also has an adminstrator property whose value is a Person with
    firstname, surname etc specified using a different vocabulary
    defined elsewhere (note the s: prefix)

        <s:Person s:firstname="Dan" s:surname="Brickley"

    the Server has a 'module' property whose value is an object of
    type JservModule

    ...which in turn has a mount property whose values for 'path'
    and 'full' properties are given as simple strings

                <mountspec path="/servlets"

    the Server object also has a directory property whose value is
    an object of type Directory. We specify a path property with
    simple value, as well as a maintainer, which is another person.
    Then we use some Dublin Core properties to characterise this
    collection of documents for retrieval-oriented applications

        <Directory path="/docs/science/">
                <s:Person s:firstname="Libby" s:surname="Miller"
                Science Docs
                A collection of documents to do with science...


Y. References

    Servlet 2.2

    Java Server Pages 1.0

<!-- EN:

Z. Legend

    AN - Author's Note
    EN - Editor's Note
    RN - Reviewer's Note

View raw message