TOP
＞
比較データ
＞ はじめに
DIxAOPコンテナ「Seasar2とSpring」
第１回：時代は今「DIxAOPコンテナ」
著者：
豆蔵 長谷川 裕一、竹端 進
2005/10/19
1
2
3
4
次のページ
はじめに
昨今、雑誌やWeb上のニュースなどで「DI（Dependency Injection）」や「AOP（Aspect Oriented Programming）」、「Seasar2」や「Spring（正式にはSpring Framework）」という単語を目にすることが多いとお感じではないでしょうか。
もし、貴方が「また流行りものか」とお考えになってこれらの用語を今まで無視されていたら、ちょっと考えを改めてもらわないといけません。なぜならDIやAOPそしてDIxAOPコンテナ（注1）と呼ばれるSeasar2やSpringは一時的な流行で終るようなものではなく、今後のJ2EE／Webアプリケーション開発では主流になるものだと考えられているからです。
※注1：
DIコンテナとAOPフレームワークとで区別するような呼称もありますが、本連載ではDIxAOPコンテナで統一します
実際に、Seasar2やSpringはJ2EEを使ったWebアプリケーションの開発現場で利用されはじめています。また、多くの企業が導入の検討を開始しています。その普及ぶりはStrutsが開発現場で利用されるようになった時以上といっても過言ではないでしょう。
しかし、なぜ多くの企業で導入が検討され、実際に開発現場で利用されているほど注目されているのでしょうか。
本連載では、DIxAOPコンテナであるSeasar2やSpringを皆さんのプロジェクトに取り入れる切っ掛けにしていただけるように、DIとAOPの概要とシステム構築における利点、設計のノウハウを解説します。
本連載の第1回である今回は
DIxAOPコンテナの利点と、Seasar2とSpringの核となるDIの部分を中心
に解説してゆきます。
DIxAOPコンテナが解決するもの
DIxAOPコンテナが生まれてきた背景の1つにはJ2EEを使ったWebアプリケーションの開発において、EJB（Enterprise Java Beans）への不満がありました。DIxAOPコンテナの出現以前は、J2EEで構築されたシステムのビジネスロジックにEJBを利用するというのが定番の1つでした。
EJBはEJBコンテナ上で動作する分散コンポーネントとして、再利用可能という宣伝のもと、多くの企業がシステム開発に取り入れましたが、その使い勝手には多くの不満もありました（表1）。
Homeインターフェースやリモートインターフェースなどの仕組みが複雑で、実装も大変
EJBコンテナの導入とEJBのデプロイなど実行環境を用意するのが大変
EJBコンテナがないと動作しないEJBは、単体テストの実施が大変
表1：EJBへの代表的な不満
DIxAOPコンテナ（注2）は、こうしたEJBへの不満を解消してくれるものとして多くの開発者に注目され好意的に迎えられたのです（表2）。
※注2：
DIxAOPコンテナをSeasar2もしくはSpringと読みかえていただいても結構です
DIxAOPコンテナ上で動作するコンポーネント（注3）は、コンテナ非依存のPOJO（Plain Old Java Object）のため、実装が簡単
DIxAOPコンテナであるSeasar2、Springとも、統合開発環境であるEclipse上に容易に導入して動作可能
DIxAOPコンテナ上で動作するコンポーネントはPOJOのため単体テストの実行は簡単（よくある勘違いですが、テストケースが簡単に書けるようになる訳ではではありません）
表2：DIxAOPが解決するEJBへの不満
※注3：
コンポーネントはオブジェクトと読みかえていただいてかまいません
このように、EJBへのアンチテーゼとしてのみ語られることの多いDIxAOPコンテナですが、単なるEJBの代替品ではありません。
例えば、貴方の身近な開発現場でコンポーネント間の結合度が強過ぎることによってメンテナンスや再利用の問題が起きていたり、利用しているフレームワークの制約が強過ぎて新しい技術やコンポーネントの拡張が困難になっているという問題が起きていないでしょうか。
また、開発者のレベルを考慮せずに高レベルの技術を初級レベルの開発者に利用させて不具合を引き起こしてしまったり、不適切な技術隠蔽をしてしまったためにその技術の利用が困難になってしまうといったような技術隠蔽の問題もよく聞く話ではないでしょうか（表3）。
コンポーネント間の結合度が強すぎる問題
コンポーネント間の依存関係が互いに影響を与え合うような密に絡み合った状態になってビジネスロジックをメンテナンスできなくなっていたり、1つのコンポーネントを再利用するために芋づる式に複数のコンポーネントが必要になってしまう。
フレームワークの制約が強すぎる問題
現在利用しているフレームワークでは制約が多く最近流行のリッチクライアントやO/Rマッパーを利用しようにも利用することができない。
技術を隠蔽しないために発生した問題
トランザクションの制御を初心者にコーディングさせてしまい、統合テストでトランザクションの不具合が頻発したり、例外処理の手順が周知されず、コンポーネント間のどこかで例外がなくなってしまう事象を運用前に発見して大騒ぎしてしまう。
不適切に技術を隠蔽した問題
トランザクション制御を開発者に隠蔽しようとフレームワークを作ってみたものの、やたら手続きが複雑で、同僚たちからはわかりづらいといわれて使ってもらえなかった。
表3：開発現場で起きている問題点
このような問題を抱える多くのWebアプリケーションの設計はAADL（注4）(Aplication Architecture Design Level)1〜2に該当します（表4）。
表4：AADL
（本連載では従来のものに少し手を加えたものになっています）
（画像をクリックすると別ウィンドウに拡大表示します）
※注4：
AADL(Aplication Architecture Design Level)
社団法人情報処理学会J2EE/DI/Aspectパターン・プロジェクトで発表されたDIxAOPコンテナの優位性を数値化したもの
DIxAOPコンテナは、コンテナ上で動くコンポーネントにPOJO(Plain Old Java Object)という普通のJavaオブジェクトを利用することにより
コンテナ非依存を実現
します。
またDIを利用することによりコンポーネント同士がスパゲッティ状にならずコンポーネント間の結合を疎にし、AOPによって技術的に高度な部分をうまく隠蔽することによって、システムの見通しをよくします。
つまり以上のような開発現場の問題をすっきり解決し、WebアプリケーションをAADL3にまで引き上げてくれるものなのです。
DIxAOPコンテナの寿命
Seasar2やSpringに限らず、オープンソースを利用する場合にはその寿命も気になるところです。私にも10年後の技術や世の中がどうなっているかはまったくわかりませんが、1つ確実なことはDIxAOPコンテナ上で動作しているコンポーネントは10年後も利用可能であるということです。
過去において0/1のビットがソフトウェアの最小単位であったように、今後新しい技術によってコンポーネントがその最小単位になったとしても、コンポーネントがなくなることはないと考えられています。つまりコンテナやそのほかの制約から解放されているPOJOは最小単位となって新しい技術の上でも生き続けることができるのです。
1
2
3
4
次のページ
著者プロフィール
株式会社豆蔵 長谷川 裕一
XMLの技術開発やCORBA、EJBを使用したシステム開発などを経て、現在はアジャイル開発プロセスの導入から工学的なソフトウエアプロセスの策定、オープンソースプロダクトに関するコンサルタント、アーキテクトとして常に第一線で活躍。共著として「プログラムの育てかた 現場で使えるリファクタリング（ソフトバンク）」、「Spring入門（技術評論社）」。
著者プロフィール
株式会社豆蔵 竹端 進
鉄鋼系SIerを経て現職に。現在はオープンソースプロダクトに関するコンサティング、開発支援、教育を行うチームに所属。日々、新たな技術をどのように生かしていくかを考える毎日。現在の注目対象はSeasar2とMaven。
INDEX
第1回：時代は今「DIxAOPコンテナ」
はじめに
ドキュメント、教育、サポート
DIxAOPコンテナとシステム構築
サンプルアプリケーションへのインターフェースの導入
