You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by James Todd <ja...@eng.sun.com> on 1999/07/22 10:30:10 UTC
config rfd
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 <go...@xphylz.eng.sun.com>
Request for Discussion: 1999.07.18.1.2
(yyyy.mm.dd.docId.revId)
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
Tomcat.
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
XML/RDF
XML/Schema
XMI/UML
<!-- 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.
<!-- REVIEWER's NOTE:
this configurable piece is a potential chicken and egg situation
-->
Viable XML parsing libraries include:
ProjectX - http://developer.java.sun.com/developer/products/xml
<!-- EN:
add'em
-->
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
service
application interactint with a jndi managed configuration
service
application interacting with an ldap managed configuration
service
<!-- RN:
i believe jndi encompasses ldap
-->
application interacting with a jini managed configuration
service
<-- EN:
add'em
-->
X. Appendix
X.1 Tomcat XML/DTD config
contributor: james.todd@sun.com
note: the following does not necessarily pass some xml parser
validations
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE WebServer [
<!ELEMENT WebServer (Service+)>
<!ATTLIST WebServer
adminPort NMTOKEN "">
<!ELEMENT Service (WebApplication*)>
<!ATTLIST Service
id ID #REQUIRED
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
path CDATA #REQUIRED
docBase CDATA #REQUIRED
maxInactiveInterval NMTOKEN "30">
]>
<WebServer>
<Service id="service0">
<WebApplication path="/examples" docBase="examples"/>
</Service>
</WebServer>
X.2 RDF (Resource Definition Format)
contributor: Daniel.Brickley@bristol.ac.uk
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:s="http://usefulvocab.org/personinfo/"
xmlns:dc="http://purl.org/dc/elements/1.0/"
xmlns="http://jakarta.apache.org/fictionalschema/">
<!--
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)
-->
<administrator>
<s:Person s:firstname="Dan" s:surname="Brickley"
s:email="daniel.brickley@bristol.ac.uk"/>
</administrator>
<!--
the Server has a 'module' property whose value is an object of
type JservModule
-->
<module>
<JservModule>
<!--
...which in turn has a mount property whose values for 'path'
and 'full' properties are given as simple strings
-->
<mount>
<mountspec path="/servlets"
full="ajpv11://localhost:8007/myZone/"/>
</mount>
</JservModule>
</module>
<!--
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
-->
<dir>
<Directory path="/docs/science/">
<maintainer>
<s:Person s:firstname="Libby" s:surname="Miller"
s:email="libby.miller@bris.ac.uk"/>
</maintainer>
<dc:Title>
Science Docs
</dc:Title>
<dc:Description>
A collection of documents to do with science...
</dc:Description>
</Directory>
</dir>
</Server>
</rdf:RDF>
Y. References
Servlet 2.2
http://java.sun.com/products/servlet
Java Server Pages 1.0
http://java.sun.com/products/jsp
<!-- EN:
add'em
-->
Z. Legend
AN - Author's Note
EN - Editor's Note
RN - Reviewer's Note