Abbildung 4: Die Catalina-Basisarchitektur
Die Basisarchitektur von Catalina ist durch die Schnittstellen Server, Service, Connector, Engine, Host und Context festgelegt. Diese Bezeichner sind schon aus dem Abschnitt "Konfiguration" als Elemente der "server.xml" bekannt. Für die Gemeinsamkeiten von Engine, Host und Context wurde zusätzlich die Schnittstelle Container definiert. Zusammen bilden sie ein Kompositum.
Abbildung 4: Die Catalina-Basisarchitektur
Server ist der Repräsentant für die JVM-Instanz, in der Tomcat läuft. In jeder Tomcat-Konfiguration existiert daher nur genau ein Server, was auch durch das Root-Element <server> in der "server.xml" deutlich wird.
Server ist für den Shutdown-Vorgang von Tomcat verantwortlich, der dadurch ausgelöst wird, daß ein bestimmtes Shutdown-Kommando (standardmäßig "SHUTDOWN") an einen bestimmten Shutdown-Port (standardmäßig 8005) gesendet wird. In Server sind daher Zugriffsmethoden für Shutdown-Kommando und -Port deklariert.
Da ein Server einen oder mehrere Services enthält, sind außerdem Methoden für diese Menge deklariert.
Unter einem Service werden alle Connectors zusammengefaßt, die auf dem gleichen Container (typischerweise der gleichen Engine) arbeiten. So ermöglicht ein Service, daß eine Engine über mehrere verschiedene Connectors erreichbar ist.
Ein Connector verbindet Tomcat mit der Außenwelt. Er ist dafür verantwortlich, daß Requests von Clients empfangen und Responses an diese zurückgeschickt werden. Dazu ist er an einen bestimmten Port gebunden.
Weiter besteht seine Aufgabe darin, aus dem eingehenden Datenstrom ein passendes Request-Objekt sowie ein leeres Response-Objekt zu erzeugen und dieses Objektpaar dann an den richtigen Container (typischerweise einer Engine) weiterzuleiten. Nachdem dieser seine Arbeit erledigt hat, muß der Connector schließlich das Response-Objekt bzw. im Fehlerfall eine geeignete Fehler-Response an den Client zurücksenden.
Engine stellt die Catalina-Servlet-Engine und damit die oberste Ebene der Requestverarbeitung dar. Sie entscheidet anhand der Details aus dem Request-Objekt, an welchen der ihr untergeordneten Container (typischerweise Hosts) das Request-Response-Objektpaar weitergeleitet wird. Wird Tomcat im Add-on-Szenario betrieben, ist die Engine nicht notwendig, da ihre Aufgabe bereits durch den zugrundeliegenden Webserver abgedeckt ist.
Damit mehrere Websites auf dem gleichen Webserver betrieben werden können, wurde das Konzept der "virtuellen Hosts" entwickelt. In Tomcat werden virtuelle Hosts durch die Schnittstelle Host abgebildet. Sie muß anhand des Requests entscheiden, an welchen Context das Request-Response-Objektpaar weiterzuleiten ist. Jeder Host hat einen Namen und eine (möglicherweise leere) Menge von Aliasnamen.
Sofern die Tomcat-Konfiguration eine Engine enthält, muß mindestens ein (Default-)Host definiert sein. Fehlt die Engine (weil Tomcat als Add-on betrieben wird), wird auch kein Host benötigt, weil die Context-Zuordnung bereits durch den zugrundliegenden Webserver geleistet wird.
Die Schnittstelle Context repräsentiert die Schnittstelle javax.servlet.ServletContext aus der Java Servlet API, gemäß der pro Web-Application genau ein ServletContext festgelegt ist. Context kann also auch als Repräsentant für eine Web-Application aufgefaßt werden. Da eine Web-Application unter Umständen aus mehreren Servlets besteht, kann ein Context auch mehrere Wrapper verwalten, die ihrerseits einer konkreten Servlet-Definition bezüglich des zugehörigen Deplyoment Descriptors (web.xml) entsprechen.
Die verschiedenen Schnittstellen der Catalina-Basisarchitektur werden durch entsprechende Standardklassen implementiert, die im Paket org.apache.catalina.core zusammengefaßt sind. Ihre Namen richten sich nach dem Namen der implementierten Schnittstelle: StandardServer, StandardService, StandardEngine, StandardHost, StandardContext. Die letzten drei erben zusätzlich von der abstrakten Klasse ContainerBase, in der für fast alle Methoden von Container eine die Default-Implementierung vorgenommen wurde.
Abbildung 5: Die Standardklassen der Catalina-Architektur
Eine Klasse StandardConnector ist natürlich nicht vorhanden, da ja jede Implementierung der Schnittstelle Connector auf ein bestimmtes Protokoll zugeschnitten sein muß. Statt dessen steht mit der Klasse org.apache.catalina.connector.http.HttpConnector ein konkreter Connector für HTTP zur Verfügung.