[Think IT] 第1回：EJBのすべてを知る (1/3)

EJB 3を再考する

第１回：EJBのすべてを知る
著者：レッドハット田澤孝之 2007/9/12

1 2 3 次のページ

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の難しさを対照的に表現するためにできた言葉だったのです。

※注1：POJO
Plain Old Java Objectの略。JavaオブジェクトがEJBのように特殊なものではなく、一般的な普通のJavaオブジェクトであることを強調する名称のこと。

図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のデザインパターンが世の中に浸透し、適用されていきました。

Core J2EE Patterns
http://java.sun.com/blueprints/corej2eepatterns/index.html

1 2 3 次のページ

著者プロフィール
レッドハット株式会社田澤孝之
JBossグループ SE部マネージャー
1989年より日立製作所にてIT業界に身をおく。1998年より日本BEAシステムズにてTPモニタ、サーバサイドJavaにフォーカス。特にJ2EEに特化しプリセールス、インストラクタ、SOAコンサルタント業務に従事。2006年よりファストサーチ&トランスファで企業向けサーチソリューションコンサルタントを経て、2007年よりレッドハットにてJBossの販売提案と導入技術支援を行う。「EJB 2.0 徹底攻略」（技術評論社）など著書、共著多数。

この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。
ご意見、ご要望にお応えします！インプレスIT INSIDE

INDEX
第1回：EJBのすべてを知る
	Java EEとEJB
	EJB 2.0の登場
	EJB 3.0の登場

EJB 3を再考する
第1回	EJBのすべてを知る
第2回	ステートレスセッションBeanでの実装
第3回	ステートフルセッションBeanでの実装

JBoss Enterprise Application Platformの全貌

DIxAOPコンテナ「Seasar2とSpring」

Think IT 過去人気記事

Think IT人気ライター BEST 5

IT製品/サービス資料ダウンロード

Think IT 過去人気記事

Think IT人気ライター BEST 5

テクノロジーメディア