At Agent startup, the servlet container loads, initializes, and deploys the servlets so they are ready and waiting for requests. When a request arrives, it enters the Agent through the connectors, which pass it to the default http handler chain, then to the servlet handler, and finally to the servlet container. The container translates the request into C++ objects and passes it to the proper servlet. The servlet processes the request and returns a response to the handler chain, which passes it back up to the Agent’s connectors and back to the requestor.

The servlet container is designed to perform well while serving large numbers of requests. A container can hold any number of active servlets, filters, listeners, or named objects. Both the container and the objects in it are multithreaded. The servlet container creates and manages threads as necessary to handle incoming requests. The container handles multiple requests concurrently, and more than one thread may enter an object at a time. Therefore, each object within a servlet container must be threadsafe.

Figure 1 presents a diagram of a running container. In the diagram, the servlet container has a single network connector. The container manages two contexts, each of which contains a number of objects.

Servlet requests are received through the connectors in the HydraExpress message transport layer. A servlet need not interact with the network itself. The Agent connectors handle the details of the network connection. The servlet container handles the necessary translation of the incoming message data format to the C++ objects needed by the servlet.

For a detailed discussion on connectors, see Chapter 5, “Connectors,” in the HydraExpress User Guide.

The servlet container can manage any number of distinct applications. A C++ application consists of any number of servlets, filters, listeners, and static Web pages. A set of components working together is a web application. The servlet container uses a context to group related components. The container loads the objects within a context as a group, and objects within the same context can easily share data. Therefore, each context usually corresponds to a distinct Web application.

At servlet execution runtime, all servlet context directories must be deployed to the servlet deployment directory, <installdir>\apps\servlets. Each directory within the servlets directory defines a context. The name of the context directory is the name of the context and determines the path to the servlets within the context. Each context directory contains a WEB-INF directory, and may also contain files related to the application. Each WEB-INF directory contains a web.xml file. The web.xml file describes the configuration of the context and the servlets, filters, and listeners that occupy the context.

For example, the directory structure below describes two contexts, one named orders and one named catalog. The catalog context contains a static HTML page, intro.html.

If the HydraExpress Agent is at http://example.com, an HTML page at <installdir>\apps\servlets\catalog\intro.html appears at the URL http://example.com/servlets/catalog/intro.html. Likewise, servlets defined in the <installdir>\apps\servlets\orders\WEB-INF\web.xml file appear at URLs underneath http://example.com/orders.

For details on creating contexts and deploying servlets within contexts, see Chapter 4, “Configuring Objects in the Servlet Container.”