日本で作られたオープンソースのアプリケーション・サーバー「Seasar」の新版では，
「IoC（Inversion of Control）コンテナ+AOP（アスペクト指向プログラミング）」という最先端の機能を実装した。Seasarは，EJBコンテナへのアンチテーゼとも言うべき設計思想を持つオープンソースの軽量コンテナだ。マネースクウェア・ジャパンのインターネット外国為替取引システムで使われた実績を持つ。同様の設計思想IoC+AOPに基づく軽量コンテナは海外でも登場しつつある。この最先端のソフトウエア動向について，IT Proの寄稿者であるITエンジニアarton氏が報告する。（日経BP Javaプロジェクト編集部）
4月10日、都内でオープンソースIoCコンテナSeasar2（沖縄の狛犬のことでシーサーと発音する）の説明会が開催された。説明会には、Seasarユーザーの他に，IoCコンテナやAOPに関心を持つ約90人の技術者が集まり，これらの技術に対する関心の高さがうかがえた。
集まったのは，Seasarユーザーのメーリングリスト参加者の約40名の他，主宰のSeasarプロジェクトのスポークスマン役を担当されている，スターロジック代表取締役CEOの羽生章洋氏の「はてなダイアリー」での告知を見て集まった技術者達だ。ちなみに筆者もその1人ということになる。
この集まり自体にも，興味深い点が幾つも見られた。例えば，集まった顔ぶれがオープンソースという言葉が持つイメージ（UNIXハッカーの集団のような）とは随分異なる点だ。全体的に年齢層が高い。おそらく学生はいなかったのではないだろうか。実際に直面しているシステム開発にどれだけ利用可能かを探るというような視線を感じた。それはSeasarが，現在のJ2EEを取り巻く最も先端的なトピックであるIoCコンテナ＋AOPの実装だということが影響しているのだろう。また最初に書いたように，「はてなダイアリー」がもたらしたこれまでとは微妙に異質な技術者コミュニティのあり様も非常に興味深いものだ。
しかし本稿では，このイベントそのものの論考ではなく，このIoCコンテナ＋AOPという目新しい概念について解説する。IoCコンテナ＋AOPは，おそらく今後3年間のJ2EEをリードする技術だと考えられる。だが，先端技術だけに広く認知されているとは思えないからだ。
「第3のコンテナ」IoCコンテナとは，そしてAOPとは
本稿では以下の3点について解説する。
1点目は，現在サーブレットコンテナ，EJBコンテナに続く第3のコンテナと目されているIoCコンテナについて概要を解説する。
2点目は，オブジェクト指向プログラミング（以下OOPと略記）の補完技術として注目されているアスペクト指向プログラミング（以下AOPと略記）技術について概要を解説する。
3点目に，IoCコンテナとAOPの組み合わせがなぜ注目されているのかについて解説する。
ただし，いずれもこれまでの約6年間に及ぶJ2EEの歴史的な考察から生み出された開発者達の知恵の成果とも言えるものであるために，本稿の限られた紙数で完全な解説ができるわけではないことを最初にお断りしておく。
最初のIoCコンテナのIoCというのは，Inversion of Control（制御の反転）という意味である。これだけでは意味が取りにくいため，マーティン・ファウラーのようにDependency Injection（依存性注入）パターンと呼ぶことの提案（参考： 角谷氏による翻訳）もある。
制御の反転とは，一般的なフレームワークやイベントドリブンプログラミングで利用される仕組みで，ハリウッド原則――（プロデュサーが役者に対して）電話をしないでくれ，必要になったらこっちから電話をするから――とも呼ばれるものだ。IoCコンテナを利用すると，個々のオブジェクトは自分が利用するオブジェクトの生成についてはIoCコンテナに一任できる。利用するオブジェクトを生成するかわりに，あらかじめ用意しておいたインタフェース（通常はコンストラクタか，設定メソッド）を通じてIoCコンテナが生成後に設定するからだ。そのため，開発時，テスト時，稼働時，それぞれにおいてのコンポーネント間の分離度を高めることが可能となる。
次のAOPだが，一言で片付ければOOPの縦型の組み合わせに対して，横型の組み合わせをサポートする機能を追加したプログラミング言語ということになる。ここでの縦型というのは，あるクラスのメソッドの置き換えは，継承関係（親子関係）を持つクラスでのみ許されるということである。一方の横型というのは，継承関係と関わりなく，メソッド単位に別途定義した処理を混入可能なことを意味する。
OOPではメソッドを継承関係の下位のクラスで置き換えることができる。この機能を利用することで，たとえばEJBコンテナが配備記述子（デプロイメント・デスクリプタ）に指定されたトランザクション境界の設定などをEJBのメソッドに付加することが可能となる。配備されたクラスを継承するクラスを生成して指定されたメソッドの周りにトランザクションの呼び出しができるからだ。また，CMP Entity Beanが抽象クラスで良いのも，EJBコンテナが具象クラスを配備時に継承して完成させるからである。
AOPでは，同様な処理のために継承したクラスを生成する必要はない。単にクラスとメソッド名を特定できれば，そこに後付けで処理を追加できるからである。
これだけであれば，とりたててAOPにメリットはないように見えるかもしれないが，逆もまた真なことに注目していただきたい。継承と無関係に後から処理を追加できるということは，EJBを開発する場合に必須な，あらかじめEJBで規定されたクラスを継承するという作業も不要化できるということを意味するからだ。特にSeasar2が提供するAOPでは，インタフェースを実装する場合に共通化可能なメソッドについてはコンパイル時には実装しなくても，AOPの機能によって実行時に処理を追加できる（抽象クラスの利用も可能）。このため，互いに継承関係を持たないが，ほとんどのクラスで共有される処理というものについては余分な記述が不要化されるというメリットもある。
かくして，3点目に挙げた「IoCコンテナとAOPの組み合わせが注目される理由」が出てくるのだ。
「IoCコンテナ」＋「AOP」＝最先端，その理由
IoCコンテナを使用することで，オブジェクト間の依存関係は実行時まで遅延させることができるし，コンポーネントは疎結合されているため，ユニットテスト時と実行時で特別な考慮は不要となる。また，AOPを利用することで，トランザクション境界の設定のような作業は，EJBと同様に，オブジェクトの実装からは分離することができる。
このことは，現在EJBに課せられている設計やテストの不自由さから開発者が解放されることを意味する。つまり，IoCコンテナ＋AOPの目的はPOJO（Plain Old Java Object――EJBのような特殊なオブジェクトではない普通のオブジェクト）を直接アプリケーションサーバー内で使用することなのだ。JakartaプロジェクトのHiveMindのWebページから引用すると" no more JNDI lookups, no more RemoteExceptions, no more home and remote interfaces"ということである。
EJBを利用することで得られるものは非常に大きい（たとえばEJBの独立性や，トランザクション管理，例外管理など）のだが，小規模なシステムや少人数のプロジェクトでは，その仕組みの複雑さが導入のネックになることが多い。それは，EJBの制約が主な原因となるからだ。
小規模なシステムや少人数のプロジェクトでは，設計／テストの自由度が乏しいEJBでは小回りがきかないため，開発者の工夫によって解消しなければならない問題が発生しても手が出ないことが多くなる傾向がある。
これが大規模なシステムであれば事情は異なる。EJBの制約の多さは開発成果物の質の粒度を一定以上に保つ方向へ働く可能性があるし，問題が発生した場合はハードウエアの増強などで解決することができるからだ。また，テストの自由度が乏しくユニットテストが困難な点も，大量動員による受け入れテストができることから，問題の先送りもある程度までは許容できるのだろう（だが，筆者は，その方法は問題だと考えているが）。
IoCコンテナとAOPの組み合わせは，現在のJ2EEの最先端にある技術だ。1番の特徴は，やはり，EJBに対する不満から出現してきた＝実際にJ2EEでシステムを開発している技術者による，という点と，その主体がオープンソース開発者コミュニティだという点だろう。前者はともかく，後者は，IoCコンテナ＋AOPという概念自体がまだ新しいために，実際にコミュニティベースのフィードバックが重視されているということだ。今やJ2EEのようなオープン性があるミドルウエアのような分野では，ベンダーがプロプラエタリに仕様を決めて先陣を切るという方法は取れないのかも知れない。
この中で最も有名なのは，『実践J2EEシステムデザイン』の著者のロッド・ジョンソンが中心になって開発しているSpring Frameworkであろう。また，オープンソースEJBコンテナで有名なJBossの次期バージョンはやはりIoCコンテナ+AOPをベースにしているようだ。TomcatやStrutsで知られているJakartaプロジェクトでもHiveMindというIoCコンテナ＋AOP（AOPとは言わずインターセプタと呼んでいる）プロジェクトがスタートした。
そして冒頭で紹介したSeasar2も，これらのそうそうたる顔ぶれと並んで今すぐに使えるIoCコンテナ＋AOPとして存在しているということだ。
もし読者がIoCコンテナ＋AOPに興味を持たれたら，やはり日本人開発者が日本語で他の開発者とやり取りをしているSeasar2にまず触れてみることをお勧めする。
なお，JavaにAOPを組み合わせる技術については現時点では標準は存在しないため，各実装はそれぞれ独自の方法によって実現しているという点には注意が必要かも知れない。しかし，どの実装を選択しても，AOPはクラスの実装と追加される処理を切り離す技術のため，作成したソースコードは元々分離されているということ，そのため，別のAOPへの移行はそれほど大した問題ではないということも覚えておいたほうが良いだろう。
筆者紹介 arton謎のITエンジニア。RTOS上でのデータベースエンジンを皮切りにミドルウエアやフレームワークとそれを利用するアプリケーションの開発を行い現在に至る。専門分野がある業界に特化しているために逆にメインフレームクラスから携帯端末まで，その時の需要に応じてダウンサイジングしたりアップサイジングしたりしながらオブジェクトを連携させていくという変化に富んだ開発者人生を歩んでいる。最近はもっぱらJ2EEが主戦場。著書に『Rubyを256倍使うための本 邪道編』『Visual C# .NETによるWebプログラミング入門』共著に『J2EEプログラミング講座』（いずれもアスキー刊）などがある。 |
