This document describes the architecture of the generic server and service framework within the JavaServer Toolkit, and how services are built using this framework. It also describes the servlet api currently used by the HTTP server.
First, some basic definitions need to be made:
The service framework is a set of classes for implementing services which use multiple handler threads to process interactions with clients. In the initial implementation, this framework supports only connection based services. This will later be enhanced to fully support datagram based services.
Connection based services start by acquiring their specific ServerSocket from a ConnectionEndpoint descriptor. This descriptor encapsulates information such as the particular port being used by the service, and a variety of optional or protocol-specific information. For example, in JDK 1.1 server sockets can bind to specific network interfaces on multihomed hosts, and server sockets can come in varieties such as SSL sockets as well as TCP sockets.
After acquiring their server sockets, services create their pool of service handler threads. Each of those handler threads then sits in a loop waiting for connection requests and then handling the protocol interactions on that connection. The size of the handler thread pool changes dynamically, and may be changed administratively while the service is running. New handler threads are created if needed, up to an upper bound. If handler threads are idle, they are destroyed, subject to a lower bound.
The core service framework noted above is always augmented by code to handle specific application protocols. For example, the HTTP service provides an HTTP service base class, and the handler threads which it creates understand both how to talk the HTTP protocol and how to dispatch to HTTP servlets.
There are standard administrative interfaces for services.
Server Processes are configured to start a set of services when they start. Each service is given its own thread group, and it then initializes as noted above. Services are specified according to which subclass of sun.server.Service they implement, and an instantiation and configuration protocol is used to initialize them.
For example, a single JavaServer process would normally include an administrative service and a handful of services such as HTTP and HTTPS services, and a web proxy service. The administration service may be used to update the server configuration data.
The HTTP service uses the base server framework to listen to the incoming HTTP requests. HTTP connections are thus given to HTTP service handler threads, which understand how to parse and generate HTTP protocol messages. (The HTTPS service is identical to the HTTP service, except that it uses an endpoint which has is configured to use SSL instead of TCP.)
Based on the URL in the request, the service handler performs any required authorization and name translation, and eventually determines which servlet will receive the request. This is driven by server configuration data.
Servlets are Java objects that conform to a specific interface. The HTTP service makes heavy use of servlets, though there can be servlets that are not used with the HTTP protocol. Servlets are similar to applets in that their classes may be dynamically loaded, either across the network or from local storage. However, they differ from applets in that they are faceless objects (without graphical interface of their own). Like applets, servlets may be identified by a URL address. Local servlets in a service can be identified by just the class name. Users can also supply a virtual name to a servlet at the time the servlet is loaded. This is useful for running multiple instances of the same servlet within an HTTP service.
Once a servlet has been loaded and initialized, clients can directly invoke the servlet by entering a URL of the form:
http://server_host/servlet/<servlet name>?arguments
Clients may also indirectly use the servlet by asking for a dynamically generated .html file. For example, all URLs prefixed with a given string might be handled by a single servlet, which uses the suffix to determine what data to produce. That data could be a mixture of statically and dynamically generated content, created from a combination of filesystem and database data as part of a web-based application.
There is a configured list of servlets to be initialized when the server starts. Servlets are also activated on demand, when a client's request needs to be handled by a servlet which has not yet been activated. Once activated, any given servlet handles requests until the server dies or until the server calls the destroy method on that servlet. For more details, see the Java Servlet API White Paper.
There are some core servlets that the HTTP service uses to provide standard HTTP functionality. For example FileServlet is used to respond to the file requests, and CgiServlet provides the base cgi functionality. There is also a core InvokerServlet that acts as a meta-servlet responsible for loading, invoking, and shutting down servlets invoked using the http://server_host/servlet/<servlet name> syntax. (Uploading and shutting down servlets is only enabled for privileged clients.) There is an internal Dispatcher servlet used to isolate partially trusted (or wholly untrusted) servlets in their own security "sandbox".
Note that the servlet interface does not enforce protection against concurrent access. This matters, because several handler threads may be using the same servlet concurrently; per-request data is held in arguments to a servlet (or on the stack) rather than in the servlet instance data. If a servlet has some shared state that it needs to protect, then it should do so by marking appropriate blocks and variables synchronized. For example, if multiple HTTP requests for files come in simultaneously, multiple handler threads will execute in the file servlet. Hence the file servlet needs to internally ensure thread-safety.
When a request is dispatched to the handler thread,
it first picks the servlet to which the request will be delivered
by applying the name translation rules. Then it
calls the service routine of the destination servlet.
Thus for fully trusted servlets (used internal to the HTTP
service, or loaded from the trusted .../servlets
directory) the cost of servicing a request is
equivalent to the cost of a procedure call.
For untrusted servlets, such as ones loaded over the network, the code is run in a thread which is isolated in a separate thread group in a Server Sandbox. As shown in the figure, there is an instance of a Dispatcher servlet for every such servlet. The service handler sends the request through the that servlet to a thread running in that sandbox, and waits for it to complete. Thus for untrusted servlets the cost of invoking a request is higher than in local servlet case. The sandbox for servlets in the server is similar in spirit to the sandbox for applets in web browsers.
Access to files is controlled using Access Control Lists (ACLs), which are a general and extensible framework.
Authentication and Authorization in the server and servlets is done on two levels. There is a server wide access control file, under the control of the web-administrator. Separate Access Control Lists can also be specified for any file or directory in the document tree. Additionally, ACLs can also be specified for a servlet. If a specific ACL is not specified for the requested file, directory or servlet, default server wide access control is applied. All the user information is passed to the servlet as part of the HTTP request in the service routine. So if needed, servlets can implement additional authorization as a part of the service() method.
Top
java-server-feedback@java.sun.com