Technical Architecture
This chapter provides a high-level view of the nevisProxy architecture including a coarse-grained view of component internals as well as a detailed description of the concepts implemented.
Software architecture
The core architecture of nevisProxy is based on a J2EE servlet API. This means that there are two groups of core components:
- The servlet container
- The various filters and servlets that implement the required functionality
This approach has the following advantages:
- The required functionality is implemented by combining filters and servlets. Each of these components hides the implementation of its functionality, i.e., replacing a servlet/filter will not have any impact on the other servlets/filters.
- The specification and implementation of all filters/servlets is based on the well-established API of the Java 2.3 Servlet Specification.
- The configuration of filters/servlets is also based on the Java 2.3 Servlet Specification featuring some extensions for more flexible filter and servlet mapping.
- The configuration of the servlet container itself is simpler and does not depend on the Apache version used (the Apache configuration is generated at runtime).
- Apache dependency was reduced to a minimum and is limited to the 'glue code' and the use of the server front end .
The following chapters provide an overview of the technical architecture of the servlet container and a description of the interaction between individual filters and servlets.
Servlet container
The Servlet Container is also referred to as Navajo (refer to Figure 2). The nevisProxy servlet container is a pure C++ implementation of the Java 2.3 Servlet Specification. For the handling of incoming HTTP requests, it resorts to proven Apache 2.x and mod_ssl functionality. The [figure] below illustrates the internal design of the nevisProxy servlet container:
From a runtime point of view, the servlet container is an Apache web server with one customized module.
Filters and servlets
The required functionality is implemented as a configurable set of filters/servlets. Each filter/servlet implements some limited and clearly specified functionality. The various filter/servlet implementations do not depend on each other. This approach has the advantage that replacing individual filters or servlets will not affect the other filters/servlets. The required nevisProxy functionality is implemented by combining filters and servlets. nevisProxy uses filters and servlets for the following general purposes:
- Filters implement the required request processing by calling the request dispatcher and the filter chain of the servlet container.
- Servlets are responsible for retrieving responses from a remote service. The term 'connector servlet' is often used.
The sequence diagram in the [figure] below illustrates interaction of nevisProxy filters and servlets: