ApplicationServer vs. Tomcat

[Olel]

Hallo zusammen,

ich bin gerade dabei mir eine Systemarchitektur für eine Webanwendung zu überlegen. Dabei stoße ich auf die Frage, ob es sinnvoll ist einen "echten" ApplicationServer einzusetzen (wie JBoss, Geronimo/WAS CE, Glassfish) oder ob ein "einfacher" Tomcat ausreicht.

Ich versuche mal kurz die Anwendung zu umreißen, damit man ein Bild von den Anforderungen bekommt.

Die Anwendung wird zentral auf einem Server (oder vermutlich eher auf einer Server-Farm) laufen und von schätzungsweise 10.000 Clients genutzt, wobei wir von ungefähr 1.000.000 Anfragen pro Tag ausgehen. Die Anfragen werden alle lesend sein, schreibende Zugriff werden sehr selten (ca. 10/Tag) erfolgen.

Die Anwendung soll mit Spring/Hibernate implementiert werden.
Die Anwendung ist technologisch nicht besonders anspruchsvoll; der Anspruch besteht eher darin, dass relativ hohe Zugriffszahlen erreicht werden und dabei sehr gute Anwortzeiten notwendig sind.

Ich gehe also davon aus, dass wir serverseitig einen Cluster aufbauen werden und vermutlich auch einen Datenbank-Cluster (was relativ gut skalieren müsste, da zu 99% Lesezugriffe erfolgen werden). Die Frage ist nun, ob wir für die Cluster-Lösung (oder aus anderen Gründen) auf einen "echten" ApplicationServer setzen sollten/müssen oder ob für die Anforderungen auch Tomcat ausreicht.
Tomcat ist ja sogar performanter als alle echten AppServer (wobei das hier auch nicht Gegenstand der Diskussion sein soll). Was mich stutzig macht ist, dass es z.B. hier (http://www.javaworld.com/javaworld/jw-12-2007/jw-12-appservers.html?page=1) heißt, dass Tomcat nur bedingt clusterfähig ist. Dabei ist mir bisher aber noch nicht klar geworden, wo denn nun die Grenzen liegen.

Für ein bisschen Untersützung wäre ich daher sehr dankbar.

Gruß,
Ole

 

[tim staeglich]

Hi Ole,

Tomcat Cluster kann man z.B. mit dem Terracotta Framework realisieren.
Ansonsten kann die jeder halbwegs fähige Admin so ein Clustering anbieten.

Tomcat reicht für Deine Anforderungen aus. Ggf. muss man gucken, ob
der Kunde Vorgaben hat und bestimmte Features wünscht, die z.B. mit einem BEA Weblogic Server oder JBoss besser abgedeckt werden können.

Es gibt ohne hin öfter mal Probleme, wenn man Anwendungen auf andere App Server
portiert, da die Konfigurationsmöglichkeiten sich doch stark unterscheiden.

Spring & Hibernate unter Tomcat funktionieren normalerweise bestens, die wichtigste Entscheidung ist
also erstmal, für welche Plattform Du dich hier entscheidest..

Grüße, Tim

 

[Olel]

Hi Tim,

erstmal danke für Deine schnelle Antwort. Du schreibst, man könne Tomcat Cluster mit dem Terracotta-Framework realisieren. Ehrlich gesagt hatte ich gedacht, dass man da gar kein extra Framework braucht, sondern einfach die Tomcat-Bordmittel zum Webserver-Clustering plus einen HTTP Load Balancer (z.B. vom Apache HTTP Server) verwendet.

Einen Kunden, der Vorgaben macht, haben wir zur Zeit nicht, da das ganze zur Zeit eine Produktentwicklung ist. Wir können also erstmal frei entscheiden.

Du schreibst, das wichtigste sei jetzt erstmal sich für eine Plattform zu entscheiden. Meinst Du jetzt wirklich Plattform oder Framework? Da ist die Entscheidung für Spring & Hibernate im Grunde gefallen. Damit erhalten wir uns auch die Möglichkeit auf einem Tomcat zu beginnen und im Falle des Falles doch auf einen AppServer zu wechseln.

Was mir immer noch nicht ganz klar ist: Welche konkreten Funktionalitäten bietet mir ein AppServer an, die ich mit Spring & Hibernate auf einem WebServer wie Tomcat nicht bekomme? Mal abgesehen davon, dass ich eben kein EJB 3.0 nutzen kann, was ich mit Spring & Hibernate aber IMHO auch nicht brauche.

Grüße,
Ole

 

[tim staeglich]

Hi Ole,

im Prinzip hast Du deine Fragen ja schon beantwortet:

z.B. bietet JBOSS für u.a. Hibernate noch extra Features
und noch einige andere Dinge für Enterprise.
Welche das genau sind - da frag aber mal lieber einen JBOSS Experten,
da ich ja Entwickler bin und kein Admin.

Mit Plattform meine ich kein Framework, sondern die Server Plattform.

Da du EJB (3.0) nicht benötigst, wäre Tomcat eine relativ unkomplizierte Lösung.

Grüße, Tim

 

[Olel]

z.B. bietet JBOSS für u.a. Hibernate noch extra Features
und noch einige andere Dinge für Enterprise.
Welche das genau sind - da frag aber mal lieber einen JBOSS Experten,
da ich ja Entwickler bin und kein Admin.

Ok, Frage ist hiermit an einen AppServer-Experten weiter geleitet ;-)
Das ist für mich noch einer der entscheidenden Punkte, damit ich von einer gefühlsmäßig richtigen Entscheidung für Tomcat zu einer fundierten Entscheidung kommen kann.

 

[Oliver Gierke]

Meine kurze Antwort: AppServer (wie man sie heute definiert) sind überbewertet. Ich sitz gerade in einem Projekt in einem großen deutschen Kreditinstitut bei dem man sich für WebSphere entschieden hat und nun a) damit beschäftigt ist alles möglich wegzukonfigurieren, was nicht laufen soll und b) man effektiv den JNDI und zwei Datasources benutzt.

Für eine Webanwendung mit DB Backend braucht man keinen Applicationserver. Ich sage das bewusst so verallgemeinernt, da die Cornercases in denen sowas nicht gilt wirklich rar gesät sind. Wenn ihr nicht gerade XA Transaktionen fahren müsst oder auf eine komplexe Messagingmiddleware angewiesen seid, tut ihr euch mit einem AS keinen gefallen.

Für einen Tomcat zu entwicklen ist zum einen für den Entwicklungsprozess wesentlich komfortabler. Zum anderen sind so sachen wie Loadbalancing per Apache eine Grundübung für jeden versierten Admin. Proprietäres AS Clustering kostet oft Geld, wenn auch nur für den Support. Davon, dass man einen Tomcat auch wesentlich leichter in die IDE bekommt, will ich gar nicht weiter reden.

Mit Spring habt ihr eine Plattform, die es erlaubt unabhängig von der Laufzeitumgebung zu arbeiten. Das heißt ich würde dann auch versuchen, die Features zu nutzen und eher Sachen mit Springmitteln erschlagen als mit AS spezifischen. Ein Spring WAR kannst du zu 99% in jeden Servletcontainer werfen und es tut out of the box.

Fürs Clustering wurden der Loadbalancer und Terracotta ja schon angesprochen. Beides gute Ideen, ich würde allerdings mit dem Loadbalancer anfangen und versuchen damit klarzukommen (d.h. möglichst keine Sessionnutzung usw.).

Gruß
Ollie

 

[Cojote]

Hallo,

ich bin kein Experte auf dem Gebiet Clustering daher kann ich dir da jetzt nichts zu sagen.

Zum Application Server, besser gesagt zum JEE5 compliant Application Server. Wie der Name schon sagt bietet ein Application Server eine Implementierung aller von JEE5 geforderten Dienste, was folgende wären:
EJB3 Container
Servlet Container
JSP 2.1
JSF1.2
RMI-IIOP/RMI-JRMP
Java IDL (Corba)
JDBC3 und 2
JNDI 1.2
JavaMail
JMS
JAXP
JCA
JAAS
WS-Java EE
JTA
Webservice Metadata for Java EE
Java Logging API
Java EE Management API
Java EE Deployment API
JAAC

Das bekommst du bei nem Application Server alles frei Haus geboten + eine vernünftige Admin Konsole wo du sehr vieles konfigurieren und überwachen kannst. Allerdings oft zu dem Preis, dass du dich an den App-Server bindest. Die Spec sagt zwar dass das alles protierbar ist, die Realität ist jedoch oftmals ne andere.

Das ganze lässt sich auch mit Spring und Tomcat machen, nur musst du dir da selbst die Implementierungen suchen und in dein Programm einfriemeln. Das kann mitunter sehr witzig werden, gerade weil es ziemlich viele Abhängigkeiten gibt. (z.B. Hibernate braucht Bib. xy in Version 1, Webservice Framework braucht xy aber in Version 2)

Das Gespann Tomcat und Spring hat für mich immer etwas Bastel-Charakter. Meist wird es verwendet weil man die ganzen Konzepte eines App-Servers erstmal nicht braucht, nur wenn man sie irgendwann braucht entstehen im Laufe der Zeit dann sehr interessante Architekturen. Das muss nicht so sein! Wenn ich dich richtig verstehe brauchst du aber eigentlich keinerlei der genannten Dienste, also würde ich den Einsatz eine App-Servers auch in dieser Richtung hinterfragen.

Mit Spring denke ich trefft ihr auf jeden Fall ne gute Wahl, aus den Gründen die ollie schon genannt hat.

Das ist lediglich meine Meinung. Im Vordergrund würde für mich stehen:
Was sind die konkreten Anforderungen. Brauche ich Konzepte wie Lastverteilung und was bieten App-Server da mehr (die Frage hast ja schon gestellt)
Will ich irgendwann EJBs einbringen, z.B. für zustandsbehaftete Komponenten. Wer bedient das Teil, wie sind die Wartungsanforderungen.

 

[Olel]

Hi Ollie,

herzlichen Dank für Deine Einschätzung. Wir werden dann auf jeden Fall mal mit einem Tomcat starten.

Eine Frage hat Dein letzter Halbsatz bei mir aber noch offen gelassen. Du schreibst, dass wir bzgl. Clusterin zunächst versuchen sollten mit dem Loadbalancer klar zu kommen und dazu auf Sessionnutzung zu verzichten.
Das ist mir jetzt noch nicht klar. Wie funktioniert der Loadbalancer so grob und was für Probleme gibt es dann mit Sessions? Und welche Art von Sessions meinst Du hier? Eine Webanwendung ohne HTTP-Session kann es ja IMHO nicht geben, oder?

Gruß,
Ole

 

[Oliver Gierke]

EJB3 Container
Servlet Container
JSP 2.1
JSF1.2
RMI-IIOP/RMI-JRMP
Java IDL (Corba)
JDBC3 und 2
JNDI 1.2
JavaMail
JMS
JAXP
JCA
JAAS
WS-Java EE
JTA
Webservice Metadata for Java EE
Java Logging API
Java EE Management API
Java EE Deployment API
JAAC

Genau das ist das Problem. Die APIs die er aus diesem Wald wirklich braucht bekommt er auch mit dem Tomcat. Wozu da eine so große Mühle hinstellen?

Das bekommst du bei nem Application Server alles frei Haus geboten + eine vernünftige Admin Konsole wo du sehr vieles konfigurieren und überwachen kannst. Allerdings oft zu dem Preis, dass du dich an den App-Server bindest. Die Spec sagt zwar dass das alles protierbar ist, die Realität ist jedoch oftmals ne andere.

Richtig. Hier prüfe man Aufwand und nutzen. Wenn man mit Spring und Tomcat anfängt kann man sehr leicht später auf einen AS wechseln, wenn sich die Notwendigkeit ergibt. Umgedreht geht das natürlich auch, wenn man gut aufpasst.

Das ganze lässt sich auch mit Spring und Tomcat machen, nur musst du dir da selbst die Implementierungen suchen und in dein Programm einfriemeln. Das kann mitunter sehr witzig werden, gerade weil es ziemlich viele Abhängigkeiten gibt. (z.B. Hibernate braucht Bib. xy in Version 1, Webservice Framework braucht xy aber in Version 2)

Von einem vernünftigen Dependencymanagement schützt dich auch der Einsatz eines ApplicationServer nicht. Aber wozu gibt es denn Buildtools wie Maven?

Das Gespann Tomcat und Spring hat für mich immer etwas Bastel-Charakter. Meist wird es verwendet weil man die ganzen Konzepte eines App-Servers erstmal nicht braucht, nur wenn man sie irgendwann braucht entstehen im Laufe der Zeit dann sehr interessante Architekturen.

Dann ist es Zeit sich nach einem guten Architekten umzusehen. Wie gesagt, für mich gibt es zwei, maximal drei gründe für einen ApplicationServer wie es sie heute gibt:

1. XA Transaktionen
2. Komplexes Messaging
(3. Administrierbarkeit - wobei ich hier die Erfahrung mache, dass kein Admin der Welt in irgendwelchen proprietären Webfrontends oder JMX APIs rumwühlen will. Zumal die Information die man über diese bezieht auch recht technisch ist und meist mehr Semantik bzw. fachliche Info gefordert ist, die man dann eh in der Anwendung selbst bereitstellt)

Will ich irgendwann EJBs einbringen, z.B. für zustandsbehaftete Komponenten. Wer bedient das Teil, wie sind die Wartungsanforderungen.

Wenn man es übertreiben will, sind Zustand und Skalierbarkeit wie Feuer und Wasser.

Eine Frage hat Dein letzter Halbsatz bei mir aber noch offen gelassen. Du schreibst, dass wir bzgl. Clusterin zunächst versuchen sollten mit dem Loadbalancer klar zu kommen und dazu auf Sessionnutzung zu verzichten.
Das ist mir jetzt noch nicht klar. Wie funktioniert der Loadbalancer so grob und was für Probleme gibt es dann mit Sessions? Und welche Art von Sessions meinst Du hier? Eine Webanwendung ohne HTTP-Session kann es ja IMHO nicht geben, oder?

Es hat sich eigentlich als Bestpractice herausgestellt keinen Zustand in der HTTP Session zu halten.

Es stellt sich die Frage, wie wichtig die Daten in der Session sind. Bzw. wie groß ist das Problem, wenn die Session wegfliegt. Wenn ich denn unbedingt Zustandsdaten halten muss, ist die Frage wo ich das tue. Das kann ich in der HTTP Session tun, aber auch über ein Datenbankbackend. In Bezug auf die Performance kommt man caching auf ähnliche Werte wie beim Arbeiten mit der HTTP Session.

Der Vorteil eines solchen Ansatzes ist, dass man zum einen nicht auf einen Servletcontainer als Sessionmanager angewiesen ist und man Datenbanken zumeist eh schon clustert, so dass einem der Overhead die Session clustern zu müssen wegfällt. In diesem Fall reicht einfaches Loadbalancing plus DB Cluster. Sonst benötigst du zusätzlich halt einen Sessioncluster.

Gruß
Ollie

 

[Olel]

Es hat sich eigentlich als Bestpractice herausgestellt keinen Zustand in der HTTP Session zu halten.

Es stellt sich die Frage, wie wichtig die Daten in der Session sind. Bzw. wie groß ist das Problem, wenn die Session wegfliegt. Wenn ich denn unbedingt Zustandsdaten halten muss, ist die Frage wo ich das tue. Das kann ich in der HTTP Session tun, aber auch über ein Datenbankbackend. In Bezug auf die Performance kommt man caching auf ähnliche Werte wie beim Arbeiten mit der HTTP Session.

Der Vorteil eines solchen Ansatzes ist, dass man zum einen nicht auf einen Servletcontainer als Sessionmanager angewiesen ist und man Datenbanken zumeist eh schon clustert, so dass einem der Overhead die Session clustern zu müssen wegfällt. In diesem Fall reicht einfaches Loadbalancing plus DB Cluster. Sonst benötigst du zusätzlich halt einen Sessioncluster.

Verstehe. Wenn ich mir nochmal so Gedanken über unsere Anwendung mache, dann stelle ich fest, dass wir im Prinzip zwei Usergruppen haben. Die eine Gruppe gibt neue Daten ein, greift also schreibend zu und benötigt dafür auch eine länger laufende Session (bzw. Transaktion), da eine Eingabe sich über mehere Minuten oder Stunden hinziehen kann. Die andere Gruppe liest nur Daten und wird definitiv niemals schreiben.
Die schreibenden User werden aber durchschnittlich nur 1 Zugriff pro Tag haben, die lesenden hingegen bis zu 1 Million. Daraus könnte man die Idee ableiten, dass für die lesenden User eine Menge von Tomcats mit Loadbalancing (ohne Clustering) zur Verfügung steht und für die schreibende Gruppe ein dedizierter Tomcat-Server, der vollkommen ohne Loadbalancing oder Clustering auskommen kann, dafür aber mit langlaufenden Sessions zurecht kommt. Alle Tomcats greifen dann natürlich auf das gleiche DB-Server-Cluster zu.