S2JMS 開発記全体像と現状

昨年の夏くらいから構想はあったわけですが．．．
すなあそびではデモを披露したわけですが．．．
それ以来放置プレイしてました．心より恥じる．

なんたって S2JMS のコードネームは "S2EbiYuri" ですから，エビちゃんの名にかけてしっかりと仕上げないといかんわけです．
ついでに S2JCA のコードネームは "S2NishiMaki" なのだ．
そしてコードネーム S2RikuEma．．．はなんかイマイチかな．ただの S2Ema でいいか？とにかく絵麻ちゃんも何かに使いたいゾ．
ちなみに直ちんのコードネームはひがさんに差し押さえられていたような気のせいが (笑)．

そんなわけで (どんなわけで？)，新年を迎えて心機一転，S2JMS に本格的に取り組もうじゃあーりませんか．
はぶさんからは遅すぎとか言われそうだけど (ごめんちゃい) 気にしない気にしない．

んで，まずは S2JMS 構想の全体像と現状を書いておくテスト．
同じことをすなあそびの発表資料とかこの日記でも以前書いたような気のせいがするわけですが，いいのだ．
最初に構想を書いてから (スタロジでスタラジの頃？) もう 1 年半くらい経ってるわけですが，いいのだ (いいのか？)．
ともあれ (JW)，S2JMS プロダクトファミリー (？) はこんな感じだ！！

S2JCA

これは S2JMS とは別プロダクトという扱いなのですが，事実上 S2JMS のために作っているのでここに含めます．
S2JCA は J2EE Connector Architecture の実装を提供するもので，S2JMS の基盤となります．
JBoss や Geronimo みたいなフルスペックの J2EE アプリケーションサーバはどれも JCA を実装しているので，その上で S2JMS を使うならこんなの必要ないのですが，スタンドアロンや Tomcat なんかでも S2JMS を使いたい場合に便利なように提供します．
S2JTA と同じような位置づけですね．
現在 OSCJ で公開しているバージョンでは JCA 仕様の「5. Lifecycle Management」「6. Connection Management」および「7. Transaction Management」あたりが実装済みです．これによって，JMS コネクションのプーリングとか JTA との連携が可能になっています．
これから必要なのは「10. Work Management」「11. Inbound Communication」「12. Message Inflow」あたり．後から出てくる S2JMS-Container の土台になります．

S2JMS-Connector

これは任意の JMS 実装向けに JCA リソースアダプタを提供します．
こちらも S2JCA 同様，OSCJ の CVS に入っている状態で outbound (アプリケーションが主体となって JMS を使う方) は実装済みで，inbound (JMS 側がアプリケーションを駆動する方) の実装がこれから必要になります．
同じようなものに Generic Resource Adapter for JMS というものがあるらしい．
ActiveMQ など，今時の JMS 実装はリソースアダプタも一緒に提供していることが多い気のせいがするので，こいつのプライオリティは低めでいいかなと思ったり．

S2JMS-Core

これは JMS API を扱う比較的低水準のコンポーネント群．S2JDBC の JMS 版みたいな．
OSCJ の CVS に入っている状態で基本的なことはできるのですが，手元ではちょこちょこ変更しちゃってます．

S2JMS-Container

これが S2JMS の目玉にして本丸．でも現時点での実装は皆無 (苦笑)．
こいつは EJB の Message Driven Beans (MDB) を代替するもので，いわゆる Message Driven POJOs を実現します．
JMS な MDB だと EJB3 になっても javax.jms.MessageLister を実装しなきゃいけないようですが (だよね？)，おいらは javax.jms.MessageLister は嫌いなので，S2JMS-Container では POJOs は特定のインタフェースを実装しなくてもいいようにします．
っていうか，javax.jms.Message も気にしなくて済むようにします．
要するに javax.jms.MessageListener は javax.servlet.http.HttpServlet，javax.jms.Message は javax.servlet.http.HttpServletRequest みたいなものなわけで，そんなのをアプリケーションコンポーネントで意識したくねーよって話です．
基本的には S2JMS-Container が javax.jms.MessageLister の実装クラスを用意して，リソースアダプタから呼び出されると javax.jms.Message のメッセージボディやヘッダ，プロパティをコンポーネントにバインドしてリスナーメソッド (名前は任意) を呼び出します．
イメージは S2JSF なんかの JMS 版．HTTP リクエストの代わりに JMS メッセージをバインドする感じ．
でもでも，S2JSF における HTML みたいな情報はないので，どこでどうやってバインディングを解決するかが悩ましい．
あと，将来アプリケーションサーバ上で S2JMS-Container を動かすことを考えると，S2JMS-Container 自身を MDB として実装することになるのかなぁ．あ，S2 が EJB3 サポートするってことなので，それでもいいかもなぁ．ちょっと考えておくテスト．
っていうか，JCA の EndPoint って MDB なんだよね．やっぱ MDB として実装するのが真っ当か？

S2JMS-Server

スタンドアロンで S2JMS-Container を実行するために main(String[]) メソッドを提供します．これまた現時点での実装は皆無．
こいつが S2 コンテナを初期化して，そうすると S2JCA がリソースアダプタを初期化して，それによってメッセージの受信が始まって，メッセージが届くと S2JMS-Container が呼び出されて，メッセージがコンポーネントにバインドされてリスナーメソッドが実行されて．．．みたいな．

だいたいこんな感じ．
前は S2JMS-Dao って構想もあったのですが，JMS の場合 Dao インタフェースをあれこれ用意したくなることはなさそうなので，なくてもいいかなと思ったり．もう着手しちゃってたらごめんなさい＞むらたさん

とりあえず S2JCA あたりから手を付けよう．これがないと始まらないので．もしかしたら S2JMS-Connector も一緒にやるかも．
と，以前も書いた気がするけど (苦笑) 気にしない気にしない．
その前に，OSCJ の CVS から seasar.org の SVN への引っ越しをしなくては．ちょっと整理した上で，近日中に移動します．

それから，S2JMS (S2JCA 含む) は Java5 前提にするかもしれません．
主に S2JCA で java.util.concurrent を使うかもしれないのと，S2JMS-Container でアノテーションを多用するかもしれないためです．
J2SE1.4 で S2JMS を使いたいなんて要望がある人はお早めに．いないと思うけど．