現在のテクノロジーのもとで Enterprise JavaBeans (EJB) コンポーネントを導入すべきかどうか、またいつ導入すべきか - 今のプロジェクト・チームはこの問題に頭を悩ませています。読者が他のテクノロジーから EJB コンポーネントへの移行を検討している場合、または EJB コンポーネントを使用する新しいプロジェクトを検討している場合には、以下に示すいくつかの質問に答えて、こうした決定を下すのに役立てることができます。さらに、EJB コンポーネントを採用した 2 つのプロジェクトを比較して、実際に EJB コンポーネントが適切に利用されている様子、および不適切に利用されている様子も示します。

EJB コンポーネントとは何でしょうか。EJB コンポーネントは、エンタープライズ・アプリケーションで使用できる Java コンポーネント・モデルです。

• EJB コンポーネントは標準的な分散オブジェクト・テクノロジーである CORBA および RMI に基づいた、サーバー側の Java コンポーネントです。EJB コンポーネントは常に分散されており、この点で標準的な JavaBeans コンポーネントとは基本的に異なります。
• EJB コンポーネントは、アプリケーションの中で “ビジネス論理” の部分を提供します。EJB は表示方法を扱わないため、何らかの表示テクノロジー (たとえば HTML クライアント用のサーブレットや JavaServer Pages (JSP) テクノロジー、または AWT や Swing のようなテクノロジーを使用する Java アプリケーション) とともに使用する必要があります。
• アプリケーション・サーバーが EJB 仕様を実装すると、セキュリティー、リソースのプール、永続性、並行性、トランザクションの保全性といった複雑な機能を処理するサービスが提供され、こうしてビジネス・アプリケーション・システムがより単純になります。

Sun の EJB コンポーネント・モデルの場合、(一般にアプリケーション・サーバーと呼ばれる) EJB サーバー環境で EJB コンポーネントを実行する必要があります。この記事で紹介する例では WebSphere Application Server アドバンスド版を使用していますが、ここで説明する機能はほとんどの EJB サーバーに当てはまります。

技術的な検討事項

読者の置かれた状況で EJB コンポーネントが適切なテクノロジーであるかどうかを判断するために、いくつかの質問をしてみましょう。これらの質問のすべてに “Yes” と答えることができれば、読者の環境では EJB コンポーネントのテクノロジーが適していると言えるでしょう。いずれかの質問が読者の環境に当てはまらない場合には、他のテクノロジーの方が適しているかもしれません。

ビジネス論理コンポーネントを公用のインターネットから分離する必要がありますか ?

多くの企業では、アプリケーション・ソフトウェア、とくにビジネス論理を構成する規則およびデータ構造 (たとえば株取引 Web サイトに含まれるプロプラエタリー分析ツール) を重要な企業資産とみなします。これらの資産のソース・コードやオブジェクト・コードに部外者がアクセスすることは、企業にとってきわめて打撃的です。このため、このような企業は、保護されたファイアウォール (非武装地帯、緩衝地帯 (DMZ) とも呼ばれる) の後ろにビジネス論理を置くことを強く望みます。

この場合、EJB テクノロジーのような分散オブジェクト・コンポーネントのアーキテクチャーを使用すれば、貴重な企業資産が DMZ の背後に配置され、表示用コードは DMZ の後ろの EJB サーバーにアクセスできます。このような分散型ソリューションが、以下の図に示されています。

ここでは、バックエンドのビジネス論理に比べて表示論理の“重要性”が低いことを前提としています。これが該当しない場合は、この方法はそれほど適切ではなく、システム全体を DMZ の後ろ、つまり DMZ の中に配置することができます。アプリケーション全体を 2 番目のファイアウォールの後ろに配置する必要がある場合 (そしてそれが可能な場合) には、たとえば JDBC 呼び出しを介して Java サーブレットからデータベースに直接アクセスするなど、他のテクノロジーを選択すべきでしょう。

さらに、このソリューションには効率上の欠点もあります。たとえば、WebSphere のインストールで、図のようにクライアント (つまりサーブレットと JavaServer Pages (JSP) ファイル) を EJB コンポーネントから分割して別の JVM にインストールすると、全体的なパフォーマンスが低下します。同一の JVM にインストールする場合に比べると、ファイアウォールを介する呼び出しにかかる時間が最大で 20 % 長くなる可能性があります。

複数のクライアント・タイプが共用データにアクセスする必要がありますか ?

多くの場合、1 つのアプリケーションの中で、複数のクライアント・タイプが同じ情報のセットにアクセスする必要があります。たとえば、1 つのアプリケーションに外部顧客用の Web ベースの HTML フロントエンドと、内部ユーザー用のより完成された Java アプリケーションとが存在する場合があります。従来は、この問題を解決するために、同じデータ・ソース (データベース・テーブル) を共有する 2 つのバージョンの同じアプリケーションを作成していました。しかしプログラミングに多くの時間がかかる点で、また複数のデータベース・ロックが同時に発生する場合のデータベース使用効率の点で、この方法は効果的とは言えませんでした。

EJB テクノロジー・ソリューションがこの問題を解決する方法は、共通データとビジネス論理を単一の EJB の中に配置し、この EJB コンポーネントに複数のクライアント・タイプ (たとえばサーブレット/HTML とアプリケーション) がアクセスするというものです。EJB コンポーネントはバックエンド・データへのアクセスを制御し、現在のトランザクションやデータベース・ロックを内部的に管理します。こうすればアプリケーション内にコードの複製を作成する必要がなく、より少ない労力でデータベース制御論理を作成できて、プログラミング全体に必要な労力が削減されます。

他にもソリューションがあります。たとえば Java アプリケーションが Java サーブレットを介して HTTP にアクセスする方法、またはブラウザーが HTTP を介して Java サーブレットにアクセスする方法です。しかしこれらの方法の問題点は、ブラウザーで情報を表示するためにサーブレットを使用する場合、他のプログラムへの情報伝送に不必要な表示論理がどうしても含まれることです。したがって、両方の場合を処理するために (一部が重複する) 2 つのサーブレットを作成することになってしまいます。さらに、HTTP は複数のプログラム間の通信に利用できる最も効率的なプロトコルではありません。HTTP パイプを介してプログラム間で情報を転送するための何らかの形式を設定する必要があります。通常、これは XML のようなテキスト・ベースの形式、または Java シリアライゼーションのようなオブジェクト・ベースの形式です (XML の場合は送信側で生成して受信側で構文解析する必要があります)。これら 2 つのオプションはいずれも実質的なプログラミング作業を伴い、ネイティブ IIOP ほど高速ではありません。

共用データへの読み取りアクセスと更新アクセスが同時に必要ですか ?

従来の“ファット・クライアント”・ソリューションでは、アプリケーションは共用データへのアクセスをデータベース・レベルで管理する必要がありました。このためデータベース・ロックおよび並行処理を可能にするために複雑な方式を使わなければならず、もしこのような問題に対処しなければデータ保全性が失われます。

EJB テクノロジーは、こうした複雑なスレッド化および共用データの問題に自動的に対処します。すでに述べたように、EJB コンポーネントはバックエンド・データへのアクセスを制御し、現在のトランザクションやデータベース・ロックを内部的に管理します。こうしてより少ない労力でデータベース制御論理を作成してプログラミング全体に必要な労力を削減でき、しかもデータの整合性と妥当性を保証することができます。

複数の異なるデータ・ソースに、トランザクション機能を使用できる形でアクセスする必要がありますか ?

多くのアプリケーションでは複数のデータ・ソースにアクセスする必要があります。たとえば、1 つのプログラムが中間層の Oracle データベースと、(MQSeries のようなミドルウェアを使用する) メインフレーム CICS システムまたは IMS システムの両方のデータを処理することがあります。ここで問題となるのは、一部のアプリケーションでは完全なトランザクション機能を使用できる形でアクセスする必要があり、すべてのデータ・ソースにおいてデータ保全性を維持しなければならないことです。たとえばあるアプリケーションでは、ユーザーから注文が出されると注文の詳細情報を Oracle データベースに保管すると同時に、MQSeries を使用して出荷情報を CICS システムにも保管する場合があります。ここでデータベース更新または MQ キューイングのいずれかが失敗すると、トランザクション全体がロールバックしなければなりません。

従来は、このようなシステムを構築する唯一の方法は Encina、CICS、または Tuxedo のようなトランザクション・モニターの使用でしたが、これらのモニターのインターフェースは標準的ではなく、COBOL、C、または C++ などの言語で開発を行う必要がありました。しかし、たとえば WebSphere アドバンスド版 EJB のコンテナーは、完全なコミット機能およびロールバック機能を使用できる形で、複数の DB2 データ・ソースに対する複数トランザクションの並行処理をサポートします (完全な 2 フェーズ・コミットが可能)。また WebSphere は単一フェーズ・コミット・トランザクションを使用できる形で (Oracle、MQSeries、CICS など) 他のデータ・ソースをサポートしています。WebSphere エンタープライズ版 EJB のコンテナーは、2 フェーズ・コミットを使用できる形でさらに多くのデータ・ソースをサポートしています。

ほとんどのコンテナーは、より広範なデータ・ソースの 2 フェーズ・コミットをサポートする点で改善されつつあります。今後も、この分野では時間がたつにつれて一層の改善が見られるでしょう。

HTML 文書、サーブレット、JSP ファイル、クライアント・ログインなどと完全に統合された、メソッド・レベルのオブジェクト・セキュリティーが必要ですか ?

ある種のアプリケーションにはセキュリティー上の制約があり、このため Java アプリケーションとしての実装が以前は困難でした。たとえばいくつかの保険アプリケーションでは、法律による規制に従って患者データへのアクセスを制限する必要があります。EJB テクノロジーが登場するまでは、特定ユーザーがオブジェクトやメソッドにアクセスすることを制限する方法はありませんでした。以前は、データベース・レベルでアクセスを制限して JDBC レベルに送られてくるエラーを“検出する”か、またはカスタマイズされたセキュリティー・コードを使ってアプリケーション・レベルでアクセスを制限するかのいずれかでした。

しかし EJB テクノロジーでは、任意の EJB コンポーネントまたはメソッドにおいてメソッド・レベルでのセキュリティーが可能です。任意の EJB コンポーネントまたはメソッドの実行を許可される (または拒否される) ユーザーやユーザー・グループを作成できます。WebSphere では、この同じユーザー・グループに対して Web リソース (サーブレット、JSP ファイル、HTML ページなど) へのアクセスを許可または拒否することができ、背景で実行されるセキュリティー・フレームワークでユーザー ID を Web リソースから EJB コンポーネントに渡すことができます。

標準的で移植可能な、コンポーネント・ベースのアーキテクチャーへの移行を検討していますか ?

将来を見据える数多くの企業では、プラットフォーム、ソフトウェア製造元、およびアプリケーション・サーバーに依存しない実装の実現が重要な課題となっています。業界標準の EJB コンポーネント・アーキテクチャーはこうした目標を達成するのに役立ちます。通常、WebSphere 用に開発された EJB コンポーネントをそれと同等の機能を持つアプリケーション・サーバーに配置したり、その逆に配置することができます。依然としてすべてのケースでこれが可能なわけではありませんが、多くのユーザーがこの方向を模索しつつあります。短期的には、標準の一歩先を行く進んだ機能を利用するのが簡単かつ効率的ですが、長い目で見ると標準に合わせる方が有利です。

また、自家製のオブジェクト管理の枠組みでは不可能なツールや EJB 標準の実装最適化がますます利用可能になってきている点も見逃せません。ミドルウェア分野に進出している業者の数が少ないため、当面はユーザーのビジネス分野に直接関連した製品に的を絞って検討してみる方が効率的でしょう。

システムのスループット上の必要および可用性上の必要を満たすために、複数のサーバーが必要ですか ?

ファット・クライアント・システムは、何千ないし何百万という規模のユーザーをかかえる可能性のある Web ベースのシステムに単純に拡張することはできません。さらにソフトウェア配布上の問題のために、肥大化したファット・クライアントを削減する必要性が喚起されています。一日 24 時間、週 7 日稼動し続ける Web の性質上、実行時間も重要な課題となっています。ただし、24 時間 / 7 日稼動用に設計された、何百万というユーザーを同時に処理できるシステムがいつも必要とは限りません。開発の簡易性や標準化を犠牲にすることなくスケーラビリティーを達成できるようなシステムを設計しなければなりません。

したがって、こうした要件を満たしながら拡張を可能にするビジネス論理をどのように開発するかが課題です。EJB テクノロジーはこのような拡張がきわめて容易な、可用性の高いシステムを構築するうえで中心的な役割を果たします。たとえば WebSphere は以下のような機能を提供して、開発者がこうしたシステムを構築できるようにします。これらの機能は代表的なもので、他のさまざまな EJB サーバーもこれらの機能を提供します。

• オブジェクトのキャッシングおよびプール – WebSphere は状態のないセッション EJB コンポーネントをサーバー・レベルで自動的にプールして、オブジェクト作成および不要情報収集に費やされる時間を削減します。こうして、より多くの処理サイクルを実質的な作業に割り当てることができます。
• サーバーにおける作業負荷の最適化 – WebSphere には EJB サーバー・クラスターの管理機能もあります。WebSphere Application Server では、複数のノードにまたがるサーバー・グループを作成できます。さらに、モデル (サーバーを抽象的に表したもの) を作成して、それを複数の JVM に複製することもできます。これらの複製を、クラスター内の任意のサーバー・マシンで実行するように構成できます。また、1 つのサーバーの複数の複製を単一マシン上で実行してマルチプロセッサー・アーキテクチャーとして利用することもできます。同様に、複数の複製からなるセットを単一グループとして管理することもできます。こうすれば可用性が高まり、アプリケーション・サーバーの 1 か所で障害が発生することを防げます。
• 複製によって、フェールオーバーが自動的にサポートされます。要求を処理できる複製が複数存在するため、障害によってスループットや信頼性が損なわれる可能性が低く抑えられます。複製をさまざまなノードに分散すれば、1 つのマシン全体が障害を起こしても深刻な事態に至ることはありません。

これらの機能はすべて、システム内で特にプログラミングしなくても自動的に実行されます。このような形のスケーラビリティーを利用するために、サーバー側のコードを変更する必要はまったくありません。

WebSphere は、サーバー側の他の Java テクノロジー (Java サーブレットや JSP ファイルなど) の分散、複製、および自動的なフェールオーバーもサポートしていることに注意してください。ただしこれらのテクノロジーは表示様式をより重視しており、競合するテクノロジーというよりもむしろ EJB コンポーネントを補完するものです。実行時間やスケーラビリティーが重要な要因である場合には、ソリューションの一部として EJB コンポーネントをぜひ含める必要があります。

上に戻る

2 つのプロジェクトの例 (EJB コンポーネントの適切な使用方法)

ここまでは、読者のアプリケーションで EJB テクノロジーを使用するのが適切かどうか判断する方法をいくつか示してきました。以下では EJB コンポーネントを使用したある 2 つのアプリケーションの例を取り上げ、開発者が目的を達成するうえでこのテクノロジーが役立った様子、または阻害要因になった様子を示します。一方のケースでは EJB コンポーネントを適切に使用して、より簡潔でわかりやすいコードを実現しました。もう一方のケースでは EJB コンポーネントを使用した結果、パフォーマンスの悪いかなり複雑なシステムになってしまいました。

ここで取り上げるアプリケーションはいくつかの実際のアプリケーションの例を組み合わせたものです。1 つの特定の企業やプロジェクト・チームの例をそのまま紹介しているわけではありません。

上に戻る

EJB テクノロジーの悪い例

新しいテクノロジーの評価を行う公認された先進的なテクノロジー・グループのあるプロジェクト・チームが、以下のようなプロジェクトを開始しました。プロジェクトのアーキテクチャーは下図のとおりです (それぞれの四角はプロセスを示し、これらは互いに別個のハードウェアで実行されます)。

いくつかの点のゆえに、このアーキテクチャーにおける EJB コンポーネントの利用方法は、第一印象で感じるほどには効果を発揮しません。

• アプリケーションの大部分を占めていたのは、Java サーブレットによる情報の表示でした。EJB コンポーネントは更新されたデータを取り出すためにのみ使用されていました。
• このチームがバックエンド・メインフレームのトランザクションに使用した接続は、XA を認識しないデータ・ソースでした。このためグループとしてトランザクションをロールバックまたはコミットすることができず、メインフレームへの各アクセスは別個の独立した関数呼び出しでした。
• Web から入って来るユーザーとメインフレーム内のユーザーを何らかの方法でマッピングしなかったため、EJB テクノロジーのセキュリティー機能が活用されていません。
• サーブレットからエンティティー EJB コンポーネントへの各アクセスはネットワーク呼び出しでした。実際のメインフレーム呼び出しは finder メソッドおよび ejbLoad() メソッド内の論理が実行しますが、それ以降、EJB コンポーネントは単にトランザクションがコミットされるまでのデータ・キャッシュとして機能し、コミットの時点で、ejbStore() メソッドが情報を作成してメインフレームに戻します。その時点までのすべてのアクセスおよび更新は、実質的なネットワーク・オーバーヘッドを発生させます。

このチームは、単にメインフレーム・データとサーブレットの間のデータ・マッピング機構としてのみ EJB コンポーネントを使用していました。これは EJB テクノロジーの効果的な使用方法ではありません。つまりこの場合、アプリケーションは次のような利点を活用していません。

• EJB コンポーネントのトランザクション機能
• EJB コンポーネントのメソッド・レベルでのセキュリティー
• EJB コンポーネントの拡張と分散 (このチームはただ 1 つの EJB サーバーしか使用していません)
• 複数のクライアントおよびクライアント・タイプの間でビジネス論理を共用できること
• CMP EJB コンポーネントの自動的なデータ・マッピング機能

データ・マッピングを Java サーブレットと同じ JVM 内で JavaBeans コンポーネントとして直接エンコードし、ネットワーク・オーバーヘッドを防止する場合に比べると、このシステムはこういう形で EJB コンポーネントを使用したことにより、パフォーマンスが非常に遅くなりました。さらに (ホームとリモートの両方のインターフェース、および配布先コードが必要とされるため) システムが必要以上に複雑になっています。実際にこのプロジェクトはあとで破棄されて EJB コンポーネントを使わないアーキテクチャーに変更され、標準的な JavaBeans コンポーネントのセットをサーブレットが使用してデータ・マッピングを行うようになりました。こうするとシステムは最終的により高速かつ単純になりました。

上に戻る

成功した EJB テクノロジーの例

ある金融機関のプロジェクト・チームが開発したこのプロジェクトは、もともと Java および RMI テクノロジーを使用するものでした。当初、このシステムのアーキテクチャーは以下のようなものでした。

プロジェクト・チームは複数のクライアント・タイプの他に、図には示されていない以下の 2 つのフレームワークをシステムに構築しました。

• Oracle テーブルを Java クラスに (またはその逆に) マップするデータベース・マッピング層 (RMI サーバー内で JDBC を使用)。
• カスタマイズされたセキュリティー・フレームワーク。これはブラウザーやアプリケーション・クライアントから入ってくるユーザーを妥当性検査し、ユーザーが RMI 呼び出しおよびデータベース呼び出しを実行できるかどうかを決定します。

このプロジェクト・チームのアプリケーション要件は EJB テクノロジーの目指すところと非常に密接に関連していたため、ただちに設計の見直しが行われて次のようなアーキテクチャーに変更されました。

コンテナーで管理された永続的な (CMP) エンティティー EJB コンポーネントを使用することで、グループはデータベース・マッピング・フレームワークの代わりに、WebSphere および VisualAge for Java に含まれる完成された効率的な実装を利用できるようになりました。またプロジェクト・チームは EJB テクノロジー・セキュリティーを使用することによって、独自のカスタマイズされたセキュリティー・フレームワークを破棄しながらも、メソッド・レベルのセキュリティーをアプリケーションで維持することができました。その結果、保守すべきコードが減ったためアプリケーションがより簡潔になりました。

要約すると、このアプリケーションは以下の理由で EJB テクノロジーの使用に適しています。

• 同じビジネス論理を共有する複数のクライアント・タイプが存在する
• トランザクションを使用する
• CMP bean を介して使用可能な、オブジェクトに関連付けられたマッピングを必要とする
• メソッド・レベルのセキュリティーを必要とする

このシステムの最終的なアーキテクチャーは、各エンティティーに配置された共通のセッション EJB コンポーネントを使ってネットワーク・トラフィックを最小限に抑えるという設計になりました。この点で EJB コンポーネントをきわめて有効に利用した例だと言えます。元のアーキテクチャーはクライアントが多数の微細な呼び出しを実行するもので、クライアントがトランザクションを開始してコミットまたはロールバックする必要があり、ネットワーク・トラフィックが増大する複雑なシステムでした。

上に戻る

まとめ

特定のアプリケーションで EJB テクノロジーを利用するのが適切かどうかをどのように判断するか、実装オプションとして EJB コンポーネントを選択する場合の利点と欠点は何か、こうしたことを理解するのが、(EJB コンポーネントを採用する可能性を含む) 新しいシステム構築に向けた第一歩です。

参考文献

• 分散コンポーネント設計のためのミニ・パターン言語 (Mini-pattern language for Distributed Component Design) (PDF 形式) には、EJB テクノロジーのようなシステムを使用するアプリケーションを開発するためのミニ・パターン言語が説明されています。
  
  
• Enterprise JavaBeans 仕様 (バージョン 1.0 および 1.1) は EJB コンポーネントについて、および EJB コンポーネントを構築する方法について説明しています。
  
  
• Enterprise Java Beans (O’Reilly & Associates 社刊、Sebastapol、California、1999 年) は、EJB コンポーネントの使用方法に関する現在のところ最も優れた解説です。
  
  
• VisualAge 開発者のページ (VisualAge Developer Domain) サイトには、EJB アーキテクチャーについて、および VisualAge for Java を使って EJB コンポーネントを構築する方法についての多数の記事が掲載されています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 技術的な検討事項
• 2 つのプロジェクトの例 (EJB コンポーネントの適切な使用方法)
• EJB テクノロジーの悪い例
• 成功した EJB テクノロジーの例
• まとめ
• 参考文献
• 著者について
• コメント