DI×AOPのこれまで、 Seasarの今、
そしてSlim3へ…

「Seasar Conference 2009 White」レポート

＠IT編集部
平田修
2009/4/2

DI×AOPを軸にしたJavaのWebシステム開発の過去・現在・未来や、日本発の世界標準を目指すSlim3の最新情報について

主な内容 ・ DI×AOPが流行した背景と現状を振り返る ・ OSSプロジェクトからNPO法人へ ・ 「Seasarは2.4を安定したバージョンとしたい」 ・ Seasarの成果を基に世界標準へと向かう 　 Slim3とは？

　2009年3月14日、東京都千代田区の法政大学 市ヶ谷キャンパス内にて「Seasar Conference 2009 White」が開催された。日本を代表するオープンソース（以下、OSS）プロジェクトである「Seasar」が主催するイベント「Seasar Conference」も今回で7回目。参加者は600人を超えセッション数は26となった。

　本稿では、数あるセッションの中からSeasarや、その運営団体、そして「DI×AOP」を軸にしたJavaのWebシステム開発の過去・現在・未来について、The Seasar Projectのひがやすを氏によるセッションを中心にレポートする。

　DI×AOPが流行した背景と現状を振り返る

　Seasarについて説明するうえで、DI×AOPに触れないわけにはいかない。DI×AOPを使ったJavaのシステム開発の歴史について、ひが氏によるセッション「最新のDI＆AOP」からレポートしよう。

　まず、話はDI×AOP登場以前にさかのぼった。当時は、JavaのWebシステム開発で、Webフレームワーク「Struts」を使うことが盛んになり始めた時期で、Strutsは主にビューの部分をつかさどるフレームワークでビジネスロジックはEJBで作ることをサン・マイクロシステムズが推奨していた。しかし、EJBは仕様が難しくて理解が大変だったこと、デプロイメント・デスクリプタの記述やコードの記述量が多く時間がかかったこと、高価なアプリケーションサーバが必要で、しかもアプリケーションサーバがないとテストができないこと、特にJUnitによる単体テストがしにくいことから「苦労した」と、ひが氏は当時を振り返る。

The Seasar Project ひがやすを 氏

　そして、POJO（Plain Old Java Object）による開発が流行した。「EJBと異なり環境に非依存なので、テストがしやすく難しいAPIがいらないということが要因だった」とひが氏は分析した。そしてPOJOによる開発は、ひが氏いわく「POJO同士を組み合わせる」DIコンテナ（DI（Dependency Injection、依存性の注入）を行うWebコンテナ）の出現で加速することになる。DIそのものについては、記事「DI：依存性の注入とは何か？」が詳しいので参照していただきたい。

　DIのポイントには「インターフェイスと実装の分離」「オープン・クローズ原則」がある。オープン・クローズ原則は、拡張に対しては開いていて変更に対しては閉じているというもので、ひが氏は「オブジェクト指向において最も重要なことだ」と述べていた。

　次にひが氏はDIコンテナの進化を3つの世代に分けて分析した。まずは、「初期のDI」がもたらしたものについて、ひが氏は次のように話した。

「DIの利点は生産性・保守機能・テスト効率の向上と学習コストの低減と信じられてい時期があった。しかし、それらは“DIの都市伝説”に過ぎなかった」

　DIは、肥大化して生産性が低くなったEJBに代わるものとして登場した。たしかにPOJOとDIによってテストのしやすさは向上したが、それは単体テストだけに当てはまるもので結合テストには当てはまらない。1つのインターフェイスに対して、結局は1つの実装しか作ることができないということが多い。また、書くコードの量が減る代わりにXML設定ファイルを書く量が増えてXML地獄が発生してしまう。特に、SSH（Struts・Spring・Hibernate）はXMLの三重苦となった。「生産性はEJBよりましなだけで低かった。だから、生産性の高いRuby on Railsが注目を集めた」（ひが氏）という。

　次に「第2世代のDI」では、コンポーネントの自動登録とアノテーションの組み合わせによるXML地獄の解消が図られた。Seasarは2005年11月公開のバージョン2.3で、Springは2007年11月公開のバージョン2.5で実現している。2007年3月に登場したDIコンテナ「Google Guice」はXMLではなくJavaのコードによって設定を記述するものだった。しかし、これらの工夫によっても、面倒だったことが解消されただけで、生産性が向上したわけではない。

　では、生産性を上げるために必要なことは何か？ ひが氏は「第3世代のDI」として「HOT deploy」機能を挙げた。HOT deployはアプリケーションサーバを稼働させたままソースコードの修正が即座に反映されるという機能で、2006年11月のSeasarの2.4で実現している。これによって、JavaでもRubyなどのいわゆる「LL」と同様にさくさくとした開発が可能になり、生産性が大きく向上した。

「ただし、トラブルも発生した。HOT deployとCOOL deployで動きが違ったり、ClassCastExceptionが起きたりもした。これらのトラブルは『Slim3』では改善して、HOT deployとCOOL deployで動きが同じになり、ClassCastExceptionが起きない工夫を施した。パフォーマンスも向上して、多分Slim3がDIの最終形となるだろう」（ひが氏）

　HOT deployやCOOL deployを含むSeasar2のSMART deploy機能については記事「サーバ再起動不要のSMART deployとバリデーション」を参照していただきたい。また、ひが氏が「DIの最終形」とする「Slim3」については、別の章でお届けしよう。同セッションの最後に、ひが氏はAOP（アスペクト指向）についても解説した。

　そもそもシステム本来の機能とは関係ないが、信頼性や保守性、使いやすさなどを向上させるための「非機能要件」に関する処理は全機能に影響するため、モジュールとして分離がしにくい。非機能要件には、アクセス制御や情報隠微（いんび）などのセキュリティに関するものや、バックアップや分散などの信頼性の確保、システムの稼働状況監視・負荷や障害状況の管理などのログ情報、システム配備や保守などのマイグレーションなどが含まれる。

　アクセス制御やシステム本来のビジネスロジックを「中心的関心事（Core concern）」とすると、非機能要件はいくつかの中心的関心事に対する「横断的関心事（Cross cutting consern）」としてとらえ、要件を2種類に分けるのがAOPの考え方だ。初期のAOPは、非機能要件の処理を追加する場所に非機能要件を追加するのに専用のコンパイラが必要で、難しいものだった。

　ところが、Seasar2などのDIコンテナの出現によって、DI行うと同時に、非機能要件の処理の追加が自動で可能になったのが「なぜDI×AOPがうれしいのか」の理由だという。DIコンテナの出現によるAOPとの相乗効果がJavaのシステム開発に与えた影響の大きさがうかがえる。

「なぜDI×AOPがうれしいのか」（ひが氏の講演資料を撮影）

　OSSプロジェクトからNPO法人へ

　ここでは、今回のイベント「Seasar Conference 2009 White」を主催する「Seasarファウンデーション」はそもそも、どんな存在なのかを確認しておきたい。Seasarファウンデーション 理事 橋本正徳氏によるセッション「特定非営利活動法人Seasarファウンデーション活動報告」の模様をレポートしよう。

　特定非営利活動（以下、NPO）法人Seasarファウンデーション（基金）は、多くの開発者を擁するオープンソースプロジェクト「The Seasar Project（Seasarプロジェクト）」を母体として2004年11月に発足。2005年12月にNPO法人として内閣総理大臣に認証されている。その目的は、「国内OSSソフトウェア開発コミュニティの運営支援と、支援コミュニティの開発成果物に付随する知的財産権管理を通じて、広く社会貢献を行っていく」ことだ。

Seasarファウンデーション 理事 橋本正徳 氏

「Seasarファウンデーションは、開発者の連携やほかのコミュテニィへの規範となること、そして開発者ミーティングなどによるコミュニティの活性化を通じて、日本IT業界全体の底上げや高度情報化社会の実現、国際協力などを目指している」（橋本氏）

　Seasarファウンデーションは、いままでSeasar2のプロダクトのメンテナンスやサポートを主な施策としてきた。今後は、出資者を募りながら、現在進行中のものを含めて以下の4つの施策を展開し、新たなOSSビジネスの創造を行っているところだ。

• ドキュメント
  入門書やマニュアル、ガイドブックなどの整備
• 教育
  商用トレーニング企業の発掘およびコースウェアの提供
• テクニカルサポート
  商用テクニカルサポート企業の発掘およびナレッジ・データベースの提供
• 認定試験：
  認定制度を作り認定試験を実施

　これらを通じて、Seasarファウンデーションが生み出したいと考えている良循環は2つある。1つは、Seasar2のプロダクトの版権管理などを組織的に行うことで、企業の要望に応え、それによって関連ビジネスが創出・拡大して、Seasarファウンデーションは新たな出資者を獲得しSeasarプロジェクトの安定化やビジネス拡大OSS開発サポートへの転換につながるということ。もう1つは、新たなOSSビジネスの創造により、OSS開発者や地域IT技術者の雇用が拡大し、Seasarプロジェクトのコミッタが充実することによりさらなるコミュニティの発展につながることだ。これらを図に表すと以下になる。

Seasarファウンデーションの目指す良循環（橋本氏の講演資料より引用）

　ところで、なぜSeasarはOSSプロジェクトからNPO法人へと変わっていったのだろうか。それについては、「そもそもNPO法人とは何か」から見ていきたい。NPOは年次で更新される個人を中心とした多数のNPO会員にて議決権を留保する。また、その会員は支払った会費口数にかかわらず、自然人／法人を問わず人格ごとに1個の議決権を持つ。さらにNPO法に定められたとおり、入会希望者について区別を行ってはならず、誰もが容易にNPO会員になることを認めている。

「NPO法人となったのは、『活動の公共性』が理由です。NPOこそがOSSソフトウェアの知的財産権を所有する最適な方法であるという考えにいたり、Seasarファウンデーションの公共性を示す根拠の1つとしています」（橋本氏）

　入会希望者を増やす施策としては、Web上でSeasarファウンデーションのNPO会員になれる仕組みを準備中だという。

1-2

Index
「Seasar Conference 2009 White」レポート DI×AOPのこれまで、Seasarの今、そしてSlim3へ…
	Page1 DI×AOPが流行した背景と現状を振り返る OSSプロジェクトからNPO法人へ
	Page2 「Seasarは2.4を安定したバージョンとしたい」 Seasarの成果を基に世界標準へと向かうSlim3とは？

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）