EJBのすべてを知る

Java EEとEJB

ご存知のとおりJava EEは企業向けの仕様であり、その仕様の中核を担ってきたコンポーネントがEJB（Enterprise Java Beans）であることは誰しも疑わないことでしょう。JBossもEJBoss（Enterprise JavaBeans Open Source Software）として1999年に産声を上げています（その後、商標の関係によりJBossに変更しています）。

Java EEアーキテクチャダイアグラムは図1のようになっています。このようにサーバサイドには2つのコンテナが協調動作をしてエンタープライズレディとなるように設計されています。

図1：Java EEアーキテクチャダイアグラム
出典:Java Platform, Enterprise Edition（Java EE）Specification, v5
（画像をクリックすると別ウィンドウに拡大図を表示します）

昨今ではJavaを利用した企業システムでも、Webコンテナのみでのシステム構築が見受けられます。Webコンテナは名前のとおり、WebブラウザとのHTTP通信をハンドリングするためのものです。

Webコンテナには主にJSPとサーブレットの動作環境が含まれますが、ビジネスオブジェクトをデプロイして動作させることやコンポーネント化する ことは考慮されていません。よって、このようなことを考えて実装しようとなると、デザインパターンを駆使してフレームワークを考えるか、もしくは既存の標 準ではないフレームワークを導入しなければなりません。

しかしEJBが市場に登場して8年以上経過していますが（1998年頃からEJBの実装が登場しています）、EJBを採用するプロジェクトはそれほど多くないのが実情でしょう。それはなぜなのか、ここでは歴史を振り返りながらEJBの現状を整理してみましょう。

EJBの生い立ち

EJBの生い立ちは分散オブジェクトとトランザクションからはじまっています。OMG（Object Management Group）による分散オブジェクトの業界標準仕様である「CORBA（Common Object Request Broker Architecture）」に続き、SunでもJava上のORB（Object Request Broker）として「RMI（Remote Method Invocation）」が登場しました。

そのRMIをベースに、RMIの難しさを隠蔽しつつ、ビジネスロジックを実装するコンポーネントとしてEJBが誕生したのです。

コンポーネントの利点はここで述べる必要はないでしょう。ビジネスロジックを実装するコンポーネントとして、EJBは多くの開発者を引き寄せ、コンポーネントの流通も模索されました。しかしこの「リモート」であるが故の制約によってEJBはその後悩まされることになります。

そして通常のクラス、今でいうPOJO（注1）を考えると、EJBの実装は複雑怪奇でした。そもそもPOJOという言葉も、EJBの難しさを対照的に表現するためにできた言葉だったのです。

図2：EJB 1.1／EJB 2の構成要素
（画像をクリックすると別ウィンドウに拡大図を表示します）

EJB 1.0／EJB 1.1

EJB 1.0ではエンティティBeanはオプション扱いでセッションBeanのみのサポートからはじまりました。この段階ではEJBを実装しているEJBコンテナはほとんどありません。EJBではファクトリパターンの採用、コンテナ経由でのオブジェクトライフサイクル制御のためにホームインターフェース、そして リモートに公開するためのリモートインターフェースも必要でした。さらに開発者を悩ませたのがデプロイメント記述子と呼ばれる定義ファイルでした。このデプロイメント記述子はEJB 1.0ではテキストファイルでの定義で、EJB1.1からXMLに変更されています。

EJB仕様で定義されているデプロイメント記述子に加え、ベンダー固有の定義ファイルまたはコンフィグレーションも必要でした。そしてEJB 1.1の仕様ではエンティティBeanもリモートインターフェースで公開する必要があり、その制限によりエンティティBeanではオブジェクトの関連を持つことができなかったのです。

このエンティティBeanはOOAD（Object-Oriented Analysis & Design）を実践するうえでどうしても不自然な表現になります。そしてリモートアクセスでは性能の問題もあり、必要ない場所でのリモート通信はリソースの無駄遣い以外の何者でもありませんでした。この頃のアプリケーションサーバの実装はWebコンテナとEJBコンテナのプロセスが分かれているものが大 多数であり、同一OS上に2つのコンテナが存在していてもJVMをまたがるリモート通信が必要でした。

この理由として、多くのベンダーはCORBAサーバをEJBサーバへと進化させたものが多かったためです。中には同一JVM内で2つのコンテナが動作するアプリケーションサーバも存在し、さらに呼び出しを参照呼出しとして（仕様では値呼び出し）、EJBのメソッドコールを最適化している実装もありました。

トランザクションに関してはEJB 1.1からうまく動作していました。Java EEのトランザクション仕様である「JTS（Java Transaction Service）」は、CORBA OTS（Object Transaction Service）のJava版という点とトランザクションの考え方、標準化団体X/Open（現、The Open Group）の分散トランザクション仕様であるDTP（Distributed Transaction Processing）モデルをベースとしていたため、それほど新しい考え方ではなかったためです。

またコンテナ管理トランザクションとセッションファサードパターンを適用した場合、これをトランザクションファサードと置き換えて考えることにより、適度なビジネスロジックの公開単位とトランザクション単位をリンクさせることができました。この頃からSunで作成されたJ2EEのデザインパターンが世の中に浸透し、適用されていきました。