 |
||||||||||||
|
||||||||||||
| 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）。
|
||||||||||||
|
表1：EJBへの代表的な不満 |
||||||||||||
|
DIxAOPコンテナ（注2）は、こうしたEJBへの不満を解消してくれるものとして多くの開発者に注目され好意的に迎えられたのです（表2）。
※注2：
DIxAOPコンテナをSeasar2もしくはSpringと読みかえていただいても結構です
|
||||||||||||
|
||||||||||||
|
||||||||||||
|
表2：DIxAOPが解決するEJBへの不満 |
||||||||||||
|
※注3：
コンポーネントはオブジェクトと読みかえていただいてかまいません
|
||||||||||||
|
このように、EJBへのアンチテーゼとしてのみ語られることの多いDIxAOPコンテナですが、単なるEJBの代替品ではありません。 例えば、貴方の身近な開発現場でコンポーネント間の結合度が強過ぎることによってメンテナンスや再利用の問題が起きていたり、利用しているフレームワークの制約が強過ぎて新しい技術やコンポーネントの拡張が困難になっているという問題が起きていないでしょうか。 また、開発者のレベルを考慮せずに高レベルの技術を初級レベルの開発者に利用させて不具合を引き起こしてしまったり、不適切な技術隠蔽をしてしまったためにその技術の利用が困難になってしまうといったような技術隠蔽の問題もよく聞く話ではないでしょうか（表3）。
|
||||||||||||
|
表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 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
