第3回　EJBの正しい用い方
――JavaBeansとEJB、どちらを使えばよいのか――

どこでも使えるビーンにするための考慮点を知る

　APサーバはEJBを稼働させる専用の機能があります。これを「EJBコンテナ」とかただ単に「コンテナ」と呼んでいます。現在、流通しているAPサーバにはコンテナ機能がほとんど組み込まれています。またいままで何度も出てきていますが、コンテナにはEJBを導入する（これをデプロイといいます）機能が付けられています。J2EEというJavaのオープンな取り決めが行われている中で、EJBだけでなくサーブレット、JSP、HTMLコンテンツなども一括してWebサーバやAPサーバ、コンテナにデプロイする方法が確立してきました。

　しかしAPサーバやEJBなどの開発ツールを提供するソフトウェアメーカーやベンダは、もっとユーザーに分かりやすい方法や手順でこれらを導入する方法を提供している場合もあります。Javaの世界では標準もどんどんいいものを取り入れて変化していきますし、いままでやっていた手順がなくなってしまうこともあります。結局重要なのは、APサーバにEJBを導入することではなく、どのAPサーバでもうまく稼働する業務ロジックのデザイン手法です。これからお話しするEJBを作る考慮点は、JavaやAPサーバのバージョンが変化しても決して変わることのない、今後も応用の利くEJBの設計コンセプトといえます。

設計コンセプト(1)
EJBはどこで動くか分からない部品だ、ということを認識しよう

　ここで重要なことは、EJBの業務ロジックの処理はコンピュータにその処理に必要な機能や資源が必ずあると思ってはいけないことです。上記のexecuteメソッドで説明した件もそうですが、EJBが動いているコンピュータに特定のRDBやそのほかのミドルソフトが必ず存在すると思ってはいけません。またEJBが動くコンピュータは大型コンピュータもあればパソコンも考えられます。コンピュータによっては、HDDを全然持たずにメモリだけで動くコンピュータもあります。それゆえ業務処理がふんだんにハードディスクやメモリを要求しても、コンピュータ自体がそれにこたえられない場合もあるわけです。ですからEJBが稼働するコンピュータに必ず自分の使いたいリソースが存在すると思わないように心がけることが重要です。
設計コンセプト(2)
コンテナで提供されるミドルソフト機能だけを使うようにしよう

　とはいっても、EJBが稼働する環境でまったく使える機能や資源がないかといえばそうではありません。コンテナではEJBの業務ロジックで必ず使うことになるような機能をいくつか提供してくれています。例えばexecuteメソッドにあった特定のRDBへのアクセスの個所を見てみましょう。業務ロジックではRDBにアクセスするというのは必須の機能でもあります。そこでコンテナではデータソースという共通のRDBアクセス機能を提供しています。これを使えば業務ロジックに特定のJDBCドライバの名前を記述しなくてよくなります。以下のリスト3を見てください。これがリスト2の部分をデータソースを使った部分に変更したものです。このような変更を行っても、それ以外のコードはまったく変更しなくても構いません。

リスト3　 DBアクセス部分をデータソースに変更する
InitialContext initCtx=new InitialContext();
DataSource ds=(DataSource)initCtx.lookup("jdbc/your_database");
Connection dbConn =ds.getConnection("userid","password");

　データソースというのは、いわばコンテナで提供されたRDB接続のための共通ミドルソフトといえます。このようにコンテナで提供された機能を使う限りは、すべてのAPサーバのコンテナでも同じ機能を使えます。すなわち結果的にどのAPサーバでも動く業務ロジックになります。またAPサーバでもデータソース以外に共通のミドルソフト機能があります。例えばOLTPミドルソフトで提供されているトランザクション機能も提供されています。通常、業務ロジックからトランザクションを発生させたり終了させる場合には、プログラムでbeginやcommitと呼ばれるAPIを呼び出す必要があります。EJBでは、これらトランザクションの制御に関するAPIをコンテナで自動的に呼び出したり、またプログラムで記述した自由に定義できる機能を提供してくれています。

　またJ2EEという仕様では、キューを使ったサーバサイドJavaプログラム間の通信（これをJMS機能といいます）を標準的なミドルソフト機能として提供します。
これをEJBで応用すると、相手のキューに対するデータ転送もトランザクション単位に含めることができるわけです。

データソースというのは、業務ロジックがデータソースを使ったとき、どのRDBにアクセスするかAPサーバ上で定義しておかないと使うことができません。

WebSphere Application Serverデータソース定義画面〜その1

データソース定義画面〜その2

このおかげで業務ロジックにデータソース名だけを指定すれば、あとはAPサーバが目的のRDBに接続してくれます。どのメーカーのRDBに接続すればいいかは、APサーバ上の定義だけで決まるのでプログラムの記述にはまったく依存しません。
設計コンセプト(3)
EJBに必要な機能を明確に分かるようにしておこう
　業務ロジックのほとんどはほかのプログラムの処理結果やミドルソフト機能の力を借りなければ実行できないケースが多いはずです。例えば業務ロジックからユーザーに対してメールを送信したり、既存のオンライン処理の一部を活用したいことも頻繁にあるでしょう。このような処理を最近では基幹システム連携ということも多いようですが、業務ロジックからこれらほかのプログラムを活用するのは、一種の業務ロジックからのミドルソフト呼び出し処理といえなくもないケースといえます。何度もいいましたが、コンテナで標準的に提供されていないミドルソフト機能を呼び出すときは、その環境がセットアップされているコンピュータ上でしか稼働できないEJBになることに注意しないといけません。しかしここで間違えてはいけないのは、絶対にこのようなEJBを作っていけないかというと、必ずしもそうではないということです。業務の内容によっては、どうしてもEJBの業務ロジックで特定のミドルソフトを使いたいケースも出てきます。このときに重要なのは、EJBの業務ロジックでどのような機能を要求するのかEJBを導入して使う人が、EJB情報やマニュアルなどを作成して、明確に分かるようにしておくことです。

　EJBをAPサーバで活用したいと思う人が、APサーバ以外のほかのどのような機能が必要になるか明確に判断できれば、だれでも失敗なく目的のEJBを動かすことができます。このようにEJBをトラブルなく稼働させるためには、業務ロジック内部の工夫だけでなく、きちんとEJBの仕様が分かる情報も一緒に付加させることが重要だということを覚えておいてください。
設計コンセプト(4)
EJBにタイミングやパフォーマンスを期待してはいけません

　最後にEJBは、どこでも必ず期待した性能で動くとは限らないことを認識しないといけません。Windowsパッケージの例に戻りますが、たとえパッケージが動いたとしてもCPUパワーが少なく、メモリやHDDの余裕のないコンピュータで動いているとすれば、パッケージの性能が悪いことは皆さんも十分承知していることだと思います。これと同じようにEJBが動く環境も、大型コンピュータもあればオフコンもあります。またパソコンもあるでしょう。このようにどんなコンピュータで動くか分からないEJBの業務ロジックに、一定時間以内に処理の戻りを期待するような、タイミング依存の処理を記述するのは避けるよう心がけてください。

4/5

　INDEX
第3回　
　 今回の内容の目的  
  JavaBeansとEJBのメリットとデメリットを知る
EJBがJavaBeansのデメリットを改善する
EJBは業務処理をサービスする窓口でもある
  EJBを流通するという考え方
業務処理は必ず失敗なく実行されないといけない
どこでも使えるBeanにするための考慮点を知る
  JavaBeansにするのか、EJBにするのか
では実際にどうするのか？
  


連載記事一覧




Java Agile フォーラム 新着記事
＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

注目のテーマ

Java Agile 記事ランキング

本日 月間
＠IT