Ein traditioneller Grund für einen Application Server ist ja die Verwaltung von Ressourcen. Mittlerweile kommen mir da allerdings Zweifel. Eine recht unstrittige Ressource, die ein Application Server verwalten muss, sind Threads und Sockets. Auch die effiziente Verwaltung dieser Ressourcen ist sehr wichtig und wird zum Beispiel auch von Web Servern implementiert.
Dann ist man allerdings beim Pooling. Das schlägt an verschiedenen Stellen zu. Bei EJBs ist hier die Frage, ob ein Pooling überhaupt noch sinnvoll ist, weil das Erzeugen von Objekten mittlerweile sehr billig ist. Es kann sogar sein, dass Pooling eine wenig effiziente Lösung darstellt. Dies ist zum Beispiel der Fall, wenn man mit einem Singleton auskommt, weil das Objekt sowieso Thread-safe ist. Genau das passiert öfter, als man denkt, denn die typischen Server-Objekte sind zustandslos. Wenn sie aber zustandslos sind, gibt es auch kaum etwas, worum sich Concurrency Probleme ranken können. Wenn dann die Objekte, die dort aufgerufen, auch alle genauso strukturiert sind, hat man gewonnen. Aber selbst wenn dies nicht der Fall ist, kann man nachträglich (mit Spring natürlich) Pools einbauen und dadurch nur dort Pooling verwenden, wo es sinnvoll ist.
Bei Datenbank-Verbindungen stellt sich die Frage, ob man nicht mit einem eigenen Verbindungs-Pool in der Anwendung nicht genauso weit kommt. Dafür gibt es unterschiedliche Open-Source Implementierungen.
Das bedeutet eigentlich, dass man mit einem Ansatz, einen Web Server zu verwenden, auch recht weit kommen sollte, weil man dort eben nur noch die Verwaltung von Threads und Sockets hat, was eben auch die wesentlichen Ressourcen sind, die ein Application Server unter Kontrolle hält. Als Unterschied bleibt eigentlich nur noch Features wie 2 Phase Commit mit einem Transaktionsdienst wie JTA, was aber eben keine Ressourcen Verwaltung ist... ¶ 00:29
