Enterprise JavaBeans 3.0仕様入門

Vimala Ranganathan、Anurag Pareek共著
2006年3月29日

概要

Enterprise JavaBeans（EJB）技術は、コンポーネントベースのビジネスアプリケーションの開発とデプロイメントのためのJ2EE技術です。 Enterprise JavaBeansアーキテクチャを使用して記述されたアプリケーションはスケーラブルで、トランザクション型で、多数のユーザが利用する場合も安全で す。

しかしながら、EJBはその豊富な機能にもかかわらず、アーキテクチャの複雑さが敬遠され広範な採用には至っていません。EJBの対象領域は競合技 術に浸食されつつあります。たとえば、永続性ソリューションの開発に際して、ToplinkなどのO/Rマッピング技術やオープンソースの HibernateフレームワークがEJBに代わって採用されるケースが増えています。EJB 3.0仕様の導入は大きな前進であり、開発者をもう一度EJBに呼び戻す絶好のきっかけになるでしょう。この仕様の目標には2つの方向性があります。

  • 開発者にとってEJBによる開発を容易にする。
  • 永続性フレームワークを標準化する。

EJB 3.0は、エンタープライズBeanを通常のJavaBeanと同じように扱うという夢を開発者にとってさらに身近なものにします。EJB 3.0は開発者が作り出すプログラミング成果物の数を減らし、コールバックメソッドの実装を不要もしくは最小限にし、エンティティBeanやO/Rマッピ ングによるプログラミングモデルの複雑さを軽減します。EJB 3.0により、J2EEはより多くの人が利用できるものに生まれ変わりました。

この記事ではまず、EJB 2.1の制限について簡単に解説します。次に、仕様で提案されている重要な変更を1つずつ説明していくことにより、EJB 3.0がこれまでの課題にどのように対処しているかについて解説します。変更点としては、各タイプのエンタープライズBeanへの影響、O/Rマッピング モデル、エンティティ/リレーションシップモデル、EJB QL（EJB Query Language）なとがあります。最後に、EJB 3.0ベースのエンタープライズBeanを使用したサンプルコードを紹介します。

EJB 2.1の制限

これまで、EJB 2.1によるEJB開発は決して容易なものではありませんでした。それは、以下のような理由によるものです。

  • 1つのEJBを作成するために、多数のXMLデプロイメント記述子を作成する必要がある。
  • 3つのソースファイルをセットで作成する必要がある。
  • 通常は決して使われない複数のコールバックメソッドを実装する必要がある。
  • さまざまなタイプの不必要な例外を送出し、捕捉する必要がある。

もう1つの不満は、コンテナ管理エンティティBeanのようなコンポーネントが抽象クラスであるために、コンテナのコンテキストの外側ではEJBのテストがまったく不可能なことです。

最後に、現在の形態のEJB-QLは機能が制限されており、使いやすいとはいえません。これらの制限により、開発者はやむなく、シンプルなJDBC とSQLの組み合わせを利用したり、ToplinkやHibernateのような他の永続性フレームワークを利用したりしています。

APIの冗長さひとつをとっても大きな頭痛の種であり、EJB 3.0ではほとんどの問題に対処するための重要な試みがなされています。この記事では、この仕様の重要な側面について扱っています。

デプロイメント記述子はもう不要

XMLデプロイメント記述子のコンフィグレーションは、EJB開発の簡素化を妨げる主要なボトルネックでした。したがってEJB 3.0仕様では、煩雑なXMLファイルの取り扱いから開発者を解放することを主目標の1つに掲げました。これは、JCP仕様JSR 175の一部としてJDK 5.0に追加されたメタデータ注釈の使用によって達成されます。注釈は属性指向のプログラミング手法の一種であり、XDocletに似ています。しかしな がら、事前のコンパイルが必要なXDocletと違って、注釈はJavaコンパイラによってコンパイル時にクラスにコンパイルされます。開発者の視点から は、注釈はpublicやprivateのような修飾子であり、クラス、フィールド、またはメソッド内で使用できます。

import javax.ejb.*; 

@Stateless

public class MyAccountBean implements MyAccount

{

  @Tx(TxType.REQUIRED) 

  @MethodPermission({"customer"})

  public void deposit(double money) {...}

}

注釈は通常、自己説明的です。 @Stateless注釈はBeanがステートレスであることを示します。 @Tx属性はメソッドのトランザクション境界設定を指定し、 @MethodPermission属 性はメソッドへのアクセスを許可されるユーザを指定します。これが意味するのは、これらのプロパティを説明するためにXMLデプロイメント記述子を記述す る必要がなくなったということです。ただし、XMLの使用が完全に排除されるわけではありません。その使用が必要に応じたものになる、というだけのことで す。仕様では、XMLデプロイメント記述子を使用してこれらの注釈をオーバーライドすることを許可しています。

POJOプログラミングモデル

重要な注意点として、上のステートレスセッションBeanの例はそれ自体で完全なものです。注釈を無視すれば、このファイルはPOJO（Plain Old Java Object：通常の従来型Javaオブジェクト）とも呼ばれるJavaBeanです。インタフェースはエンティティBeanに対してはオプションであ り、セッションBeanおよびメッセージ駆動型Beanに対しては必須です。ただしこれは、セッションBeanまたはメッセージ駆動型Beanに対して開 発者がインタフェースを定義しなければならないという意味ではありません。開発者がインタフェースを実装しない場合、Beanインタフェースは自動的に生 成されます。生成されるインタフェース（ローカルまたはリモート）のタイプは、Beanクラスで使用した注釈に依存します。次のように、Beanクラスの すべてのpublicメソッドは、自動生成されるビジネスインタフェースの一部として取り込まれます。

public interface ShoppingCart

{

  public void purchase(Product product, int quantity);

  public void emptyCart();

}

クライアントに公開するインタフェースのメソッドを自分で選択したい場合や、自動生成される名前とは異なる名前をインタフェースに付けたい場合は、インタフェースを明示的に生成することが推奨されます。

このインタフェースクラスはPOJI（Plain Old Java Interface：通常の従来型Javaインタフェース）です。インタフェースとBeanクラスはどちらも、 RemoteExceptionのような不必要な例外を送出する必要はありません。

Pages: 1, 2, 3, 4, 5, 6

Next Page »