TomcatではなくJBossを選ぶ○○の理由
java-ja忘年会でharu860さんに聞かれたのでエントリを書くよ。と思ってざっくり書いて放置していましたすみません。この質問へのよくある回答として「EJBを使うとき」みたいなものがありますが、この回答は多くの場合何の役にも立ちませんね。このような回答をする人はJBossをあまり良く理解していない可能性があります。
というわけで、JBossを使っているユーザがどのようなモチベーションでTomcatではなくJBossを使うのか、もしくは完全にJBossに乗り換えているのか、実例ベースの理由をいくつか紹介しましょう。
機能
Tomcatで提供される機能は基本的にServlet, JSP, JDBC接続プールのみで、他のものは提供されていません。シンプルですが、他のものが必要になったときに、それらをインテグレーションするコストが発生するなど、少し面倒なことになります。
TomcatになくてJBossにあるものを軽く列挙してみます。
どれも正しく使えばものすごい強力な技術です。例えば百万メッセージを短時間で分散処理したい、という要件があったときに、JBossだったらノード8台のJMSクラスタに百万メッセージ投げて全ノードで非同期分散処理、共有データはDBの他に分散キャッシュも利用でき、アプリではMDB書くだけでおしまい、という設計ができます。
他にもメールがMDBで処理できるとか定時処理書くとかJMXとかbshスクリプトで柔軟な運用ができるとか実はmod_rewriteの機能が使えるとかちょこっと設定するだけでJPAでのDBアクセスキャッシュしてくれるだとか細かい機能はいっぱいあります。
結局のところ機能についてはこういった「JBossの持つ機能を有効活用できるユースケースはあるか？」というところが技術的な判断基準になります。ただ、上に挙げたような「JBossの持つ機能」というのは一覧表で見せられてすぐ理解応用の効くような技術ばかりではないですし、使いどころをまともに判断もできないでしょうから、普段からある程度素振りをしておく必要があります。
アプリケーションサーバの種類の統一
あるプロジェクトではTomcatでいい、他のプロジェクトでは機能的にJBoss、となった時点で管理インタフェースだとか設定ファイルの位置や内容だとかEclipseプラグインだとか運用方法だとかがいろいろ違って、開発や運用するにあたってそれぞれを別々に覚えなきゃ状態になってしまい非常に面倒です。ではどっちかに統一しましょう、となったときに機能の少ない方には倒せないのでJBossのほうに統一することがほとんどです。
JBossは必要の無いサービスは削除できるので、Tomcat相当なものにしたいのであればServlet, JSP, JDBCだけ使える軽いプロファイルを設定すれば良いでしょう。
運用管理の容易性
上の機能と少しかぶりますが、運用管理の容易性はTomcatがほぼ何も提供していないのに対し、JBossはJMXアクセスなどかなり便利です。カスタムの運用管理ツールやJMX MBeanなんかも簡単に作れます。
