ユーザ毎にカスタマイズ可能な Webアプリケーションの 効率の良い実装方法 理学部　情報科学科 05_21621　別役　浩平 指導教員　千葉　滋

ユーザ毎にカスタマイズ可能なWebアプリ 自分のページの利便性を向上 サイトの集客に影響 例) iGoogle 一般的にはプラグイン機構などをWeb アプリに組み込む Web アプリ開発者 ・・・カスタマイズ機構をもった Web アプリを開発 プラグイン開発者 ・・・ プラグインなどの拡張を作成 ユーザ ・・・ 拡張を選択し、Web アプリをカスタマイズ！

従来技法: プラグイン機構 カスタマイズ可能部分を拡張ポイントとして公開 Web アプリ開発者・・・インタフェースとして拡張ポイントを公開 プラグイン開発者・・・実装クラスをサーバーに登録 ユーザ・・・サーバー上のプラグインを選択 void setLayout(){ PageLayout p = webapp.getLayout(uid); setTitle(p.getTitlePos()); setColor(p.getbgColor()); : Interface PageLayout{ String getTitlePos(); String getbgColor(); : 拡張ポイント Class Layout1 impl. PageLayout{ String getTitlePos(){return “center”; } String getbgColor(){return “black”; } : <Config> <Layout class=“Layout1”/> </Config> Class Layout1 impl. PageLayout{ String getTitlePos(){return “ left”; } String getbgColor(){return “ red”; } : 3 ユーザの設定(xml ファイル)

従来のプラグイン機構の問題点 Web アプリ開発者にとって実装コストが大きい プラグイン開発者の自由度が低い プラグイン機構を実装 拡張ポイントA 拡張ポイントB 拡張ポイントC Plug-in 1 Plug-in 2 Plug-in 4 Plug-in 3 プラグイン開発 プラグイン開発者 カスタマイズ不可能

Per-session AOP を用いたフレームワークの提案 プラグインをアスペクトとして記述 処理の流れ アスペクトを選択したユーザがリクエストを送信 セッションからユーザが選択したアスペクトを特定 そのアスペクトを weave し、Web アプリをロード Web アプリの実行 サーバー ユーザ ④ ユーザ A 本フレームワーク Web アプリ ① ③ ユーザ B weave アスペクト ② ユーザ A が選択したアスペクト ユーザ B が選択したアスペクト

Per-session AOP セッション毎にロード時に weave プラグインをアスペクトで記述 weave ユーザ毎に異なるクラスローダを利用 セッション毎に Web アプリを再ロード プラグインをアスペクトで記述 Web アプリ開発者は、プラグイン機構を実装しなくてよい Webアプリの任意の場所を自由にカスタマイズ可能にできる @Glue class Layout{ @Around(“{setTitle(`center`);}) Pointcut pc1 = Pcd.call(“setTitle(..)”); @Around(“{setColor(`black`);}) Pointcut pc2 = Pcd.call(“setColor(..)”); 　　　　　　　　　　： void setLayout(){ setTitle(DefaultSetting.LEFT); setColor(DefaultSetting.WHITE); : weave 6 登録済みアスペクト（GluonJ）

Web アプリのカスタマイズ可能部分をロード 効率化のための実装 クラスローダの親子関係を使用 Web アプリ内で使われているライブラリを全ユーザに共通の 親ローダを用いてロード クラスローダをキャッシュ アスペクトの変更がないユーザのクラスローダをキャッシュ 再ロードの必要がない ユーザ共通の クラスローダ Webアプリ内の ライブラリのみロード ユーザ A の クラスローダ ユーザ B の クラスローダ Web アプリのカスタマイズ可能部分をロード ...

実験 掲示板アプリへのリクエスト送信実験 実験環境 フレームワークの使用・不使用、効率化のための実装の有無にわけて測定 Client マシン 平均応答時間 100 ユーザ、100 スレッドで各ユーザが 10 リクエストを送信 処理の内訳 100 ユーザ、単一スレッドで各ユーザが 10 リクエストを送信 実験環境 Client マシン OS : Windows Vista CPU : Core 2 Duo 3.00 GHz Memory : 4 GB Server マシン OS : Linux 2.6.26 CPU : Xeon 2.83 GHz , 4 Cores

平均応答時間 効率化がない場合に比べて、7～28 倍の速度向上 エントリ 100 でも Tomcat のみの場合に比べ、 3～8 倍遅い 本フレームワークでは無効になる 19832 20000 共通の親ローダを使用 ms 素朴な実装 Tomcat のみ

処理の内訳（単一スレッド） クラスのロードがオーバーヘッドの主因 キャッシュエントリ数を増やすにつれてフレームワーク 内の処理時間が減少 クラスローダの作成やアスペクトの weave 時間が原因 400 共通の親ローダを使用 ms 369 素朴な実装 Tomcat のみ

関連研究 Per-session weaving[戸部、千葉 ‘08] Dynamic weaving 基本的なアイデアは公表済み 素朴な実装ではロードによるオーバーヘッドが大きい 本研究ではローダの親子関係とキャッシュを用いることで オーバーヘッドを削減 Dynamic weaving アスペクトによるカスタマイズが制限される PROSE[Popovici ら ‘02] イベント通知を用いた Dynamic weaving システム 時間的コストが大きい

まとめと今後の課題 まとめ 今後の課題 Per-session AOP を用いたフレームワーク 効率化のための実装 実験 プラグインをアスペクトで記述 効率化のための実装 クラスローダの親子関係を利用 キャッシュの使用 実験 平均応答時間、処理の内訳の測定 今後の課題 現状：プラグイン開発者は自由にアスペクトを記述可能 プラグイン開発者に対する信頼が必要 不正なアスペクトに対するセキュリティ対策 アドバイス実行中のみセキュリティマネージャーを切り替える