[Catalina] Factoring to support non-HTTP servlets and protocols

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Andy Riedel <an...@hearme.com> has been corresponding with me privately
about using Tomcat as the basis of support for non-HTTP based servlets
and communications protocols, particularly in the wireless arena.  The
current Tomcat 3.x code is pretty heavily built on assumptions that it
is dealing with HTTP semantics.  However, that is not as much the case
with Catalina, and we're exploring what it would take to make the
architecture reflect the fact that not all servlets in the world need be
HttpServlet.

It's time to bring this discussion to the public list, because others
may well be interested in this topic as well.  To start that off, I'm
posting a couple of quesions that Andy just asked, and my initial
thoughts in reply.  (If you want to see the Catalina source code that we
are talking about, download the source distribution of Tomcat via CVS
and look at the contents of the "proposals/catalina" subdirectory.

ANDY:  What classes do you see being modified/extended by someone
implementing their own protocol?

CRAIG:  There are at least two general approaches that could be taken:

    1)  Write a Connector implementation that accepts
        requests via the desired protocol, and maps them
        into what looks (to the rest of Tomcat) like an HTTP
        request.  For protocols with lots of similarity to the
        semantics of HTTP, this might be quite feasible.

    2) Dispense with any vestige of HTTP, and go your own.
        This will involve at least the following:

        - Write your own Connector implementation.  Because
          this is also a factory for Request and Response objects,
          you will also need to write those (perhaps extending
          RequestBase and ResponseBase), as well as suitable
          implementations of the standard ServletInputStream and
          ServletOutputStream classes.

        - Implement at least one Container, which is responsible
          for accepting request/response objects from the connector,
          and mapping them to a particular Wrapper that manages
          the execution of a particular servlet.  Depending on the
          requirements, this could be a one-object implementation,
          or you might emulate the Engine/Host/Context hierarchy
          of the standard HTTP-based approach.

        - Management for sessions at the container level is going
          to be highly desireable.  It is quite possible that the
existing
          implementations of Manager and Session used for HTTP
          servlets will be sufficient, because they don't really have
any
          protocol dependencies.  Otherwise, you may need to roll
          your own implementations here as well.  (Highly desireable --
          if Tomcat supports things like session persistence and
          distributed processing for HTTP sessions, that support should
          work for non-HTTP sessions as well).

        - Depending on your requirements, custom implementations of
          the various utility components (Loader, Logger, Realm, and
          Resources) may or may not be required.  Of these, only
Resources
          will tend to be protocol-specific (for example, it needs to
know the
          document root of a Context in the HTTP based implementation).

        - Depending on your requirements, Valves that pre-process and
          post-process requests to your custom container can be
implemented.
          The standard Catalina machinery for managing these chains
          should work fine.

ANDY:  Should the Request, Response, and Session interfaces (and their
corresponding implementation classes) be factored into generic and
HTTP-specific versions?

CRAIG:  For Request and Response, this could easily be done because the
servlet API itself defines the functionality that would go in each layer
(ServletRequest versus HttpServletRequest, for example).  I will be
working on these two.  For sessions, I'm not sure there is any value add
in trying to build something generic, because (as mentioned above) there
is little or no protocol dependency in an HttpSession itself (other than
the fact that "Http" appears in the name:-).  What do you think?

Craig McClanahan

PS:  As an aid to developers that are interested in working on the
current Tomcat 3.x code, please prefix the subject line of messages
related only to Catalina with "[Catalina]".  That way, the messages of
no interest to these developers can be quickly skipped (or filtered into
a different folder for later perusal).