初めてのJava EE 6──第3回 ビジネス層と永続化層の開発にEJB、JPA使う理由

Oracle Java & Developers編集部
2014-05-26 11:00:00
  • このエントリーをはてなブックマークに追加

Java EEアプリケーションの開発では、なぜEJBとJPAを使うのだろうか? 最終回となる今回は、ビジネス層、永続化層の開発にこれらの技術を使う理由と、それぞれの特徴を説明する。

【「初めてのJava EE 6」シリーズ 前回までの記事はこちら】

EJB─作るのは簡単。POJOにアノテーションを追加するだけ

松林晶氏
日本オラクル Fusion Middleware事業統括本部ソリューション本部 Cloud Application Foundationソリューション部 シニアセールスコンサルタントの松林晶氏

 前回はJava EEアプリケーションのプレゼンテーション層を担うJSF(JavaServer Faces)について説明しましたが、今回はビジネス層を担う「EJB(Enterprise JavaBeans)」と、永続化層を担う「JPA(Java Persistence API)」を取り上げます。まずはEJBについて説明しましょう。

 JSFで作られた画面でユーザーが入力した値は、何らかの業務処理を経た後、その結果が遷移先の画面として返されます。この流れの中で、業務処理を行うビジネス・ロジックの開発に使うフレームワークがEJBです。

 EJBで開発するコンポーネントは「EJBコンポーネント」と呼ばれますが、これには下表に示すようにいくつかの種類があります。

【EJBコンポーネントの種類】

コンポーネントの種類 説明
セッションBean(Session Bean) クライアント/サーバ間やシステム間のやり取り(セッション)を通じて実行するビジネス・ロジックを実装するためのEJBコンポーネント。セッションの状態を保持しないステートレス・セッションBean(Stateless Session Bean)、セッションの状態を保持するステートフル・セッションBean(Stateful Session Bean)、JVMごとにインスタンスが常に1つであることが保証されるシングルトン・セッションBean(Singleton Session Bean)の3種類がある
メッセージ駆動Bean(MDB:Message Driven Bean) メッセージ・サーバからの要求に応じてビジネス・ロジックを実行するEJBコンポーネント。メッセージングを介したシステム連携を行う場合に作成する
エンティティBean(Entity Bean) データベースへのデータ永続化に使用するEJBコンポーネント。同様の機能を実現する技術としてJPAが導入されたのに伴い、現在は非推奨(将来的に廃止される予定の機能であるため、使用が推奨されない)の扱いとなっている

 表に挙げたEJBコンポーネントのうち、皆さんがWebアプリケーションの開発で最も頻繁に作るのは「ステートレス・セッションBean」でしょう。そこで以降では、このステートレス・セッションBeanを例にとって説明します。

 次に示すのは、ステートレス・セッションBeanのコードの例です。

【ステートレス・セッションBeanのコードの例】


@Stateless
@LocalBean

public class BookSessionBean {
    public void addBook(Book b){
      …略…
    }

    public Book getBook(long id){
      …略…
    }
}


 この例では、蔵書を管理するアプリケーションを想定しており、「蔵書データベースに新たな書籍情報を追加する(メソッドaddBook)」、「蔵書データベース内の特定の書籍情報を参照する(メソッドgetBook)」といった操作がビジネス・ロジックに当たります。

 ステートレス・セッションBeanなどと書くと難しそうな印象を受けるかもしれませんが、ご覧のとおり、通常のJavaクラス(POJO:Plain Old Java Object)とほとんど変わりません。POJOと異なるのは、コード内に赤字で記した部分です。これらの部分では、Javaのアノテーションの仕組みを利用して、次の情報をアプリケーション・サーバに伝えています。

  • @Stateless:ステートレス・セッションBeanであることを示す
  • @LocalBean:EJBの旧バージョンで必須とされていたインタフェースの作成を省略することを示す

 POJOにこれらのアノテーションを付加するだけで、そのJavaクラスはアプリケーション・サーバ上でEJBコンポーネントとして扱われるのです。EJBは、かつては約束事や作成するファイルが多く、敷居の高い技術だと言われていましたが、Java EE 6ではこんなに簡単に作れるようになっているのです。

なぜEJBを使うのか?

 ところで、前回も触れたように、Java EEでは、プレゼンテーション層を担うJSFだけで、ある程度の機能を備えたWebアプリケーションを作ることが可能です。それでは、なぜプレゼンテーション層とは別にビジネス層を設け、その開発にEJBを使うのでしょうか。その理由としては、次の2つが挙げられます。

  • ビジネス・ロジックの再利用性の確保
  • アプリケーション・サーバ/EJBコンテナに備わる機能の活用

 まず「再利用性」ですが、企業システムにおいて、ビジネス・ロジックを呼び出すプログラムは、Webアプリケーションの画面だけとは限りません。SwingやJavaFXで作られたスタンドアロンのアプリケーションからネットワークを介してリモートで呼び出されることもありますし、メッセージングを介して他システムから呼び出されることも、あるいはWebサービスとして他システムから呼び出されることもあります。

 しかし、呼び出し元が何であれ、実行するビジネス・ロジックは同じです。そこで、呼び出し元の違いに応じてビジネス・ロジックを作るのではなく、ビジネス・ロジックはビジネス層として、呼び出し元の違いを吸収する層(Webアプリケーションならプレゼンテーション層)とは分けて作ることで、ビジネス・ロジックを再利用できるようにしているのです。

 ただし、単に再利用性の確保だけが目的なら、ビジネス・ロジックをEJBコンポーネントとして作る必要はありません。POJOとして作り、それを各呼び出し元から使うかたちにしても問題はないはずです。実際、簡易なシステムでは、そのように作るケースもあります。

 それでは、なぜEJBを使うのかというと、アプリケーション・サーバと、その一部であるEJBコンポーネントの実行環境(これを「EJBコンテナ」と呼びます)の機能を利用するためです。

 第1回でも説明したように、Java EEは、Java SEに対して企業システムの開発に必要となる機能を追加した仕様です。その追加された機能を、EJBコンテナやアプリケーション・サーバが提供してくれることで、開発者は個々のアプリケーションに固有の処理だけを作れば済むようになるのです。アプリケーション・サーバやEJBコンテナが提供する主な機能としては、次が挙げられます。

●依存性の注入(DI:Dependency Injection):

ビジネス・ロジックの実行にあたって必要となる他のJavaオブジェクトへの参照を自動的に注入(Inject)する。この機能により、ビジネス・ロジックを、その実行に際して必要となる周辺機能から容易に分離して再利用することが可能となる

●トランザクション管理:

データベースに対するトランザクションの開始、終了、ロールバックなどの制御を行う

●インスタンス・プーリング:

一度生成したEJBコンポーネントのインスタンスをプールして複数のセッションで再利用し、インスタンス生成などによるリソース消費を抑制する

●セキュリティ:

クラスやメソッドのレベルでEJBコンポーネントへのアクセスを制御する

●タイマー:

指定した時間にビジネス・ロジックを実行する

 これらは、いずれも今日の企業システム開発に必須の機能です。ビジネス・ロジックをEJBコンポーネントとして作る場合、アプリケーション・サーバやEJBコンテナに用意されたこれらの機能を使えるようになり、開発者はアプリケーション固有の処理の開発に注力することができます。これが、ビジネス・ロジックをEJBで作る理由なのです。