現場レベルでのJDBCとEJBのトレードオフ

パコパコキーボードを叩きつつ、今日も開発しております。
以外に日記が書ける分余裕があると思いきや、土日に纏めて書いているので、もはや「日記」では無いですね。

漸く開発も佳境に差し掛かってきました。ま、半分程度ですが。いよいよ取り込んだデータをDBに保存する部分の開発になりました。フレームワークが古い為、当然JDBC(Java Data Base Connect)を利用するわけですが、世の中はEJB(Enterprise JavaBean)一色です。

The Enterprise JavaBeans architecture is an architecture for component-based distributed computing.Enterprise beans are components of distributed transaction-oriented enterprise applications.

EJBは米JavaSoftが提供する「Enterprise JavaBeans Specification v1.1 (release 12/17/99)」には上のように定義されています。
つまり、「分散トランザクションを実行する分散型エンタープライズ・アプリケーションを構築するためのコンポーネント・モデルである」という事らしいのです。
実装観点で言えば、EJBはアプリケーションサーバーのEJBコンテナで動作し、ローレベルのサービス（トランザクション制御、EJB自身のライフサイクル管理、マルチスレッド制御、各種オブジェクトのプーリングやキャッシングなど）を提供します。
特にWork Threadを使用しているWebアプリケーションの場合は、インスタンスの寿命やDBアクセスのタイミングを制御する必要があります。これらを実装する事無く、Webサービスとして制御出来るとなれば、かなり楽になるわけです。

でもですね、遅いんですよ、EJB。CMP 1.1の仕様通りの実装になると、EJBの変更の有無を判断できないので、無条件で読み出しては書き出すという処理を実行してしまうのです。
インスタンス化の度にSQLを発行していたら、いくらトランザクション管理がなされているとはいえ、サーバーリソースを無制限に使う事になってしまいます。

EJB2.0の仕様で大分改善が成されたとはいえ、まだまだJDBC隆盛は続く事でしょう。SQL発行と同時にJavaBeansをインスタンス化し、使う度にインスタンスを破棄するか、Sessionに格納すれば任意の場所でデータ使えますし（Sessionが重くなってしょうがないですけど）。

新しい技術が次々と生まれてきますが、実際使えるかは自分のスキル次第と言う事でしょうか。私の様な未熟者にはまだまだ難しい技術ではあります。
でもですね、便利な技術が沢山生まれてくるからといって、それが流行るかどうかは別問題で、そのサポートをするかは更に別問題です。作っても保守できないと意味が無いですしね。
さて、テスト仕様書書かなくては…。