AOPは近年、全体的に宣伝過剰な失敗した技術(source)だとして冷淡な姿勢を見せるギャビン・キング(Gavin King)と、アスペクトがプログラミングの主流となることについて、少数の熟練した開発者のための特殊な知識にとどまるのではないか(source)、という深刻な疑問を表明するセドリック・ビュースト(Cedric Beust)によって議論されてきました。この記事はアスペクト指向プログラミング(AOP)のファンシンドローム(source)を生み出そうとするものではなく、土壇場でプロジェクトの要件を変更するような、いくつかの重大な横断的関心事(cross cutting concerns)を扱う大手金融機関のJava EEプロジェクトで、この技術がどのようにして実際に多くの利益をもたらしたかについて述べるものです。述べられるシナリオと実施される解決方法は、ビジネスアプリケーションのモデリングで直行する関心事を扱う際に、AOPがどのようにOOPを補完するかをうまく示しています。
問題
私たちはJava EEの技術と、Oracle 10g RACのデータベースクラスタ、Websphere MQのメッセージングミドルウェアを利用して、大手金融機関のための証券取引バックオフィスソリューションの開発に取り組んでいます。プロジェクトがユーザ受け入れテスト(UAT)の段階に入ったとき、経営者はクラスタ構成によるアプリケーションの透過的なフェイルオーバーサービスを実装することを決定しました。
Oracle 10g RACは、JDBCアプリケーションがコネクションフェイルオーバー環境を利用するための洗練された方法を提供する、FCF(Fast Connection Failover)をサポートします。しかし本当に難しいのは、アプリケーションレイヤでのフェイルオーバー処理と、ユーザから見て透過的なリトライとリカバリの仕組みなのです。
Oracleノードがフェイルオーバーする場合、以下のイベントシーケンスが発生します。
- データベースインスタンスが故障し、いくつかの不要なコネクションがコネクションキャッシュに残る。
- データベースのRACメカニズムは、JDBCを含んでいるJVMに送るRACイベントを生成する。.
- RACイベントを受け取ったJVM内のデーモンスレッドは、すべてのコネクション発見し、SQLExceptionによってコネクションが閉じられたことを通知して、開いているすべてのトランザクションをロールバックさせる。RACサービスの障害がJDBCアプリケーションに伝えられたとき、すでにデータベースはローカルトランザクションをロールバックしている。
1つのRACノードがダウンしたときにFCFが有効なら、コネクションキャッシュは自動的に無効にされ、利用されていないすべてのコネクションは新しいノードに再設定されます。しかしそれは、すでにアプリケーションによって利用されているコネクションには当てはまりません。このシナリオでは、ノードがフェイルオーバーする前に接続していたコネクションをアプリケーションが利用しようとすると、コネクションが閉じられたことを知らせるSQLException(ORA-17008)が投げられます。アプリケーションは手動でコネクションをリトライしなければならず、FCFは次のコネクションを成功させようとすることを保証します。
強引な解決方法
上記のアプリケーションが手動でリトライしなければならない問題は、適切なリトライとリカバリの仕組みによって解決しなければなりません。私たちはORA-17008を特別に扱い、自動的なリトライを可能にする特別なハンドラを、アプリケーションレベルで組み込まなければならないことに気が付きました。問題は、この2年間で開発した6000以上のクラスと500以上のデータベースから成る200万行以上のJavaとJSPのコードベース、そしてそこにある以下のようなコードです。
long id = ...;
try {
Instrument instr = new Instrument(id, conn); } catch(SQLException ex) {
throw new KeyedException("cam.error.failed.retrieve.instrument",
ex);
}
...
SQLExceptionはすべてのデータベース関連の障害を捕捉させるために一般的な検査例外なので、上記のようなコードによってすべてのコードベースが汚染されます。(やれやれ、検査例外は煩わしい…Springのように非検査例外でラップすべきです)。強引な解決方法は、SQLExceptionを捕捉しているすべての箇所に、特別なハンドラを組み込むことでしょう。この方法は、ユーザ受け入れテストを行うことや、すべてのコードベースにひどい影響を与えるかもしれないことを考慮して、除外されます。クライアントも間違いなく喜ばないでしょう！
アスペクトの導入
私たちはコードベースを慎重に分析した結果、リトライとリカバリの仕組みを実装しなければならない主な箇所が、多くのサービスコンポーネントやコンソールアプリケーションに及ぶことを発見しました。私たちは歴史的な理由からEJBを利用していません。その代わりにすべてのサービスコンポーネントやコンソールアプリケーションはドライバとしてランチャー基底クラスを持っています。それでも、私たちが扱わなければならない機能の範囲は、コードベース全体の半分以上に及びます。本当の横断的関心事なのです。
そこで私たちは、この問題を扱うためにアスペクトを組み込むことを考えました。以下の解決方法が提案され実施されました。
- SQLExceptionを処理するためのポイントカットを定義する。
- ポイントカットで実行され、例外をインターセプトして型付の例外を投げるアドバイスを定義する。
- このエラーを、サービスコンポーネントの基底クラスとコンソールアプリケーションの基底クラスの2つだけで、処理しなければならない。これらの2つのクラスは、このエラーのためのハンドラの中に、リトライとリカバリの機能を実装する。
以下のアスペクトは、上記の仕組みの骨組みを実現します。
public aspect AspectFastConnFailOver
{
pointcut sqlHandler(SQLException exception):
handler(SQLException+) && args(exception);
// advice to be executed as the handler of SQLException
// its derived exception
before(SQLException exception): sqlHandler(exception){
...
// handle only if non-UI
if (!Application.getInstance()
.getContext()
.getCallerIdentity()
.isInteractiveUser()) {
if(exception.getErrorCode() == Globals.FCF_SQLEX_ERRORCODE)
{
throw new DatabaseNotAvailableError();
} } }
... }
MQフェイルオーバーの実装
私たちはデータベースサーバのための透過的なアプリケーションフェイルオーバーを達成しましたので、VERITASのStorage Foundation 4.0/HAとMQ Agentのサーバフレームワークで構成したクラスタ上に配備される、Websphere MQサービスに同じような実装の仕組みを試してみることにしました。
Oracle 10g RACを利用したフェイルオーバーでは、フェイルオーバーするたびに適切なイベントが生成され、特別なエラーコードとともにアプリケーションのJDBCレイヤに伝播されます。JDBCはエラーコードに基づいて、コネクションプールで利用されていないすべてのコネクションを無効にし、現在のコネクションに関連するトランザクションをロールバックします。私たちはアプリケーションレベルでエラーコードを捕らえ、状況に対処するために新しいコネクションの再取得を試みる必要があります。コネクションを取得するための次の呼び出しは、それまでにフェイルオーバーが行われていれば、成功すべき新しいコネクションを生成するでしょう。
MQフェイルオーバーによる状況は、VERITASのクラスタが本質的にフェイルオーバーを処理しないので、イベントがアプリケーションレベルに返送されないため複雑です。そのためアプリケーションはフェイルオーバーを検知し、コネクションプールのすべてのコネクションとセッションを無効にし、トランザクションをロールバックする必要があります。メッセージの処理において、Connection、Session、Receiver、Sender、BrowserなどのインタフェースのあらゆるメソッドがJMSの仕様に従い、SQLExceptionのようにJMSExceptionを投げる可能性があります。そのためリトライとリカバリは、適切なポイントカットで集中的に実装される必要があります。
インターセプトを行うアスペクトの断片のようなものを以下に示します。
public aspect AspectFailOver
{
pointcut jmsHandler(JMSException exception):
handler(JMSException+) && args(exception)
&& !within(...)
&& !withincode(...));
// advice to be executed as the handler of JMSException
// its derived exception
before(JMSException exception): jmsHandler(exception){
...
if (!Application.getInstance()
.getContext()
.getCallerIdentity()
.isInteractiveUser()) {
if(isMQFailoverException(exception)) {
throw new MQNotAvailableError();
}
}
} ...
}
}
Oracleのフェイルオーバーと同じようにMQNotAvailableErrorは、リトライとリカバリのループを実装するサービスコンポーネントとコンソールアプリケーションの2つの基底クラスの中で捕らえられます。
最小の影響、最大の効果
結果は素晴らしいものでした。AOPのおかげで私たちは既存のコードベースへの最小の影響で目標を達成しました。私たちはAspectJとコンパイル時のウィービングを利用しました。AOPを利用することでビルド時間は増えましたが、コードベースに大きな影響を与えない技術として、クライアントは満足そうでした。
著者について
デバシシュ・ゴーシュは、グローバルなIT業界で17年以上の経験を持ち、小さな会社からFortune 500のような大企業まで、さまざまなクライアントにエンタープライズ規模の問題解決を指導することを専門にしている、Anshin Software(サイト・英語)のCTOです。彼はAnshin Softwareのテクノロジエバンジェリストで、ソフトウェアデザインとプログラミングのベストプラクティスを制度化することに誇りを持っています。彼はJava、RubyおよびScalaのプログラミングが好きで、C++のアンマネージドな世界から必死に抜け出そうとしています。デバシシュはAnshin Softwareのコアマネージメントチームの一員として、4人のグループを現在の150人の会社にまでした主要な1人です。彼はこのごろhttp://debasishg.blogspot.com(英語)でたくさんのブログを書いています。
原文はこちらです：http://www.infoq.com/articles/Application-Failover-using-AOP
（このArticleは2006年7月4日にリリースされました）