Microkernelアーキテクチャ

昨3月にJBoss関係の一般セミナーを聞きにいったとき，JBossはマイクロカーネルアーキテクチャだと教えられた．その当時は，J2EEサーバに「カーネル」なんて大層な概念の実装が施されているなどと知りもしなかったので，J2EEサーバの話でカーネルという単語が出てきたこと自体にまず驚き，そしてさらにJBossがマイクロカーネルなるアーキテクチャパターン（当時はアーキテクチャパターンという言葉も概念も知らない）を採用しているということに驚いた．

人から聞いた話，という感じでJBossを説明するときに「JBossはJMXを基盤としたマイクロカーネルアーキテクチャを採用しています」という話をすることは簡単にできたけど，なぜマイクロカーネルなのか，何が良いのかは実のところ，よくわかっていないという状態だった．

マイクロカーネルという言葉から直感的に連想されるイメージから，またOSについてのアーキテクチャ（モノリシック対マイクロカーネル）について知ったことから，なんとなくマイクロカーネルがどんなものかというのは分かった．でもOSの分野で成功しているプロダクト（Windows，Linux）はどれもモノリシックカーネルであり，マイクロカーネルは理屈の上ではモノリシックカーネルよりも良くとも，パフォーマンスまで含めて評価した場合にはモノリシックの方が優位というのが見えてきた実情だった．

ではもう一度，JBossはなぜマイクロカーネルアーキテクチャを採用しているのか．マイクロカーネルの利点は，カーネルがコア機能による最小構成となっていてそれ以外の機能は全てプラグイン形式で取り扱われることから，大胆で柔軟な構成変更が行えるという点だ．

J2EEは非常に多数のサービスによって構成される．従って，あるサービスの実装だけをオンライン中にアップデートしたいということがあるかもしれない．その場合には，マイクロカーネルであることのメリットを生かせる，とまあ，これくらいにしか僕は考えることが出来ていなかった．

ところが今日，かなりこのことについての見方が変わることとなった．

一般的に，JSP+Servlet+JNDI+JDBCという環境ならTomcatを使い，そこにEJBが入るならJBossと言われている．確かについ先日まではその捉え方を僕も行っていた．しかし，この考えは，今でははっきりいうが，必ずしも正解ではない．

サービス/設定ファイルレベルでのJBossの整理をした．MBeanレベルでのJBossの整理をした．起動プロセスからJBossのカーネルが起動するあたりまで（MBeanServerの起動と必須なDeployerの生成/登録）のソースコードは読んだ．

その結果，やっと分かった（単に気づくのが遅い？）んだが，JBossというのは，EJBコンテナを使う/使わない，WEBコンテナを使う/使わないに関わらず，常に最適な状態で利用が可能なものだ．

JBossのカーネル（注：厳密にカーネルの定義されてるわけではない）は，MBeanServerと必須Deployer（SARDeployer&JARDeployer）だけで，つまりマイクロカーネルで，それ以外は必要なものだけを起動時にプラグイン（MBeanの生成/登録）すれば良いという話が正しい理解．

例えば，HSQLDBだけが稼動しているようなJBossとか，そういうのもありだし，むしろ利用側の要件に応じて，自由に積極的にコンフィギュレーションすべきもの，ということ．

HSQLDBだけを使うならHSQLDBを直接スタンドアローンで起動すればいいじゃんと思うかもしれないけど，JBoss上で稼動させればJMXを通じて管理ができる．どっちにしろ管理はしないといけないんだから積極的にJMXマイクロカーネルを利用したほうがよいね．

そんなわけで，JMXマイクロカーネルアーキテクチャの採用というJBoss側の選択は，回避不可で必要不可欠なものだったということが分かったのでした．

ちゃんちゃん♪