EJB 3.0 への移行 Oracle ホワイト ペーパー 2005 年 10 月
EJB 3.0 への移行 2
EJB 3.0 への移行 移行が必要な理由... 4 EJB 3.0 における変更点... 4 Session Bean の移行... 5 Session Bean の変更... 5 Session Bean を使用するアプリケーション コードの移行... 7 Message-Driven Bean(MDB) の移行... 8 EJB 3.0 の永続化への移行... 9 新しい永続化 API... 9 EJB 2.x CMP Entity Bean の移行... 9 DTO と EJB 3.0 エンティティ... 10 DTO の EJB 3.0 エンティティへの移行... 11 EJB 2.x Entity Bean の移行... 12 EJB 2.x エンティティ ホームの移行... 16 ライフサイクル メソッドの移行... 17 O-R マッピングの移行... 17 例外処理... 18 CMP クライアント アプリケーション コードの移行... 18 CMP クライアントの移行... 18 POJO アプリケーションの移行... 19 結論... 19 EJB 3.0 への移行 3
EJB 3.0 への移行 オラクルが提供する EJB 3.0 の機能については otn.oracle.com/ejb3 を参照してください Enterprise JavaBeans(EJB) のプログラミング モデルは EJB 3.0 で飛躍的に簡素化されており サーバー側のビジネス ロジック プログラミングの新しい標準として Java 開発者から歓迎されています 一方で 以前のバージョンの EJB API を使用して作成された J2EE アプリケーションの数は数千にも及ぶため 相互運用性と EJB 3.0 を使用するためのアプリケーションの移行について 不安が広がっています このホワイト ペーパーでは これらの問題に関連するさまざまな内容について説明します 移行が必要な理由 EJB 3.0 対応の J2EE コンテナへのアップグレードを計画する場合 なぜアプリケーションを移行する必要があるのかという問題について J2EE プロジェクトの参加者で議論する必要があります オラクルをはじめとする すでに EJB 3.0 機能を提供している大手アプリケーション サーバー ベンダーでは 新しい EJB 3.0 コンテナでも引き続き EJB 2.x をサポートする予定です つまり EJB 2.x で記述されたアプリケーションは まったく変更しなくても今後も実行できるのです しかし EJB 3.0 API を使用するためにアプリケーションの移行を希望する組織も実際にあります EJB 2.x から移行することで得られる利点には 以下が含まれます EJB を取り囲む複雑さの軽減 インタフェース ホーム インタフェース およびメタデータが大幅に簡素化されます エンティティやエンティティを使用するコンポーネントの容易なテスト EJB 2.x の永続化ソリューションでは ほとんどのアプリケーションで重要なユニット テストが行われていませんでした EJB 2.x Entity Bean の制限を回避するための 問題が発生しやすいコードの削減 これらのパターンには データ転送オブジェクト (DTO) や Service Locator の実装が含まれます 上記の利点は 開発者の生産性 アプリケーション品質 およびメンテナンス コストに重要な影響を与えます ここで課題となるのは これらの利点と移行にかかるコストを把握した上で アプリケーションの開発サイクルのどの時点でこの移行を実行することがもっとも効率的であるかを判断することです EJB 3.0 における変更点 EJB 3.0 の主要な目標は プログラミング モデルを簡素化することと Java プラットフォーム向けの永続化 API を定義することにあります EJB 開発を容易にするための EJB の主な変更点は次のとおりです EJB 3.0 への移行 4
EJB 3.0 では Plain Old Java Object(POJO) が使用されます XML ディスクリプタが不要になり 代わりにアノテーションが使用されます 可能な限り デフォルトが設定されます 不要なアーチファクトやライフサイクル メソッドを定義する必要がなくなりました 依存性の注入によりクライアント ビューが簡素化されました EJB 3.0 に関する最新情報については Sun のドラフト仕様を参照してください POJO の永続化モデルが J2EE のコンテキスト内で標準化されたことにより 今までコンテナの外部や自社製品でしか使用できなかった継承やポリモフィズムが使用できるようになります さらに POJO の Entity Bean を EJB コンテナの内部と外部の両方で使用し テストできるようになりました Session Bean の移行 EJB 3.0 の Session Bean における主要な変更の目的は 開発を容易にすることにあります これは Bean を POJO にし XML ディスクリプタに加えてアノテーションも使用可能にするとともに JNDI ルックアップの代わりに依存性の注入を提供することで実現されます この移行に伴って発生する変更には Bean 自体の変更と Bean を使用するアプリケーション コードの変更があります Session Bean の変更 EJB 3.0 へ移行するために必要な EJB 2.x の Session Bean の変更には 次が含まれます リモートおよびローカルのインタフェースで javax.ejb.ejbobject または javax.ejb.ejblocalobject を実装する必要がなくなりました コンポーネント インタフェースはビジネス インタフェースとして使用できます また アノテーション @Remote を使用すると インタフェースがリモート クライアントからアクセス可能であることを示すことができます リモート インタフェース上のメソッドから RemoteExceptions をスローする必要がなくなりました リモート EJB 2.x の Session Bean の簡単な例を次に示します public interface HelloWorld extends EJBObject { String sayhello(string name) throws RemoteException; When migrated to EJB 3.0 the remote interface is simply: @Remote public interface HelloWorld { String sayhello(string name); EJB 3.0 への移行 5
Bean クラスが実装するのは javax.ejb.sessionbean ではなくビジネス インタフェースです この結果 Bean に不要なライフサイクル メソッドを実装する必要がなくなりました 代わりに 必要なライフサイクル コールバックはアノテーションを使用して示されます 次に 簡単な EJB 2.x のステートレス Session Bean を表す Bean クラスを示します public class HelloWorldBean implements SessionBean { public void ejbcreate() { public void ejbactivate() { public void ejbpassivate() { public void ejbremove() { public void setsessioncontext(sessioncontext ctx) { public String sayhello(string name) { return "Hello " + name; EJB 3.0 に移行すると Bean クラスは次のようになります @Stateless public class HelloWorldBean implements HelloWorld { public String sayhello(string name) { return "Hello " + name; ステートフル Session Bean の場合 ejbcreate メソッドは コンテナが維持する必要のあるステートを初期化するビジネス メソッドに置き換えられます たとえば 次のように ビジネス メソッドを作成し @PostConstruct を使用してアノテートできます @PostConstruct public void initialize() { items = new ArrayList(); ステートフル Bean がアプリケーションで不要になったことをコンテナに示す削除メソッドは @Remove を使用してアノテートします トランザクションおよびセキュリティ用のアノテーションを使用するための Session Bean コードの移行は 任意で行います EJB 3.0 への移行 6
Session Bean を使用するアプリケーション コードの移行 Bean 自体の変更に加えて Session Bean を使用するアプリケーション コードを移行する必要があります これには 別の J2EE および J2SE コンポーネント内で使用されるアプリケーション コードも含まれます EJB 3.0 では 依存性注入の原則を導入することによって リソースや EJB 参照が簡単に使用できます リソースや参照の注入は 注入ターゲットのアノテーションまたは ejb-jar.xml ディスクリプタ内のターゲットの指定を介して実行されます EJB 2.x EJB 3.0 別の EJB の使用 : XML ディスクリプタ内の ejb-ref JNDI ルックアップによるホーム インタフェースの取得 home.create の呼び出しによるインスタンスの取得 別の EJB の使用 : ejb-ref にホーム インタフェースは不要 ホーム インタフェースから移行されたビジネス インタフェースへの変更 home.create の削除と EJB メソッドの直接起動 EJB ビジネス インタフェースのプロパティやフィールドのアノテートによるインスタンスの取得 ( 任意 ) リソース アクセス JNDI ルックアップによるリソースの取得 リソース アクセス リソースのプロパティやフィールドのアノテートによるリソースの取得 ( 任意 ) たとえば 別の EJB 2.1 Bean で CartEJB を使用している場合 デプロイメント ディスクリプタ内で ejb-ref を使用して CartEJB への参照を定義する必要があります <ejb-ref-name>mycart</ejb-ref-name> <ejb-ref-type>session</ejb-ref-type> <home>carthome</home> <remote>cart</remote> 次に JNDI を使用して CartEJB のホーム インタフェースを検索すると CartEJB のインスタンスが作成できます Object homeobject = context.lookup("java:comp/env/mycart"); CartHome home =(CartHome)PortableRemoteObject.narrow(homeObject, CartHome.class); EJB 3.0 への移行 7
Cart cart =(Cart)PortableRemoteObject.narrow(home.create(), cart.additem("item1"); Cart.class); EJB 3.0 の注入パターンへ移行した後は 依存性注入を利用することでこのコードは非常に簡単になります @EJB Cart cart; public void additems() { cart.additem("item1"); また CMP Entity Bean のファサードとして Session Bean を使用することもできるため CMP Entity Bean から EJB 3.0 の永続化 API へと移行する動きが高まっています Message-Driven Bean(MDB) の移行 EJB 3.0 の MDB では javax.ejb.messagedriven インタフェースを実装する必要はなくなりました 代わりに @MessageDriven を使用してアノテートできます Session Bean と同じ方法で リソースや EJB 参照を MDB に注入できます 同様に コンテキスト (MDB の MessageDrivenContext) を Message-Driven Bean に注入できます 次の表に EJB 2.x と EJB 3.0 での MDB の変更点をまとめます EJB 2.x EJB 3.0 javax.ejb.messagedriven の実装デプロイメント ディスクリプタ内で宛先タイプ 名前などを指定 SetMessageDrivenContext() による MessageDrivenContext の取得 Queue や Topic などのリソースの使用には デプロイメント ディスクリプタ内での resource-ref と JNDI ルックアップが必要 @MessageDriven を使用したアノテート @ActivationConfigProperty を使用したアノテートが可能依存性注入を使用した MessageDrivenContext の取得 例 : @Resource javax.ejb.messagedrivencontext mc; 依存性の注入を使用して実行可能 例 : @Resource(name="jms/myQueue") private QueueConnectionFactory queueconnectionfactory; EJB 3.0 への移行 8
EJB 3.0 の永続化への移行 永続化は J2EE 開発者が直面している最大の課題の 1 つです Enterprise Java プラットフォームには標準の永続化 API が欠如しているため この問題はさらに悪化しています 通常 J2EE アプリケーションは次のいずれかの方法で永続化を実現しています EJB 2.x コンテナ管理永続性 (CMP)Entity Bean Oracle TopLink JBoss Hibernate またはカスタムの O-R マッピング フレームワークなどの POJO 永続化フレームワーク JDBC を使用したデータ アクセス オブジェクト Java データ オブジェクト EJB 3.0 で定義されている新しい永続化 API では これらの選択肢すべてをまとめた待望の標準が提供されます どの永続化手法を使用しているかによって 移行の課題と機会はそれぞれ異なります このホワイト ペーパーでは EJB 2.x CMP からの移行に重点を置いて説明します この移行には飛躍的な変更が必要であり 2.x 仕様で定義した現在のソリューションを採用している顧客に影響を与えるためです 新しい永続化 API 新しい永続化 API の中心となるのは EntityManager です EntityManager はアプリケーションが使用するプライマリ インタフェースであり 永続化エンティティの取得と変更を行います このインタフェースが J2EE コンポーネント内で使用できることに加えて 新しい永続化 API では EJB 3.0 の統合コンテナの外部サポートが提供されます このサポートは Application Managed と呼ばれており コンテナ外部でアプリケーション コードと EJB コンポーネントをテストすることを主な目的とするとともに その他の機能も提供しています これにより 開発者は 単純なテスト ケースを作成して エンティティとその関連コードの動作を検証できるようになります これは 永続化 API がもたらすもっとも顕著な利点の 1 つです EJB 2.x CMP Entity Bean の移行 EJB 2.x の永続性を EJB 3.0 へ移行するプロセスは 両者の共存から完全な移行と新手法の導入まで多岐にわたります 移行には モデル そのマッピング 問合せ および永続化 API を使用するアプリケーション コードに対する変更が含まれます 移行には 次の 3 つの基本的な手法があります 1. エンティティ DTO を EJB 3.0 エンティティへ移行する 2. EJB 2.x の Entity Bean を EJB 3.0 エンティティへ移行する 3. 新しい EJB 3.0 のエンティティ モデルを作成する はじめの 2 つの手法は アプリケーション コードの変更を最小限に抑えることを目的としています 3 番目の手法は 新しいモデルを作成することにより コーディングと設定作業を削減することを目的としています この手法では 自動生成ツールを使用する場合があります この方法は EJB 3.0 の永続化モデルを構築するための最適な方法ですが アプリケーション コードの移行コストはもっとも高くなります EJB 3.0 への移行 9
DTO と EJB 3.0 エンティティ 特定のアプリケーションにとってどれが最適な手法であるかを取り上げる前に DTO に関する課題と EJB 3.0 の永続性において DTO が果たす役割について明らかにしておく必要があります EJB 2.x では アプリケーションの別の層で使用する際コンテナの外部で永続化データを取得するために DTO が必要でした EJB 3.0 のエンティティはシリアライズ可能であるため DTO を使用する必要はなくなりました これ g は 必要とされる分離機能を提供している場合でも DTO を使用できないということではありません ただし 一般的に行われている Entity Bean のミラー化やビジネス ロジックのレプリケーションを目的とした DTO の使用は解消されます これらの " エンティティ DTO" と呼ばれる DTO は もはや必要ありません DTO が果たすもう 1 つの役割は " ビュー DTO" です ビュー DTO は CMP エンティティをミラー化しないオブジェクトで 代わりに 1 つまたは複数の Entity Bean から取得した よりおおまかなデータ ビューを提供します また 異なる階層間での相互作用を最適化するために使用されます EJB 3.0 でもこのようなタイプの DTO の必要性はなくなりませんが EJB 3.0 が提供する機能によって より簡単に使用できるようになります 従来のアプリケーションでは 根底にあるエンティティを取得してから プログラムを使用してビュー DTO にデータを挿入する必要がありましたが EJB 3.0 の問合せの結果は バインディング コードを追加しなくてもビュー DTO に直接反映されます EJB 3.0 の EJB QL クエリーでは 非永続クラスを使用して結果が返されます この場合 問合せ文により必要な属性と永続化モデルに関連する選択基準が定義されますが これらの 1 つが返される代わりに 非永続クラスが指定されます この指定に使用される NEW 演算子は クラスと 結果オブジェクトの構築に使用されるコンストラクタを定義します SELECT NEW EmpView(e.id, e.firstname, e.lastname, d.name) FROM Employee e JOIN e.department d WHERE e.salary > 50000 エンティティ DTO から EJB 3.0 エンティティへの移行を選択すると これらのシリアライズしたオブジェクトを使用するクライアント層の変更を最小限に抑えることができます また EJB 層に含まれるアプリケーション ロジックがごくわずかであるか またはエンティティ DTO に集中している場合も この移行を選択してください この手法では エンティティ DTO が有効な JavaBean であり 関連づけられた Entity Bean のデータ要素と 1 対 1 の対応関係を維持している必要があります また DTO を変換した後に永続化ロジックを単独で更新できるように DAO 層を配置することが強く推奨されています アプリケーション ロジックで EJB 2.x エンティティを直接使用している場合は Entity Bean の移行の項で説明したテクニックの方が適している場合もあります EJB 3.0 への移行 10
DTO の EJB 3.0 エンティティへの移行 移行プロセスの最初のステップは クラス定義に @Entity アノテーションを追加することにより エンティティ DTO を永続化オブジェクトとして指定することです EJB 3.0 のデフォルトでは これだけでエンティティ DTO がデータベースにマッピングされる永続化オブジェクトになります デフォルトでは 表の名前はクラス名と同じであり JavaBean に含まれる public の getter メソッドは それぞれプロパティと同じ名前を持つ表の列に一致するとみなされます @Table @Column 及びその他の EJB 3.0 アノテーションを使用して これらのデフォルトのマッピングをカスタマイズできます 各エンティティ DTO を永続化オブジェクトとして指定し データベース マッピングを適切に設定した後 次のステップとして 新しいエンティティ間の関係を定義します EJB 3.0 にはオブジェクト リレーショナル アノテーションの完全な一式が含まれており エンティティ関係を識別するとともに永続化操作における動作を制御します EJB 2.x の ejb-jar.xml ファイルに含まれる <ejbrelation> ディスクリプタは 関係を持つエンティティの各ペアに直接マッピングできます 次のリレーションシップ ディスクリプタについて検討します <ejb-relation> <ejb-relation-name>dept-emps</ejb-relation-name> <ejb-relationship-role> <ejb-relationship-role-name>dept-has-emps </ejb-relationship-role-name> <multiplicity>one</multiplicity> <relationship-role-source> <ejb-name>deptbean</ejb-name> </relationship-role-source> <cmr-field> <cmr-field-name>employees</cmr-field-name> <cmr-field-type>java.util.set</cmr-field-type> </cmr-field> </ejb-relationship-role> <ejb-relationship-role> <ejb-relationship-role-name> Emps-have-Dept </ejb-relationship-role-name> <multiplicity>many</multiplicity> <relationship-role-source> EJB 3.0 への移行 11
<ejb-name>empbean</ejb-name> </relationship-role-source> <cmr-field> <cmr-field-name>dept</cmr-field-name> </cmr-field> </ejb-relationship-role> </ejb-relation> 次の Employee エンティティの一部は Emps-have-Dept ロールがどのようにマッピングされるかを示します @Entity public class Employee { private Department department; //... @ManyToOne public Department getdepartment() { return department; public void setdepartment(department dept) { this. department = dept; 表名やフィールド名がデフォルトで設定され 上書きできるのと同様に 外部キーの列名もデフォルト設定されます これに対して リレーションシップ マッピング アノテーションでは @JoinColumn を使用してデフォルトとは異なる列名を提供します この時点では 既存アプリケーションの動作で変更はないことに注意してください ここまでで実行したことは もとのエンティティ DTO にメタデータを追加して これらを EJB 3.0 の永続化エンティティとして使用可能にしただけです エンティティ DTO を管理する DAO 層が適切に配置されている場合 この層を更新することにより EntityManager を使用して新しくアノテートされた永続化オブジェクトの取得 格納 更新を行うことができます EJB 2.x Entity Bean の移行 DTO をエンティティへ移行するためのもう 1 つの方法は 既存の EJB 2.x のエンティティ モデルを活用することです 説明のため ここでは Entity Bean のローカル インタフェースのみが使用されていることにします これは ローカル インタフェースが現在のアプリケーションにもっとも普及しており リモート オブジェクトとしてのエンティティは EJB 3.0 ではサポートされていないためです アプリケーションがリモート オブジェクトとして Entity Bean を使用している場合 移行にはより抜本的な設計変更が必要になります EJB 3.0 への移行 12
このタイプの移行の目的は エンティティのローカル インタフェースとホーム インタフェースに結合しているクライアント コードの変更を最小限に抑えることにあります 1. Bean クラスでの抽象的な指定を排除し プロパティ アクセッサ (get/set) メソッドの明確な実装を行います 2. エンティティをデータベースにマッピングするオブジェクト リレーショナル アノテーションを Bean クラスに指定し この関係を記述します 3. Bean クラスの名前をローカル インタフェースの名前に変更し ローカル インタフェースを削除します これにより このインタフェースを介して Bean を使用しているアプリケーション コードへの変更が最小限に抑えられます 4. Bean に関連づけられたファインダと select を Bean クラスの @NamedQuery アノテーションに変換します エンティティ Bean が別の Bean のクライアントとして機能している場合 後述のとおり このコードをアプリケーション クライアント コードとして移行する必要があります 次の EJB 2.x の Department Bean について検討します public abstract class DepartmentBean implements EntityBean { public abstract Long getid(); public abstract void setid(long id); public abstract String getname(); public abstract void setname(string name); public abstract Collection getemployees(); public abstract void setemployees(collection employees); public void ejbcreate(long id) throws CreateException { public void ejbpostcreate(long id) throws CreateException { public void ejbstore() { public void ejbload() { public void ejbremove() throws RemoveException { public void ejbactivate() { public void ejbpassivate() { public void setentitycontext(entitycontext ctx) { public void unsetentitycontext() { 上記は 次のファインダ定義に基づいています EJB 3.0 への移行 13
<query> <description></description> <query-method> <method-name>findall</method-name> <method-params/> </query-method> <result-type-mapping>local</result-type-mapping> <ejb-ql>select OBJECT(d) From Department d</ejb-ql> </query> <query> <description></description> <query-method> <method-name>findbydeptname</method-name> <method-params> <method-param>java.lang.string</method-param> </method-params> </query-method> <result-type-mapping>local</result-type-mapping> <ejb-ql>select DISTINCT OBJECT(d) FROM Department d WHERE d.name =?1</ejb-ql> </query> 上記のステップに続いて 最後に次の処理を実行します @Entity @Table(name="DEPT") @NamedQueries({ @NamedQuery(name="DepartmentFindAll", querystring="select OBJECT(d) FROM Department d"), @NamedQuery(name="DepartmentFindByName", querystring="select OBJECT(d) FROM Department d WHERE d.name=?1") ) public class Department { EJB 3.0 への移行 14
private long id; private String name; private Collection<Employee> employees; public Department() { @Id public long getid() { return id; public void setid(long id) { this.id = id; public String getname() { return name; public void setname(string name) { this.name = name; @OneToMany public Collection getemployees() { return employees; public void setemployees(collection employees) { this.employees = employees; 特に重要なのは EJB 2.x のコンテナ管理リレーションシップ (CMR) が使用されていることです EJB 3.0 では リレーションシップ管理は標準の Java コーディング プラクティスを使用して実行されています リレーションシップが形成された場合 リレーションシップの両方が正しく更新されるようにすることは 開発者の責任になります 一般的に モデルの一貫性を維持するには リレーションシップの処理を行うごとにコードを 1 行追加する必要があります コレクションに関しては クライアント コードでコレクションを直接操作する代わりに add や eremove などのヘルパー メソッドを使用することが推奨されています @Entity public class Department { private Collection<Employee> employees; public void addemployee(employee emp) { employees.add(emp); emp.setdepartment(this); 移行の際 これらの一般的な変更に加えて EJB 2.x の Entity Bean 実装に関する作業が必要となる場合があります これらの作業には Bean 自体の中での EntityContext の使用と ejbhome メソッドの使用が含まれます EJB 3.0 のエンティティには EntityContext は含まれません エンティティは 単純に "this" を使用して自身を解決してから 別の Bean のメソッドに渡します 実装済みの ejbhome メソッドは そのままにしておくか または使用していることが明らかになるように静的メソッドに変換します EJB 3.0 への移行 15
EJB 2.x エンティティ ホームの移行 ホーム インタフェースは Entity Bean のロケーティングや管理を行うアプリケーション コードを有効化する主要なメカニズムです EJB 3.0 では ホーム インタフェースに相当するものが提供されないため 移行における最大の課題がここに生じます クライアント コードへの変更を最小限に抑えるためのもっとも容易なホームの移行方法は EntityManager を保持するヘルパー クラスを作成し ホーム上でアプリケーション コードから呼び出されるメソッドを実装することです 次に ホームの代わりの役割を果たすヘルパー クラスの例を示します public class DepartmentHome { private EntityManager em; public DeptHome(EntityManager em) { this.em = em; public Department create(long id) { Department dept = new Department(id); em.persist(dept); public void remove(department dept) { em.remove(dept); public Department findbyprimarykey(long id) { return em.find(department.class, id); public Department findbyname(string name) { return (Department) em.createnamedquery(-departmentfindbyname").setparameter(0, name).getsingleresult(); public Collection findall() { EJB 3.0 への移行 16
return em.createnamedquery(-departmentfindall").listresults(); このヘルパー クラスでは ファインダを実装するためにエンティティ クラスで定義した名前付き問合せを利用していますが 動的な問合せを使用することもできます このヘルパーの remove メソッドは これまで Entity Bean に含まれていた EJBLocalObject.remove() に取って代わります Bean の remove メソッドに対するすべてのコールは ヘルパーの remove メソッドへのコールに変更するか または EntityManager を使用して直接コールするように変更する必要があります ライフサイクル メソッドの移行 EJB 2.x では ライフサイクル メソッド一式を定義した EntityBean インタフェースを実装するには厳しい要件がありました これらのライフサイクル イベントには EJB 3.0 で適用されなくなったものもあります 次の表に これらのメソッドをすでに実装している場合に推奨される移行方針を示します EJB 2.x のライフサイクル メソッド EjbCreate EjbPostCreate EjbRemove setentitycontext unsetentitycontext EjbActivate EJB 3.0 での処理 init メソッドまたはコンストラクタ内にロジックを実装コンストラクタ内にロジックを実装 またはビジネス メソッドの作成と @PostPersist によるアノテートビジネス メソッドの作成と @PreRemove によるアノテート適用なしビジネス メソッドの作成と @PostLoad によるアノテート EjbPassivate 適用なし ( 削除可 ) EjbStore ビジネス メソッドの作成と @PrePersist または @PreUpdate によるアノテート O-R マッピングの移行 EJB 3.0 以前の O-R マッピングは常にベンダーの領域に含まれていたため 通常 ベンダー固有のデプロイメント ディスクリプタ内に格納されていました 現在 O-R マッピングは EJB 標準に統合され Bean クラスのアノテーションとして または標準 XML ファイル内に定義できます ほとんどのベンダーから このマッピングを標準の EJB マッピングに変換する方法が提供されており 自動化された移行ツールまたはマッピング エディタを使用して実行できます EJB 3.0 への移行 17
例外処理 例外はチェックされないため 以前と同じ CreateException RemoveException および FinderException の catch 句は適用されません CMP クライアント アプリケーション コードの移行 EJB 2.x の Entity Bean を使用するアプリケーション コードは Entity Bean のホーム インタフェースと ローカル インタフェースまたはリモート インタフェースに密結合されています このコードの移行が自動化される可能性はほとんどありませんが 以下の方針に従うことができます ホーム インタフェースのルックアップと問合せの実行は コンテナで管理されていない EntityManager または Home-helper クラスを直接使用するように変更する必要があります Entity Bean インタフェースを使用しているコードは 新しい EJB 3.0 エンティティを使用するように変更する必要があります エンティティ クラスでは インタフェース エンティティ DTO または新規の Entity Bean クラスのいずれかを使用できます これらの変更の選択と挿入は 選択した移行方式モデルにより異なります エンティティのデタッチメントとアタッチメントを優先して エンティティ DTO のデタッチメント コードおよびアタッチメント コードを削除できます ビュー DTO を作成するコードは 非永続ビュー オブジェクトを動的に作成する EJB QL クエリーで置き換えることができます CMP クライアントの移行 EJB 2.x の Entity Bean は ローカル クライアントかリモート クライアント またはその両方からアクセスされていました 定評のあるベスト プラクティスでは Entity Bean はローカルにとどめておき セッション ファサードでラップすることが推奨されています EJB 3.0 のエンティティは通常の Java オブジェクトであるため 常にローカル オブジェクトであり リモート (RMI) オブジェクトになることはありません これらは EntityManager API を介して取得および問合せが行われます クライアント コード ( セッション ファサードの場合は Session Bean) は エンティティ ホームの使用やコンポーネント固有のメソッドを変更し EntityManager を利用してエンティティにアクセスするように変更する必要があります ローカルおよびリモートのエンティティ参照は デプロイメント ディスクリプタ内での宣言が必要でした クライアント コードでは JNDI を使用してホームをルックアップしてから create や find などのホーム処理を実行する必要がありました 次に クライアントのルックアップの例を示します public void createnewcustomer(string name, String city) throws CreateException, NamingException, RemoteException { InitialContext ctx = new InitialContext(); CustomerHome home = (CustomerHome) ctx.lookup( "java:comp/env/ejb/customerhome"); CustomerLocal customer = null; customer = home.create(name, city); EJB 3.0 への移行 18
このコードを移行すると 次のようになります @PersistenceContext private EntityManager em; public void createnewcustomer(string name, String city) { Customer cust = new Customer(); cust.setname(name); cust.setcity(city); em.persist(cust); 以上により EJB 2.x の Entity Bean から EJB 3.0 への移行はもっとも複雑な作業で クライアントに影響を及ぼすため 慎重な計画が必要であることが分かります POJO アプリケーションの移行 一部のフレームワークでは Java オブジェクトとリレーショナル データベースの関係を長期にわたって維持しており 非常に多くのアプリケーションが Oracle TopLink などの O-R フレームワークを使用して作成されています POJO 永続化フレームワークを使用中のアプリケーションでは ドメイン オブジェクトとしてすでに Java オブジェクトを使用しているため EJB の永続化 API への移行に適しています また 永続化フレームワークのトランザクション メカニズムおよびセッション レベル API は 新しい EJB の永続化 API のものに類似しています したがって コードの修正は非常に少なくて済みます 現在 J2EE アプリケーションで使用する永続化フレームワークを評価している場合 Oracle TopLink などの POJO 永続化フレームワークを使用することが最善の選択です EJB 3.0 の永続化 API への移行が容易に実現できるからです 新しい永続化 API へ移行するには 次の 2 つのステップが必要です 永続化フレームワークで使用されているセッション API を EntityManager API に変更します 専用の O-R XML から O-R マッピング アノテーション または EJB 3.0 の永続化 API で定義されている O-R XML に変更します POJO の永続性を EJB 3.0 へ移行するための技術的な詳細は 今後 別の記事で取り上げる予定です 結論 J2EE アプリケーションから EJB 3.0 への移行は高度な技術を要するものではありませんが その他すべての移行作業と同様に 充実した知識 リソース 計画が求められます プラットフォームの移行先と最終的な状態を把握することが 最初のステップです テクノロジを理解した後 最善の移行戦略を決定するための計画に取りかかります EJB 3.0 への移行 19
まずアプリケーションの一部を移行してから その手法をアプリケーション全体に適用する方法が賢明です この戦略を使用すると 移行における多くの困難な問題が浮かび上がり どの手法がアプリケーションに最適であるかを見いだすことができます この手法に従う場合 EJB 2.x と EJB 3.0 のコンポーネント間での相互運用性などの機能が不可欠です EJB 3.0 を早期に実装した Oracle Application Server 10g などを利用することで EJB 3.0 の試用を開始し EJB 3.0 への移行の準備を整えることができます EJB 3.0 への移行 20
EJB 3.0 への移行 2005 年 6 月著者 : Debu Panda (debabrata.panda@oracle.com) Doug Clarke (douglas.clarke@oracle.com) Merrick Schincariol (merrick.schincariol@oracle.com) Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口 : 電話 : +1.650.506.7000 ファクシミリ : +1.650.506.7200 www.oracle.com Copyright 2003, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle は米国 Oracle Corporation およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です