アスペクト指向プログラミング(Aspect Oriented Programing:AOP)とは、「横断要素
」と呼ばれるオブジェクトを跨った処理を、各オブジェクトに分散させるのではなく、
単一のモジュール「アスペクト」にまとめて記述しておき、後からコンパイラなどのツ
ールを用いて、プログラムを結合しようというものです。
Nimbus2のアスペクト指向サービスでは、そのような「アスペクト」を
Interceptorとして実装し、クラスファイルのバイトコードを操作する事で、
既存のソースコードに手を入れる事なく、動的にInterceptorを挟み込む処理を行います。
また、クラスファイルのバイトコードを操作する契機として、静的変換と動的変換の2種類を用意してます。
静的変換は、javacでアスペクト対象のクラスをコンパイルした後に、
更にCompilerを使用して、アスペクトコンパイルをかけます。
動的変換は、JVMがクラスをロード時する時に、アスペクトコンパイルしてロードします。
静的変換は、事前にクラスファイルをアスペクトコンパイルしておくので、
実行時には通常のクラスと同様に扱われるため、性能や安定性に優れています。
しかし、JVMの起動中にアスペクトを動的に差し替えたりする事はできません。
動的変換は、クラスのロード時にアスペクトコンパイルされるので、
クラスローダの構造が複雑なアプリケーションサーバでの動作が不安定であったり、
クラスのロード時間が若干長くなったりします。
しかし、JVMの起動中にアスペクトを動的に差し替えたりする事が可能になります。
それぞれの使い分けとしては、開発中のテストなどでアスペクトを使用したい場合は、
動的変換の方が使い勝手が良い場合が考えられます。
それに対して、実運用でアスペクトを使用したい場合は、
動的変換の利点を享受する機会は少ないので、静的変換の方が良いでしょう。
アスペクト指向を考える時、利用用途として最も重要な概念は、
「本来の処理の前または後、もしくはその両方で、特定の処理を行う」という事でしょう。
その概念を抽象化したインタフェースが、Interceptorです。
また、その「特定の処理」を行う上で、本来行おうとしている処理または本来の処理の結果を抽象化したのが、
InvocationContextです。
次に、Interceptorという概念にオブジェクト指向を絡めると、
その「特定の処理」を細分化して再利用したいと考えるでしょう。
その際に、細分化した特定の処理を組み合わせて順次実行するという概念が生まれます。
その概念を抽象化したインタフェースが、InterceptorChainListです。
このように連ねたInterceptorの辿り着く先には、「本来の処理」が待っています。
その本来の処理を呼び出すという概念を抽象化したインタフェースが、Invokerです。
さらに、これらの全ての概念を繋いで、「本来の呼び出し情報を伝播しながら、
複数の特定の処理を連ね、本来の呼び出しを行い戻ってくる」という概念を抽象化したインタフェースが、
InterceptorChainです。
このパッケージでは、これらの概念を具体化したサービスを提供します。