EJB 3.0の新しい方向性について、大いに期待している人々がいたるところに見受けられます。 事実、J2EEコンポーネント・スイートの役割は開発プロセスの簡素化であり、エンタープライズ・アプリケーションの開発、テスト、配置の大幅な簡素化が期待されています。 EJB 3.0では、開発の簡素化がきわめて重要と見なされており、TopLinkで10年前から行われているPlain Old Java Object（POJO）永続化を提供すべく、モデルの調整が行われました。

EJB 3.0仕様のリーダーであるLinda DeMichielが、TopLinkをはじめとした製品からの助言や経験に目を向けようと思ったのは、偶然ではありません。 これにより、EJB 3.0仕様は、すでに定評と実績を得たテクノロジにより切り開かれた道をたどることができ、実際に業界の事実上の標準となりました。 これでEJB仕様は、大多数のアプリケーションですでに実施されている仕様との調和が取れたため、適切かつ有用な永続化仕様に再び移行しつつあると自信を持って断言できます。

仕様の調整は急速に進行しており、オラクルは新しいEJBモデルの強力なサポーターとして、このプロセスに積極的に参加しています。 オラクルは、技術面での多大な貢献に加え、現在はEJB 3.0コンテナ・テクノロジのプレビュー・リリース提供に向けた準備も行っています。

プレビュー版はアプリケーションの本番環境への配置に適しておらず、またEJB 3.0の最終リリースの発表は来年になると思われるため、 それは良いことだが、今どうすればいいのかという疑問が生じます。 「EJB 3.0に向けたアプリケーションの準備を積極的に行ってください」というのがその答えです。 EJB 3.0仕様の最終稿が発表されるとき、アプリケーションを新しい永続化標準に簡単に移行できる状態にしておきたい、とお思いのことでしょう。 さらに言うと、この標準で提供される機能の一部を事前にアプリケーションで使用しておきたい、という要望もあるでしょう。 ここでは、こうした要望を実現する方法について説明し、EJB 3.0に向けた準備のみならず、すでに対応した状態とするために、どの機能を使用すべきかについてのアドバイスを行います。

最初のステップは、永続性に基づく標準と設計パターンの使用をアーキテクチャで徹底させることです。 これにはアプリケーションの変更が必要な場合がありますが、アプリケーションを長く使用したい場合には十分に投資価値があります。 セッション・ファサード、DAO(Data Access Object）レイヤーまたはサービス・レイヤーの使用は一般的に良いとされていますが、この場合は不可欠です。 通常はあまり行いませんが、リモート・エンティティを使用してアプリケーションを構築した場合は、アーキテクチャの再構築が必要です。 永続性オブジェクトにアクセスするには、リモータブル・サービス・レイヤーの配置が必要となります。 エンティティを使用している場合は、かならずローカル・エンティティを使用してください。

ただし、ローカル・エンティティを使用すれば終わりというわけではありません。エンティティの使用により、配置の際にエンティティのトランザクション要件とセキュリティ要件を宣言的に記述できるようになります。 EJB 3.0では、これらの属性をエンティティ・レベルで設定できません。 かわりに、エンティティを実行するコンテキストをコール元が決定するため、必要なトランザクション・コンテキストまたはセキュリティ・コンテキストを、それを内包するJ2EEコンポーネントでインストールまたは宣言する必要があります。 これにより、永続性の直交する問題は、他の分散コンポーネント・モデルから切り離されます。

すでにCMPを使用している場合は、次の3つの思いがあるかもしれません。 まず、新機能が待ち遠しく、従来のEntity Bean開発の際の悩みの種であった余分なインタフェースや不必要なBeanコード、面倒なXMLデプロイメント・ディスクリプタからの解放を喜ぶ気持ち。 EJBObjectの拡張が必要なリモート・インタフェース、EJBLocalObjectの拡張が必要なローカル・インタフェースは不要となり、エンティティは、選択すればPOJI（Plain Old Java interface）の実装のみを行うことができるようになりました。

次に、コンテナへのEJB配置の大幅な簡素化や、さらに言うとEJBを配置せずにスタンドアロン環境のコンテナ外部でテストすることを夢見る気持ち。 エンティティは具象クラスのPOJO（Plain Old Java Object）であるため、Javaオブジェクトと同じ方法でnew()を使用して作成できます。

最後に、新しい3.0形式のプログラミングを使用するように既存の2.1形式のBeanの一部を移行するのは大変なのではないかという心配。 オラクルではこの問題を重要視しています。 実際、EJB製品の提供する移行戦略の強みは、EJB 3.0の実装を選択する際にアプリケーションに適用される主要な基準の1つとなると確信しています。 オラクルは可能な限りこの移行を簡単にすることを目標とし、その目標に基づいて実装の計画と開発を進めています。

新しい永続化APIの大半は、EntityManagerからアクセス可能で、Session Beanへの注入やJNDIでの検索を行えます。 EntityManagerは、トランザクション永続性コンテキストを示し、TopLink UnitOfWorkへの非常に密接なマッピングを行います。 UnitOfWorkまたはEntityManagerで管理されるオブジェクトで、トランザクション終了時にコミットされていないオブジェクトとして検出されたものは、データ・ストアに書き出されます。

UnitOfWork/Session成果物を取得するコードを抽象化することにより、アプリケーションを広範囲の変更から分離できます。 これにより、実際に使用するセッションをプラッガブルに取得できます。 セッションを定義して周囲のレイヤーを外部から設定可能にする方法は、EJB 3.0コンテナで採用されている依存性注入の枠組みに似ています。 このパターンを、アプリケーションで使用されるあらゆるリソースに適用する必要があります。 EJB 3.0標準では、リソースはアプリケーションによって宣言され、その後実行時にBeanに注入されます。

EJB 3.0機能の多くは、長年にわたりTopLinkで使用されている機能内に認められるでしょう。 これらの機能の使用により、APIは未完成であっても、EJB 3.0の機能を使用することができます。

問合せは、今すぐ使用できるEJB 3.0機能の1つです。 TopLinkには、名前付き問合せを定義して実行する機能があります。 問合せは、クライアントの基準に基づいてジャストインタイムで行えるように、静的にも動的にも構成できます。

EJB 3.0の問合せはEntityManagerから取得でき、そこで実行できます。 まれに、直接SQLを使用して問合せからオブジェクトの取得が必要な場合がありますが、その場合はネイティブSQLクエリーを作成できます。 TopLinkにはまさにそれを行うカスタム・クエリーがあり、これを使用して結果のデータ・セットをオブジェクトにマッピングできます。

問合せ言語は、実質的または包括的な変換パーサー・ツールを記述せずに自動的に変換することが困難であるため、しばしば移行時の頭痛の種となります。 EJB QLでは、リレーショナル問合せ言語の合理的で十分な抽象化が行われているため、現在追加されている複数の新機能が有効です。 既存のEJB QLに適用され、より多くのEJB QLの構成メンバーと関数によって問合せ言語がさらに拡張されます。 問合せ言語は、大幅に変更されることはなく追加対応されるため、問合せAPIがリリースされていなくても、EJB QLを使用して問合せを記述する意味はあります。 TopLinkでは、POJOでのEJB QL使用がサポートされるため、これによりアプリケーションは問合せを別のデータベースやフレームワーク、Persistence APIに移植できるようになります。

J真の自然な継承は、Javaオブジェクトがサポートし関与するよう作成されましたが、EJB 2.1仕様で定められることはありませんでした。 実際、ベンダーがあきらめずに障害に対処した場合のみ継承は可能でしたが、依然として定義と管理は非常に困難でした。 EJB 3.0ではそのようなことはありません。 具象Javaオブジェクト間での相互継承が可能で、継承の範囲に制約を課すメソッドの定義が不要のため、エンティティ継承階層を任意の深さと幅で作成できます。

現在、これと同様の柔軟性は、TopLink Mapping WorkbenchまたはJDeveloper（Javaオブジェクトのマッピングを行うGUIツール）、オブジェクトのマッピングを行うJavaベースのAPIの両方で実現可能です。 仕様のリリースを待たずに、アプリケーションに適した継承戦略に従って、ドメイン・モデルの作成を行うことができます。

TopLinkが積極的にサポートしているコミット時ロック・モデルが、EJB 3.0モデルで採用される予定です。 これはアプリケーションにとって非常に好ましいことです。なぜなら、通常90：10という読取り/書込みアクセスの比率を考えるとパフォーマンスが大幅に向上する上、最新システムに必要な種類のスケーラブルなアーキテクチャが構築できるためです。 これは、Webアプリケーションに必要なスケーラビリティを実現するために、すでに業界内の非常に多くのアプリケーションで使用されている主要なロックの枠組みです。

値をロックするTopLinkのオプションの柔軟性と、値の決定、計算、格納方法は、EJB 3.0仕様に含まれているものに優先します。 ただし、基本的な部分ははっきりしており、コミット時ロックされた各オブジェクトのデータベース列やオブジェクト・バージョン・フィールドの簡単な方法を利用することで、移植性は簡単に実現されます。

このロックを使用すると、切断モードでオブジェクトを使用できるという付加的な利点もあります。 オフライン状態でのデータやリレーションシップの変更は、単にトランザクションにデータを戻してマージし、コミット時ロック値により修正オブジェクトが古いコピーでないことを検証することで、簡単にサポートできます。 これは、TopLinkでオブジェクトを作業ユニットに戻してマージする場合に行う処理と、完全に一致します。

ライフ・サイクル・コールバックのEJBモデルは、現在2つの有効な方法で適応されています。 1つは、コールバックとO/Rマッピングのランタイム実行モデルとの関係を強固にし、データベースへの挿入などのきめ細かいイベントでアクションを実行して監査や会計などを行うものです。 もう1つは、Bean以外のイベント・リスナーを登録して、イベント・コールバックの処理を行うものです。 つまり、TopLinkイベント・リスナーを使用している場合は、すでにEJB 3.0エンティティを利用できるモデルを使用しているということになります。

TopLinkが長年提供しているサポートのうちでもっとも顕著なものは、オブジェクト・データとそのリレーションシップをリレーショナル表にマッピングする機能です。 これは、オブジェクト指向のJavaプログラムを作成し、データをリレーショナル・データベースに格納するアプリケーションでは、深刻な問題でした。

オブジェクト・リレーショナル・マッピングのために標準化されたメタデータとセマンティクスのEJB 3.0への追加を決定したことは、アプリケーションを選択して異なるデータベースで実行し、しかも異なる永続性フレームワークを使用してそれを実行するという、アプリケーションの柔軟性を実現した大きな一歩です。 O-Rマッピング標準の最初の段階には、基本的なデータ変換、1対1関係および多対多リレーションシップなどの、ドメイン・モデルのマッピングに使用されるもっとも一般的なマッピングが含まれます。 今後のドラフトには、TopLinkですでに提供されている「高度な」マッピングが数多く追加される予定です。そのため、アプリケーションに特別な要件があっても、仕様が成熟するにつれて、アプリケーションの移植可能なソリューションとして一層TopLinkに近いものとなるでしょう。

過去10年間にわたり、TopLinkは、大規模な顧客基盤の要件を取り入れ、アプリケーションのオブジェクトに永続性を持たせる方向で進化しています。 EJB 3.0が、大半のアプリケーションと足並みを揃えるために永続化へのアプローチを改革しているため、長年にわたりPOJOベースの永続化を行ってきたTopLinkユーザーにとっては、自分たちの正当性が証明されたと感じ、標準をリードしていることを確信できるでしょう。 TopLinkモデルは、ユーザーの永続化フレームワークに対する満足度を示す1つの例として挙げられるため、その機能をEJB 3.0標準への一歩として使用できます。 つまり、EJB 3.0仕様が未熟であっても、EJB 3.0を今すぐ実装したいアプリケーションで、安定した実績のある製品を使用できます。

TopLinkはEJB 3.0に全面的に注力しており、ユーザーのEJB 3.0への移行をサポートしています。 オラクルは、現行のTopLinkユーザーに対するEJB 3.0への移行支援に加え、他のテクノロジをベースとするアプリケーションのサポートも計画しています。 アプリケーションにEJB 3.0の永続性を採用することにより得られるメリットについての記事やセミナー、会議などにご注目ください。

Mike Keith は、オラクルのTopLink製品のアーキテクトであり、EJB 3.0エキスパート・グループの代表を務めています。