軽量Javaが最近もてはやされる理由   翔泳社『DBマガジン』2005年9月号 「アプリケーション開発-そこが知りたい-」に掲載   石川智久/高橋英一郎/山本啓二

悩みの種は尽きません

前回の繰り返しになりますが、ソフトウェアアーキテクチャには、ソフトウェアのレイヤ構成、ユーザー認証、セッション管理、DBMSへのアクセスなど、多岐にわたる要素が含まれます。それらの中でソフトウェアのレイヤ構成は、すべてのアプリケーションに必須であるにもかかわらず、その設計と実装にこれといった一般解が存在しないため、開発者を非常に悩ませます。プレゼンテーション層、ビジネスロジック層、永続化層といった各層（レイヤ）をどのような技術を利用して実装するのか、各層の間をどう結合するのか、悩みの種は尽きることがありません。プレゼンテーション層については、最近、Struts(注1)などがデファクトスタンダード的なポジションを占めるようになり、悩むことが少なくなりました。しかし、それ以外の層に関してはなかなか単純に決めることができないのが現状です。そこで今回は、J2EE においてビジネスロジック層から永続化層までをカバーする「EJB（Enterprise JavaBean）」にスポットを当て、その仕組みと現状を見ていきます。さらに、EJB以外の選択肢となる技術を紹介します。

EJB の仕組みと問題

EJBとは

ご存知の方も多いと思いますが、EJBの概要について簡単に説明します。EJBとは、J2EE の中核をなす仕様で、一言で要約すると「サーバーサイドにおけるコンポーネント技術」です。コンポーネントという言葉もアーキテクチャに負けず劣らず実体を捉えづらい言葉ですが、ここでは「“受注処理”といった特定のサービスを提供するクラスの集合体」だと思ってください。特定の機能に特化したクラス群を一箇所に集めてコンポーネント化しておくことでクラス間の依存性を管理しやすくなり、コードの再利用性やメンテナンス性を高めることができます。大規模なシステムになるとコードの再利用性やメンテナンス性が非常に重要となってきますので、EJBはそのような状況で力を発揮してくれる技術と言えます。さらに、EJBでは各コンポーネントを分散オブジェクト(注2)として呼び出すことも可能ですので、大規模システムで問題になりがちなスケーラビリティに関しても有効です。EJBはそのほかにも、トランザクション管理、セキュリティ管理といった種々の機能を提供しています。EJBは、コンポーネントの実体である「エンタープライズBean」と、そのエンタープライズBeanが動作する環境である「EJBコンテナ」とが協力して動作します（図1）。

図1 EJBはエンタープライズBeanとEJBコンテナが協力して動作する

エンタープライズBeanは、EJBの規約に従ってコーディングされたJavaクラスで構成されます。開発したエンタープライズBeanを実行するには、EJBコンテナに「デプロイ（配置）」します。EJBコンテナは、設定に従ってエンタープライズBeanを実行可能な状態にし、エンタープライズBeanにトランザクションやセキュリティなどのさまざまなサービスを提供します。EJBコンテナがさまざまな機能を提供してくれることで、開発者はトランザクションやセキュリティなどの非機能的なコードを記述する必要がなくなり、本来の目的であるビジネスロジックの実装に注力できます。また、エンタープライズBeanには、その用途別にいくつかのタイプが存在します（図2）。

図2 さまざまなエンタープライズBean

「エンティティBean」は、ビジネスデータを表わすコンポーネントで、DBMSとのマッピングに使用されます。「セッションBean」は、ビジネスプロセスを表わすコンポーネントで、ビジネスロジックの実行に使用されます。「メッセージ駆動型Bean」は、ビジネスプロセスを表わすコンポーネントであるという点においてはセッションBeanに似ていますが、呼び出し方法が同期ではなく非同期（呼び出した処理の終了を待たずに次の処理に移る方式）で行なわれる点がセッションBeanと大きく異なります。

複雑で難しすぎるEJB

「ソフトウェアのコンポーネント化が可能」「トランザクション管理やセキュリティ管理などをコンテナに任せられる」「分散オブジェクトも可能」と、たくさんのメリットがあるEJBです。至るところでその能力を遺憾なく発揮している……と思いきや、実情は少し異なっているようです。確かにEJBは優れた技術であり、大規模システムなど、利用される場面によっては非常に有効です。にもかかわらず、実際にEJBが利用されている場面はかなり限られており、筆者の周りでは唯一セッションBeanだけが利用されているという状況(注3)です。セッションBean以外のエンティティBeanやメッセージ駆動型Beanなどはあまり利用されません。特に、中小規模システムではこの傾向が顕著なようです。なぜでしょうか。理由は単純明快です。EJBは「複雑すぎる」のです。そもそも、EJBは多種多様な機能を提供するために非常に重厚長大な仕様となっています。現在、主に利用されているEJBのバージョン2.1の仕様書(注4)は、何と650ページを超えます。EJBが提供している機能を考えると妥当なページ数なのかもしれませんが、「ちょっと勉強しよう」というレベルからは遠くかけ離れているのは確かです。仕様の複雑さを反映するかのように、利用方法もかなり難易度が高く、一昼夜程度の付け焼刃の勉強では開発マシンを前に頭を抱えることになってしまうでしょう。実際にEJBを使用するためには、EJB固有のコーディング方法からトランザクションなどの各種設定方法、エンタープライズBeanのデプロイ方法、アプリケーションサーバー依存（！）の設定方法などさまざまなことを学習しなければなりません。その教育コストを考慮すると、多くのプロジェクトではEJBを利用することのメリットがデメリットよりも小さくなってしまうのです。ほかにもありますが、これがEJBが積極的に利用されていない主な理由です（図3）。

図3 EJB のメリットとデメリット

EJBの中でセッションBeanだけが利用されているのは、分散オブジェクトによるリモート呼び出しや、トランザクション管理の自動化といったメリットが大きいからです。ビジネスロジックをセッションBeanでラッピングしておくことで、ビジネスロジックを分散オブジェクトとしてアクセスすることが可能となります。そのため、後からシステム間連携が必要となった場合でもビジネスロジックをリモートから簡単に呼び出せますし、 スケーラビリティに関するチューニングが必要になっても比較的容易に対応できます。セッションBeanを利用していないアプリケーションにこれらの対応を行なうのは、かなりのコード変更を伴う大きな改修となってしまいます。さらに、単純なトランザクションの場合、セッションBeanを利用してEJBコンテナにトランザクション管理を任せたほうがコードがシンプルになりますし、開発の工数を抑えることができます。ただし、筆者がセッションBeanを使用する場合、複雑な設定を要する機能の利用は避け、極力設定を複雑にしないように注意しています(注5)。

 

（注1）Apacheプロジェクトが開発を行なっているJ2EE用のWeb 層フレームワーク。http://struts.apache.org/

（注2）リモートのシステムから呼び出せるオブジェクトのこと。EJB のほかにも、CORBA（Common ObjectRequest Broker Architecture）やCOM+（ComponentObject Model Plus）などの仕様が有名。

（注3）セッションBeanにはステートレスとステートフルの2 種類が存在していますが、実際に利用されているのはほとんどがステートレスです。これは、単純にEJBでセッションを維持することがないためです。

（注4）EJB の仕様書は、http://java.sun.com/products/ejb/docs.htmlで入手できます。

（注5）それでも、結構複雑で面倒な設定が必要になってしまったりするのですが……。