OC4J-TWP-EJB3-MIGRATION-1013

Size: px

Start display at page:

Download "OC4J-TWP-EJB3-MIGRATION-1013"

ためひとくまじ
6 years ago
Views:

1 EJB 3.0 への移行 Oracle ホワイトペーパー 2005 年 10 月

2 EJB 3.0 への移行 2

3 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 エンティティ DTO の EJB 3.0 エンティティへの移行 EJB 2.x Entity Bean の移行 EJB 2.x エンティティホームの移行ライフサイクルメソッドの移行 O-R マッピングの移行例外処理 CMP クライアントアプリケーションコードの移行 CMP クライアントの移行 POJO アプリケーションの移行結論 EJB 3.0 への移行 3

4 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

5 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 を実装する必要がなくなりましたコンポーネントインタフェースはビジネスインタフェースとして使用できますまたを使用するとインタフェースがリモートクライアントからアクセス可能であることを示すことができますリモートインタフェース上のメソッドから 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 public interface HelloWorld { String sayhello(string name); EJB 3.0 への移行 5

6 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 public class HelloWorldBean implements HelloWorld { public String sayhello(string name) { return "Hello " + name; ステートフル Session Bean の場合 ejbcreate メソッドはコンテナが維持する必要のあるステートを初期化するビジネスメソッドに置き換えられますたとえば次のようにビジネス public void initialize() { items = new ArrayList(); ステートフル Bean を使用してアノテートしますトランザクションおよびセキュリティ用のアノテーションを使用するための Session Bean コードの移行は任意で行います EJB 3.0 への移行 6

7 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

8 Cart cart =(Cart)PortableRemoteObject.narrow(home.create(), cart.additem("item1"); Cart.class); EJB 3.0 の注入パターンへ移行した後は 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 インタフェースを実装する必要はなくなりましたを使用してアノテートできます 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 を使用したアノテートが可能依存性注入を使用した MessageDrivenContext の取得例 javax.ejb.messagedrivencontext mc; 依存性の注入を使用して実行可能例 private QueueConnectionFactory queueconnectionfactory; EJB 3.0 への移行 8

9 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

10 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 > エンティティ DTO から EJB 3.0 エンティティへの移行を選択するとこれらのシリアライズしたオブジェクトを使用するクライアント層の変更を最小限に抑えることができますまた EJB 層に含まれるアプリケーションロジックがごくわずかであるかまたはエンティティ DTO に集中している場合もこの移行を選択してくださいこの手法ではエンティティ DTO が有効な JavaBean であり関連づけられた Entity Bean のデータ要素と 1 対 1 の対応関係を維持している必要がありますまた DTO を変換した後に永続化ロジックを単独で更新できるように DAO 層を配置することが強く推奨されていますアプリケーションロジックで EJB 2.x エンティティを直接使用している場合は Entity Bean の移行の項で説明したテクニックの方が適している場合もあります EJB 3.0 への移行 10

11 DTO の EJB 3.0 エンティティへの移行移行プロセスの最初のステップはアノテーションを追加することによりエンティティ DTO を永続化オブジェクトとして指定することです EJB 3.0 のデフォルトではこれだけでエンティティ DTO がデータベースにマッピングされる永続化オブジェクトになりますデフォルトでは表の名前はクラス名と同じであり JavaBean に含まれる public の getter 及びその他の 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

12 <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 public class Employee { private Department department; public Department getdepartment() { return department; public void setdepartment(department dept) { this. department = dept; 表名やフィールド名がデフォルトで設定され上書きできるのと同様に外部キーの列名もデフォルト設定されますこれに対してリレーションシップマッピングを使用してデフォルトとは異なる列名を提供しますこの時点では既存アプリケーションの動作で変更はないことに注意してくださいここまでで実行したことはもとのエンティティ 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

13 このタイプの移行の目的はエンティティのローカルインタフェースとホームインタフェースに結合しているクライアントコードの変更を最小限に抑えることにあります 1. Bean クラスでの抽象的な指定を排除しプロパティアクセッサ (get/set) メソッドの明確な実装を行います 2. エンティティをデータベースにマッピングするオブジェクトリレーショナルアノテーションを Bean クラスに指定しこの関係を記述します 3. Bean クラスの名前をローカルインタフェースの名前に変更しローカルインタフェースを削除しますこれによりこのインタフェースを介して Bean を使用しているアプリケーションコードへの変更が最小限に抑えられます 4. Bean に関連づけられたファインダと select を Bean アノテーションに変換しますエンティティ 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

14 <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> querystring="select OBJECT(d) FROM Department querystring="select OBJECT(d) FROM Department d WHERE d.name=?1") ) public class Department { EJB 3.0 への移行 14

15 private long id; private String name; private Collection<Employee> employees; public Department() 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 = public Collection getemployees() { return employees; public void setemployees(collection employees) { this.employees = employees; 特に重要なのは EJB 2.x のコンテナ管理リレーションシップ (CMR) が使用されていることです EJB 3.0 ではリレーションシップ管理は標準の Java コーディングプラクティスを使用して実行されていますリレーションシップが形成された場合リレーションシップの両方が正しく更新されるようにすることは開発者の責任になります一般的にモデルの一貫性を維持するにはリレーションシップの処理を行うごとにコードを 1 行追加する必要がありますコレクションに関してはクライアントコードでコレクションを直接操作する代わりに add や eremove などのヘルパー 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

16 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

17 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 メソッドまたはコンストラクタ内にロジックを実装コンストラクタ内にロジックを実装またはビジネスによるアノテートビジネスによるアノテート適用なしビジネスによるアノテート EjbPassivate 適用なし ( 削除可 ) EjbStore ビジネスによるアノテート O-R マッピングの移行 EJB 3.0 以前の O-R マッピングは常にベンダーの領域に含まれていたため通常ベンダー固有のデプロイメントディスクリプタ内に格納されていました現在 O-R マッピングは EJB 標準に統合され Bean クラスのアノテーションとしてまたは標準 XML ファイル内に定義できますほとんどのベンダーからこのマッピングを標準の EJB マッピングに変換する方法が提供されており自動化された移行ツールまたはマッピングエディタを使用して実行できます EJB 3.0 への移行 17

18 例外処理例外はチェックされないため以前と同じ 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

19 このコードを移行すると 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

20 まずアプリケーションの一部を移行してからその手法をアプリケーション全体に適用する方法が賢明ですこの戦略を使用すると移行における多くの困難な問題が浮かび上がりどの手法がアプリケーションに最適であるかを見いだすことができますこの手法に従う場合 EJB 2.x と EJB 3.0 のコンポーネント間での相互運用性などの機能が不可欠です EJB 3.0 を早期に実装した Oracle Application Server 10g などを利用することで EJB 3.0 の試用を開始し EJB 3.0 への移行の準備を整えることができます EJB 3.0 への移行 20

21 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 U.S.A. 海外からのお問合せ窓口 : 電話 : ファクシミリ : Copyright 2003, Oracle.All rights reserved. 本文書は情報提供のみを目的として提供されておりここに記載される内容は予告なく変更されることがあります本文書は一切間違いがないことを保証するものではなくさらに口述による明示または法律による黙示を問わず特定の目的に対する商品性もしくは適合性についての黙示的な保証を含みいかなる他の保証や条件も提供するものではありませんオラクル社は本文書に関するいかなる法的責任も明確に否認し本文書によって直接的または間接的に確立される契約義務はないものとします本文書はオラクル社の書面による許可を前もって得ることなくいかなる目的のためにも電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle は米国 Oracle Corporation およびその子会社関連会社の登録商標ですその他の名称はそれぞれの会社の商標です

V8.1新規機能紹介記事

V8.1新規機能紹介記事 WebOTX V8.1 新規機能 EJB 3.0 WebOTX V8.1より Java EE 5(Java Platform, Enterprise Edition 5) に対応しましたこれによりいろいろな機能追加が行われていますが特に大きな変更であるEJB 3.0 対応についてご紹介いたしますなお WebOTX V7で対応したEJB 2.1についてもWebOTX V8.1で引き続き利用することが可能です