JavaでWEBアプリを組むにはまずServletを用い、アクセスの度にクラスからオブジェクトを生成しないようにする。
なぜ、そうなったのかと云えば、
Servletを採用した当時はハードウェアもソフトウェアも圧倒的に貧相だったからだ。
だから、もうServletなんぞ捨てて、ポートを直接listeningしか方が数段良いという本音を「サーバーもJavaScriptで作ろう」というキャッチコピーでやっているのがNode.js派だ。
直接listeningしているのだから、apacheやTomcatが適当にはぐらかしているブロッキングI/O（他の処理に比べ１桁も２桁も遅い処理が混入していることによるスループット低下）問題にまともにぶち当たるのはTCP/IP通信の碇石だ。
いずれは、ポートListenerChainクラスをインスタンス化するとか、ブロッキングI/O依存クラスをブローカークラスのインナークラスにするリファクタリング機能とかで妥協するだろうから、それまでNode.jsは待ち状態。
そんなこんなで、J2EEちゃん。
エンタープライズな準廃SE用パッケージとして今でもServletやEJBを大事にしてる。
とは云ってもJavaなWEBアプリ・コンテナ（Tomcatなど）がWARファイルの中のServlet派生クラスにアクセスする時点でマルチスレッドで解決しているのであってJ2EEはただのゲスト・ライブラリィ。だからデプロイも簡単。
一気にスタックを食いつぶす勢いでアクセスされればあっさりクラッシュするけど、それはJavaなWEBアプリ・コンテナの問題であってJ2EEの問題ではない（つまりサーバー運用の問題）と云い訳ができてしまうから始末が悪い。
勿論、ServletやEJBを直接アクセスするのは誰でも嫌（理由：サラっとドキュメントを見ればスパゲッティーなコードしか出来ないのがすぐ判る）なので、色々とワークフレームが作られた。
その代表例がStrutsだ。労働集約型でweb.xmlから参照されるstruct.xmlなど多数のXMLファイルにマークアップを入れ、その通りにたくさんのコードを埋めていくのでスケジュールを立てやすく見通しも原則的には良いハズだが、その場凌ぎのたくさんのコードを埋めていくというのがクセもので、粗製乱造された仕様書がピンボケ（意味：意味不）なのは避けられず、その類の仕事は前世期から上手くいった試しが無い。
その後、Spring、Seasar,wicket あるいは Struts 2 と Java WEBアプリのワークフレームは変遷を続け 軽量ワークフレームまで 出てくるが、
【帯に短し襷に長し】
の状況はそのまんまだったとさ。
メデタシメデタシ？