GluonJ を用いたビジネスロジックからのデータベースアクセスの分離 東京工業大学　情報理工学研究科 数理・計算科学専攻 石川　零 千葉　滋 SPA '05, Ikaho, Gunma

コンポーネント間の依存関係 コンポーネント間の依存関係を弱める技術が注目されている ： Design Patterns 　　　　： Design Patterns Dependency Injection Aspect Oriented Programming (AOP) 横断的関心事を実装するコンポーネントと、他のコンポーネントの間の依存関係を弱める 仕様変更による、コンポーネントの追加や取り外しを容易にする …と我々は 考えている SPA '05, Ikaho, Gunma

依存関係を弱めたい例 Database Access Object (DAO) Service オブジェクトとの依存関係 同じセッションに属す Service オブジェクトは同一の DAO と結びつける 横断的関心事の一種 例: SPAの論文投稿システム DAO 著者登録 Service DAO データ ベース 論文投稿 Service DAO 著者登録 Service これは典型的な Web アプリケーションの構成 SPA '05, Ikaho, Gunma

Dependency Injection (DI) コンテナの利用 サービスオブジェクトからDAO の生成を分離 DI コンテナ: DAO を生成してService オブジェクトへ与える Service オブジェクトはインタフェースを介してDAO を操作 欠点: サービスオブジェクトの再利用性は低い 決められたインタフェースを実装しないオブジェクトとは一緒に使えない DI コンテナによる注入 OracleDAO AuthorCheckService MySQLDAO DAO dao; MailTransferAgent SPA '05, Ikaho, Gunma

提案するAOP 言語 : GluonJ アスペクト指向の利用 コンポーネント同士の結びつけに利用 依存関係の記述をコンポーネントから完全に除去 AuthorCheckService DAO PaperCheckService DAO AuthorCheckService アスペクトが Service オブジェクトと DAO を結ぶ SPA '05, Ikaho, Gunma

GluonJ のアスペクト 大きく2つの要素から構成 Service オブジェクトからDAO へのリンクの宣言 DAO の呼び出しの記述 <aspect> <injection> DAO AuthorCheckService.aspect = DAO.factory (this.sessionId); </injection> <advice> <pointcut> execution ( void AuthorCheckService. checkAuthorInfo(..)) </pointcut> <after> DAO.aspectOf (this). postAuthor ( this.firstname, this.lastname); </after> </advice> </aspect> 大きく2つの要素から構成 Service オブジェクトからDAO へのリンクの宣言 DAO の呼び出しの記述 AspectJ のポイントカット＆アドバイスと似た記述 DAO の 呼び出し アスペクト (XML で記述) SPA '05, Ikaho, Gunma

リンクの宣言 Service オブジェクトからDAO へのリンクを追加 リンク元コンポーネント <injection> DAO AuthorCheckService.aspect = DAO.factory (this.sessionId); </injection> リンク先コンポーネント SPA '05, Ikaho, Gunma

DAO の呼び出し リンクしたDAO を呼び出す Service オブジェクトのメソッド呼び出しのあとに、DAO のメソッドを呼び出す <advice> <pointcut> execution (void AuthorCheckService. checkAuthorInfo(..)) </pointcut> <after> DAO.aspectOf (this).postAuthor (this.firstname, this.lastname); </after> </advice> AspectJ のポイントカット& アドバイスに似た記述 aspectOf メソッド: this と リンクする DAO オブジェクト を取得 SPA '05, Ikaho, Gunma

AspectJ では記述できないか？ プログラミング idiom を駆使すれば可能 AspectJ のデザイン プログラムから開発者の設計意図（アーキテクチャ）を読み取りにくい AspectJ のデザイン 横断的関心事をアスペクトで直接実装する アスペクトは暗黙のうちに生成　（new できない） AuthorCheckService オブジェクト AuthorCheckService オブジェクト PaperCheckService オブジェクト SID : 001 SID : 002 SID : 002 DAO をアスペクトとして実装 DAO DAO SPA '05, Ikaho, Gunma

AspectJ 実装 – issingleton + ハッシュテーブル DAO をアスペクトとして記述 DAO アスペクトインスタンスを1つ用意 セッション ID ごとにまとめておきたいデータをハッシュテーブル型のフィールドで管理 AuthorCheckService オブジェクト AuthorCheckService オブジェクト PaperCheckService オブジェクト 002 001 ハッシュテーブル ID SID : 001 SID : 002 SID : 002 DAO 問合せ SPA '05, Ikaho, Gunma

AspectJ 実装 – issingleton + インタータイプ宣言 DAO アスペクトインスタンスを1つ用意 DAOのフィールドのデータをインタータイプ宣言したフィールドに保存 インタータイプ宣言 他のクラスにフィールドやメソッドを追加する技術 AuthorCheckService オブジェクト AuthorCheckService オブジェクト PaperCheckService オブジェクト SID : 001 SID : 002 SID : 002 DAO SPA '05, Ikaho, Gunma

AspectJ 実装 – perthis の利用 サービスオブジェクトごとにアスペクトインスタンスを生成 perthis : 1つのオブジェクトに1つのアスペクトインスタンスを結びつける セッション ID ごとの結びつけは困難 AuthorCheckService オブジェクト AuthorCheckService オブジェクト PaperCheckService オブジェクト SID : 001 SID : 002 SID : 002 DAO DAO DAO SPA '05, Ikaho, Gunma

Association Aspects [Sakurai, ’04] の利用 新しい言語機構を導入して AspectJ を拡張 アスペクトインスタンスを明示的に生成できる 結びつけのルールを新たに追加 下の設計を実現できる AuthorCheckService オブジェクト AuthorCheckService オブジェクト PaperCheckService オブジェクト SID : 001 SID : 002 SID : 002 DAO DAO SPA '05, Ikaho, Gunma

Dependency Reduction [ECOOP ’05] これが AOP の本質なのでは？ コンポーネント間の依存関係を弱める技術が AOP GluonJ はこの認識に立って設計された言語 横断的関心事はAOPが役立つ応用例 横断的関心事: 他のコンポーネントの結びつきが元々弱く、将来結びつきが変わる可能性が高い 　 → 依存関係を弱める必要がある 横断的関心事の実装技術が AOP ではない GluonJ はAspectJ とは異なる立場 -> DB のような、コンポーネントの依存関係の解決を大きな問題としてみる 最初からこの解決を目的に、根本的に作り直してみたのがGluonJ ECOOP で我々が発表する論文 一般にAOP := 横断的関心事の解決 but, AOP にとってCC は1つの応用例では？ cc : もともと SPA '05, Ikaho, Gunma

関連研究: Dependency Injection コンポーネント間の依存関係を、プログラムから分離して記述する技術 DI コンテナ: コンポーネントの生成を分離 DI コンテナは、AOP言語のサブセットと見ることができるのでは？ GluonJ はコンポーネントの生成とメソッド呼び出しをプログラムから分離できる GluonJ はDI コンテナより強力 SPA '05, Ikaho, Gunma

まとめと今後の課題 まとめ 今後の課題 GluonJ AspectJ, Association Aspects との比較 アスペクトをコンポーネント同士の結びつけに用いる 依存関係の記述をコンポーネントから完全に除去 今後の課題 AspectJ, Association Aspects との比較 GluonJ を用いたコンポーネントフレームワークの作成 SPA '05, Ikaho, Gunma