読者です 読者をやめる 読者になる 読者になる

nekop's blog

OpenShift / JBoss / WildFly / Infinispanの中の人 http://twitter.com/nekop

TomcatではなくJBossを選ぶ○○の理由

java 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がほぼ何も提供していないのに対し、JBossJMXアクセスなどかなり便利です。カスタムの運用管理ツールJMX MBeanなんかも簡単に作れます。

柔軟性

JBossは大量の機能、サービスがあり、そしてそれ動かす柔軟な基盤Microcontainerを持っています。Java EEアプリケーションという枠に収まらないようなカスタムのサービスを作成し、デプロイして動作させることも簡単にできます。JMXサービスが典型的な例です。

JBoss Seam

柔軟性の高い非常にパワフルなWebアプリケーションフレームワークです。Googleで.seamというSeamのデフォルト拡張子を検索するとわかりますが、既に日本でも多くのユーザが利用している実績があります。JBoss ASとJBoss Seamは一番最初にテストされ、また一番よく使われている組み合わせであるので、Seamを利用する場合はアプリケーションサーバJBossにしたほうがいいよね、ということでSeamの存在がJBossへ移行する一因となっています。

とりあえず思いつくだけ書いてみましたが、この記事は後でフィードバックなども含めて追加していく予定です。