JCA 入門記 ライフサイクル管理 その 1

Tech JCA

うー，これだけスタートが遅いと毎日は難しいな．．．
いやその，朝早く出勤すれば早く帰ってこれるという突っ込みはなしで．
そんなわけで (どんなわけで？)，とりあえずできるところまで行ってみよう！


Chapter 5 Lifecycle Management
本章では，アプリケーションサーバとリソースアダプタ間の規約が定義されるということです．ようやく楽しくなりそう．
この規約により，アプリケーションサーバはリソースアダプタのライフサイクルを管理できるようになるとのこと．


5.1 Overview
リソースアダプタがアプリケーションサーバにデプロイされた時，あるいはアプリケーションサーバが起動した時，アプリケーションサーバはリソースアダプタのインスタンスをブートしなければなりません．
リソースアダプタがアプリケーションサーバからアンデプロイされた時，あるいはアプリケーションサーバが停止する時，アプリケーションサーバはリソースアダプタのインスタンスを停止しなければなりません．
ライフサイクル管理は，そのためのメカニズムを提供するとのことです．らじゃあ．


5.2 Goals
アプリケーションサーバがリソースアダプタのインスタンスについてライフサイクルを管理出来るようなメカニズムを提供すること．らしい．


5.3 Lifecycle Management Model
javax.resource.spi パッケージに属する二つの interface が提供されているようです．
その interface とここで注目のメソッド．

  • ResourceAdapter
    • start(BootstrapContext ctx)
    • stop()
  • BootstrapContext
    • getWorkManager()

ResourceAdapter はリソースアダプタが提供します．BootstrapContext はアプリケーションサーバが提供します．
さらに，BootstrapContext#getWorkManager() が返す

  • WorkManager

という interface もあるようです．
まずはこの 3 つを頭に入れて，と．


5.3.1 ResourceAdapter JavaBean and Bootstrapping a Resource Adapter Instance
リソースアダプタの提供者は，ResourceAdapter を実装したクラスを提供します．その実装クラスは JavaBean であるとのことです．すなわち，引数のない public なコンストラクタを持ち，getter/setter によりアクセスすることの出来るプロパティがあるということです．Serializable は任意．
リソースアダプタは JavaBean なので，プロパティにいろいろ設定してデプロイすることが出来ます．
リソースアダプタがデプロイされたりアプリケーションサーバが起動されたりすると，アプリケーションサーバは ResourceAdapter 実装クラスをインスタンス化し，プロパティを設定して start(BootstrapContext) メソッドを呼び出します．呼び出された ResourceAdapter 実装クラスのインスタンス (以下「リソースアダプタのインスタンス」と記述) は，自身を初期化します．


リソースアダプタのインスタンスは，あうあう，ぴーーー．．．
(ぷっつん)


(ぴーーーーがががっ)
復旧！
でもでも，わけわかだぞ．困ったな．
ともあれ (JW)，リソースアダプタのインスタンスは，exactly one functional ResourceAdapter JavaBean per functional resource adapter instance を表現しているとかなんとか．functional resource adapter instance ？
推測というか憶測というかヤマカンで書いてみるテスト．大雑把に言うと，ResourceAdapter の実装クラスごとに一つのインスタンスってことかなぁ？
例えば接続するメインフレームが 10 台あっても，リソースアダプタのインスタンスは一つで，単に複数のコネクションが使われるだけ，みたいな．
あ，でもプロパティの値を変えなきゃいけない場合はそうもいきませんね．
ってことは，同じクラスで同じ構成のリソースアダプタごとに一つのインスタンスということか？ アプリケーションサーバにデプロイした単位ごとっていうか．
ともあれ (JW)，アプリケーションサーバはリソースアダプタのインスタンスをそういう単位に一つ作成するらしいです．
といいつつも一応，アプリケーションサーバは同じ ResourceAdapter 実装クラスのインスタンスを複数同時に生成できるとか．その条件として，インスタンスの equals(Object) メソッドが true を返してはダメらしい．同値になるインスタンスは一つしか存在できないということですね．ってことはあれだ，ResourceAdapter 実装クラスの equals(Object) は，同じ構成情報を持っていたら true を返すべきってことか？
ただし，アプリケーションサーバは異なった JVM に 複製を生成することが出来るそうです．これは可用性のためですね．たぶん，インスタンス化はしても start(BootstrapContext) は呼び出さないものと思われ．


そんなわけで (どんなわけで？)，リソースアダプタのインスタンスが生成されると start(BootstrapContext) が呼び出されるわけですが，それには当然アプリケーションサーバのスレッドコンテキストが使われます．なので，初期化を終えると制御を戻さなければなりません．っていうか，素早くリターンしないとタイムアウトしちゃうみたい．
もし リソースアダプタのインスタンスが初期化に時間がかかるとか，あるいは初期化後も動作するバックグラウンドのスレッドを必要とする場合には，BootstrapContext#getWorkManager() が返す WorkManager を使うことが出来ます．
WorkManager は，どうやらアプリケーションサーバが提供するスレッド管理機能 (スレッドプールなど) を使用するための interface のようで，次のメソッドを持っています (一部)．

    • doWork(Work work)
    • startWork(Work work)
    • scheduleWork(Work work)

ここに出てくる

  • Work

は，Runnable を extends した interface です．
リソースアダプタは，Work の実装クラスに別のスレッドで実行する処理を記述して WrokManager に渡すことで，アプリケーションサーバが用意したスレッドの上でその処理を実行できるということみたいです．
でもでも，WorkManager#doWork(Work) は Work の実行が終了するまでブロックするので使えません．っていうか，WorkRejectedException が吹っ飛んでくるみたい．
startWork(Work) は，Work の実行が開始されるまでブロックしますが，終了までは待ちません．そのため，作業が始まったことを確認できるようです．scheduleWork(Work) は全然ブロックしないので，Work の実行が始まったかどうかも確認できないらしい．
ともあれ，doWork(Work) ではなく，startWork(Work) または scheduleWork(Work) を使えとのこと．
ResourceAdapter#start(BootstrapContext) が例外を投げると，リソースアダプタの初期化は失敗ということになります．将来の仕様では，2 段階の初期化が導入されるとのことですが，どんなシナリオで必要になるのかは書いてありません．残念！！！！


リソースアダプタのインスタンスは，ライフサイクルの間にいくつかのオブジェクトを生成したり破棄したりするわけですが，その中には次のようなものが含まれるとのこと．

  • ManagedConnectionFactory
  • ActivationSpec
  • 様々なコネクション
  • リソースアダプタ固有のオブジェクト

ManagedConnectionFactory は，EIS からコネクションを確立する場合に使われるそうです．一方の ActivationSpec は，EIS からの要求でコネクションが確立される場合に使われるようです．
ResourceAdapter な JavaBean はリソースアダプタのインスタンスであると同時に，そのインスタンス固有の構成 (Configuration) を持ちます．その構成は，ManagedConnectionFactory および ActivationSpec のデフォルトとして使われるそうです．
この二つの interface についての詳細は，それぞれ 6 章，12 章で記述されているようですが，この後にも少し出てくるようです．
が，今日はここまで♪


そうですか，JCA のリソースアダプタってアプリケーションサーバの提供するスレッドを活用できるんですね．
ってことはですよ，S2EbiYuri 構想の一部として考えていた S2JMS Container for JBoss なんかやめて，ResourceAdapter として JMS Container を作ればいいのかも？ s2jms.rar とか提供しちゃったりなんかして！？ おぉ，JMS と JCA がつながっていくゾ！！
なんか学習意欲がわいてきました♪


あ．
ResourceAdapter として JMS Container を作っても，それをアプリから使う形にはならないような？ それでいいのか？ あまりよくないような．
うーみゅ．．．