40. EJB が要求したものと Spring の登場

(Enterprise JavaBeans)は、でサーバ側の業務部品を書くための仕様です。EJB 2.1(2003年11月)でという部品を1つ作るには、Bean クラスのほか、リモートから呼ばせるならリモートとホームの2つの、さらに XML のが要りました。Bean クラスは javax.ejb.SessionBean を実装する決まりです。

業務ロジックのが、の定めた型を実装しないと部品になれない点が論点でした。Fowler らは2000年9月、普通の Java をと名付けています。公式リファレンスは、は2003年に初期の J2EE 仕様の複雑さに応えて生まれたと書きます。2004年3月24日の 1.0 の告知は、どの POJO にも(開始と確定を設定で指定する方式)をかけられる点を挙げました。

ただし「EJB は重かったので消えた」とは言えません。確かめられるのは、EJB 3.0(2006年5月)の仕様自身が目的を「開発者から見た複雑さを減らすこと」と書き、ホームインターフェースや記述子を必須から外したことまでです。2.1 の API は 3.0 でも残りました。Spring のリファレンスも、Java EE と Spring は競合ではなく補完し合うものだと述べています。

点線の付いた語はタップすると説明が出ます。用語集を開く →

部品1つに必要だったもの(EJB 2.1 仕様 7.11)と、3.0 で必須から外れたもの

リモートインターフェースEJBObject を継承

ホームインターフェースEJBHome を継承

デプロイ記述子META-INF/ejb-jar.xml

どれも次の1クラスを部品にするために書く

Bean クラスjavax.ejb.SessionBean を実装 + 業務メソッド

コンテナの型に依存している

業務ロジックだけを取り出すと

POJOPlain Old Java Object。何も継承・実装しない普通のクラス

Spring 1.0(2004年3月)はこれをクラスの外から組み立てる

・EJB 3.0(2006年5月)は、ホームインターフェースと記述子を必須から外し、業務インターフェースは EJB の型を継承しない普通のインターフェースでよいとしました。Bean クラスが javax.ejb の型を実装する要求も外れました
・EJB 3.0 の仕様は目的を reducing its complexity from the enterprise application developer's point of view と書いています
・ここに挙げたのは EJB 2.1 の仕様の文言です。2.0(2001年9月)の仕様本文はこのコースでは確かめていません

サンプルコード(フレームワーク環境が必要なため表示のみ)

// EJB 2.1 で「送料を計算する部品」をリモートから呼べるようにするとき、
// 用意するものの構造(仕様 7.11 の要求を自作の例で並べた擬似コード)
//
// 1. リモートインターフェース ShippingFee
//      業務メソッドの宣言。EJB の型(EJBObject)を継承する
// 2. ホームインターフェース ShippingFeeHome
//      部品を作ってもらう窓口。EJB の型(EJBHome)を継承する
//      リモートインターフェースを出すなら、こちらも必ず要る
// 3. Bean クラス ShippingFeeBean
//      javax.ejb.SessionBean を実装する。業務メソッドに加えて、
//      コンテナから呼ばれるメソッド(ejbCreate など)も書く
// 4. デプロイ記述子 META-INF/ejb-jar.xml
//      上の3つの対応とトランザクションの属性などを XML で書く
//
// 業務ロジックそのものは、この数行
class ShippingCalculator {
    int total(int itemPrice, int fee) {
        return itemPrice + fee;
    }
}

// POJO という考え方: 上のクラスを、何も継承・実装しないまま部品として使う。
// 作ること・つなぐこと・トランザクションをかけることは、クラスの外(コンテナ)に任せる

図やコードに出てくる用語(タップで説明)

サンプルコードで身につける(5本) →

学んだ概念を、素朴な例から実務寄りの例まで5つの具体例で確認します。

公式ドキュメントで詳しく ↗