Ramnivas Laddad氏がAspectJおよびSpring AOPでのAOP選択について語る

作者 Srini Penchikala , 翻訳者 編集部 投稿日 2009年1月9日

セクション

設計/アーキテクチャ

トピック

AOP ,

方法論 ,

Architecture ,

プログラミング ,

AspectJ ,

Aspect Oriented Programming ,

AJDT

共有 |

Spring AOPまたはAspectJの組み合わせは、多くの選択肢を提供している。AOPシステム関連(バイトコードベースかプロキシベースのAOP)、構文関連(従来型AspectJ、 @AspectJまたはXML構文)またはウィービングオプション(ビルド時またはロード時のweaver)などである。そしてエンタープライズアプリ ケーションでアスペクトを使用する場合、プログラムによってそれらを適用するためには、これらすべての選択肢を正しく理解することが極めて重要である。

Ramnivas Laddad氏(リンク)は、1種類のAOPだけではすべてのアプリケーションに適合しないので、正しい組み合わせを選ぶことで、デベロッパはAOPでうまくやっていくことができる、と述べた。氏は、最近開催されたSpringOne Americasカンファレンス(リンク)でプレゼン(リンク)をした。その内容は、Spring AOPフレームワークが提供しているさまざまな設計や実装の選択肢およびWebアプリケーションでそれを使用する際のベストプラクティスについてである。

Ramnivas氏は、AspectJウィービングおよびプロキシベースのSpring AOPアプローチの利点と制限について話した。Spring AOPとAspectJのどちらを選択するかは、設計や環境要因による。以下のシナリオではSpring AOPを使用する。

• メソッド専用の傍受が十分である。
• AOPのフルパワーが計り知れないほどである。
• AspectJコンパイラ(ajc)のような特殊なコンパイラ(ajc)(リンク)が不要である。 
• ドメインオプジェクトのクロスカットが不要である。
• 事前に記述したアスペクトがニーズを満たす。

他のすべてのシナリオで AspectJ AOPを使用する。氏は、AspectJ(きめの細かいトレーシングおよびモニタリング、ドメインオブジェクト、きめの細かいセキュリティ)およびプロキ シAOP(トランザクション管理、JMXモニタリング、リモーティングおよびセキュリティ)のサンプルアプリケーションのいくつかをリストした。そのプレゼンで、Ramnivas氏は従来のAspectJ(リンク)と@AspectJ(リンク)構文オプションの相違をコードの例で示した。

アスペクトウィービングの選択肢にはコンパイル時(リンク)またはロード時のウィービングがある(LTW)(リンク)。LTWオプション使用時は、Spring駆動LTWを使用することができる。それは、コンテナ起動スクリプト修正( -javaagent なし)(リンク)なしで、もしくは、構成オプションを使用したSpringのJPAエージェントを使用することで、アスペクトウィービングを可能にする。これら2つ のウィービングの比較は、以下のとおりである。

ビルド時(コンパイル/バイナリ)：

• ウィービングは、ビルド時に高くつくが、ロード時はフルスピードである。
• ビルドシステムの修正が必要。
• デプロイメントの変更は不要。
• Eclipse AspectJ Development Tools(AJDT)(リンク)を使用した、最良のIDEサポート。

ロード時：

• ロード時の速度、メモリフットプリントが影響を受ける。
• ビルドシステムは変わらないが、アスペクトの作成にはデプロイメントの変更が必要である。
• IDEツールのサポートなし。

AOP設計の選択肢には、接合点の署名を利用したポイントカット実装や、ワイルドカードを使用して幅広い接合点を選択することが含まれる。メタデータ(アノテーション)(リンク)は、接合点を取り込むために使用することができる。それにより以下のメリットやデメリットを提供する。

• メリット： 
  アプリケーションにおけるクロスカットに関する特定の問題を取り込むには、アノテーションは容易な手段である。アノテーションに対するアスペクトおよびクラス間の協調を制限するのに役立つ。
• デメリット： 
  クラスからの協調が必要である。また、アノテーションの過剰使用は、AOPの不明瞭なプロパティをあいまいにする場合がある。

AOP実装向けのメタデータを使用する際のベストプラクティスは、以下のとおりである。

• アノテーションは、プログラムエレメントの固有の特性を表すのには、最適である。
• 接合点においてtrueであることを表し、発生することは表さない。
• 実装に特有のアノテーションは回避する。
• アノテーションは、注釈付きエレメントでtrueであることを示す。たとえば、読み取り専用のシナリオを取り込む場合、アノテーション名として@ReadOnlyを使用する。@TakeReadLockではない。トランザクションにする必要があるメソッドに印を付けるには、@JTATransactionalではなく、@Transactionalを使用する。
• マクロの作成にアノテーションを使用してはいけない。
• JPA(@Entity(リンク)、@Table(リンク))、JAX-WS(@WebService(リンク)、@WebMethod(リンク))、Spring(@Component(リンク)、@Service(リンク)、@Autowired(リンク)、@ManagedResource(リンク))のようにすでに存在しているアノテーションを使用する。

原文はこちらです：http://www.infoq.com/news/2009/01/ramnivas-aop-choices