Fusion Middleware Oracle Java CAPS Migration Toolユーザーズ・ガイド

11g リリース1 (11.1.1.6.0)

B66433-01(原本部品番号:E24884-01)

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 Oracle Java CAPS Migration Toolの概要

- 1.1 Oracle Java CAPSの一般的な略語

- 1.2 移行プロセスの概要

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

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

- 1.2.1.2 JBIプロジェクトの移行

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

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

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

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

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

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

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

- 1.2.4 移行時のJAXBの生成

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

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

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

- 1.2.5.3 システム・プロパティ

- 1.2.5.4 BPEL 2.0コンストラクト

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

- 1.3.1 Springへの変換について

- 1.4 移行の考慮事項

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

- 1.4.2 移行方法の決定

- 1.5 移行ツールの制約

2 Oracle Java CAPS Migration Toolのインストール

- 2.1 インストールについて

- 2.1.1 前提条件

- 2.2 移行ツールのインストール

3 プロジェクトの移行

- 3.1 移行ツール・プロセスの概要

- 3.2 Oracle Java CAPSプロジェクトの移行

- 3.2.1 開始する前に

- 3.2.1.1 JBIプロジェクトの準拠の確認

- 3.2.1.2 ビジネス・プロセスの変更

- 3.2.1.3 ファイル書込み操作を持つプロジェクトの変更

- 3.2.1.4 移行するプロジェクトの再ビルドと再デプロイ

- 3.2.2 移行ロギング・プロパティの設定

- 3.2.3 ウィザードを使用したプロジェクトの移行

- 3.2.4 コマンドラインを使用したプロジェクトの移行

- 3.2.4.1 移行ツールの使用方法

- 3.3 OTDからXSD形式への変換

- 3.4 XSDからJAXB形式への変換

4 移行後のタスク

- 4.1 移行後のプロジェクトをOracle JDeveloperで開く

- 4.2 移行後のJBIプロジェクトの構成

- 4.2.1 移行後のバインディング・コンポーネントの構成

- 4.2.1.1 JMSアダプタの変更

- 4.2.2 サービス要素の追加

- 4.2.3 サービス品質プロパティの構成

- 4.2.4 BPEL構造の確認

- 4.3 移行後のアダプタおよびOTDの構成

- 4.3.1 ファイルまたはJMSのメッセージ・タイプをopaqueとして有効化

- 4.3.2 インバウンドおよびアウトバウンドに同じXSDおよびFCX OTDを持つプロジェクトの構成

- 4.3.3 FCX OTDの構成

- 4.3.4 移行ツールで変換されなかったアダプタの追加

- 4.4 変換後のOracle SOA Suite Springコンポーネントの構成

- 4.4.1 Spring BeanのJavaクラスの変更

- 4.4.2 バイト配列入力から文字列への変換

- 4.4.3 ファイルまたはJMSのアウトバウンド・アダプタのSpring Beanクラスの構成

- 4.4.4 JMSヘッダー・プロパティへのアクセス

- 4.4.5 Javaコラボレーション定義から呼び出されるサブコラボレーションの構成

- 4.5 ビジネス・プロセスの構成

- 4.5.1 ビジネス・プロセスのユーザー・アクティビティの移行

- 4.5.2 マーシャルおよびアンマーシャル・アクティビティ内の相関の初期化の移行

- 4.6 移行後のプロジェクトへのJARファイルの追加

- 4.7 JMSリソースの作成

A Javaコラボレーション定義の変換の例

- A.1 スタンドアロンのJCDを移行した場合のサンプル・コード

- A.2 ビジネス・プロセスから呼び出されるJCDを移行した場合のサンプル・コード

用語集

Oracle® Fusion Middleware

Oracle Java CAPS Migration Toolユーザーズ・ガイド

11g リリース1 (11.1.1.6.0)

B66433-01(原本部品番号:E24884-01)

2011年11月

開発者向けのドキュメントで、既存のOracle Java CAPSリポジトリ・プロジェクトとJavaコラボレーション定義をOracle SOA SuiteプロジェクトとSpringコンポーネントに移行したり、リポジトリ・プロジェクトおよびJBIプロジェクトとBPELビジネス・プロセスをOracle SOA Suite BPELプロジェクトに移行する自動移行ツールの使用方法について説明します。

Oracle Fusion Middleware Oracle Java CAPS Migration Toolユーザーズ・ガイド, 11g リリース1 (11.1.1.6.0)

B66433-01

Copyright (C) 2011, Oracle and/or its affiliates.All rights reserved.

原本著者:  C.Thom

原本協力著者:

原本協力者:  Oracle SOA SuiteおよびOracle Java CAPS開発、製品管理および品質保証チーム

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはX/Open Company, Ltd.によってライセンス提供された登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

『Oracle Fusion Middleware Oracle Java CAPS Migration Toolユーザーズ・ガイド』では、リポジトリ・プロジェクトおよびJBIプロジェクトをOracle Java CAPSからOracle SOA Suiteに移行する方法について説明します。

対象読者

このドキュメントは、Oracle SOA SuiteプロジェクトをOracle SOA Suiteプロジェクトに移行する作業を担当する開発者を対象にしています。

ドキュメントのアクセシビリティについて

オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibilityを参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧のみを行に記述する必要があります。しかし、一部のスクリーン・リーダーは括弧のみの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracleサポートへのアクセス

お客様は、My Oracle Supportから電子サポートにアクセスできます。詳細は、http://www.oracle.com/support/contact.htmlまたはhttp://www.oracle.com/accessibility/support.html（聴覚障害者向け）を参照してください。

関連ドキュメント

詳細は、次に示すオラクルの資料を参照してください。

- Oracle Java CAPS 6.3ドキュメント・ライブラリ(http://download.oracle.com/docs/cd/E21454_01/index.html)

- 『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Oracle Java CAPS Migration Toolの概要

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

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

- 1.1項「Oracle Java CAPSの一般的な略語」

- 1.2項「移行プロセスの概要」

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

- 1.4項「移行の考慮事項」

- 1.5項「移行ツールの制約」

1.1 Oracle Java CAPSの一般的な略語

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

- JCD: Javaコラボレーション定義

- OTD: オブジェクト型定義

- FCX OTD: XMLBean OTD (ファースト・クラスOTDとも呼びます)

- UD OTD: ユーザー定義OTD

- JBI: Java Business Integration

- JAXB: Java Architecture for XML Binding

- JAX-WS: Java API for XML Web Services

- DOM: Document Object Model

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オブジェクトに変換できます。

- XSDをJAXBに変換するには、-xsd2jaxbオプションを使用します。詳細は、3.4項「XSDからJAXB形式への変換」を参照してください。

- OTDをXSDに変換するには、-otd2xsdオプションを使用します。詳細は、3.3項「OTDからXSD形式への変換」を参照してください。

デフォルトでは、移行ツールは、元の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 生成された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の型を持っている必要があることを意味します。それは、complextypeやsimpletypeにはできません。移行する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 SpringコンテキストXMLファイル」の説明

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

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

「図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 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に移行する最高の候補は、次の基準を満たすものです。

- Javaコードが100行よりも長く、いくつかのマッピングが含まれていること。

- マッピングが複雑であること。

- プロジェクト内のアダプタに、ファイル、JMSまたはWebサービスが含まれていること。

- プロジェクトに、ユーザー定義OTDまたは複雑なメッセージOTD (X12、HL7など)が含まれていること。

- プロジェクトで、複数のマッピング内でインラインで呼び出されるカスタムJARファイルを使用していること。

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リポジトリ・プロジェクトの移行

- メッセージ・タイプがopaqueとして定義されていない場合は、入力メッセージの内容は要素で囲まれている必要があります。ファイル・メッセージとJMSメッセージのいずれの場合も、opaqueとして定義されていない場合は、このラッパー・ノードが必要です。メッセージ・タイプがopaqueとして定義されていない場合、Oracle SOA SuiteではXMLメッセージのみが処理されます。
詳細は、4.3.1項「ファイルまたはJMSのメッセージ・タイプをopaqueとして有効化」を参照してください。

- 一部のリポジトリ製品は、現時点では、移行ツールでサポートされていません。これには、Oracle Java CAPS Master Index、Oracle Java CAPS Data Integrator、Oracle Java CAPS B2B Suite、Oracle Java CAPS BAMなどのコンポーネントがあります。
ファイル、JMSおよびWebサービス以外のアダプタは、プレースホルダとして移行され、後で対応するOracle SOA Suiteアダプタに置換できます。

- 一部のJBI製品は、現時点では、移行ツールでサポートされていません(Oracle Java CAPS BPELサービス・エンジン以外のサービス・エンジンなど)。
ファイル、HTTPおよびJMS以外のバインディング・コンポーネントは、プレースホルダとして移行され、後で対応するOracle SOA Suiteアダプタに置換できます。

- 複数のreturn文を持つメソッドが存在する場合は、移行後のJCDコードでSpring Beanを変更する必要があります。例としては、メソッド内に条件付きの戻り値を持たせる場合です。

- フローのブランチでcreateInstanceをyesに設定した受信操作は、Oracle SOA Suiteでは許可されないため、ビルド・プロセス時に失敗します。

- プロジェクトに複数のビジネス・プロセスが含まれる場合は、ターゲット・ネームスペースとビジネス・プロセス名は同じにできません。

- Oracle SOA Suiteでは、開始アクティビティはメッセージ・アクティビティであることを想定しています。ビジネス・プロセス・インスタンスを作成する開始アクティビティの前に、それ以外のアクティビティは許可されません。

- スタンドアロンのJCDでは、インバウンドのWebサービス・アダプタ、インバウンドおよびアウトバウンドのファイル・アダプタ、およびインバウンドおよびアウトバウンドのJMSアダプタのみがサポートされます。

- 移行ツールでは、ビジネス・プロセスのユーザー・アクティビティ(Worklist Manager)は移行できません。ビジネス・プロセスには、Oracle Java CAPS固有のBPELコンストラクトが含まれるため、それらを手動でOracle SOA Suiteのワークフローに置換する必要があります。

- マーシャルおよびアンマーシャルのInvokeアクティビティにビジネス・プロセスの相関の初期化が含まれている場合、マーシャルおよびアンマーシャル・アクティビティは移行後のビジネス・プロセスでJava Embeddingアクティビティに変換されるため、これは無視されます。移行後のプロジェクトで、手動による変更が必要です。

- リポジトリ・プロジェクトのバージョン・コントロールは移行されません。

- 割当てアクティビティ内の連結するオプション・ノードは、式から連結された1つ以上のノードが見つからない場合やそのデータが存在しない場合であっても、移行後のプロジェクトに引き継がれます。これは、次に示すように、Oracle SOA SuiteではignoreMissingFromDataプロパティがyesに設定されるためです。

<assign name="SetdataNascimento">
<copy ignoreMissingFromData="yes">
<from>concat(concat(concat(concat(
$DateunmarshalFromStringOutput1.Date/YEAR, '-'),
$DateunmarshalFromStringOutput1.Date/Month), '-'),
$DateunmarshalFromStringOutput1.Date/Day)
</from>
<to>$ICObterNomeDnNatMorValPortTypeICObterNomeDnNatMorValInput.
ICObterNomeDnNatMorValResponse/qual3:dadosPesquisa/qual3:dataNascimento
</to>
</copy>

注意:
前述のコードは、見やすくするために行を折り返しています。

2 Oracle Java CAPS Migration Toolのインストール

この章では、Oracle Java CAPS Migration Toolおよび関連するJARファイルのインストール方法と、移行のためのOracle Java CAPS環境の構成方法について説明します。

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

- 2.1項「インストールについて」

- 2.2項「移行ツールのインストール」

2.1 インストールについて

移行ツールはZIPファイルで提供され、ツールをインストールするには、このファイルをダウンロードして解凍するだけです。インストールに含まれるファイルは次のとおりです。

- MigrationTool.jar: このユーティリティは、Oracle Java CAPSプロジェクトをOracle SOA Suiteプロジェクトに変換します。また、OTD形式をXSDに変換して、XSD形式をJAXBオブジェクトに変換する際にも使用します。

- logging.properties: このファイルは、移行プロセスのロギング・レベルを設定します。

- oracle.migrationtool.jcaps.libraries: このフォルダには、移行ツールに必要なすべてのライブラリが含まれています。

移行ツールを使用する前に、追加のJARファイルをインストールして、Oracle Java CAPS IDEを構成する必要があります。両方のプロセスについて、この章で説明します。

2.1.1 前提条件

移行ツールを実行するには、次のものがインストール済で、移行ツールの場所からそれらにアクセス可能である必要があります。

- Oracle Fusion Middleware (特に、oracle_commonディレクトリ)

- Oracle SOA Suite

また、プロジェクトによっては移行の前に再ビルドして再デプロイする必要があるため、Oracle Java CAPS 6.xまたは5.xにアクセス可能である必要があります。

2.2 移行ツールのインストール

移行ツールのインストールでは、使用しているコンピュータ上の場所へのツールの解凍、追加のJARファイルのインストール、およびOracle Java CAPS環境の構成を行います。

移行ツールをインストールする手順は、次のとおりです。

1. ツールを保存するコンピュータ上のフォルダにMigrationTool.zipをダウンロードします。

2. ZIPファイルを解凍します。

サードパーティのJARファイルをインストールする手順は、次のとおりです。

- 移行ツールのインストールのoracle.migrationtool.jcaps.libraries/libフォルダに、次の3つのファイルをダウンロードします。

- Swing Application Framework: http://download.java.net/maven/2/org/jdesktop/appframework/1.0.3/appframework-1.0.3.jar

- Swing Worker API: http://download.java.net/maven/2/org/jdesktop/swing-worker/1.1/swing-worker-1.1.jar

- Java Parser: https://docs.google.com/uc?id=0B6K9IqkgGbcgZTg3ZWMzMzYtNDQ4Zi00NzBmLWI1OTUtOTM2MTViMjYyMmEw&export=download&hl=en_US

注意:
このリンクを使用するには、Googleアカウントへのログインが必要です。

Oracle Java CAPS環境を設定する手順は、次のとおりです。

Oracle Java CAPS IDEに新しいフラグを追加すると、生成されるEARファイルですべてのJCDのJavaコードが保持されるようになり、これは移行を正常に完了するために必要です。

1. Javaコラボレーション定義(JCD)が含まれるOracle Java CAPS 6.xリポジトリ・プロジェクトを移行する場合は、次の手順を実行します。

1. Oracle Java CAPSホーム・ディレクトリ内の/netbeans/etcにナビゲートします。

2. テキスト・エディタでnetbeans.confを開きます。

3. netbeans_default_optionsプロパティの最後(終了の二重引用符の前)に、次のフラグを追加します。

-J-Drun.mode=debug

4. このファイルを保存して閉じます。

2. Oracle Java CAPS 5.xプロジェクトを移行する場合は、次の手順を実行します。

1. Oracle Java CAPSホーム・ディレクトリ内の/edesigner/binにナビゲートします。

2. テキスト・エディタでruned.batを開きます。
ファイルをダブルクリックして開かないでください。ファイルをダブルクリックすると、Enterprise Designerが起動します。

3. netbeans_default_optionsプロパティの最後(終了の二重引用符の前)に、次のフラグを追加します。

"-J-Drun.mode=debug"

4. このファイルを保存して閉じます。

3 プロジェクトの移行

この章では、提供されている移行ツールを使用して、Oracle Java CAPSからOracle SOA Suiteへの移行を実行する方法の手順を説明します。

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

- 3.1項「移行ツール・プロセスの概要」

- 3.2項「Oracle Java CAPSプロジェクトの移行」

- 3.3項「OTDからXSD形式への変換」

- 3.4項「XSDからJAXB形式への変換」

3.1 移行ツール・プロセスの概要

移行ツールは、ウィザード・モードまたはコマンドライン・モードで実行できます。ウィザード・モードでは、移行プロセスの視認性が向上し、移行されるOracle Java CAPSのコンポーネントおよびファイル内容と、生成されるOracle SOA Suiteのファイルおよび内容を確認できます。移行ツールでは、Oracle SOA Suiteプロジェクトを生成する方法を決定するために、Oracle Java CAPSプロジェクトから生成されたプロジェクトEARまたはZIPファイルを使用します。

移行ツールの出力には、必要なプロジェクト・コンポーネントと、Oracle JDeveloperプロジェクト・ファイル(JPRファイル)が含まれます。これらのアーティファクトには、composite.xmlファイルが含まれ、さらにSpringコンポーネント・ファイル、BPELビジネス・プロセス・ファイル、WSDLファイル、スキーマ定義、JARファイル、Javaクラスなどが含まれることもあります。

プロジェクトによっては、移行ツールの出力を手動で変更する必要があります(たとえば、ファイルまたはJMS以外のアウトバウンド・アダプタを持つプロジェクトでは、生成されたプレースホルダをOracle SOA Suiteアダプタに置換する必要があります)。移行ツールの出力に対して必要になる可能性がある変更については、第4章「移行後のタスク」で説明します。

3.2 Oracle Java CAPSプロジェクトの移行

この項では、移行ツールのウィザード・モードとコマンドライン・モードの両方のモードでの実行について説明します。移行ツールを実行する前に、必ず、3.2.1項「開始する前に」に記載されている手順を完了してください。

3.2.1 開始する前に

移行するOracle Java CAPSファイルを正しく構成して、インストール手順に記載されている新しいデバッグ・オプションで再ビルドして再デプロイする必要があります。移行ツールを実行する前に、次の手順を実行してください。最初の2つの手順は、移行するプロジェクトのタイプに応じたオプションですが、最後の手順は、移行が正常に処理されるために実行する必要があります。

- JBIプロジェクトの準拠の確認

- ビジネス・プロセスの変更

- ファイル書込み操作を持つプロジェクトの変更

- 移行するプロジェクトの再ビルドと再デプロイ

3.2.1.1 JBIプロジェクトの準拠の確認

ほとんどのJBIのBPELプロジェクトは正常に移行できますが、プロジェクト・コンポーネントがOracle SOA Suiteでサポートされている標準に準拠していることを確認する必要があります。Oracle Java CAPS JBIとOracle SOA Suiteの違い、および必要になる可能性がある変更の詳細は、1.2.5項「JBIプロジェクトの移行のサポート」を参照してください。

3.2.1.2 ビジネス・プロセスの変更

複数のビジネス・プロセスが含まれるプロジェクトを移行する場合、移行が正常に処理されるためには、ターゲット・ネームスペースとビジネス・プロセス名は同じにできません。複数のビジネス・プロセスで同じネームスペースを使用している場合は、移行前にいずれかの名前を変更してください。

Oracle SOA Suiteでは、開始アクティビティはメッセージ・アクティビティである必要がありますが、Oracle Java CAPSでは、割当てアクティビティを最初のアクティビティにすることができます。ビジネス・プロセスの開始アクティビティがメッセージ・アクティビティでないプロジェクトがある場合は、移行を開始する前にビジネス・プロセスを変更してください。

割当てアクティビティ内の接頭辞が、異なるネームスペースの定義で重複する場合は、このあいまいさを解決して、マッピングに正しい接頭辞を割り当てる必要があります。

3.2.1.3 ファイル書込み操作を持つプロジェクトの変更

古いOracle Java CAPSプロジェクトでは、出力コンテナなしのファイル書込み操作を持っている場合があります。これらのプロジェクトは、Oracle SOA Suiteでビルドされません。この状態のプロジェクトが存在する場合は、移行を実行する前に、出力変数を設定してください。

3.2.1.4 移行するプロジェクトの再ビルドと再デプロイ

リポジトリ・プロジェクトの移行を実行するには、「Oracle Java CAPS環境を設定する手順」で説明されているように、更新したデバッグ・フラグを使用して、プロジェクトを再ビルドして再デプロイする必要があります。次に、移行ツールの場所からアクセス可能なプロジェクトから、生成されるEARファイルを作成する必要があります。JBIプロジェクトの場合は、生成されたコンポジット・アプリケーション・サービス・アセンブリ(CASA)のZIPファイルを使用できるようにする必要があります。リポジトリ・プロジェクトとJBIプロジェクトのどちらも、更新したフラグで再ビルドして再デプロイする必要があります。

3.2.2 移行ロギング・プロパティの設定

移行ログ・ファイルに記録され、移行ツールを実行したコンソールに出力される移行処理情報の情報量を構成できます。ロギング・レベルは、グローバル、ハンドラ単位および移行ツール自体の3つのレベルで設定します。ハンドラ設定は、グローバル設定よりも優先されます。

次のログ・レベルを指定できます(提供される情報が少ないものから多いものの順に記載しています)。

- SEVERE (障害メッセージのみ)

- WARNING

- INFO

- CONFIG

- FINE

- FINER

- FINEST (最も詳細なロギング)

移行ロギング・プロパティを構成する手順は、次のとおりです。

1. Oracle Java CAPS Migration Toolをインストールした場所にナビゲートします。

2. テキスト・エディタでlogging.propertiesを開きます。

3. 次の表に記載されている任意のプロパティを変更し、ファイルを保存して閉じます。

プロパティ

説明

handlers

移行に使用するログ・ハンドラ・クラスのカンマ区切りリスト。デフォルトは、java.util.logging.FileHandler, java.util.logging.ConsoleHandlerです。この場合は、移行ツール・フォルダ内のログ・ファイルと、移行ツールを実行したコンソールの両方にログ・メッセージが送信されます。

level (global)

すべてのロガーにおけるログ・メッセージの詳細度のインジケータ。この値よりも、このファイルの後の方で各ロガーに指定したログ・レベルの方が優先されます。デフォルトでは、コメント・アウトされ、使用されません。

FileHandlerのプロパティ

pattern

各ログ・ファイルに付けられる名前を示すパターン。デフォルト値はmigrationtool_%u.logで、この場合、ログ・ファイル名はmigrationtool##.logで作成され、##は各ログ・ファイルごとに増分される数値を示します。

level

ログ・ファイルに記録されるイベントのログ・メッセージの詳細度のインジケータ。

limit

各ファイルに記録されるログの最大バイト数。この値が0 (ゼロ)の場合は無制限です。

count

循環を行う出力ファイルの数。

formatter

ログ・ファイル内のメッセージの書式設定に使用するJavaフォーマッタ・クラスの名前。デフォルトは、java.util.logging.SimpleFormatterです。

ConsoleHandlerのプロパティ

level

コンソールに表示されるイベントのログ・メッセージの詳細度のインジケータ。

formatter

コンソール上のメッセージの書式設定に使用するJavaフォーマッタ・クラスの名前。デフォルトは、java.util.logging.SimpleFormatterです。

移行ツールのプロパティ

level

移行ツール全般のログ・メッセージの詳細度のインジケータ。

3.2.3 ウィザードを使用したプロジェクトの移行

移行ツール・ウィザードでは、グラフィカルな表示で、元のOracle Java CAPSプロジェクトのプロジェクト・コンポーネントと、移行ツールによって生成されるOracle SOA Suiteプロジェクトのコンポーネントが表示されます。

ウィザードを使用してプロジェクトを移行する手順は、次のとおりです。

1. コマンドラインから、次のコマンドを実行します。

java -jar MigrationTool.jar -soahome middleware_home -wizard

注意:
移行するプロジェクトに、ビジネス・プロセスで呼び出されるJCD、またはWebサービスとして公開されているJCDが含まれている場合は、コマンドの最後に-usejaxbオプションを追加してください。middleware_homeディレクトリは、Oracle Fusion Middlewareインストール先のoracle_commonへのパスです。これらのオプションの詳細は、3.2.4.1項「移行ツールの使用方法」を参照してください。

2. 移行ウィザードで、次の情報を入力します。

- ソース・フォルダ: 移行するOracle Java CAPSのEAR (リポジトリ・プロジェクト)またはZIP (JBIプロジェクト)ファイルのパスとファイル名。

- プロジェクト名: ここには、EARファイルまたはコンポジット・アプリケーションの名前が移入されます。

- 場所: 移行ツールによって、生成されたOracle SOA Suiteプロジェクトが格納されるディレクトリ。指定しない場合は、現在の作業ディレクトリが使用されます。

- プロジェクト・フォルダ: ここには、移行後のOracle SOA Suiteプロジェクトが格納される場所のフルパスが自動的に移入されます。

図3-1 Oracle Java CAPS Migration Tool - ソースの選択ページ

「図3-1 Oracle Java CAPS Migration Tool - ソースの選択ページ」の説明

3. 「次へ」をクリックします。
移行ツールにより、プロジェクトのZIPまたはEARファイル全体が解析されて、必要なアーティファクトが抽出され、プロジェクトにビジネス・プロセスが存在する場合はウィザードにアーティファクトが表示されます。

図3-2 Oracle Java CAPS Migration Tool - ソースのコンポジット・アプリケーション・ページ

「図3-2 Oracle Java CAPS Migration Tool - ソースのコンポジット・アプリケーション・ページ」の説明

4. 次のいずれかを実行します。

1. プロジェクトにビジネス・プロセスが存在しない場合は、手順8に進みます。

2. プロジェクトにビジネス・プロセスが存在する場合は、名前をクリックして、プロジェクト・エクスプローラの右側のキャンバスでアーティファクトの内容を確認します。

5. 「次へ」をクリックします。
ウィザードに解析結果が表示され、プロジェクトのサービス、参照、接続およびプロパティが表示されます(もう一度、ビジネス・プロセスのもののみが表示されます)。

図3-3 Oracle Java CAPS MIgration Tool - エンドポイントおよび接続

「図3-3 Oracle Java CAPS MIgration Tool - エンドポイントおよび接続」の説明

6. 公開または参照されている任意のエンドポイントをクリックすると、関連付けられているパートナ・リンクが表示されます。接続をクリックすると、接続されているコンポーネントの2つのパートナ・リンクが強調表示されます(これは、Oracle SOA Suiteコンポジット内のワイヤを表します)。

7. 「次へ」をクリックします。
移行ツールによってOracle SOA Suiteファイルが生成され、確認のために表示されます。コンソール・ウィンドウで処理メッセージとステータスを確認できます。エラーまたは例外が発生した場合は、移行プロセスが中止され、コンソールにエラーの原因が表示されます。

8. レビュー・ページで、移行されたアーティファクトの内容を確認し、出力プロジェクトの場所でファイルを確認します。

図3-4 Oracle Java CAPS MIgration Tool - レビュー・ページ

「図3-4 Oracle Java CAPS MIgration Tool - レビュー・ページ」の説明

9. 準備ができたら、次へをクリックします。

10. 終了ページで、「終了」をクリックします。
移行プロセスが完了すると、ウィザードはソースの選択ページに戻り、必要な場合は別のプロジェクトの移行を開始できます。移行ツールのディレクトリ内のログ・ファイルを確認して、移行プロセスを確認できます。

11. 一部のコンポーネントは、手動で変更したり手動で移行する必要があります。詳細および手順は、次を参照してください。

- 第3章「XSDからJAXB形式への変換」

- 第3章「OTDからXSD形式への変換」

- 第4章「移行後のタスク」

3.2.4 コマンドラインを使用したプロジェクトの移行

ウィザード・モードではなく、コマンドライン・モードを使用してOracle Java CAPSプロジェクトを移行する場合は、必要なすべての情報をコマンドで指定し、移行されるコンポーネントおよびファイル、または生成されるコンポーネントおよびファイルのプレビューは表示されません。コンソールに、移行の処理ステータスと発生した警告またはエラーが表示されます。

3.2.4.1 移行ツールの使用方法

構文

java -jar MigrationTool.jar <-soahome parent_directory_of_oracle_common>
[-archive path_of_input_file] [-projectname output_project]
[-output output_folder] [-wizard] [-usejaxb]

表3-1 コマンドラインのオプションおよびフラグ

オプション/フラグ

説明

-soahome

Oracle Fusion Middlewareのホーム・ディレクトリのパス。これは、oracle_commonディレクトリの親ディレクトリで、JAX-WSインタフェースを生成するために必要です。たとえば、C:\Oracle\Middlewareです。

このオプションは、コマンドライン・モードとウィザード・モードの両方で必須です。

-archive

移行するOracle Java CAPSのEARまたはZIPファイルのパスとファイル名。

-projectname

移行ツールによって生成されるOracle SOA Suiteプロジェクトの名前。

-output

移行ツールによって、生成されたOracle SOA Suiteプロジェクトが格納されるディレクトリ。指定しない場合は、現在の作業ディレクトリが使用されます。

-wizard

移行ツールをウィザード・モードで開始するフラグで、グラフィカルなインタフェースを起動し、そのインタフェースで移行オプションを指定してプロジェクト・コンポーネントを確認できます。このモードでコマンドを実行する場合、-soahome以外の他のすべてのオプションはオプションです。他のオプションを指定した場合、それらの値は移行ウィザードに自動的に移入されます。

-usejaxb

JAXBオブジェクトを直接使用するように元のJCDインタフェースを変更し、移行後のコードでJAXBオブジェクトとOracle Java CAPSのOTDオブジェクト間のコピーが行われないようにするフラグ。

このフラグは、BPELビジネス・プロセスで呼び出されるJCD、およびWebサービスとして公開されているスタンドアロンのJCDを持つプロジェクトを移行する場合にのみ有効です。JCDでファースト・クラス(FCX) OTDが使用されていて、FCX OTD (XMLBeans)がJAXBオブジェクトに置換される場合、このオプションは自動的に有効になります。JCD内に入力および出力としてHL7 OTDを持つプロジェクトを移行する場合は、このオプションを使用しないでください。

注意: -usejaxbオプションを使用して移行ツールを実行した場合、生成されたJAXBオブジェクトでは一部のOTDヘルパー・メソッドを使用できないため、移行後のOracle SOA SuiteプロジェクトでJCDのJavaコードのコンパイルに失敗する可能性があります。XSDフィールドのgetterおよびsetterメソッドのみ使用できます。OTDに、OTDフィールドのgetterおよびsetterメソッド以外の追加ヘルパー・メソッドが含まれる場合は、移行ツールの実行時にこのオプションを使用しないでください。

例3-1 コマンドライン構文

java -jar MigrationTool.jar -soahome C:\Oracle\Middleware\ -archive
C:\javacaps\migration_projects\JCDOTD_CAPSProject_20110930.ear -projectname
PurchaseOrder -output C:\SOA_Suite\mywork -usejaxb

3.3 OTDからXSD形式への変換

移行ツールでは、移行プロセス中にほとんどのOTDが変換されます。自動的に変換されないOTDのために、移行ツールでは-otd2xsdのオプションが用意されており、このオプションでは指定されたOTDクラスに基づいてXSDファイルが生成されます。生成されたXSDファイルは、移行後のBPELビジネス・プロセスで使用したり、-xsd2jaxbオプションを使用してJAXBオブジェクトを生成するために使用できます(3.4項「XSDからJAXB形式への変換」を参照してください)。この方法は、OTDが、対応するスキーマ定義を持っていない場合に使用します。

次のコマンドを実行すると、指定したOTDのXSDファイルが生成されます。XSDは、-otdclasspathオプションで指定したJARファイルで使用できます。

java -jar MigrationTool.jar <-soahome parent_directory_of_oracle_common>
<-otd2xsd> <-otdclass OTD class name to search in the supplied jar files>
<-otdclasspath comma separated list of OTD and dependent jar files>

表3-2 コマンドラインのオプションおよびフラグ

オプション/フラグ

説明

-soahome

Oracle Fusion Middlewareのホーム・ディレクトリのパス。これは、oracle_commonディレクトリの親ディレクトリで、JAX-WSインタフェースを生成するために必要です。たとえば、C:\Oracle\Middlewareです。

-otd2xsd

移行ツールをOTDからXSDへの変換モードで実行するインジケータ。

-otdclass

XSDに変換するOTDのクラス名。

-otdclasspath

OTDおよび依存するJARファイルの絶対パスとファイル名のカンマ区切りリスト。

例3-2 OTDからXSDへの変換

java -jar MigrationTool.jar -soahome C:\Oracle\Middleware\ -otd2xsd -otdclass
xsd.xsdICP_ICPOutput.ICPOutput -otdclasspath
C:/migration_projects/xsdICP_ICPOutput.jar,
C:/migration_projects/xsdICP_ICPOutput2.jar

前述のテキストは見やすくするために行を折り返していますが、コマンド全体は、(JARファイル名の間にスペースを入れずに)1行で入力してください。OTDからXSDへの変換を実行した後は、XSDをJAXBオブジェクトに変換するか(3.4項「XSDからJAXB形式への変換」を参照)、Oracle JDeveloperでXSDファイルを移行後のプロジェクトに追加できます。

3.4 XSDからJAXB形式への変換

移行ツールを使用して変換するプロジェクトが、他のOTDとして使用されるFCX OTDを持つJavaコラボレーション定義を使用している場合、Oracle Java CAPSで生成されたFCX OTDはOracle SOA Suiteと互換性がないため、移行後のプロジェクトは実行時に失敗します。もう一度、移行ツールをXSDからJAXBへの変換モードで実行して、FCX OTDをJAXBオブジェクトに変換する必要があります。

次のコマンドを実行すると、既存のFCX OTDのXMLスキーマを使用してJAXBオブジェクトが生成されます。

java -jar MigrationTool.jar <-soahome parent_directory_of_oracle_common>
<-xsd2jaxb> <-jaxboutput JAXB output folder> <-schema XSD schema location>
[-jaxbpackage package for generated JAXB objects]

表3-3 コマンドラインのオプションおよびフラグ

オプション/フラグ

説明

-soahome

Oracle Fusion Middlewareのホーム・ディレクトリのパス。これは、oracle_commonディレクトリの親ディレクトリで、JAX-WSインタフェースを生成するために必要です。たとえば、C:\Oracle\Middlewareです。

-xsd2jaxb

移行ツールをXSDからJAXBへの変換モードで実行するインジケータ。

-jaxboutput

生成されたJAXBオブジェクトを格納する場所の絶対パス。

-schema

変換に使用するXSDファイルの絶対パスとファイル名。

-jaxbpackage

生成されるJAXBオブジェクトのJavaパッケージ。このパラメータは、オプションです。

例3-3 FCX OTDからJAXBへの変換

java -jar MigrationTool.jar -soahome C:\Oracle\Middleware\ -xsd2jaxb -jaxboutput
C:\javacaps\migration_projects\FCX_JAXB -schema
C:\javacaps\migration_projects\JavaCAPS_FCX.xsd -jaxbpackage
com.oracle.caps.conversion

前述のテキストは、見やすくするために行を折り返しています。XSDからJAXBへの変換を実行した後は、移行後のOracle SOA SuiteプロジェクトにJAXBオブジェクトを追加し、FCX OTDのかわりにJAXBオブジェクトを使用するように移行後のJCDコードが含まれるSpringコンポーネントを変更する必要があります。

4 移行後のタスク

この章では、Oracle Java CAPSからOracle SOA Suiteに移行したプロジェクトに行う必要がある更新の手順について説明します。移行ツールでプロジェクトを変換した後は、Oracle JDeveloperでプロジェクトを開いて、生成されたコンポーネントの一部を変更し、場合によっては新しいコンポーネントを追加する必要があります。その後に、それらのプロジェクトをWebLogic Serverにデプロイできます。

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

- 4.1項「移行後のプロジェクトをOracle JDeveloperで開く」

- 4.2項「移行後のJBIプロジェクトの構成」

- 4.3項「移行後のアダプタおよびOTDの構成」

- 4.4項「変換後のOracle SOA Suite Springコンポーネントの構成」

- 4.5項「ビジネス・プロセスの構成」

- 4.6項「移行後のプロジェクトへのJARファイルの追加」

4.1 移行後のプロジェクトをOracle JDeveloperで開く

Oracle Java CAPS Migration Toolでプロジェクトの移行を完了した後は、生成されたOracle SOA SuiteファイルをOracle JDeveloperで開いて、プロジェクトを確認し、場合によってはプロジェクト・コンポーネントを変更または追加する必要があります。

移行後のプロジェクトをOracle JDeveloperで開く手順は、次のとおりです。

1. Oracle JDeveloperを起動します。
Oracle JDeveloperを起動するには、jdeveloper_home/jdev/binにナビゲートして、jdev実行可能ファイルを実行します。

2. Oracle JDeveloperのメイン・メニューで、「ファイル」をクリックし、「開く」を選択します。

3. 表示されたダイアログで、移行後のプロジェクト・ファイルが存在するフォルダを参照して、プロジェクト・ファイルを選択します。

ヒント:
これは、JPRの拡張子を持つファイルです。

4. ダイアログの「開く」をクリックします。
「プロジェクトを収容するアプリケーションの作成」ダイアログが表示されます。

5. ダイアログで、アプリケーションの名前を入力し、「OK」をクリックします。
左側のアプリケーション・ナビゲーション・パネルに、プロジェクト・ファイルが表示されます。

6. ナビゲーション・ツリーで、「SOAコンテンツ」を開いて、composite.xmlファイルを開きます。
図4-1に、Oracle JDeveloperでの変換後のプロジェクトの例を示します。サービス、ビジネス・プロセス、Springコンポーネントおよび複数の参照が含まれています。

図4-1 Oracle JDeveloperでの変換後のOracle Java CAPSプロジェクト

「図4-1 Oracle JDeveloperでの変換後のOracle Java CAPSプロジェクト」の説明

4.2 移行後のJBIプロジェクトの構成

移行ツールを使用してOracle Java CAPS JBIプロジェクトを処理した後は、移行を完了して移行後のプロジェクトの正常なデプロイメントを実行するために、手動での手順が必要な場合があります。次に、移行後のJBIプロジェクトに対して必要になる可能性がある更新をいくつか示します。

- 4.2.1項「移行後のバインディング・コンポーネントの構成」

- 4.2.2項「サービス要素の追加」

- 4.2.3項「サービス品質プロパティの構成」

- 4.2.4項「BPEL構造の確認」

4.2.1 移行後のバインディング・コンポーネントの構成

すべてのOracle Java CAPSバインディング・コンポーネント・プロパティに、Oracle SOA Suiteアダプタ・プロパティとの1対1の対応関係が存在するとはかぎらないため、移行ツールでは、必須のプロパティ・セットのみが移行されます。移行後のプロジェクトをデプロイする前に、コンポジット内の各サービスおよび参照に対して構成ウィザードを実行し、構成を確認または更新する必要があります。

サービスまたは参照を構成する手順は、次のとおりです。

1. 4.1項「移行後のプロジェクトをOracle JDeveloperで開く」の説明に従って、Oracle JDeveloperでプロジェクトとそのコンポジットを開きます。

2. 構成するサービスまたは参照をダブルクリックするか、コンポーネントを右クリックして「編集」を選択します。
そのコンポーネントの構成ウィザードが表示されます。

3. ウィザードの手順に従って、構成を完了します。

4.2.1.1 JMSアダプタの変更

JMSアダプタ構成ウィザードの「JMSプロバイダ」ページで、移行後のプロジェクトに対してデフォルトで選択されるオプションは「サード・パーティ」です。JMSプロバイダがOracle WebLogic JMSまたはOracle Advanced Queueingである場合は、選択をOracle Enterprise Messaging Serviceに変更して、使用するプロバイダを選択する必要があります。

JMSアダプタの場合は、Oracle WebLogic Server管理コンソールで、新しい接続ファクトリと宛先を作成する必要があり、JMSアダプタ構成で指定されている名前と一致するようにします。別の方法として、既存の接続ファクトリと宛先を使用するようにアダプタを再構成することもできます。WebLogic ServerでJMSリソースを作成する手順については、4.7項「JMSリソースの作成」を参照してください。

4.2.2 サービス要素の追加

WSDLは、特定のポート・タイプに対する複数の操作をサポートします。Oracle Java CAPSでは、ポート・タイプに対して1つのサービス定義であってもかまいませんが、Oracle SOA Suiteでは、各操作に対して複数のサービス要素を定義する必要があります。コンポジット内での参照の場合は、複数の操作を持つポート・タイプに対して複数の参照要素は必要ありません。SOAP以外のバインディング・タイプを持つOracle SOA Suiteプロジェクトでは、JCAファイル内のバインディング構成で、複数のエンドポイント・アクティブ化およびエンドポイント相互作用の要素(各操作につき1つずつ)を定義します。

複数の操作を持つポート・タイプが使用されているOracle Java CAPS WSDLドキュメントの場合は、移行ツールによって、移行後のWSDLおよびJCAファイルに複数のエンドポイント・アクティブ化およびエンドポイント相互作用の要素が移入されますが、生成されたcomposite.xmlファイルでは(各操作につき1つずつの)複数のサービス要素は定義されません。

そのようなプロジェクトの場合は、生成されたcomposite.xmlファイルを手動で編集して、複数のサービス要素(各操作につき1つずつ)を作成する必要があります。また、service要素のbinding.jca属性をoperation属性で修飾する必要があります。

例4-1 複数の操作を持つポート・タイプの手動変更

この例の場合、元のJava CAPSバインディング・コンポーネントでは、インバウンド・ファイル・エンドポイントに対して2つの操作を定義していました。次に、移行ツールによって生成されたcomposite.xmlファイル内のservice要素を示します。

<service name="FileInboundService_FileInWSDL_InboundPort"
ui:wsdlLocation="FileInWSDL.wsdl">
<interface.wsdl interface="http://j2ee.netbeans.org/wsdl/FileInOut/
FileInWSDL#wsdl.interface(FileInboundPortType)"/>
<binding.jca
config="FileInboundService_FileInWSDL_InboundPort_file.jca"/>
</service>

必要な変更を行った後のcomposite.xml内のservice要素は次のようになります。

<service name="FileInboundService_FileInWSDL_InboundPort"
ui:wsdlLocation="FileInWSDL.wsdl">
<interface.wsdl interface="http://j2ee.netbeans.org/wsdl/FileInOut/
FileInWSDL#wsdl.interface(FileInboundPortType)"/>
<binding.jca
config="FileInboundService_FileInWSDL_InboundPort_file.jca"
operation="pollMain"/>
</service>
<service name="FileInboundService_FileInWSDL_InboundPort"
ui:wsdlLocation="FileInWSDL.wsdl">
<interface.wsdl interface="http://j2ee.netbeans.org/wsdl/FileInOut/
FileInWSDL#wsdl.interface(FileInboundPortType)"/>
<binding.jca
config="FileInboundService_FileInWSDL_InboundPort_file.jca"
operation="pollBackupDir"/>
</service>

4.2.3 サービス品質プロパティの構成

Oracle Java CAPS JBIプロジェクトの場合は、いくつかのサービス品質プロパティを構成できます。これらのプロパティのすべてがそのままOracle SOA Suiteの機能に引き継がれるわけではありません。制限および再配信のプロパティは、Oracle Java CAPS Migration Toolによって移行されません。制限を使用すると、一貫したパフォーマンスが維持されるように、特定のエンドポイントで処理される同時メッセージの最大数を設定できます。再配信の設定では、初回の配信が失敗した場合のメッセージ配信を処理します。

制限では、BPELプロセス・サービス・エンジン用のメモリー内のリクエスト数を制限できます。これは、入力専用のインバウンド・リクエストに影響を及ぼします。この制限を設定するには、BPELプロセス・サービス・エンジンのMaximumNumberOfInvokeMessagesInCacheプロパティを構成します。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「BPELプロセスのサービス・コンポーネントとエンジンの構成」を参照してください。

BPELプロセス・サービス・エンジンのフォルト・ポリシーを使用して、様々な再配信を構成できます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のフォルト管理フレームワークの使用に関する項を参照してください。

4.2.4 BPEL構造の確認

Oracle Java CAPS JBIでサポートされているBPEL 2.0の一部はOracle SOA Suiteでは使用できないため、次のコンストラクトを使用しているプロジェクトの場合は、変換後のBPELコードを確認する必要があります。これらはOracle SOA Suiteではサポートされませんが、変換後のBPELコードには含まれます。

- 補正ハンドラおよび終了ハンドラ: 元のJava CAPSビジネス・プロセスにこれらが存在する場合、パートナ・リンクは、移行後のBPELではプレースホルダとして含まれます。移行後に、パートナ・リンクを再作成して構成する必要があります。

- 標準フォルト: これには、forcedTermination、repeatedCompensationおよびinvalidReplyがあります。

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

4.3 移行後のアダプタおよびOTDの構成

移行ツールでは、ファイル、JMSおよびWebサービスのアダプタと、メッセージ可能OTDがサポートされていますが、これらのコンポーネントの移行を完了するには、手動による手順が必要です。

JMSアダプタの場合は、Oracle WebLogic Server管理コンソールで、新しい宛先を作成する必要があり、JMSアダプタ構成で指定されている名前と一致するようにします。アダプタ構成ウィザードを使用して、JMSアダプタの構成を確認してください。JMS宛先の作成の詳細は、4.7項「JMSリソースの作成」を参照してください。

次に、移行後のJBIプロジェクトに対して必要になる可能性がある更新をいくつか示します。

- 4.3.1項「ファイルまたはJMSのメッセージ・タイプをopaqueとして有効化」

- 4.3.2項「インバウンドおよびアウトバウンドに同じXSDおよびFCX OTDを持つプロジェクトの構成」

- 4.3.3項「FCX OTDの構成」

- 4.3.4項「移行ツールで変換されなかったアダプタの追加」

また、4.2.1項「移行後のバインディング・コンポーネントの構成」および4.2.1.1項「JMSアダプタの変更」の説明に従って、移行後のアダプタ構成を確認する必要があります。また、4.2.2項「サービス要素の追加」の情報は、Oracle Java CAPSリポジトリ・プロジェクトにも適用されます。

4.3.1 ファイルまたはJMSのメッセージ・タイプをopaqueとして有効化

Oracle Java CAPS Migration Toolでは、すべてのファイルおよびJMSのインバウンドおよびアウトバウンド・アダプタは、Oracle SOA Suiteのファイル・アダプタおよびJMSアダプタを使用するように変換されます。変換後のJMSおよびファイルのアダプタは、それらが対応するWSDLドキュメント内のewaytype:FileTextMessageおよびewaytype:MessageのXMLスキーマ・タイプを使用するように構成されます。WSDLドキュメントはコンポジット内の移行後のアダプタ接続によってインポートされるため、これらのファイルへの変更は、そのアダプタのすべての接続に影響を及ぼします。

定義されるewaytypeは要素タイプであるため、入力メッセージは、例4-2に示すようにXMLタグで囲む必要があります。Oracle SOA Suiteでは、常に、opaqueとして定義されていないファイルおよびJMSのエンドポイントに対する入力メッセージとして、XML要素が必要です。変換後のWSDLドキュメントでは、デフォルトで、メッセージ・パートが文字列の要素として定義されます。

例4-2

<?xml version="1.0" encoding="UTF-8" ?>
<FileTextMessage xmlns=" http://xml.netbeans.org/schema/eWayTypes " >
<<Actual messagse input>>
</FileTextMessage>

WSDLドキュメントを変更して、Oracle SOA Suiteの入力のメッセージ・パートをewaytypeの要素タイプからopaqueの要素タイプに変換できます。メッセージ・パートがopaqueに変換されると、Oracle SOA Suiteアダプタでは、メッセージはBase64エンコード形式の文字列として処理されます。opaqueのメッセージ・タイプを使用すると、Oracle Java CAPSアダプタと同様に、入力および出力メッセージを単純な文字列にすることができます。

メッセージ・タイプをopaqueとして有効にする手順は、次のとおりです。

1. 変換後のプロジェクトをOracle JDeveloperで開き、変更するWSDLドキュメントを開きます。

2. WSDLドキュメント内のmessage要素までスクロールします。
次に、typesおよびmessage要素の抜粋を示します。コメントのセクションで、要素をopaqueとして定義する方法を説明しています。

<types>
<schema targetNamespace="http://xml.netbeans.org/schema/eWayTypes"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="Message" type="string"/>
</schema>
<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/opaque/"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="Message" type="base64Binary"/>
</schema>
</types>

<message name="Message">
<part name="Message" element="ewaytype:Message"/>
<!-- This is an opaque message type, comment out Message part defined above
and uncomment following Message part to use opaque message type
<part name="Message" element="opaque:Message"/>
-->
</message>

3. メッセージ・タイプをopaqueに変更するために、説明コメントの直前の行をコメント・アウトし、<part name="Message" element="opaque:Message"/>のコメント・アウトを外します。

4. 入力の文字列メッセージの使用や、出力メッセージの書込みまたは送信を行う前に、opaqueのメッセージ・タイプの場合は、次の手順を実行します。

1. oracle.soa.common.util.Base64Decoder.decode()メソッドを使用してBase64エンコード形式の入力をデコードして、文字列メッセージを取得します。

2. oracle.soa.common.util.Base64Encoder.encode()メソッドを使用して、出力メッセージをBase64文字列に変換します。

5. opaqueのメッセージ・タイプに対して、次のいずれかを行います。

- OTDUtil.otdOperationメソッドを使用してopaqueのメッセージをマーシャルまたはアンマーシャルする場合は、次に示すように、最後のパラメータをtrueに設定します。

OTDUtil.otdOperation(otdClass,"marshalToString",inputelem,"text",true);

- OTDUtil.otdOperationメソッドを使用しない場合は、ビジネス・プロセスまたはSpring出力でメッセージを使用する前に、エンコード・メソッドまたはデコード・メソッドをコールしてメッセージを変換するロジックを追加する必要があります。

注意:
OTDUtil.otdOperationの最後のパラメータをtrueに設定すると、使用されるOTD操作に応じて、次の処理が実行されます。

- marshalToString操作の後は、出力がBase64に変換されます。

- unmarshalFromString操作の前には、Base64Decoderを使用して入力がデコードされます。

メッセージがBase64にエンコードされずにアウトバウンド・アダプタが呼び出された場合、Oracle SOA Suiteアダプタは予想どおりに動作しない可能性があります。

4.3.2 インバウンドおよびアウトバウンドに同じXSDおよびFCX OTDを持つプロジェクトの構成

インバウンドおよびアウトバウンドに同じXSDおよびFCX OTDを持つJCDが含まれるプロジェクトを移行する場合は、次に示すように、JAX-WSホルダーから値を取得する必要があります。このタイプの実装の場合に生成されるJAX-WSプロキシでは、JAXBオブジェクトをカプセル化するJAX-WSホルダーが作成されます。

public void test(Holder<org.netbeans.xml.schema.synchronous.TypeA> input,
Holder<org.netbeans.xml.schema.synchronous.TypeA> output) throws Throwable {
//output.setTypeA(input.getTypeA()); ? Replace this line
output.value = input.value; ? Retrieve the value from the input Holder to output.

4.3.3 FCX OTDの構成

移行ツールは、ビジネス・プロセスまたはJCD内にFCX OTDを持つリポジトリ・プロジェクトの移行を自動化します。サポートされるモデルは次のとおりです。

- マーシャルおよびアンマーシャル・アクティビティを実行するFCX OTDを持つビジネス・プロセス。

- インバウンドとアウトバウンドの両方としてFCX OTDを持つJCDを呼び出すビジネス・プロセス。

- リクエスト・タイプおよびリプライ・タイプとしてFCX OTDを持ち、Webサービスとして公開されているスタンドアロンのJCD。

前述の場合、移行ツールは、XMLBeanに基づくFCX OTDをJAXBオブジェクトに置換することによって変換します。Oracle Java CAPSプロジェクトのFCX OTD内のマッピングは、JAXBオブジェクト内に保持されます。

Oracle Java CAPSプロジェクトに含まれるJCDのFCX OTDが他のOTDとして使用されている場合は、移行ツールでは、OTDをJAXBオブジェクトに変換しません。他のOTDとして使用されているFCX OTDをJAXBに変換するには、-xsd2jaxbオプションを使用します。

注意:
これらの手順を実行しない場合、変換後のOracle SOA Suiteプロジェクトのビルドおよびデプロイでエラーは発生しませんが、XMLBeanの競合により、実行時にエラーが発生します。

他のOTDとして使用されているFCX OTDを更新する手順は、次のとおりです。

1. 3.2項「Oracle Java CAPSプロジェクトの移行」の説明に従って、プロジェクトのEARファイルに対して移行ツールを実行します。
変換後のJavaコードにナビゲートすると、他のOTDとして使用されているFCX OTDはOTDのまま残され、JAXBに変換されていないことを確認できます。

2. -xsd2jaxbオプションを使用して移行ツールを実行し、FCX OTDをJAXBオブジェクトに変換します。
これは、3.4項「XSDからJAXB形式への変換」で説明しています。

3. 変換後のJCDコード内のFCX OTDを、変換後のJavaコード内の生成されたJAXBオブジェクトに置換します。

4.3.4 移行ツールで変換されなかったアダプタの追加

移行ツールによって、JMS、ファイルおよびWebサービスのOTDのコードは自動的に生成されますが、一部のアダプタは移行ツールで処理されないため、手動でプロジェクトに追加する必要があります。移行ツールにより、ビジネス・プロセス・プロジェクト内にこれらのエンドポイントのプレースホルダが生成され、プレースホルダを対応するOracle SOA Suiteアダプタに置換する必要があります。

注意:
これらの手順は、Oracle JDeveloperで移行後のプロジェクトに未変換のアダプタを追加する際に変更が必要なSpring BeanのJavaクラス・ファイルにもパブリッシュされます。

未変換のアダプタをSpringに追加する手順は、次のとおりです。

1. Oracle JDeveloperで、移行後のOracle SOA Suiteプロジェクトを開き、関連するcomposite.xmlファイルを開きます。

2. コンポーネント・パレットで、移行されなかったアダプタに相当するOracle SOA Suiteアダプタを探し、それをサービスまたは参照のスイムレーンまでドラッグします。

3. 構成ウィザードの手順に従って、アダプタを構成します。

4. 該当するJCD (つまり、元のOracle Java CAPSプロジェクト内の移行されなかったアダプタに接続されていたJCD)に対応して生成されたSpringコンポーネントに、新しいアダプタを接続します。

5. アプリケーション・ナビゲータで、「アプリケーション・ソース」を開き、先ほど接続したSpringコンポーネントのJavaクラスを探します。

Spring BeanのJavaクラスのパッケージおよびクラス名は、Spring XMLファイルのbean要素で確認できます。次に例を示します。

<bean name="Consume_Message_ptt" class="CAPSJCDProj_JMSInFileJMSOut.Collaboration_JMSIn">

6. Javaクラス・ファイルを開いて、前述の新しいアダプタを接続したときに生成されたアダプタ・インタフェース・クラスの型のグローバル・フィールドを追加します。そのフィールドのアクセッサ・メソッドを作成します。

7. 確認を行い、Javaファイルを保存して閉じます。

8. composite.xmlで、Springコンポーネントを右クリックして「編集」を選択します。
Oracle JDeveloperエディタで、Spring XMLファイルが開かれます。

9. Spring XMLファイルで、アダプタとSpringコンポーネントを接続したときに生成されたアダプタ参照を探します。Springクラスのbean要素に、前の手順で作成したグローバル・フィールドを追加し、そのプロパティからアダプタ参照を参照します。

注意:
前の手順で作成したグローバル・アダプタ・フィールドは、実行時に自動的にインスタンス化されます。それは、すでにインスタンス化されているかのように使用できます。

例4-3 移行されなかったアダプタの追加

前述の例として、次の条件でデータベース・アダプタを移行後のプロジェクトに追加します。

- 前述の手順6で、Javaクラスに追加されたグローバル・フィールドは、次の文で特定されます。

private xe.projectname.db.adapter.pcbpel.com.oracle.xmlns.XE_ptt database;

- アダプタをSpringコンポーネントに接続すると、Spring XMLファイルに次の参照が生成されます。

<reference type="xe.projectname.db.adapter.pcbpel.com.oracle.xmlns.XE_ptt"
name="XE" xmlns="http://xmlns.oracle.com/weblogic/weblogic-sca" />

次のプロパティをSpring XMLファイルに追加する必要があります。

<property name="database" ref="XE" />

4.4 変換後のOracle SOA Suite Springコンポーネントの構成

移行ツールによって元のJCDコードから生成されたSpring BeanのJavaクラスでは、アウトバウンドのファイル・アダプタまたはJMSアダプタの変更と、JCDがサブコラボレーションを呼び出している場合はプロジェクトの変更が必要です。次の手順を実行して、Javaクラスを構成します。

- 4.4.1項「Spring BeanのJavaクラスの変更」

- 4.4.2項「バイト配列入力から文字列への変換」

- 4.4.3項「ファイルまたはJMSのアウトバウンド・アダプタのSpring Beanクラスの構成」

- JMSヘッダー・プロパティにアクセスする必要がある場合は、4.4.4項「JMSヘッダー・プロパティへのアクセス」の手順に従います。

- 元のJava CAPSプロジェクトのJCDでサブコラボレーションを呼び出している場合は、4.4.5項「Javaコラボレーション定義から呼び出されるサブコラボレーションの構成」の手順に従います。

4.4.1 Spring BeanのJavaクラスの変更

この項に記載されている特別なケースにプロジェクトが該当するかどうかにかかわらず、元のJCDロジックが含まれる移行後のJavaクラスを確認することは重要です。このクラスに含まれるコメントおよびノートでは、ユーザー固有のJCDを実装する場合に必要になる可能性がある変更についての詳細な情報が提供されます。

Spring BeanのJavaクラスを変更する手順は、次のとおりです。

1. Oracle JDeveloperで、SpringコンポーネントXMLファイルを開きます。

2. Beanクラスの名前が含まれるbean要素を探して、パッケージ名およびクラス名をメモします。要素は次のようなものです。

<bean name="Consume_Message_ptt" class="CAPSJCDProj_JMSInFileJMSOut.Collaboration_JMSIn"

3. Oracle JDeveloperの左側のナビゲーション・パネルで、「アプリケーション・ソース」を開き、bean要素で指定されているパッケージを開きます。

4. bean要素で指定されている名前のJavaクラス・ファイルを開きます。

5. コードを確認し、移行ツールによって生成されたコメントを探します。これらの前には、***Migration Tool***のテキストが付いているため、ファイル内で簡単に見つかります。

6. 変更が完了したら、ファイルを保存して閉じます。

4.4.2 バイト配列入力から文字列への変換

デフォルトでは、Oracle SOA Suiteは、インバウンドのJMSアダプタおよびファイル・アダプタの入力メッセージをByte型のメッセージとして受信します。Oracle Java CAPSプロジェクトでは、入力がString型のメッセージである可能性があります。この場合は、生成されたコード内でバイト配列を文字列に変換する必要があります。

バイト入力配列を文字列に変換する手順は、次のとおりです。

1. 4.4.1項「Spring BeanのJavaクラスの変更」の説明に従って、Spring Beanクラスを探して開きます。

2. Spring BeanのJavaクラス・ファイルで、入力がテキストであるかどうかを確認します。次に例を示します。

public void receive(com.stc.connectors.jms.Message input,
com.stc.connector.appconn.file.FileApplication FileClient_1,
com.stc.connectors.jms.JMS JMS_1)  throws Throwable {
String in = input.getTextMessage();
...

3. 元のJCDがTextMessageをファイル・アダプタの入力として受信している場合は、次に示すように、byte[]をStringに変換します。

String in =  new String(input.getBytesMessage());

4. 元のJCDがTextMessageをJMSアダプタの入力として受信している場合は、次に示すように、consumeMessageメソッドのコードにTextMessageを設定します。

public void consumeMessage(byte opaque[]) {
com.stc.connectors.jms.Message input = new
com.stc.connectors.jms.impl.MessageImpl();
//input.setBytesMessage(opaque);
input.setTextMessage(new String(input.getBytesMessage()));

5. このファイルを保存して閉じます。

4.4.3 ファイルまたはJMSのアウトバウンド・アダプタのSpring Beanクラスの構成

変換後のアウトバウンドのファイル・アダプタおよびJMSアダプタについて、生成されたSpring BeanクラスでOracle Java CAPSのファイルまたはJMSのアウトバウンド参照を使用しているすべてのコードを探し、それをSpring Bean参照を使用したOracle SOA Suiteの呼出しに置換します。

ファイルまたはJMSのアウトバウンド・アダプタのSpring Beanクラスを構成する手順は、次のとおりです。

1. 4.4.1項「Spring BeanのJavaクラスの変更」の説明に従って、Spring Beanクラスを探して開きます。

2. Spring XMLファイルを開いて、Beanプロパティを探します。次に例を示します。

<bean name="Consume_Message_ptt" class="CAPSJCDProj_JMSInFileJMSOut.Collaboration_JMSIn">
<property name="JMSOUT_Collaboration_JMSIn_JMS_1"
ref="JMSOUT_Collaboration_JMSIn_JMS_1"/>
<property name="FILEOUT_Collaboration_JMSIn_FileClient_1"
ref="FILEOUT_Collaboration_JMSIn_FileClient_1"/>
<property name="collabContext" ref="collabCtxBean"/>
....

注意:
前述のコードは、見やすくするために行を折り返しています。

3. アウトバウンド・アダプタのプロパティ名をメモします。

4. Spring BeanのJavaクラス・ファイルで、メソッドのパラメータとして使用されているJava CAPSアウトバウンドのファイル・アダプタおよびJMSアダプタを表すすべての変数を探します。次に例を示します。

public void receive(com.stc.connectors.jms.Message input,
com.stc.connector.appconn.file.FileApplication FileClient_1,
com.stc.connectors.jms.JMS JMS_1)  throws Throwable {
String in = new String(input.getBytesMessage());
System.out.println("@@ Input message " + in);
System.out.println("@@ Sending text message to File " + in);
FileClient_1.setText(in);
FileClient_1.write();
System.out.println("@@ Sending text message to JMS " + in);
JMS_1.sendText(in);
}

5. Java CAPSアダプタ参照を、Spring XMLファイルからのOracle SOA SuiteアダプタのSpring Beanプロパティに置換します。次に例を示します。

String in = new String(input.getBytesMessage());
System.out.println("@@ Input message " + in);
System.out.println("@@ Sending text message to File " + in);
this.FILEOUT_Collaboration_JMSIn_FileClient_1.write(in.getBytes());
System.out.println("@@ Sending text message to JMS " + in);
this.JMSOUT_Collaboration_JMSIn_JMS_1.produceMessage(in.getBytes());

6. このファイルを保存して閉じます。

4.4.4 JMSヘッダー・プロパティへのアクセス

Oracle Java CAPSではJMSメッセージがサポートされており、JMSメッセージはペイロードと一緒にJMSヘッダーをカプセル化します。Oracle SOA Suiteでは、JMSヘッダーとペイロードは1つのオブジェクト内で関連付けられていませんが、コードを定義してヘッダー・プロパティにアクセスできます。

注意:
これは、Oracle SOA Suite 11.1.1.6.0以降でのみサポートされています。

SpringコンポーネントからJMSヘッダー・プロパティにアクセスする手順は、次のとおりです。

1. Oracle JDeveloperで、変更する必要があるSpringコンテキストを開きます。

2. 適切なbean要素のSpringコンテキストに次のプロパティを追加します。

<property name="headerHelper" ref="headerHelperBean"/>

3. エディタで、プロパティを追加したSpring Beanのクラス・ファイルを開き、次の手順を実行します。

1. IHeaderHelperBeanヘルパー・クラスのimport文を追加します。

import oracle.soa.platform.component.spring.beans.IHeaderHelperBean;

2. headerHelperという名前(Springコンテキスト・ファイルで使用されている名前)の変数を宣言します。

private IHeaderHelperBean headerHelper;

3. BeanクラスでheaderHelper変数のgetterおよびsetterメソッドを定義します。
ヘッダー・ヘルパーBeanからgetおよびsetプロパティを使用します。すべてのカスタム・プロパティで、jca.jms.JMSProperty.<PROPERTY_NAME>の接頭辞を使用します。

headerHelper.setHeaderProperty("jca.jms.JMSDestinationName", "queue_TMHException");

4.4.5 Javaコラボレーション定義から呼び出されるサブコラボレーションの構成

Oracle Java CAPSプロジェクトに含まれるメインのJavaコラボレーション定義(JCD)で別のJCD (サブコラボレーションと呼びます)を呼び出している場合、そのモデルは完全には移行されません。JCDのコードは両方とも、生成されるOracle SOA Suiteプロジェクトに変換されるため、手動でプロジェクトを更新して移行を完了できます。

メインJCDのみ、Spring Beanクラスに変換されます。サブコラボレーションには、手動による変換とメインJCDへのワイヤリングが必要です。

サブコラボレーションを移行する手順は、次のとおりです。

1. Javaインタフェースを作成し、サブコラボレーションのメソッド定義(つまり、メインの操作)を追加します。

2. 新しいインタフェースを実装するようにサブコラボレーションを更新します。

3. サブコラボレーションのSpringコンポーネントXMLファイルで、サービス・ノードおよびBeanノードを追加する変更を行います。サービス・ノード・タイプのインタフェースを参照し、Beanノード・クラスのサブコラボレーションのBeanクラスを参照します。

4. メインJCDのSpringコンポーネントXMLファイルで、そのタイプの参照ノードを前の手順で作成したJavaインタフェースとして追加する変更を行います。

5. Beanプロパティを追加し、ref属性にサブコラボレーションの参照ノードを設定します。

6. メインJCDのSpringコンポーネントXMLファイルに追加したBeanプロパティ名と同じ名前のクラス変数を作成します。

7. メインJCDのBeanクラスで、前の手順で定義したBeanプロパティのgetterおよびsetterメソッドを定義します。
前述の変更を行うと、Oracle SOA Suiteプロジェクトのcomposite.xmlファイルで、メインJCDとサブコラボレーションの両方のSpringコンポーネントで新しいエンドポイントが公開されます。

8. 2つのエンドポイントを接続することで、メインJCDのSpringコンポーネントをサブコラボレーションのSpringコンポーネントにワイヤリングします。

9. メインJCDのSpringコンポーネントXMLファイルで、サブコラボレーションを呼び出すJCDへの参照をサブコラボレーションのSpring Bean参照に置換する変更を行います。

10. プロジェクトを保存します。

4.5 ビジネス・プロセスの構成

次に、ビジネス・プロセスを持つリポジトリ・プロジェクトを移行する場合に必要になる可能性がある更新をいくつか示します。

- 4.5.1項「ビジネス・プロセスのユーザー・アクティビティの移行」

- 4.5.2項「マーシャルおよびアンマーシャル・アクティビティ内の相関の初期化の移行」

4.5.1 ビジネス・プロセスのユーザー・アクティビティの移行

移行ツールでは、ユーザー・アクティビティ(Worklist Manager)を持つビジネス・プロセスは移行できません。元のビジネス・プロセスには、Oracle Java CAPS固有のBPELコンストラクトが含まれるため、それらを手動でOracle SOA Suiteのヒューマン・ワークフロー・サービスに置換する必要があります。Oracle SOA Suiteヒューマン・ワークフロー・サービスの使用の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・ワークフローの開始」を参照してください。

4.5.2 マーシャルおよびアンマーシャル・アクティビティ内の相関の初期化の移行

ビジネス・プロセスのマーシャルおよびアンマーシャル(Invoke)アクティビティで相関を初期化している場合、マーシャルおよびアンマーシャル・アクティビティは埋込みJavaアクティビティに置換されるため、移行後のビジネス・プロセスではこの初期化は無視されます。

これを解決するには、この状態のプロジェクトを移行する前に、相関の初期化ロジックをマーシャルおよびアンマーシャル・アクティビティの外に移動します。次の手順を実行して、WSDLドキュメント内の相関プロパティの別名定義を、messagetype属性ではなく、要素の属性に置換します。

- messageType属性をそれに対応する要素の属性に変更します

- propertyAlias定義のpart属性を削除します

次に、必要な変更を行う前と後のコードの例を示します。

<message name="ReserveVehicleIn">
<part name="itinerary" element="ota:TravelItinerary"/>
</message>

<bpws:propertyAlias
propertyName="tres:ItineraryRefId"
messageType="vres:ReserveVehicleIn"
part="itinerary">
<bpws:query>/ota:TravelItinerary/ota:ItineraryRef/ota:UniqueID</bpws:query>
</bpws:propertyAlias>

propertyAlias定義を次のように変更します。

<bpws:propertyAlias
propertyName="tres:ItineraryRefId"
element="ota:TravelItinerary">
<bpws:query>/ota:TravelItinerary/ota:ItineraryRef/ota:UniqueID</bpws:query>
</bpws:propertyAlias>

4.6 移行後のプロジェクトへのJARファイルの追加

JCDが含まれるリポジトリ・プロジェクトでは、Oracle Java CAPS固有の追加JARファイルが使用されている場合があります。これらのファイルは、移行後のOracle SOA Suiteプロジェクトでも必要で、生成されたプロジェクトの/SCA-INF/libディレクトリに追加されます(それらは、ソースのEARファイルにパッケージされているためです)。JARファイルのほとんどは、移行ツールによって自動的にJDeveloperプロジェクト・ファイルに追加されます。プロジェクトに追加する必要がある追加のJARファイルが存在する場合は、Oracle JDeveloperにロードできます。

移行後のプロジェクトにJARファイルを追加する手順は、次のとおりです。

1. 移行後のプロジェクトをOracle JDeveloperで開きます。

2. アプリケーション・ナビゲータで、プロジェクト名を右クリックして、「プロジェクト・プロパティ」を選択します。
プロジェクト・プロパティ・エディタが表示されます。

図4-2 プロジェクト・プロパティ - プロジェクトのソース・パス

「図4-2 プロジェクト・プロパティ - プロジェクトのソース・パス」の説明

3. 左側のナビゲーション・ペインで、「ライブラリとクラスパス」を選択します。
「ライブラリとクラスパス」ページが表示されます。

図4-3 プロジェクト・プロパティ - ライブラリとクラスパス

「図4-3 プロジェクト・プロパティ - ライブラリとクラスパス」の説明

4. 「JAR/ディレクトリの追加」をクリックします。

5. 追加するJARファイルを参照して選択し、「選択」をクリックします。
JARファイルが「クラスパス・エントリ」リストに追加されます。

6. 別のJARファイルをさらに追加する場合は、前の2つの手順を繰り返します。

4.7 JMSリソースの作成

JMSリソースを作成するために必要な手順は、メッセージ・プロバイダとしてOracle WebLogic JMSを使用しているか、サードパーティのメッセージ・プロバイダを使用しているかによって異なります。既存のJMSモジュールおよびサービスを使用したり、必要な場合は新しいものを追加できます。WebLogic以外のJMSサーバーを使用している場合は、外部サーバーを作成して構成し、新しいサーバーに接続ファクトリを追加する必要がある場合があります。

次に、JMSモジュールに宛先を追加する一般的な手順を示します。Oracle WebLogic Server管理コンソールを使用してJMSリソースを作成する方法の詳細と手順については、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』を参照してください。

JMSモジュールに宛先を追加する手順は、次のとおりです。

1. Webブラウザで、Oracle WebLogic Server管理コンソールを起動します。

http://hostname:port_number/console

2. 「サービス」の下の「JMSモジュール」を選択します。
「JMSモジュール」ページが表示されます。

3. 「JMSモジュール」表で、宛先を追加するモジュールを選択します。
選択したモジュールの「設定」ページが表示されます。

4. 「リソースのサマリー」表で、「新規」をクリックします。
「新しいJMSシステム・モジュール・リソースの作成」ページが表示されます。

5. 「キュー」または「トピック」を選択し、「次へ」をクリックします。

6. 「名前」フィールドに、このトピックまたはキューの名前を入力します。これは、Oracle WebLogic Serverで参照される論理名です。

7. 「JNDI名」フィールドに、この宛先を参照するためにアプリケーションで使用するローカルJNDI名を入力します

8. 「次へ」をクリックします。

9. サブデプロイメントを宛先で使用するには、次の手順を実行します。

1. 「サブデプロイメント」フィールドから既存のサブデプロイメントを選択するか、「新しいサブデプロイメントの作成」をクリックして新しいものを作成します。

2. サブデプロイメントのターゲット・サーバーを選択します。

10. 「終了」をクリックします。
新しい宛先が「リソースのサマリー」表に追加されます。

11. これらの変更を有効にするには、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。

12. サーバーを再起動します。

A Javaコラボレーション定義の変換の例

この付録では、スタンドアロンのJavaコラボレーション定義(JCD)がどのようにSOA Suiteに変換されるか、およびビジネス・プロセスから呼び出されるJCDがどのように変換されるかを示すコード・サンプルを紹介します。

この付録のトピックは、次のとおりです。

- A.1項「スタンドアロンのJCDを移行した場合のサンプル・コード」

- A.2項「ビジネス・プロセスから呼び出されるJCDを移行した場合のサンプル・コード」

JCDの移行の詳細は、1.2.2.1項「Javaコラボレーション定義の移行のサポート」を参照してください。

A.1 スタンドアロンのJCDを移行した場合のサンプル・コード

次の例は、ファイル・インバウンド接続、およびファイルとJMS両方のアウトバウンド接続を持つJCDがどのようにSOA SuiteのSpring Beanクラスに変換されるかを示しています。

スタンドアロンのJCDのサンプル・ソースJCDコード

package CAPSProject1;
public class Collaboration_1
{
public com.stc.codegen.logger.Logger logger;
public com.stc.codegen.alerter.Alerter alerter;
public com.stc.codegen.util.CollaborationContext collabContext;
public com.stc.codegen.util.TypeConverter typeConverter;

public void receive( com.stc.connector.appconn.file.FileTextMessage input,
com.stc.connector.appconn.file.FileApplication FileClient_1,
com.stc.connectors.jms.JMS JMS_1,employees.EmployeesOTD Employees_1 )
throws Throwable
{
logger.info( "inside receive." );
com.stc.connectors.jms.Message msg =
JMS_1.createTextMessage( input.getText() );
employees.EMPLOYEES emp = Employees_1.getEMPLOYEES();
logger.info( emp.getLAST_NAME() );
JMS_1.send( msg );
FileClient_1.setText( input.getText() );
FileClient_1.write();
}
}

スタンドアロンのJCDの場合にSOA Suite用に生成されるサンプル出力

package CAPSProject1;

public class Collaboration_1 implements
FILEIN_Collaboration_1_input.capsproject1.file.adapter.pcbpel.com.oracle.xmlns.Read_ptt {

private JMSOUT_Collaboration_1_JMS_
1.capsproject1.jms.adapter.pcbpel.com.oracle.xmlns.Produce_Message_ptt
JMSOUT_Collaboration_1_JMS_1;
private FILEOUT_Collaboration_1_FileClient_
1.capsproject1.file.adapter.pcbpel.com.oracle.xmlns.Write_ptt
FILEOUT_Collaboration_1_FileClient_1;

public void read(byte opaque[]) {
com.stc.connector.appconn.file.FileTextMessage input = new
com.stc.connector.appconn.file.FileTextMessageImpl();
input.setByteArray(opaque);
com.stc.connector.appconn.file.FileApplication FileClient_1 = new
com.stc.connector.appconn.file.FileApplication();
com.stc.connectors.jms.JMS JMS_1 = new com.stc.connectors.jms.JMS();
employees.EmployeesOTD Employees_1 = new employees.EmployeesOTD();
try {
this.receive(input, FileClient_1, JMS_1, Employees_1);
} catch (Throwable exp_0) {
throw new java.lang.RuntimeException(exp_0);
} finally {
}

//JMSOUT_Collaboration_1_JMS_1.produceMessage(opaque);
//FILEOUT_Collaboration_1_FileClient_1.write(opaque);
}

public com.stc.codegen.logger.Logger logger;
public com.stc.codegen.alerter.Alerter alerter;
public com.stc.codegen.util.CollaborationContext collabContext;
public com.stc.codegen.util.TypeConverter typeConverter;
public void receive(com.stc.connector.appconn.file.FileTextMessage input,
com.stc.connector.appconn.file.FileApplication
FileClient_1, com.stc.connectors.jms.JMS JMS_1, employees.EmployeesOTD
Employees_1) throws Throwable {
logger.info("inside receive.");
com.stc.connectors.jms.Message msg = JMS_1.createTextMessage(input.getText());
employees.EMPLOYEES emp = Employees_1.getEMPLOYEES();
logger.info(emp.getLAST_NAME());
JMS_1.send(msg);
FileClient_1.setText(input.getText());
FileClient_1.write();
}

public final void setJMSOUT_Collaboration_1_JMS_1(JMSOUT_Collaboration_1_JMS_
1.capsproject1.jms.adapter.pcbpel.com.oracle.xmlns.Produce_Message_ptt
JMSOUT_Collaboration_1_JMS_1) {
this.JMSOUT_Collaboration_1_JMS_1 = JMSOUT_Collaboration_1_JMS_1;
}

public final JMSOUT_Collaboration_1_JMS_1.capsproject1.jms.adapter.pcbpel.com.
oracle.xmlns.Produce_Message_ptt getJMSOUT_Collaboration_1_JMS_1() {
return this.JMSOUT_Collaboration_1_JMS_1;
}

public final void setFILEOUT_Collaboration_1_FileClient_1(FILEOUT_Collaboration_
1_FileClient_1.capsproject1.file.adapter.pcbpel.com.
oracle.xmlns.Write_ptt FILEOUT_Collaboration_1_FileClient_1) {
this.FILEOUT_Collaboration_1_FileClient_1 = FILEOUT_Collaboration_1_
FileClient_1;
}

public final FILEOUT_Collaboration_1_FileClient_1.capsproject1.file.adapter.
pcbpel.com.oracle.xmlns.Write_ptt getFILEOUT_Collaboration_1_FileClient_1() {
return this.FILEOUT_Collaboration_1_FileClient_1;
}

public final void setLogger(com.stc.codegen.logger.Logger logger) {
this.logger = logger;
}

public final com.stc.codegen.logger.Logger getLogger() {
return this.logger;
}

public final void setAlerter(com.stc.codegen.alerter.Alerter alerter) {
this.alerter = alerter;
}

public final com.stc.codegen.alerter.Alerter getAlerter() {
return this.alerter;
}

public final void setCollabContext(com.stc.codegen.util.CollaborationContext
collabContext) {
this.collabContext = collabContext;
}

public final com.stc.codegen.util.CollaborationContext getCollabContext() {
return this.collabContext;
}

public final void setTypeConverter(com.stc.codegen.util.TypeConverter
typeConverter) {
this.typeConverter = typeConverter;
}

public final com.stc.codegen.util.TypeConverter getTypeConverter() {
return this.typeConverter;
}
}

前述のサンプルを見ると、移行後のJCDクラスではSOA Suiteファイル・アダプタ・インタフェースが実装され、実装されたインタフェース・メソッドpublic void read(byte opaque[])で元のJCDの次のメソッドが置換されていることが確認できます。

public void receive(com.stc.connector.appconn.file.FileTextMessage input,
com.stc.connector.appconn.file.FileApplication FileClient_1,
com.stc.connectors.jms.JMS JMS_1, employees.EmployeesOTD Employees_1)

これは、入力ディレクトリに入力ファイルが存在する場合のトリガー・メソッドです。SOA Suiteファイル・アダプタの構成は、移行ツールによって生成されたJCAファイル内に定義されます。この構成は、Oracle JDeveloperで変更できます。

このインタフェース・メソッドでは、元のJCDのメソッドが呼び出されます。次の2つのクラス・フィールドは、アウトバウンドSOA Suiteファイル・アダプタおよびJMSアダプタを表します。

private JMSOUT_Collaboration_1_JMS_1.capsproject1.jms.adapter.pcbpel.com.oracle.xmlns.Produce_Message_ptt JMSOUT_Collaboration_1_JMS_1;
private FILEOUT_Collaboration_1_FileClient_1.capsproject1.file.adapter.pcbpel.com.oracle.xmlns.Write_ptt FILEOUT_Collaboration_1_FileClient_1;

前述の2つのクラス・フィールドは、元のJCDの次のクラス・フィールドと同様にインスタンス化されませんが、それらのgetterおよびsetterメソッドは生成されます。これにより、SOA Suiteのコンテキスト・インジェクションを使用して、それらをインスタンス化できます。

public com.stc.codegen.logger.Logger logger;
public com.stc.codegen.alerter.Alerter alerter;
public com.stc.codegen.util.CollaborationContext collabContext;
public com.stc.codegen.util.TypeConverter typeConverter;

A.2 ビジネス・プロセスから呼び出されるJCDを移行した場合のサンプル・コード

次の例は、ビジネス・プロセスから呼び出されるJCDがどのようにSOA SuiteのSpring Beanクラスに変換されるかを示しています。

ビジネス・プロセスから呼び出されるJCDのサンプルJCDソース・コード

package Jcd_Bpel_Project;

public class Collaboration_3
{
public com.stc.codegen.logger.Logger logger;
public com.stc.codegen.alerter.Alerter alerter;
public com.stc.codegen.util.CollaborationContext collabContext;
public com.stc.codegen.util.TypeConverter typeConverter;
public void op1_vikas( dtd.otdInputDTD_2111422138.DBemployee input,
dtd.otdOutputDTD_1854792262.DBemployee output )
throws Throwable
{
output.setEmpNo( input.getEmpNo() );
output.setLastname( input.getLastname() );
output.setFirstname( input.getFirstname() );
output.setRate( input.getRate() );
output.setLastDate( input.getLastDate() );
Thread.sleep( 120000 );
}
}

ビジネス・プロセスから呼び出されるJCDの場合に生成されるサンプル出力コード

package Jcd_Bpel_Project;

import oracle.migrationtool.migration.caps.runtime.OTDUtil;

public class Collaboration_3 implements urn_stc_egate_jce_collaboration_1wsdl.ExecutePortType {
private stc.egate.otd.dtd.otdoutputdtd_1854792262.DBemployee output;

public stc.egate.otd.dtd.otdoutputdtd_1854792262.DBemployee
op1Vikas(stc.egate.otd.dtd.otdinputdtd_2111422138.DBemployee DBemployee)
throws urn_stc_egate_jce_collaboration_1wsdl.JavaExceptionMessage {
this.output = new stc.egate.otd.dtd.otdoutputdtd_1854792262.DBemployee();
try {
this.op1_vikas(DBemployee, this.output);
} catch (Throwable exp_0) {
throw new urn_stc_egate_jce_collaboration_1wsdl.JavaExceptionMessage
(exp_0.getMessage(), null, exp_0);
} finally {
}
return this.output;
}

public com.stc.codegen.logger.Logger logger;
public com.stc.codegen.alerter.Alerter alerter;
public com.stc.codegen.util.CollaborationContext collabContext;
public com.stc.codegen.util.TypeConverter typeConverter;

public void op1_vikas(stc.egate.otd.dtd.otdinputdtd_2111422138.DBemployee input,
stc.egate.otd.dtd.otdoutputdtd_1854792262.DBemployee output) throws Throwable {
output.setEmpNo(input.getEmpNo());
output.setLastname(input.getLastname());
output.setFirstname(input.getFirstname());
output.setRate(input.getRate());
output.setLastDate(input.getLastDate());
Thread.sleep(120000);
}

public final void setOutput(stc.egate.otd.dtd.otdoutputdtd_1854792262.DBemployee
output) {
this.output = output;
}

public final stc.egate.otd.dtd.otdoutputdtd_1854792262.DBemployee getOutput() {
return this.output;
}

public final void setLogger(com.stc.codegen.logger.Logger logger) {
this.logger = logger;
}

public final com.stc.codegen.logger.Logger getLogger() {
return this.logger;
}

public final void setAlerter(com.stc.codegen.alerter.Alerter alerter) {
this.alerter = alerter;
}

public final com.stc.codegen.alerter.Alerter getAlerter() {
return this.alerter;
}

public final void setCollabContext(com.stc.codegen.util.CollaborationContext
collabContext) {
this.collabContext = collabContext;
}

public final com.stc.codegen.util.CollaborationContext getCollabContext() {
return this.collabContext;
}

public final void setTypeConverter(com.stc.codegen.util.TypeConverter
typeConverter) {
this.typeConverter = typeConverter;
}

public final com.stc.codegen.util.TypeConverter getTypeConverter() {
return this.typeConverter;
}
}

変換後のクラスではJAXBプロキシ・インタフェースが実装され、JCDの元のOTDクラスはJAXBオブジェクトに置換されます。Springコンテキスト・インジェクション用にgetterおよびsetterが生成されます。

元のJCD内のコメントのほとんどは、移行後のSOA Spring Beanクラス内に保持されます。後ろにJava文が続かないコメントは、移行時に保持されません。コメントが保持されるようにするには、元のJCD内の後ろにJava文が続かないコメントの後にセミコロン(;)を追加します。

用語集

アダプタ(またはeWayアダプタ)

Javaコラボレーション定義またはビジネス・プロセスと、外部接続(メッセージ・サーバー接続(トピックまたはキュー)など)または外部アプリケーションの間のリンク。アダプタはリポジトリ・プロジェクトに固有のもので、Oracle Java CAPS JBIバインディング・コンポーネントおよびOracle SOA Suiteアダプタと同じような機能を提供します。

Document Object Model (DOM)

使用中のプログラミング言語からXML文書内のオブジェクトにアクセスして操作するための、言語に依存しない標準。

Document Type Definition(DTD)

XML文書の構造を定義する宣言のセット(XMLスキーマの原型)。

エンタープライズ・アーカイブ(EAR)

Java CAPSリポジトリ・モジュールを、アプリケーション・サーバーにデプロイ可能な単一のアーカイブにパッケージ化するためのファイル形式。

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

XMLBeanベースのオブジェクト型定義(OTD)。

Java Business Integration (JBI)

サービス指向アーキテクチャ(SOA)を実装するための仕様で、これにはWebサービス、サービス・プロデューサおよびコンシューマのコンテナ、接続性を定義するバインディング・コンポーネント、サービス・エンジン、および正規化されたメッセージ・ルーターが含まれます。

Javaコラボレーション定義(JCD)

Java CAPSリポジトリ・プロジェクトに書き込まれたJava形式のビジネス・ルールおよびロジック。通常、このエンコーディングは、オブジェクト型定義に対する操作によって構成されます。

JAXB

JavaクラスをXML表現にマップするためのJava API。Java Architecture for XML Binding (JAXB)は、Java EEプラットフォームの一部です。

JAX-WS

Webサービスを作成するためのJava API。Java API for XML Web Services (JAX-WS)は、Java EEプラットフォームの一部です。

JBIプロジェクト

JBIテクノロジに基づいたOracle Java CAPSプロジェクト。これらのプロジェクトでは、サービス・エンジンとバインディング・コンポーネントを使用して、ビジネス・ロジックおよび接続性を定義します。ソース・コードはファイル・システムに保存されます。

マーシャル

XML構造またはオブジェクトを文字列、バイトまたはストリーム形式にシリアライズするOTD操作。

メッセージ可能OTD

マーシャルおよびアンマーシャル・メソッドを持つOTD(シリアライズ可能なオブジェクト)。これらのOTDは、アダプタには関連付けられませんが、特定のメッセージ形式のデータ構造を定義するために使用されます。

オブジェクト型定義(OTD)

オブジェクトを定義するデータ構造およびルール。OTDは、Oracle Java CAPS全体のマッピングで使用可能な正規のオブジェクトに、データおよび外部システムをマップするために使用するAPIを定義します。

リポジトリ・プロジェクト

Oracle Java CAPS 5.1.3テクノロジに基づいたOracle Java CAPSプロジェクト。これらのプロジェクトでは、オブジェクト型定義、Javaコラボレーション定義、BPEL 1.0のビジネス・プロセスおよびeWayアダプタを使用して、ビジネス・ロジックおよび接続性を定義します。ソース・コードは、エンコードされたリポジトリに保存されます。

ユーザー定義OTD (UD OTD)

ユーザーが手動で、またはフラット・ファイルから作成および構成したカスタムOTD。ユーザー定義OTD内のノードを追加または削除したり、それらのプロパティを編集できます。

アンマーシャル

文字列、ストリームまたはバイト形式のメッセージをOTDオブジェクトにデシリアライズするOTD操作。

Copyright © 2011, Oracle and/or its affiliates. All rights reserved.