ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Java CAPS Migration Toolユーザーズ・ガイド
11g リリース1 (11.1.1.6.0)
B66433-01
  目次へ移動
目次

前
 
次
 

1 Oracle Java CAPS Migration Toolの概要

この章では、Oracle Java CAPS Migration Toolを使用して、Oracle Java CAPSのリポジトリ・プロジェクトおよびJBIプロジェクトをOracle SOA Suiteに移行するプロセスの概要を説明します。

この章には次のトピックが含まれます:

1.1 Oracle Java CAPSの一般的な略語

この項では、Oracle Java CAPSコンポーネントと、Oracle Java CAPSで使用されているテクノロジで一般的に使用される略語および頭字語を列記します。これらは、このドキュメント全体で使用します。これらのコンポーネントの定義については、「用語集」を参照してください。

1.2 移行プロセスの概要

Oracle Java CAPS Migration Toolは、既存のOracle Java CAPSのリポジトリ・プロジェクトおよびJBIプロジェクトをOracle SOA Suiteプロジェクトに移行し、変換後のプロジェクトでマッピングとビジネス・ロジックを保持するために必要な変換の多くを自動化します。移行ツールは、デプロイされたOracle Java CAPS JBIコンポジット・アプリケーション(ZIPファイル)、またはリポジトリ・プロジェクトのアーカイブ(EARファイル)から開始します。移行ツールは、入力のZIPまたはEARファイルを読み込み、Oracle SOA Suiteに必要なプロジェクト・コンポーネントをOracle JDeveloperと互換性があるファイル構造で生成します。

Oracle Java CAPSリポジトリ・プロジェクト・コンポーネント(BPEL 1.0のビジネス・プロセス、XSDファイル、WSDLファイル、メッセージ可能OTD、Javaコラボレーション定義(JCD)など)が解析され、Oracle SOA Suiteコンポーネントと互換性がある形式に変換されます。JBIプロジェクト・コンポーネント(BPEL 2.0のビジネス・プロセス、WSDLファイル、XSDファイルなど)は、Oracle SOA Suiteと互換性が高いため、少ない変更でOracle SOA Suiteプロジェクトの構造に変換されます。

Oracle Java CAPS Migration Toolの出力はOracle SOA Suiteプロジェクトで、これはOracle JDeveloperで開いて表示したり編集できます。また、移行後のプロジェクトには、そのプロジェクトが依存するOracle Java CAPSのJARファイルも含まれます。移行ツールを使用して、Oracle Java CAPSのバージョン5.0.5 (すべての更新リリース)、5.1.3 (すべての更新リリース)、およびリリース6以降を移行できます。

1.2.1 プロジェクトの移行仕様

リポジトリ・プロジェクトの移行は、Oracle SOA Suiteプロジェクトへの直接的なマッピングが含まれるJBIプロジェクトの移行よりも複雑なプロセスになります。いずれの場合も、移行ツールは、生成されたデプロイメント・ファイルから開始します。リポジトリ・プロジェクトの場合、これはEARファイルで、JBIプロジェクトの場合、これはビルドZIPファイルです。入力のプロジェクトはOracle Java CAPSで正常にビルドされてデプロイされたものであるため、有効なものであるとみなされ、移行ツールでは入力のプロジェクトに対する検証は行いません。

1.2.1.1 リポジトリ・プロジェクトの移行

ビジネス・プロセスが含まれるリポジトリ・プロジェクトを移行すると、BPEL 1.0のコードはOracle SOA SuiteプロジェクトではBPEL 2.0に変換されます。Javaコラボレーション定義(JCD)はSpringコンポーネントに変換され、関連するSpringコンテキスト・ファイルが生成されます。必要で使用可能なJARファイルは、Oracle Java CAPSプロジェクトからOracle SOA Suiteプロジェクトにコピーされます。Webサービスとして公開されているJCDは、移行後のプロジェクトでは、サービスとして公開されるSpringコンテキストに変換されます。JCDを呼び出すビジネス・プロセスを持つプロジェクトは、Springコンポーネントを呼び出すビジネス・プロセスに変換されます。

移行ツールでは、ファイル、JMSおよびWebサービスのアダプタは移行できますが、その他のタイプのアダプタのコードは移行されません。専用のアダプタ(データベース・アダプタなど)を使用するプロジェクトを移行した場合は、移行ツールによって、移行プロジェクトにプレースホルダのエンドポイント(単なる基本的なWSDLインタフェース)が生成されます。これらのプロジェクトの変換を完了するには、Oracle JDeveloperで、対応するOracle SOA Suiteアダプタを移行後のプロジェクトに追加し、そのアダプタを、対応するSpringコンポーネントまたはビジネス・プロセスにマップする必要があります。詳細は、4.3.4項「移行ツールで変換されなかったアダプタの追加」を参照してください。

ビジネス・プロセスのマーシャルおよびアンマーシャル操作のほとんどは、移行後のプロジェクトのビジネス・プロセスではJava Embeddingアクティビティに変換されます(たとえば、XSD、DTD、ユーザー定義およびSWIFT OTDのマーシャルおよびアンマーシャル操作)。また、Springコンポーネントに変換されたすべてのJCDでは、OTDUtilクラスからヘルパー・メソッドを使用して、生成されたJAXBオブジェクトのマーシャルおよびアンマーシャルを実行できます。

リポジトリ・プロジェクトを移行すると、指定したディレクトリに新しいOracle SOA Suiteプロジェクト用のフォルダ構造が作成されます。このフォルダには、必要なすべてのOracle SOA Suiteファイルが含まれます(BPELファイル、WSDLドキュメント、コンポジット・ファイル、プロジェクト・ファイルなど)。また、移行ツールでは、移行ツール・ディレクトリに一時フォルダを作成して、移行されたOracle Java CAPSプロジェクトの元のコードを保存します。これにより、Oracle Java CAPSとOracle SOA Suiteプロジェクトの共通ファイルの比較、JCDのソース・コードと移行後のコードの比較、BPELファイルの比較などが可能です。

1.2.1.2 JBIプロジェクトの移行

Oracle SOA SuiteとOracle Java CAPS JBIのプロジェクト・コンポーネントのマッピングは、比較的直接的であるため、必要な変換は少なくなります。Oracle Java CAPSリポジトリ・プロジェクトのときのようにOTDを使用するのではなく、JBIプロジェクトとOracle SOA Suiteプロジェクトの両方では、ネイティブ・メッセージ形式をXMLに変換し、後でまた変換を戻します。JBIプロジェクトを移行すると、移行ツールは、コンポジット・アプリケーションのビルドZIPファイルから情報を抽出します。jbi.xmlファイルからエンドポイントおよびサービス接続情報を取得して、BPELファイル、関連するWSDLおよびJCAファイル、Oracle JDeveloperのcomposite.xmlファイル、およびプロジェクトJPRファイルを生成します。


注意:

移行後のOracle SOA Suiteプロジェクトでは、具体的なバインディング情報およびサービス要素は、WSDLファイルからコンポジットおよびバインディング構成(JCA)ファイルに移動されます。Oracle SOA Suiteでは、WSDLファイルは抽象的な情報で、バインディング・タイプ情報はcomposite.xmlおよびアダプタJCAファイルで直接指定されます。

移行ツールを使用して、すべてのOracle Java CAPS JBIプロジェクト・タイプを変換できるわけではありません。ほとんどそのまま変換されるプロジェクトでは、ファイル、JMSまたはHTTPのバインディング・コンポーネントを持つビジネス・プロセスを使用します。専用のサービス・エンジン(Worklist ManagerやData Mashupなど)およびバインディング・コンポーネント(SchedulerやHL7など)は移行されません。

1.2.1.3 Oracle Java CAPSリポジトリとOracle SOA Suiteのマッピング

表1-1に、各Oracle Java CAPSリポジトリ・コンポーネントと、それに対応するOracle SOA Suiteコンポーネント(移行後のコンポーネント)を示します。前述したように、Oracle Java CAPS JBIプロジェクトには、Oracle SOA Suiteプロジェクトとの1対1の直接的なマッピングが存在します。

表1-1 Oracle Java CAPSリポジトリ・コンポーネントとOracle SOA Suiteのマッピング

Oracle Java CAPSコンポーネント マップ先のOracle SOA Suiteコンポーネント

正規のデータ: OTD

正規のデータ: XMLオブジェクト

正規のインタフェース: OTD、WSDL

正規のインタフェース: WSDL

所有者

規格

JCD

Springコンテキスト

接続マップ

コンポジット

JCDを呼び出すビジネス・プロセス

Springコンテキストを呼び出すビジネス・プロセス

サービスとしてのJCD

サービスとしてのSpringコンテキスト


1.2.1.4 移行ツールのプロセス・フロー

  1. 移行ツールは、コマンドライン・モードまたはウィザード・モードのいずれかのモードで実行します。入力は、Oracle Java CAPSアーカイブ・ファイル(ZIPまたはEARファイル)、出力ディレクトリ、および移行後のプロジェクトのOracle SOA Suiteプロジェクト名です。

  2. 移行ツールは、入力ファイルの内容を一時的な場所に抽出し、移行プロセスを開始するために必要なファイルを選択します。

  3. 移行ツールは、(Oracle SOA Suiteコンポジット内のワイヤを判別する)プロジェクトのエンドポイントを導出します。

  4. 移行ツールは、一連のパーサーを起動します。

    • BPELパーサーは、パートナ・リンク定義を取得し、リポジトリ・プロジェクトの場合はBPEL 1.0のコードをBPEL 2.0に変換します。

    • WSDLパーサーは、WSDLドキュメントに定義されているパートナ・リンクを変換後のBPELにマップします。また、WS-I Basic Profileと互換性を持つようにメッセージ・タイプを変換します。

    • JCDパーサーは、JCDのJavaコードを解析して、インバウンドおよびアウトバウンドを導出します。JAX-WSプロキシ・メソッドと、Logger、CollaborationContextおよびTypeConverterのすべてのアクセッサ・メソッドを追加します。

    • 接続パーサーは、エンドポイントを解析して、Oracle SOA Suiteコンポジット内にワイヤ情報を作成します。

    • ディスクリプタ・パーサーは、Oracle Java CAPSのファイル・アダプタおよびJMSアダプタのエンドポイント・プロパティ・ファイルを読み込んで、Oracle SOA Suiteプロジェクトに必要なJCAファイルを作成します。このパーサーは、プロジェクトのra.xmlおよびejb.xmlファイル全体を読み取ってエンドポイント・プロパティを導出し、JCAファイルの生成に必要なメタデータを作成します。

  5. 移行ツールにより、次のプロジェクト・コンポーネントが生成されます。

    • 移行後のビジネス・プロセスのJava Embeddingアクティビティ(メッセージ可能OTDのマーシャルおよびアンマーシャル・プロセスのそれぞれに対して)。

    • ビジネス・プロセスで呼び出されるJCD、およびWebサービスとして公開されるJCDのJAX-WSインタフェース。

    • プロジェクト内のメッセージ可能OTDのXSDファイル。

    • 各JCDのSpringコンテキストおよびコンポーネント・タイプ。

    • Oracle SOA Suiteのcomposite.xmlファイル。

    • JCAファイル。

    • Oracle SOA Suiteプロジェクト・ファイル(.jpr) (これは、移行後のプロジェクトをOracle JDeveloperで開くために必要です)。

  6. 移行ツールにより、ソース・ファイルから必要なOracle Java CAPSライブラリが抽出され、移行後のプロジェクトの/SCA-INF/libディレクトリにコピーされます。

1.2.2 リポジトリ・プロジェクトの移行のサポート

リポジトリ・プロジェクトの場合、ビジネス・プロセスとJCDプロジェクトの両方を移行できます。ただし、使用されているアダプタに完全に一致するものがOracle SOA Suiteでは提供されていない場合があります。移行ツールでは、一部のアダプタおよびOTDを完全に移行できますが、そうでないものは、移行ツールでの変換が完了した後に手動で調整する必要があります。

ビジネス・プロセスおよびJavaコラボレーション定義

移行ツールでは、スタンドアロンのビジネス・プロセスまたはJCDが含まれるプロジェクトや、ビジネス・プロセスおよびJCDの組合せ(サブプロセスやサブコラボレーションの呼出しなど)が含まれるプロジェクトが変換されます。たとえば、次がサポートされます。

  • ビジネス・プロセス(BPEL 1.0)でサブプロセスまたはサブコラボレーションを呼び出す場合。

  • JCDでサブコラボレーションを呼び出す場合(この場合は、JCDを再接続する手動での変更が必要です)。

  • JCDがWebサービスとして公開されている場合。JCD内のWebサービスのアウトバウンドは移行されません。

ファイル、JMSおよびWebサービスのOTD

移行ツールでは、次のタイプのファイル、JMSおよびWebサービスのOTDプロジェクトがサポートされます。

  • ビジネス・プロセスおよびファイル、JMSまたはWebサービスのエンドポイント(インバウンドとアウトバウンドの両方)が含まれているリポジトリ・プロジェクト。

  • ビジネス・プロセスと、ファイルまたはJMSのアダプタがインバウンドとして、他のアダプタ(OracleやSAPなど)がアウトバウンドとして含まれているリポジトリ・プロジェクト。アウトバウンド・アダプタは自動的に移行されませんが、移行後のプロジェクトにプレースホルダのエンドポイントが生成されます。

  • Javaコラボレーション定義(JCD)と、インバウンドおよびアウトバウンドのファイル・アダプタまたはJMSアダプタが含まれているリポジトリ・プロジェクト。

  • JCDと、ファイルまたはJMSのアダプタがインバウンドとして、他のアダプタ(OracleやSAPなど)がアウトバウンドとして含まれているリポジトリ・プロジェクト。アウトバウンド・アダプタは自動的に移行されませんが、移行プロジェクト内に対応するOracle SOA Suiteアダプタを作成してワイヤリングできます。

XSD、DTDおよびUD OTD

移行ツールでは、XSD、DTDおよびユーザー定義OTD内にマーシャルおよびアンマーシャル操作を持つリポジトリ・プロジェクトの移行がサポートされます。

ファースト・クラス(FCX) OTD

移行ツールでは、次のタイプのFCX OTDプロジェクトがサポートされます。

  • JCD内のインバウンドおよびアウトバウンドとしてFCX OTDのあるリポジトリ・プロジェクト。

  • Webサービスとして公開されているJCDと、FCX OTDがインバウンドおよびアウトバウンドとして含まれているリポジトリ・プロジェクト。

  • JCDを呼び出すビジネス・プロセスと、FCX OTDがインバウンドおよびアウトバウンドとして含まれているリポジトリ・プロジェクト。

HL7 OTD

移行ツールでは、次のタイプのHL7 OTDプロジェクトがサポートされます。

  • ビジネス・プロセスのHL7 OTDメッセージにマーシャルおよびアンマーシャル操作が含まれているリポジトリ・プロジェクト。HL7 OTDメッセージ用のデータ・マッピングは、変換後のプロジェクトでも保持されることに注意してください。

  • JCDを呼び出すビジネス・プロセスと、HL7が入力と出力の両方のOTDメッセージとして含まれているリポジトリ・プロジェクト。

SWIFT OTD

ビジネス・プロセスおよびJCDにSWIFT OTDを持つOracle Java CAPSリポジトリ・プロジェクトは、移行ツールによって自動的に移行されます。SWIFT OTDを持つものでサポートされるモデルをいくつか次に示します。

  • SWIFT OTDからのマーシャルおよびアンマーシャル・アクティビティを持つビジネス・プロセスが含まれているリポジトリ・プロジェクト。

  • ファイルまたはJMSのインバウンドおよびアウトバウンドと、SWIFT OTDがJCDの他のOTDとして存在するスタンドアロンのJCD。ファイルまたはJMSの内容は、SWIFT OTDにアンマーシャルされます。

1.2.2.1 Javaコラボレーション定義の移行のサポート

移行ツールでは、1.2.2項「リポジトリ・プロジェクトの移行のサポート」に記載されている形で実装されているJavaコラボレーション定義(JCD)が含まれるOracle Java CAPSプロジェクトが変換されます。JCDを移行する際、移行ツールは、JCDのソース・コードをEARファイルから読み込んで解析します。JCDの実装のタイプに基づいて、JCDパーサーによって、元のソース・コードが変更されます。

スタンドアロンのJCDでインバウンドまたはアウトバウンド接続にファイル・アダプタまたはJMSアダプタを使用している場合、パーサーはインバウンド接続タイプを識別して、対応するOracle SOA Suiteアダプタ・インタフェースを実装するようにJCDを変更します。パーサーは、元のJCDメソッドのコールを実行する疑似コードを使用して、このインタフェースのメソッドを作成します。

ビジネス・プロセスから呼び出されているJCDの場合、およびファイル・アダプタまたはJMSアダプタをインバウンド接続に使用してアウトバウンド接続に使用していないスタンドアロンのJCDの場合、パーサーは、JAX-WSインタフェースを実装するようにJCDを変更します(このインタフェースは、Oracle SOA Suite JAX-WSツールによって生成されます)。元のJCDの入力および出力OTDのタイプは、JAXBに変換されます。生成されたJAXBオブジェクトは、いくつかのJavaクラスによって表されます。

JCDからの移行時に作成されたすべてのSpring Beanでは、OTDUtilクラスからヘルパー・メソッドを使用して、生成されたJAXBオブジェクトのマーシャルおよびアンマーシャルを実行できます。

変換後のJCDの詳細およびサンプル・コードについては、付録A「Javaコラボレーション定義の変換の例」を参照してください。

1.2.2.2 アダプタおよびOTDのサポート

Oracle Java CAPS Migration Toolでは、ユーザー定義、XSD、DTD、SWIFTおよびHL7のオブジェクト型定義(OTD)の移行をサポートしています。移行ツールでは、Oracle Java CAPSプロジェクトで使用されているすべてのOTDをXSDファイルに変換するとともに、XMLデータ(XSDによって定義されるJAXBおよびDOM)をOTDに変換したりOTDデータをXMLデータに戻すユーティリティ・メソッドを提供します。移行ツールのOTDパーサーは、入力EARファイル内のOTD JARファイルからOTDメタデータを読み込みます。次に、OTDを表すXSDファイルを作成し、移行後のOracle SOA SuiteプロジェクトのxsdフォルダにそのXSDファイルを格納します。

移行ツールでは、生成元のOTDの名前に基づいて、XSDファイルの名前が決定されます。生成されたWSDLドキュメントは、これらのXSDを使用してメッセージ・タイプを定義するように変更されるため、そのOTDを使用するすべてのビジネス・プロセスでOTDメッセージ・タイプを解決できます。

生成されたXSDファイルでは、無効な要素名になる場合を除いて、要素名にOTDのフィールド名が使用されます。OTDタイプを使用しているBPEL XPath式は、生成されたXSDファイルに一致するように変換されます。提供されているOTDUtilメソッドを使用して、OTDとXMLデータ間のデータ変換を実行できます。移行ツールによって、OTDUtilクラスが組み込まれ、移行後のOracle SOA Suiteプロジェクトにパッケージ化されます。OTDUtilクラスで提供されるユーティリティ・メソッドでは、OTDの実装のOTD操作を呼び出してネイティブOTD操作を実行して、生成されたXSDで定義されていたXMLにデータを戻すことができます。詳細は、移行ツールと一緒にパッケージされている(migration_tool_home/oracle.migrationtool.jcaps.libraries/libの)caps.migration.runtime.util.jarファイルにパッケージされているmigration.caps.runtime.OTDUtil javadocを参照してください。このJARファイルは、移行後のOracle SOA Suiteプロジェクトにも組み込まれます。

1.2.2.2.1 JMSアダプタのreceiveWait操作を持つプロジェクトの移行

Java CAPSのJMSアダプタでは、receiveWaitのWebサービス操作がサポートされていますが、これに相当するものはOracle SOA Suiteに存在しません。receiveWaitおよびsend操作を持つアウトバウンドJMSアダプタが含まれるプロジェクトは、Oracle SOA Suiteに移行して、Oracle JDeveloperで正常にデプロイできます。Oracle Java CAPS Migration Toolでは、アウトバウンドJMSアダプタのreceiveWait操作は削除されます。

1.2.2.2.2 HL7 OTDを持つプロジェクトの移行

次のようなHL7 OTDを持つOracle Java CAPSプロジェクトのモデルは、移行に適した候補です。

  • HL7 OTDのマーシャルおよびアンマーシャル・アクティビティを持つビジネス・プロセスが含まれるプロジェクト。

  • インバウンドとアウトバウンド接続の両方としてHL7 OTDを持つJCDを呼び出すビジネス・プロセスが含まれるプロジェクト。

  • ファイルまたはJMSのインバウンド・アダプタから、HL7 OTD構造へのアンマーシャルおよびマーシャルを実行しているスタンドアロンのJCDが含まれるプロジェクト。

JCD内に入力および出力としてHL7 OTDを持つプロジェクトを移行する場合は、-usejaxbオプションを使用しないでください。この場合に-usejaxbオプションを使用すると、JAXBオブジェクトではすべてのメソッドが使用可能であるとはかぎらないため、移行後のJCDのJavaコードのコンパイルに失敗する可能性があります。これは、その他のタイプのOTDでも発生する可能性があります。

1.2.2.2.3 マーシャルおよびアンマーシャルの移行

ビジネス・プロセスのOTDのマーシャルおよびアンマーシャル操作およびfunctoidは、移行ツールによって、OTDUtilメソッドを使用したmarshalToStringおよびunmarshalFromString操作を実行する埋込みJavaコードに変更されます。これらの操作は、BPELビジネス・プロセスのJava Embeddingアクティビティとして組み込まれます。Java Embeddingアクティビティをそのままビジネス・プロセスに残しておくか、またはアダプタ構成ウィザードを使用して、別のメッセージ・スキーマを使用するようにプロジェクトの入力JCAエンドポイントを変更できます。これにより、メッセージは指定されたスキーマ・タイプに内部変換されるため、マーシャルおよびアンマーシャル操作を削除できるようになります。入力がユーザー定義OTDである場合は、埋め込まれたJava実装を使用したり、入力をXMLメッセージに変更したり、ネイティブ・フォーマット用のスキーマ(nxsd)を定義できます。

1.2.2.2.4 マーシャルおよびアンマーシャル・プロセスについて

マーシャルおよびアンマーシャルのプロセスには、3つの主要ステップがあります。

  • Oracle SOA SuiteのBPELXExecLetクラスのgetVariableDataメソッドをコールして、入力変数を取得します。

  • OTDクラス名、OTD操作名、入力要素および出力コンテナ・パート名をパラメータとして使用して、OTDUtil.otdOperationメソッドをコールします。これにより、OTDオブジェクトが作成されて、unmarshalFromStringおよびmarshalToString操作が呼び出され、結果はDOM要素に出力コンテナ・パート名としてルート付きでラップされます。

  • Oracle SOA SuiteのBPELXExecLetクラスのsetVariableDataメソッドをコールして、出力をBPEL変数に設定します。

1.2.2.2.5 BPELのマーシャルおよびアンマーシャルの例

次の例は、移行後のアンマーシャルおよびマーシャル操作を示しています。

例1-1 移行後のアンマーシャル操作

//1: Get OTD marshal/unmarshal operation input by passing inputvariable and part name 
org.w3c.dom.Element inputelem = (org.w3c.dom.Element)getVariableData
    ("customerunmarshalFromStringInput","text");
String otdClass = "ud1.customer689211042.Customer"; 
    //Name of OTD class generated by Java CAPS

//2: Invoke OTDUtil.otdOperation by passing OTDClassType, operationname, and input element
Object output = migration.caps.runtime.OTDUtil.otdOperation(otdClass,
"unmarshalFromString",inputelem,"customer"); //3 : Set OTD marshal/unmarshal operation output by passing outputvariable, part name, and data element setVariableData("customerunmarshalFromStringOutput","customer",output,false);

例1-2 移行後のマーシャル操作

//1: Get OTD marshal/unmarshal operation input by passing inputvariable and part name
org.w3c.dom.Element inputelem =
  (org.w3c.dom.Element)getVariableData("customermarshalToStringInput","customer");
String otdClass = "ud1.customer689211042.Customer"; 
    //Name of OTD class generated by Java CAPS

//2:Invoke OTDUtil.otdOperation by passing OTDClassType, operationname, and input element
Object output = migration.caps.runtime.OTDUtil.otdOperation(otdClass,
    "marshalToString",inputelem,"text");

//3:Set OTD marshal/unmarshal operation output by passing outputvariable, part name, and data element
setVariableData("customermarshalToStringOutput","text",output,false);

FCX OTDの場合は、XMLBeanと互換性がないためOracle SOA Suiteでロードできないので、otdClassパラメータはnullです。XMLベースのOTDの場合は、OTDClassパラメータをnullにすることができ、その場合、実際のOTDはロードされずにマーシャルおよびアンマーシャル操作が実行されます。この場合、OTDUtilでは、XML DOMが文字列に変換されるか(マーシャル)、文字列のXMLがXML DOMに戻されます(アンマーシャル)。

1.2.2.2.6 JCD内のマーシャルおよびアンマーシャル操作

Oracle Java CAPS Migration Toolでは、JCD内で使用されているOTDはJAXBオブジェクトに変換されます。ほとんどの場合、移行後のSpringクラスでこれらのJAXBオブジェクトを使用できます。また、必要な場合は、OTDUtilからjaxbMarshalToOTDおよびjaxbUnmarshalFromOTDメソッドを使用して、JAXBをOTDに変換したり、OTDをJAXBに変換できます。

1.2.2.3 Oracle Java CAPSフレームワーク・クラスのサポート

移行時には、Oracle SOA SuiteでOracle Java CAPSフレームワーク・クラスを処理するためのコードが生成されます。これには、ロガー、コラボレーション・コンテキストおよびタイプ・コンバータのクラスが含まれます。移行ツールでは、アラータ・クラスは処理されません。移行後のコードにはこれらのクラスのアクセス・メソッドが含まれ、これらのクラスへの参照のインスタンス化はSpringコンテキスト・インジェクションによって行われます。クラスは、移行プロジェクトのApplication Sourcesフォルダのjcaps_interfaces.jarに格納されます。

1.2.3 OTDからXSDおよびXSDからJAXBへの変換

プロジェクトの初期移行が完了した後は、移行ツールを異なるモードで実行して、OTDをXSD形式に、およびXSD形式をJAXBオブジェクトに変換できます。

デフォルトでは、移行ツールは、元のJCDインタフェースを保持します。追加オプションの-usejaxbは、JCDの入力引数および出力引数のJAXBオブジェクトをOTDに変換せずに使用することを示し、実行時のパフォーマンスがわずかに向上します。

1.2.4 移行時のJAXBの生成

ビジネス・プロセスでJCDを呼び出していたり、JCDをWebサービスとして公開しているOracle Java CAPSプロジェクトは、特殊な移行ケースです。これらのプロジェクトにはWSDLインタフェースが含まれ、移行時にJAX-WSプロキシ・インタフェースに変換されます。WSDLドキュメントで定義されているOTDメッセージ・タイプは、JAXBオブジェクトに変換されます。

JAXBオブジェクトを生成するために、移行ツールでは、次の特定バージョンのJAXBおよびXJCライブラリが使用されます。次に示すバージョンは、WebLogic Server内では使用できず、Oracle Java CAPS Migration Toolで使用するためだけに組み込まれます。

  • Oracle_SOA_Home/oracle_common/modules/glassfish.jaxb.xjc_1.0.0.0_2-1-12.jar

  • Oracle_SOA_Home/oracle_common/modules/glassfish.jaxb_1.0.0.0_2-1-12.jar

前述のバージョンのこれらのライブラリには、元のOTD動作との一貫性を維持するために、次の処理ルールが含まれます。

  • 元のXSDファイル内のアンダースコアは、生成されたJAXBオブジェクトでも残されます。

  • アンダースコアの後の小文字は、生成されたJAXBオブジェクトでも小文字のまま残されます。

  • 元のXSDファイル内にネストした複合型が存在する場合、生成されたJAXBオブジェクトのgetterメソッドによってオブジェクトがnullであるかどうかがチェックされ、そうである場合は新しいオブジェクトが作成されます。

生成されたJAX-WSプロキシ・クラスは、WSDLパッケージの下のOracle SOA Suiteプロジェクトのsrcフォルダに格納されます。プロキシ・クラスのファイル名は、ExecutePortType.javaです。

図1-1 生成されたOracle SOA SuiteプロジェクトのJAX-WSプロキシ・クラス

図1-1の説明は図の下にあります。
「図1-1 生成されたOracle SOA SuiteプロジェクトのJAX-WSプロキシ・クラス」の説明

1.2.5 JBIプロジェクトの移行のサポート

移行ツールでは、ファイル、JMSまたはHTTPのバインディング・コンポーネントを持つビジネス・プロセスを使用するすべてのOracle Java CAPS JBIプロジェクトが移行されます。また、サブプロセスを呼び出すビジネス・プロセスも移行されます。JBIプロジェクトはOracle SOA Suiteプロジェクトに類似しているため、必要な変換はリポジトリ・プロジェクトより少なくなります。

Oracle Java CAPS JBIとOracle SOA Suiteでは、いずれもBPEL 2.0がサポートされていますが、一部のコンストラクトはOracle SOA Suiteではサポートされていないため、移行ツールでプロジェクトを変換した後に、手動で変更を行う必要があります。

1.2.5.1 WS-Iバージョン1の準拠

Oracle SOA Suiteは、Web Services Interoperability Organization (WS-I)のBasic Profileバージョン1.0に準拠しています。これは、WSDLドキュメントには1つのパートのみを含めることができ、elementの型を持っている必要があることを意味します。それは、complextypesimpletypeにはできません。移行するJBIプロジェクトがWS-I準拠であることを確認してください。そうでない場合、移行後のプロジェクトは、ビルド、デプロイメントまたは実行時に失敗する可能性があります。移行ユーティリティでは、WS-I準拠のチェックは実行されません。

1.2.5.2 異なるメッセージ定義に対する同じターゲット・ネームスペース

Oracle Java CAPS JBIプロジェクトでは、WSDLドキュメントで同じターゲット・ネームスペースを使用できますが、メッセージ定義はオーバーライドされます。つまり、要素名は同じでも構造は別のものになります。Oracle SOA Suiteでは、最初のWSDLドキュメントのみがロードされ、オーバーライドされた定義は失われます。移行するJBIプロジェクトに複数のWSDLドキュメントが含まれ、同じターゲット・ネームスペースを使用している場合は、一意の名前を持つようにターゲット・ネームスペースを変更するか、同じターゲット・ネームスペースを使用するWSDLドキュメントで同じ名前のメッセージ・タイプ定義を定義しないようにしてください。

1.2.5.3 システム・プロパティ

Oracle Java CAPSでは、サービス接続に対して追加のサービス品質(QoS)プロパティを構成できます(再配信や制限など)。Oracle SOA Suiteには、対応するプロパティはありません。移行ツールでは、これらの構成は移行時に無視されます。移行後に、使用可能なOracle SOA Suiteのプロパティを使用して、プロジェクトの構成を行うことができます。詳細は、4.2.3項「サービス品質プロパティの構成」を参照してください。

1.2.5.4 BPEL 2.0コンストラクト

Oracle Java CAPS JBIでサポートされている一部のBPEL 2.0コンストラクトは、Oracle SOA Suiteでは使用できません。移行時に、BPEL 2.0のコードは変換されますが、BPELコンストラクトは変更されません。次のようなOracle Java CAPSで機能していたコンストラクトは、Oracle SOA Suiteでは機能しません。

  • 補正ハンドラおよび終了ハンドラ

  • 標準のフォルト: forcedTermination、repeatedCompensationおよびinvalidReply

  • パートナの概念(パートナは複数のpartnerLink要素をグループ化しますが、実行可能なプロパティがなかったため、BPEL 2.0から削除されました)

補正ハンドラおよび終了ハンドラでは、パートナ・リンクはプレースホルダとして移行され、これはユーザーが再作成する必要があります。また、switch要素もBPEL 2.0から削除されましたが、switch要素はOracle SOA Suiteプロジェクトでは移行ツールによってif要素に置換されます。

サポートされていないコンストラクトを解決する移行後の手順については、4.2.4項「BPEL構造の確認」を参照してください。

1.3 移行後のOracle SOA Suiteプロジェクトについて

移行後のOracle SOA Suiteプロジェクトでは、すべてのJCDはSpringコンテキスト・コンポーネントに、BPEL 1.0のビジネス・プロセスはBPEL 2.0のプロセスになっています。元のOracle Java CAPSプロジェクトでサポートされていたすべてのJCDにつき、Oracle SOA Suiteプロジェクトには、それぞれのサービスと参照ノードを持つSpringコンポーネントとコンテキストXMLファイルが含まれます。ビジネス・プロセスおよびSpringコンテキストは、自動的にインバウンドおよび外部システムに接続されますが、プロジェクトを移行した後に追加のワイヤリングが必要な場合があります。

1.3.1 Springへの変換について

各JCDは、Springコンポーネントと、関連するSpringコンテキストXMLファイルに変換されます。また、JCDのJavaクラスはOracle SOA Suiteプロジェクトに引き継がれ、JAX-WSプロキシ・メソッドと、ロガー、コラボレーション・コンテキストおよびタイプ・コンバータのすべてのアクセッサ・メソッドを実装するように変更されます。

生成されたSpringコンテキストには、元のJCDクラスを表すbean要素が含まれます。Beanでは、JCDロジックの定義に加えて、追加のプロパティ(ロガー、コラボレーション・コンテキスト、タイプ・コンバータなど)を定義し、これらは実行時にSpringコンテキストにインジェクトされます。

図1-2 SpringコンテキストXMLファイル

図1-2の説明は図の下にあります。
「図1-2 SpringコンテキストXMLファイル」の説明

元のJCDコード内でのJMSアダプタまたはファイル・アダプタの各アウトバウンド相互作用に対して、Springコンテキストには、追加のbean要素参照が含まれ、これも実行時にインジェクトされます。アウトバウンド・アダプタとの相互作用を機能させるには、BeanのAPIを呼び出す必要があります。

図1-3 Springコンポーネント・タイプ・ファイル

図1-3の説明は図の下
「図1-3 Springコンポーネント・タイプ・ファイル」の説明

各JCDに対して、Springコンポーネント・タイプも生成されます。コンポーネント・タイプでは、JCDクラスによって実装されていたJAX-WSインタフェース・クラスを定義します。すべてのJAX-WSプロキシ・クラスおよびSOA Suiteアダプタ・インタフェース・クラスは、Oracle SOA Suiteプロジェクトの同じApplication Sourcesフォルダに格納されます。

図1-4 Oracle SOA SuiteプロジェクトのApplication Sources

図1-4の説明が続きます。
「図1-4 Oracle SOA SuiteプロジェクトのApplication Sources」の説明

1.4 移行の考慮事項

Oracle Java CAPS Migration Toolでは、バージョン5.0.5 (すべての更新レベル)、5.1.3 (すべての更新レベル)、および6.0以降のビジネス・プロセスおよびJCDリポジトリ・プロジェクトがサポートされます。移行ツールでは、バージョン6.0以降のJBIプロジェクトがサポートされます。それぞれのプロジェクトによって、プロジェクト内のマッピングやその他のビジネス・ロジックの再利用のレベルは異なります。推奨される再利用レベルは様々な要因によって決まります(マッピングの数、マッピングの複雑さ、使用されているOTDの型、使用されているアダプタおよびバインディング・コンポーネントなど)。ほとんどの場合は、すべてのマッピングをそのまま保持できますが、それが最良の方法でない場合もあります。

一般的に、JCDからSpringに移行する最高の候補は、次の基準を満たすものです。

1.4.1 移行するかどうかの決定

次に、Oracle Java CAPSプロジェクトの移行を決定する際に考慮する必要があるいくつかの考慮事項を示します。

  • 取るに足りないJCDプロジェクト(たとえば、100行未満のコードで単純なマッピングのプロジェクト)であるかどうか。その場合は、従来のOracle Java CAPSのOTDを再利用することよりも、Oracle SOA SuiteコンポーネントとネイティブXMLを使用して、JCDを再作成することを検討してください。Oracle Java CAPSのOTD形式の変換オーバーヘッドが原因で、Oracle Java CAPSとOracle SOA Suiteを混合するよりも、Oracle SOA Suiteコンポーネントを排他的に使用するほうがパフォーマンス面で上回る可能性があります。

  • Oracle Java CAPSで使用できなかったOracle SOA Suiteコンポーネントのみを使用して、必要な処理を行うもっとよい方法があるかどうか。たとえば、ルーティング・ロジックを上位レベルのOracle Mediatorプロジェクトに切り離して、設計面を向上できる場合があります。

  • プロジェクトの複雑さによりますが、場合によっては、Oracle Java CAPSプロジェクトをOracle SOA Suiteに移行する作業に大変な手間がかかることがあります。

  • ビジネス・プロセスが含まれるリポジトリ・プロジェクトを移行するには、BPEL 1.0のコードをBPEL 2.0に変換する必要があります。この変換は移行ツールによって自動的に実行されますが、Oracle Java CAPSとOracle SOA Suiteでは異なるBPEL 2.0コンストラクトがサポートされているため、手動での変更が必要になる場合があります。手動の変換プロセスでは、残りのコンポーネントとシームレスな統合を完成させるために追加のリソースと時間が必要になります。

  • 移行の多くは自動的に実行されますが、JCDが含まれるリポジトリ・プロジェクトの移行では、JCDのJavaコードをOracle SOA Springコンポーネントに手動で変換する必要があります。

  • 一部のメッセージ可能OTDを持つリポジトリ・プロジェクトの移行では、Oracle SOA Suiteで機能させるために大幅な修正や設計変更が必要になる場合があります。

1.4.2 移行方法の決定

Oracle Java CAPSのJCDプロジェクトを移行することを決定した後は、どのように進めるかを決定するために、次の質問を確認してください。

  • Oracle Java CAPSアダプタ・メソッドに依存するJCDマッピングが比較的少ないかどうか。

    影響を受けるマッピングの数がわずかな場合は、Oracle SOA Suiteプロジェクト内のOracle Java CAPSマッピングで使用されているOracle Java CAPSのOTDを、対応するOracle SOA SuiteのアダプタAPIに置換します。これにより、Oracle Java CAPSアダプタのコードがJCDで必要とされなくなり、従来のOracle Java CAPSアダプタAPIへの実行時の依存がなくなります。

  • Oracle Java CAPSのメソッドに依存するJCDマッピングの数が多いかどうか。

    アダプタ・コードによる影響を受けるマッピングの数が非常に多く、これらのマッピングにOracle Java CAPSアダプタのメソッドが大量に埋め込まれている場合は、既存のマッピングを最大限に再利用できるように、Oracle Java CAPSアダプタのOTDをそのまま残しておく方がよい場合があります。短所は、移行後のコードが従来のOracle Java CAPSのアダプタ・ライブラリに依存することです。また、マッピングの外に、Oracle Java CAPSアダプタのOTDをOracle SOA SuiteアダプタのXMLオブジェクトに変換する追加コードを作成する必要があります。たとえば、データベースのOTDフィールドをデータベース・アダプタのXML形式にマップする追加コードの作成が必要な場合があります。

1.5 移行ツールの制約

Oracle Java CAPS Migration Toolは、既存のOracle Java CAPSプロジェクトをOracle SOA Suiteに移行するいくつかのタスクを自動化しますが、Oracle Java CAPSプロジェクトには様々なコンポーネントの組合せが存在する可能性があるため、プロジェクトの移行に関していくつかの制約があります。そのため、ほとんどの移行は完了するために手動での作業が必要です。必要な変更の原因は、移行するアーティファクトの性質のためや、アーティファクトをOracle SOA Suiteの対応するアーティファクトにツールで変換できないためなどです。また、アーティファクトが依存する機能やコンストラクトが、Oracle SOAでサポートされていない可能性もあります。

次に、移行ツールの開発中に発見された制約をいくつか示します。

Oracle Java CAPSリポジトリ・プロジェクトの移行