IBM WebSphere WebSphere Integration Developer
バージョン 6.1
マイグレーション・ガイド
お願い
本書および本書で紹介する製品をご使用になる前に、特記事項に記載されている情報をお読みください。
このエディションは、WebSphere Integration Developer のバージョン 6.1 に適用されます。
IBM 発行のマニュアルに関する情報のページ
http://www.ibm.com/jp/manuals/
こちらから、日本語版および英語版のオンライン・ライブラリーをご利用いただけます。また、マニュアルに関するご意見やご感想を、上記ページよりお送りください。今後の参考にさせていただきます。
(URL は、変更になる場合があります)
お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。
- 原 典:
-
WebSphere(R) Integration Developer Version 6.1
Version 6 Release 1
Migration Guide
- 発 行:
- 日本アイ・ビー・エム株式会社
- 担 当:
- ナショナル・ランゲージ・サポート
|
第1刷 2008.2
Copyright International Business Machines Corporation 2005, 2007. All rights reserved.
第 1 章 WebSphere Integration Developer へのマイグレーション
WebSphere(R) Integration
Developer Version 6.1 には、既存の環境をマイグレーションするために必要なツールが用意されています。
注: WebSphere Integration Developer 6.0.2 および 6.1 のプロジェクトを WebSphere Integration Developer 6.0.1 で使用することはできません。
WebSphere Integration Developer 6.0.2 または 6.1 にアップグレードした後に、プロジェクトを、WebSphere Integration Developer 6.0.1.x に戻すことはできません。また、6.0.2 または 6.1 のユーザーがコードをリポジトリーにチェックインするかプロジェクトをエクスポートした後、それらのプロジェクトを WebSphere Integration Developer 6.0.1 のユーザーと共用することもサポートされていません。
以下のトピックでは、WebSphere Integration Developer にマイグレーションする場合の概念、参照情報、および段階的指示について説明します。
第 2 章 前バージョンの WebSphere Integration Developer からのマイグレーション
以前のバージョンの WebSphere Integration Developer から WebSphere Integration Developer 6.1 へのマイグレーションがサポートされています。これは、バージョン間 マイグレーションと呼ばれます。
WebSphere Integration Developer 6.1 へのマイグレーションでは、既存のアプリケーションの基本構造は保存され、再構成は最小限で済みます。バージョン間プロセスにはマイグレーション・ウィザードが関連付けられていない ことに注意してください。
以下のトピックでは、WebSphere Integration Developer のバージョン間マイグレーション・プロセスについて、詳しく説明します。
バージョン間マイグレーション・プロセスの考慮事項
前のバージョンの WebSphere Integration Developer から V6.1 にマイグレーションするとき、ほとんどのマイグレーションは自動的に行われます。しかし、追加の手動構成が必要になる場合があるいくつかの考慮事項について知っておく必要があります。
以下の考慮事項は、バージョン間のマイグレーション・プロセスを支援するためのものです。
- アダプター
- 以前のレベルのアダプターを使用するアプリケーションは、ユーティリティーによって現行レベルへ素早くマイグレーションすることができます。詳細については、下記の関連リンクのセクションで、トピック『以前のアダプター・レベルを使用したアプリケーションのマイグレーション』を参照してください。
- CEI イベント
- WebSphere Integration Developer 6.0.2 モニター・モデルを新規に作成することはできませんが、既に作成されているものを WebSphere Integration Developer 6.1 で使用することはできます。
- イベント定義エディター
- このエディターは、WebSphere Integration Developer 6.1 では推奨されません。
- XSD Federation
- XSD Federation (つまり、xsd-include の生成) は、WebSphere Integration Developer 6.1 では除去されました。したがって、古い PI では、必要な xsd-include があれば PI 内に組み込んでおく必要があります。これは、WebSphere Integration Developer 6.0.2.x でエクスポートされた PI では自動的に行われます。しかし、PI を 6.0.1.2 からエクスポートするには、エクスポートを実行するときに「生成されたファイルを組み込む (Include derived files)」チェック・ボックスに明示的にチェック・マークを入れる必要があります。
- XSL 変換プリミティブ
- WebSphere Integration Developer 6.1 では、XSL 変換プリミティブは新しい XML マッピング・エディターを備えています。前のバージョンで作成された XML マップを編集するには、それらのマップを事前に新しいフォーマットにマイグレーションしておく必要があります。詳細については、下記の関連リンクのセクションでトピック『XSL 変換プリミティブのマイグレーション』を参照してください。
開発およびデプロイメントのバージョン・レベル
使用する環境でどのバージョン・レベルが必要かについての決定は、アプリケーションの開発に使用されたバージョン・レベルによって決まります。
WebSphere Process Server 6.1 および WebSphere Integration Developer 6.1 は、以前のリリースと次のような互換性があります。
注: i5/OS(R) システムの場合、前にインストールされているバージョンはありません。
- WebSphere Integration Developer 6.0.x.x (ここで、6.0.x.x は 6.0.1.x または 6.0.2.x を指します) から WebSphere Process Server 6.1 へのデプロイメントがサポートされます。
- WebSphere Integration Developer 6.0.x.x を使用してオーサリングおよび生成されたアプリケーションは、WebSphere Process Server 6.1 サーバーに対して公開できます。
- WebSphere Integration Developer 6.0.x.x でオーサリングされ、生成され、このバージョンからエクスポートされたアプリケーションは、WebSphere Process Server 6.1 サーバーにインストールできます。
- WebSphere Process Server 6.1 の成果物を WebSphere Process Server 6.0.x.x で実行することは、サポートされていません。
- WebSphere Integration Developer 6.1 でオーサリングされたアプリケーションを WebSphere Process Server 6.0.x.x (すべての旧リリース) サーバーへ公開またはインストールすることはできません。そのようなコンテンツは WebSphere Process Server 6.0.x.x では正しく実行されず、コード生成の変更により、アプリケーションは WebSphere Process Server 6.0.x.x 上で正しく実行されません。
- WebSphere Integration Developer 6.0.x.x でオーサリングされ、WebSphere Integration Developer 6.1 で生成されたアプリケーションを WebSphere Process Server 6.0.x.x に公開またはインストールすることはできません。コード生成の変更により、アプリケーションは WebSphere Process Server 6.0.x.x 上で正しく実行されません。
- WebSphere Process Server 6.1 サーバーから serviceDeploy を使用して生成されたアプリケーションは、WebSphere Process Server 6.0.x.x サーバーにインストールできません。コード生成の変更により、アプリケーションは WebSphere Process Server 6.0.x.x 上で正しく実行されません。
第 3 章 WebSphere InterChange
Server からの WebSphere Process
Server へのマイグレーション
WebSphere InterChange Server から WebSphere Process Server へのマイグレーションは、WebSphere Integration Developer で以下の機能を介してサポートされます。
注: WebSphere Process Server のこのリリースでのマイグレーションに関連する制限に関する情報については、リリース情報を参照してください。
- 以下のものから呼び出せる、マイグレーション・ツールを介したソース成果物の自動マイグレーション。
- WebSphere Integration Developer の「ファイル」 -> 「インポート」 -> 「ビジネス・インテグレーション」メニュー
- WebSphere Integration
Developer の初期ページ
- reposMigrate コマンド行ユーティリティー
- 多くの WebSphere
InterChange Server API のランタイムでのネイティブ・サポート
- 現行の WebSphere Business Integration Adapter テクノロジーに対するサポート。これにより、既存のアダプターが WebSphere Process Server と互換性を持つことになります。
ソース成果物のマイグレーションがサポートされているにしても、広範囲にわたる分析とテストを行い、結果として得られるアプリケーションが、WebSphere
Process Server で期待されるとおりに機能するかどうか、あるいはマイグレーション後の再設計を必要とするかどうかを判別することが推奨されます。この推奨事項は、WebSphere InterChange Server とこのバージョンの WebSphere Process Server との機能的な同等性についての以下の制限に基づいています。このバージョンの
WebSphere
Process Server には、以下の
WebSphere InterChange Server 機能に相当するもののサポートがありません。
- グループ・サポート
- ホット・デプロイメント/動的更新
- スケジューラー - 一時停止操作
- セキュリティー - 監査
- セキュリティー - きめ細かな RBAC
- セキュリティー記述子はマイグレーションされません
WebSphere InterChange Server のサポート対象マイグレーション・パス
WebSphere Process Server マイグレーション・ツールは、WebSphere InterChange Server バージョン 4.2.2 以降からのマイグレーションをサポートしています。
バージョン 4.2.2 より前のリリースの WebSphere InterChange Server は、WebSphere Process Server にマイグレーションする前に、まずバージョン 4.2.2 または 4.3 へマイグレーションする必要があります。
WebSphere InterChange
Server から WebSphere Process
Server にマイグレーションする前に、環境が適切に準備されていることを最初に確認する必要があります。
WebSphere Process
Server には、WebSphere InterChange Server からマイグレーションするために必要なツールが用意されています。
これらのマイグレーション・ツールは、以下から呼び出すことができます。
- WebSphere Integration Developer の「ファイル」 -> 「インポート」 -> 「ビジネス・インテグレーション」メニュー
- WebSphere Integration
Developer の初期ページ
マイグレーション・ツールへの入力は、WebSphere InterChange
Server からエクスポートされたリポジトリー JAR ファイルです。このため、これらのオプションのいずれかからマイグレーション・ツールにアクセスする前に、最初に以下を行う必要があります。
- WebSphere Process Server にマイグレーション可能な WebSphere InterChange Server のバージョンを実行していることを確認します。トピック『WebSphere InterChange Server のサポート対象マイグレーション・パス』を参照してください。
- WebSphere InterChange
Server の資料で説明されているように、WebSphere InterChange Server repos_copy コマンドを使用して、WebSphere InterChange
Server からリポジトリー JAR ファイルにソース成果物をエクスポートします。ウィザードは、入力として WebSphere InterChange Server リポジトリー JAR ファイルを必要とします。この JAR ファイルは、マイグレーションされているアプリケーションに関して、必要なものを完備している必要があります。つまり、この JAR ファイルには、この JAR ファイル内の成果物によって参照されるすべての成果物も含まれている必要があります。生成されるリポジトリー JAR ファイルが必要なものをすべて完備しているようにするには、サーバー・リポジトリーをエクスポートする前に、repos_copy コマンドを -vr オプション付きで実行します (これによってリポジトリーの妥当性が検査されます)。リポジトリーが妥当である場合、repos_copy は次の出力をコンソールに書き込みます。Validation Succeeded. All Dependencies
Resolved. リポジトリーが妥当でない場合、repos_copy は解決する必要がある依存関係のリストを出力します。リポジトリーをエクスポートする前に、それらの依存関係を解決してください。
WebSphere InterChange Server repos_copy コマンドを -o オプション付きで実行して、リポジトリー成果物をエクスポートし、リポジトリー JAR ファイルを作成します (個々のコンポーネントのエクスポート方法も含め、詳細については、
WebSphere InterChange Server 4.3 の資料を参照してください)。
WebSphere InterChange Server マイグレーション・プロセスの考慮事項
以下の考慮事項は、WebSphere InterChange Server 用のインテグレーション成果物の開発を支援するためのものです。これらのガイドラインに従うことで、WebSphere InterChange Server 成果物の
WebSphere Process
Server に容易にマイグレーションできます。
以下の推奨事項は、単なるガイドとして使用されることを想定しています。これらのガイドラインから逸脱することが必要な場合もあります。これらの場合には、成果物のマイグレーションに必要な再作業の量を最小化するために、逸脱の範囲を制限するように注意を払う必要があります。ここに概要を示したガイドラインのすべてが、WebSphere InterChange Server 成果物の開発に関する一般的推奨事項であるわけではないことに注意してください。それよりむしろ、将来、成果物をマイグレーションする場合の容易さに影響する考慮事項に範囲を限定しています。
考慮事項: 一般的開発
ほとんどのインテグレーション成果物に広く適用される考慮事項がいくつかあります。一般に、ツールによって提供される機能を活用し、ツールによって強制されるメタデータ・モデルに準拠する成果物は、最も円滑にマイグレーションされます。また、大幅な拡張と外部依存を持つ成果物は、マイグレーション時に、より多くの手動介入を必要とする傾向にあります。
以下のリストでは、将来のマイグレーションを容易にするために役立つ、WebSphere InterChange
Server ベースのソリューションの一般的開発についての考慮事項を要約します。
- システムおよびコンポーネントの設計を文書化する
- 開発ツールを使用してインテグレーション成果物を編集する
- ツールおよび Java(TM) Snippet を使用するルールを定義するために、提案を活用する
インテグレーション・ソリューションが
WebSphere InterChange Server によって提供されるプログラミング・モデルおよびアーキテクチャーに準拠していることが重要です。WebSphere InterChange Server 内のインテグレーション・コンポーネントはそれぞれ、アーキテクチャー内で、厳密に定義されたロールを遂行します。このモデルから大幅に逸脱すると、コンテンツを
WebSphere Process Server 上の該当する成果物にマイグレーションすることが、より一層難しくなります。
将来のマイグレーション・プロジェクトの成功率を高めるもう 1 つの一般的な方法は、システム設計を文書化することです。これには、サービス要件の機能設計と品質、プロジェクト全体で共用される成果物の相互依存性、およびデプロイ時に行われた設計上の意思決定も含めた、インテグレーション・アーキテクチャーと設計を必ず取り込むようにしてください。これにより、マイグレーション時のシステム分析が支援され、再作業の労力が最小化されます。
成果物定義の作成、構成、および変更の際には、提供されている開発ツールのみを使用してください。成果物メタデータの手動操作 (例えば、XML ファイルの直接編集) は避けてください。これを行うと、マイグレーション対象の成果物が壊れる可能性があります。
Java コードを、コラボレーション・テンプレート、マップ、共通コード・ユーティリティー、およびその他のコンポーネント内で開発する場合は、以下のガイドラインに従ってください。
- 公開されている API のみを使用する。
- Activity Editor を使用する。
- アダプターを使用して EIS にアクセスする。
- Java Snippet コード内で外部依存関係を避ける。
- 移植性のために、J2EE の開発方法に準拠する。
- スレッドの作成またはスレッド同期プリミティブの使用を行わないこと。これらを作成または使用しなければならない場合、マイグレーション時に、これらを、非同期 Bean を使用するように変換する必要があります。
- java.io.* を使用したディスク I/O を行わないこと。
JDBC を使用して、データを保管してください。
- EJB コンテナー用に予約されている可能性のある、ソケット I/O、クラス・ロード、ネイティブ・ライブラリーのロードなどの機能を実行しないこと。これらを実行しなければならない場合、マイグレーション時に、これらの Snippet を EJB コンテナー機能を使用するように手動で変換する必要があります。
成果物には、WebSphere InterChange Server の製品資料で公開されている API のみを使用してください。これらは、WebSphere
InterChange Server の開発ガイドに概要が詳しく説明されています。
WebSphere Process Server では、公開済みの WebSphere InterChange Server API と互換性のある API が提供される予定です。WebSphere InterChange Server には多数の内部インターフェースがあり、それらを使用したいと考える場合があるかもしれませんが、このインターフェースが将来もサポートされる保証はないので、使用することはお勧めしません。
マップおよびコラボレーション・テンプレートでビジネス・ロジックおよび変換ルールを設計する場合は、Java アーカイブ (*.jar) ファイルとして WebSphere InterChange Server のクラスパスに組み込まれている、フィールド開発の共通コード・ユーティリティー・ライブラリーは避けてください。これらのライブラリーは、手動でマイグレーションする必要があります。
Activity Editor ツールを最大限に利用してください。これにより、ロジックは、より容易に新しい成果物に変換可能なメタデータを使用して記述されるようになります。ツールで再利用したい操作の場合は、Activity Editor の「My Collections」フィーチャーを可能な限り使用してください。
開発が必要になる可能性がある Java
コード Snippet では、コードを可能な限り単純かつ最小単位のものにしてください。
Java コードにおける複雑さは、スクリプト記述 (基本的な評価、操作、および計算を含む)、データのフォーマット設定、型変換などと同じようなレベルに留めてください。より包括的または複雑なアプリケーション・ロジックが必要な場合は、WebSphere Application Server で稼働する EJB を使用してロジックをカプセル化することを検討し、Web サービス呼び出しを使用してそれを WebSphere InterChange Server から呼び出してください。別個にマイグレーションする必要のある、サード・パーティーまたは外部のライブラリーではなく、標準 JDK ライブラリーを使用してください。さらに、すべての関連ロジックを単一のコード Snippet 内に集め、接続およびトランザクション・コンテキストが複数のコード Snippet にまたがるロジックの使用は避けてください。例えば、データベース操作の場合、接続の取得、トランザクションの開始と終了、および接続の解放に関連するコードは、1 つのコード Snippet にしてください。
一般に、エンタープライズ情報システム (EIS) とインターフェースするように設計されるコードは、アダプター内に配置し、マップまたはコラボレーション・テンプレート内には配置しないようにしてください。これはアーキテクチャーの設計で一般的に推奨される方法です。これはまた、接続管理や、考えられる Java Native Interface (JNI) 実装など、サード・パーティー・ライブラリーおよびコード内の関連考慮事項に対する前提条件の回避に役立ちます。
適切な例外処理を使用することにより、コードをできるだけ安全にしてください。また、たとえコードが現在 J2SE 環境内で稼働しているにしても、コードに互換性を持たせて、J2EE アプリケーション・サーバー環境内でも稼働するようにしてください。静的変数、スレッドの作成、ディスク I/O を回避するなど、J2EE の開発方法に従うようにしてください。これらは、一般に順守するのが好ましい方法であるだけでなく、移植性も向上させます。
考慮事項: 共通コード・ユーティリティー
WebSphere InterChange Server 環境内で、インテグレーション成果物間で使用する共通コード・ユーティリティー・ライブラリーの開発を回避することが推奨されます。インテグレーション成果物間でコードの再利用が必要な場合は、Activity Editor ツールの「My Collections」フィーチャーの活用が推奨されます。また、WebSphere Application Server
で稼働する EJB を使用してロジックをカプセル化することを検討し、
Web サービス呼び出しを使用してそれらを
WebSphere InterChange Server から呼び出してください。
一部の共通コード・ユーティリティー・ライブラリーが WebSphere Process Server 上で適切に実行されることもあり得ますが、カスタム・ユーティリティーのマイグレーションは、お客様の責任で行ってください。
考慮事項: データベース接続プール
マップまたはコラボレーション・テンプレート内の WebSphere InterChange Server データベース接続プールは、WebSphere Process Server では標準 JDBC リソースとして提供されます。しかし、接続とトランザクションの管理方法は、WebSphere InterChange Server と WebSphere Process Server とで異なる場合があります。このため、複数の Java Snippet にまたがってデータベース・トランザクションをアクティブにしておくことは避けてください。
ユーザー定義のデータベース接続プールは、マップおよびコラボレーション・テンプレート内で単純なデータ検索や複数のプロセス・インスタンスにまたがった複雑なステート管理に使用すると便利です。WebSphere InterChange Server のデータベース接続プールは、WebSphere Process Server の標準
JDBC リソースとして提供され、基本機能は同じです。しかし、接続とトランザクションの管理の方法は異なる場合があります。
将来の移植性を最大化するために、コラボレーション・テンプレートまたはマップ内の複数の
Java Snippet ノードに渡ってデータベース・トランザクションをアクティブに保持することは避けてください。例えば、接続の取得、トランザクションの開始と終了、および接続の解放に関連するコードは、1 つのコード Snippet に入れてください。
考慮事項: ビジネス・オブジェクト
ビジネス・オブジェクトの開発には、成果物を構成するために提供されているツールのみを使用し、明示的なデータ型と長さをデータ属性に使用し、文書化された API のみを使用してください。
WebSphere Process Server 内のビジネス・オブジェクトは、サービス・データ・オブジェクト (SDO) に基づいています。SDO は、強く型付けされているデータ属性を使用します。WebSphere InterChange Server およびアダプターのビジネス・オブジェクトの場合、データ属性は強く型付けされておらず、ユーザーが非ストリング・データ属性にストリング・データ型を指定する場合があります。WebSphere Process Server での問題を避けるために、データ型は明示的に指定してください。
WebSphere Process Server 内のビジネス・オブジェクトは、実行時にコンポーネント間で受け渡されるとき、シリアライズされる場合があるため、データ属性に必須の長さを明示して、システム・リソースの使用率を最小化することが重要です。この理由のため、例えば、ストリング属性には最大の 255 文字長を使用しないでください。同様に、現在のところデフォルトで 255 文字になっていますが、ゼロの長さ属性も指定しないでください。その代わりに、属性に必要な正確な長さを指定してください。
WebSphere Process Server 内のビジネス・オブジェクトの属性名には、XSD NCName ルールが適用されます。このため、ビジネス・オブジェクト属性の名前の中でスペースまたは「:」を使用しないでください。スペースまたは「:」の付いたビジネス・オブジェクトの属性名は、WebSphere Process Server 内では無効です。マイグレーションする前に、ビジネス・オブジェクトの属性名を変更してください。
ビジネス・オブジェクト内で配列を使用する場合は、「マップ」または「リレーションシップ」(あるいは、その両方) 内の配列に索引付けする際に、配列の順序に依存することはできません。WebSphere Process Server 内にマイグレーションされる構成では、特にエントリーが削除される場合、索引順序は保証されません。
Business Object Designer ツールのみを使用してビジネス・オブジェクト定義を編集し、インテグレーション成果物内のビジネス・オブジェクトに対して、公開されている API のみを使用することが重要です。
考慮事項: コラボレーション・テンプレート
これまでに説明したガイドラインの多くは、コラボレーション・テンプレートの開発に適用されます。
プロセスがメタデータを使用して適切に記述されるようにするためには、コラボレーション・テンプレートの作成および変更には、常に Process Designer ツールを使用するようにし、メタデータ・ファイルを直接に編集することは避けてください。可能な限り Activity Editor ツールを使用して、メタデータの使用を最大化し、必要なロジックを記述してください。
マイグレーションで必要となることがある手動による再作業量を最小化するために、コラボレーション・テンプレート内では、文書化された API のみを使用してください。静的変数の使用は避けてください。その代わりに、非静的変数およびコラボレーション・プロパティーを使用して、ビジネス・ロジックの要件に対応してください。
Java Snippet 内では、Java 修飾子 final、transient、および native の使用は避けてください。これらは、コラボレーション・テンプレートをマイグレーションした結果である、BPEL Java Snippet 内で使用することができません。
将来の移植性を最大化するために、ユーザー定義のデータベース接続プールでの明示的な接続解放呼び出し、および明示的なトランザクション・ブラケット操作 (すなわち、明示コミットおよび明示ロールバック) の使用は避けてください。その代わりに、コンテナーが管理する暗黙接続クリーンアップ、および暗黙トランザクション・ブラケット操作を使用してください。また、コラボレーション・テンプレート内の複数の
Java Snippet ノードに渡って、システム接続およびトランザクションをアクティブに保つことは避けてください。これは、外部システムへのすべての接続のほか、ユーザー定義のデータベース接続プールにもあてはまります。外部 EIS を使用した操作はアダプター内で管理する必要があり、データベース操作に関連するコードは 1 つのコード Snippet 内に含まれている必要があります。これは、BPEL ビジネス・プロセス・コンポーネントとして提供される場合に、割り込み可能フローとして選択的にデプロイされることがあるコラボレーション内で必要となります。この場合、プロセスはいくつかの別々のトランザクションで構成され、ステートおよびグローバル変数の情報のみがアクティビティー間で受け渡されます。これらの複数のプロセス・トランザクションに渡るシステム接続または関連トランザクションのコンテキストは失われます。
コラボレーション・テンプレート・プロパティー名には、W3C XML NCName 命名規則に従った名前を付けてください。WebSphere Process Server は、これらの規則に準拠した名前を受け入れます。許可されていない文字は、マイグレーション先となる BPEL プロパティー名の中で無効になります。マイグレーションで生成される BPEL の構文エラーを避けるため、マイグレーションを行う前にプロパティー名を変更し、許可されていない文字を除去してください。
「this.」を使用している変数は、参照しないでください。例えば、「this.inputBusObj」の代わりに、単に「inputBusObj」を使用してください。
変数には、シナリオのスコープを持つ変数の代わりに、クラス・レベルのスコープを使用してください。シナリオのスコープは、マイグレーション時に転送されません。
Java Snippet で宣言されているすべての変数を、例えば「Object myObject = null」のように、デフォルト値で初期化してください。マイグレーションを行う前の宣言のときに、必ずすべての変数を初期化しておいてください。
コラボレーション・テンプレートのユーザー変更可能セクションに、Java の import ステートメントがないことを確認してください。コラボレーション・テンプレートの定義で、インポート・フィールドを使用して、インポートする Java パッケージを指定してください。
着信ビジネス・オブジェクト値が triggeringBusObj 変数に保管されるような設定はしないでください。
WebSphere InterChange Server 内では、triggeringBusObj は読み取り専用であり、その値を上書きすることはできません。したがって、着信ビジネス・オブジェクト値は保管されません。triggeringBusObj をインバウンド・サービス呼び出しで着信ビジネス・オブジェクトの受け取り側変数として使用すると、マイグレーション後のインバウンド・サービス呼び出しの動作が異なるものになります。つまり、BPEL プロセス内では、インバウンド・サービス呼び出しからの着信値により、triggeringBusObj に保管されている値が上書きされます。
考慮事項: マップ
コラボレーション・テンプレートに関して説明したガイドラインの多くは、マップにも適用されます。
マップがメタデータを使用して適切に記述されるようにするために、マップの作成および変更には、常に Map Designer ツールを使用するようにし、メタデータ・ファイルを直接に編集することは避けてください。可能な限り Activity Editor ツールを使用して、メタデータの使用を最大化し、必要なロジックを記述してください。
マップ内の子ビジネス・オブジェクトを参照する場合は、子ビジネス・オブジェクト用のサブマップを使用してください。
SET 内で Java コードを「値」として使用することは避けてください。これは、WebSphere Process Server 内では無効であるためです。代わりに、定数を使用してください。例えば、set の値が「xml version=」+「1.0」+「encoding=」+「UTF-8」である場合、これは、WebSphere
Process Server 内では妥当性検査されません。代わりに、マイグレーションする前に、「xml version=1.0 encoding=UTF-8」に変更してください。
マイグレーションで必要となることがある手動による再作業量を最小化するために、マップ内では、文書化された API のみを使用してください。静的変数の使用は避けてください。代わりに、非静的変数を使用してください。マップ・カスタム・コード内では、
Java 修飾子 final、transient、および native の使用は避けてください。
ビジネス・オブジェクト内で配列を使用する場合は、マップ内で配列に索引付けする際に、配列の順序に依存しないでください。WebSphere Process Server 内にマイグレーションされる構成では、特にエントリーが削除される場合、索引順序は保証されません。
将来の移植性を最大化するために、ユーザー定義のデータベース接続プールでの明示的な接続解放呼び出し、および明示的なトランザクション・ブラケット操作 (すなわち、明示コミットおよび明示ロールバック) の使用は避けてください。その代わりに、コンテナーが管理する暗黙接続クリーンアップ、および暗黙トランザクション・ブラケット操作を使用してください。また、カスタム・マップ・ステップで、変換ノードの境界を越えてシステム接続およびトランザクションをアクティブに保つことは避けてください。これは、外部システムへのすべての接続のほか、ユーザー定義のデータベース接続プールにもあてはまります。外部 EIS を使用した操作はアダプター内で管理する必要があり、データベース操作に関連するコードは 1 つのカスタム・ステップ内に含まれている必要があります。
マップ内では、インナー・クラスを使用しないでください。マイグレーション・コマンド (reposMigrate) はインナー・クラスをマイグレーションせず、マップにインナー・クラスが含まれているとエラーになります。WebSphere InterChange Server リポジトリーでは、インナー・クラスをノード内に定義し、同じコラボレーション・テンプレート内で他のノードからそれを参照できます。WebSphere Process Server では、BPEL コンポーネント内で定義されたインナー・クラスを、他のコンポーネントが使用することはできません。この制限のために、インナー・クラスは変換されず、手動で処理される必要があります。推奨される変更は、インナー・クラス・コードを外部クラスとしてライブラリーにパッケージ化するか、インナー・クラス宣言を除去し、エラーがあれば解決し、必要に応じて BPEL 全体にコードを配置することです。
考慮事項: リレーションシップ
リレーションシップについては、リレーションシップ定義は WebSphere
Process Server で使用するためにマイグレーションが可能であると同時に、リレーションシップ・テーブル・スキーマおよびインスタンス・データは、
WebSphere Process Server による再使用、および WebSphere InterChange Server と WebSphere Process
Server 間での並行した共用も可能であることに注目してください。
リレーションシップについては、関連するコンポーネントを構成するために提供されているツールのみを使用し、公開されている API のみをインテグレーション成果物内のリレーションシップに使用してください。
リレーションシップ定義の編集には、Relationship Designer ツールのみを使用してください。さらに、リレーションシップ・スキーマの構成には、WebSphere InterChange Server のみを使用するようにしてください。このスキーマはリレーションシップ定義をデプロイすると自動的に生成されます。データベース・ツールまたは SQL スクリプトを使用してリレーションシップ・テーブル・スキーマを直接に変更することは、しないでください。
リレーションシップ・テーブル・スキーマ内のリレーションシップ・インスタンス・データを手動で変更する必要がある場合は、必ず Relationship Manager が提供する機能を使用してください。
インテグレーション成果物内のリレーションシップには、公開されている API のみを使用してください。
考慮事項: フレームワーク・クライアントへのアクセス
CORBA IDL インターフェース API を採用して新規クライアントを開発することは、しないでください。これは、WebSphere
Process Server ではサポートされていません。
考慮事項: データベースの競合の防止
イベントの発生間隔を 2 秒以上にスケジュールすることにより、データベースの競合の発生を防止できます。
マイグレーションされたアプリケーションが、WebSphere Business Integration コンポーネントに対して同時に複数のイベントを発生させる場合は、データベースの競合、つまりデッドロックが発生するおそれがあります。これが発生するのは、WebSphere Process Server Application Scheduler (AppScheduler) によって、複数のイベントが正確に同じ時刻に発生するようスケジュールされた場合です。デッドロックが発生すると、その原因となったイベントはロールバックされ、できるだけ早く再試行されます。このサイクルは、データベースにアクセスを試みている各スレッドが正しくデータベースを更新できるまで続きます。
例:
AppScheduler E com.ibm.wbiserver.scheduler.AppSchedulerMB process CWLWS0021E:
The AppSchedulerMB.process method has generated an exception.
WSRdbXaResour E DSRA0304E: XAException occurred.
XAException contents and details are:
The DB2 Error message is : Error executing a XAResource.end(), Server returned
XA_RBDEADLOCK The DB2 Error code is : -4203
The DB2 SQLState is : null
この発生を避けるには、イベントが十分に離れて発生するようにスケジュールし、デッドロックが起きないようにします。イベントが少なくとも 2 秒離れて発生するようスケジュールしてください。ただし、必要な時間量は、環境内でパフォーマンスに影響を及ぼすその他の要因 (例えば、データベース・サイズ、ハードウェア、接続速度、およびその他の要因) によって異なります。
考慮事項: 事後マイグレーション
WebSphere InterChange Server から WebSphere Integration Developer または WebSphere Process Server へアプリケーションをマイグレーションしたときは、WebSphere InterChange Server のアーキテクチャーとの違いがあるため、マイグレーションされたアプリケーションが WebSphere Integration Developer および WebSphere Process Server でも意図された機能を一貫して実行できるよう、いくつかの領域で特に注意を払う必要があります。
事後マイグレーションに関する考慮事項の詳細については、事後マイグレーションに関する考慮事項 (Post-migration considerations) を参照してください。
マイグレーション・ウィザードを使用した WebSphere InterChange Server のマイグレーション
WebSphere Integration
Developer マイグレーション・ウィザードを使用して、既存の WebSphere InterChange Server 成果物をマイグレーションできます。
「マイグレーション」ウィザードを使用してWebSphere InterChange Server 成果物をマイグレーションするには、以下の手順に従ってください。
- 「ファイル」 -> 「インポート」 -> 「ビジネス・インテグレーション」 -> 「WebSphere InterChange Server JAR ファイル」を選択してウィザードを呼び出し、「次へ」をクリックします。
または、「ようこそ」ページから「本製品のご使用経験のある方へ」アイコン
をクリックして「本製品のご使用経験のある方へ」を開くことによって、マイグレーション・ウィザードを開くこともできます (「ヘルプ」 -> 「ようこそ」をクリックすることにより、いつでも「ようこそ」ページに戻ることができます)。
「本製品のご使用経験のある方へ」ページの左側にある「マイグレーション」をクリックして、「マイグレーション」ページを開きます。「マイグレーション」ページから、「WebSphere ICS リポジトリーをマイグレーションする」オプション
を選択します。
- マイグレーション・ウィザードがオープンします。
「参照」ボタンをクリックしてファイルに移動し、ソース・ファイルの名前を「ソース」選択フィールドに入力します。関連するフィールドにライブラリー名を入力します。共用ライブラリーが現時点でワークスペース内に存在しない場合は、「新規...」をクリックして共用ライブラリーを作成する必要があります。「次へ」をクリックします。
- 「マイグレーション・オプション」ウィンドウが開きます。ここでマイグレーションのデフォルトを受け入れるか、チェック・ボックスを選択してオプションを変更することができます。
次の表に、選択可能なマイグレーション・オプションの概要を示します。
オプション |
説明 |
Java 構文解析エラーの場合に警告する |
(オプション) デフォルトでは、Java 変換問題が検出された場合、個々の成果物のマイグレーションは失敗します。このオプションを設定した場合、すべての Java 変換問題は警告としてのみ扱われ、成果物は可能な限りマイグレーションされます。 |
最初の障害でマイグレーションを停止する |
(オプション) デフォルトでは、マイグレーション・ウィザードは特定の成果物の処理中にエラーが発生した場合、JAR ファイル内の残りの成果物の処理を続行します。このオプションを設定した場合、処理はエラーが検出されると同時に停止します。エラーのある成果物と後続のすべての成果物は、処理されません。 |
コラボレーション・テンプレート・ループ解明を使用する |
(オプション) コラボレーション・テンプレート内に存在するすべてのループを維持するよう要求します。このオプションが存在しない場合、デフォルトではマイグレーションでループ解明が使用されます。 |
イベント順序付けを使用可能にする |
(オプション) すべての非同期 WSDL メソッドについて、イベント順序付けを使用可能に設定するよう要求します。このオプションが存在しない場合、デフォルトでは、マイグレーションでイベント順序付けがどの WSDL メソッドに対しても使用可能に設定されません。 |
デフォルト・テンプレートを使用する |
(オプション) 指定されたディレクトリー内のすべてのアセンブリー・エディター・テンプレートをロードし、XML から Javaへの変換に使用するよう要求します。このプロパティーのデフォルトは、Standard Assembly Editor Template v4.3.3 のみを XML から Javaへの変換に使用することです。 |
- 「終了」をクリックします。
マイグレーション・ダイアログの下部にある進行状況表示バーに、マイグレーションの進行状況が示されます。マイグレーション・プロセスが完了すると、マイグレーション・ダイアログは消去され、「マイグレーション結果」ウィンドウが開きます。
WebSphere InterChange Server マイグレーションの検査
WebSphere InterChange
Server の jar ファイルのマイグレーション中にエラーが報告されなかった場合は、成果物のマイグレーションが正常に行われています。マイグレーションが正常に完了しなかった場合は、エラー・メッセージ、警告メッセージ、情報メッセージのリストが表示されます。これらのメッセージを使用して、WebSphere InterChange Server マイグレーションを検査することができます。
注: WebSphere InterChange
Server から WebSphere Process Server へのマイグレーションは複雑なので、本番に移行する前に、WebSphere Process Server で実行しているアプリケーションを広範囲に渡りテストし、予想通りに機能することを確認してください。
マイグレーション・メッセージがマイグレーション・プロセス中に生成された場合は、次のページが表示されます。
「マイグレーション結果」ウィンドウで、マイグレーション・プロセス中に生成されたマイグレーション・メッセージを見ることができます。上部のメッセージ・リストからメッセージを選択すると、そのメッセージに関する詳細が「メッセージの説明」ウィンドウに表示されます。
今後の参照用にすべてのメッセージを保存しておくには、「タスクの生成」ボタンをクリックして、タスクのリストをタスク・ビューに作成するか、「別名保管...」ボタンをクリックしてファイル・システム内のテキスト・ファイルにメッセージを保管するか、またはその両方を行います。生成された予定を表示するには、「ウィンドウ」 -> 「ビューの表示」 -> 「その他... (Other...)」 -> 「一般」 -> 「タスク」をクリックして、「OK」をクリックします。「タスク」ビューが開き、生成された予定のリストがマイグレーション・プロセスから表示されます。
WebSphere InterChange Server からのマイグレーション失敗時の作業
WebSphere InterChange
Server からのマイグレーションが失敗した場合、これに対処するには 2 つの方法があります。
注: 最初は、WebSphere
InterChange Server により詳しくなるために、最初のオプションを選択してください。ただし、WebSphere Process Server とその新しい成果物に慣れてきたら、WebSphere Integration Developer でマイグレーションした成果物を修復するよう選択することもできます。
- エラーの性質上許可される場合は、WebSphere InterChange Server ツール・セットを使用して WebSphere InterChange Server 成果物を調整してから、JAR ファイルを再度エクスポートし、マイグレーションを再試行できます。
- WebSphere Integration
Developer で成果物を編集して、マイグレーションした WebSphere Process Server 成果物のエラーを修正できます。
マイグレーション・ツールが処理する
WebSphere InterChange Server 成果物
マイグレーション・ツールは、一部の WebSphere InterChange Server 成果物を自動的にマイグレーションできます。
以下の成果物をマイグレーションできます。
- ビジネス・オブジェクト: これは WebSphere Process Server のビジネス・オブジェクトになります
- マップ: これは WebSphere Process Server のマップになります
- リレーションシップ: これは WebSphere Process Server のリレーションシップおよびロールになります
- コラボレーション・テンプレート: これは WebSphere Process Server の BPEL および WSDL になります
- コラボレーション・オブジェクト: これは WebSphere Process Server のモジュールになります。これらのモジュールには、コラボレーション・テンプレート BPEL へバインドされた SCA コンポーネントおよび必要なすべての SCA ワイヤリングが入っています。
- コネクター定義: これは WebSphere Process Server のモジュールになります。これらのモジュールには、レガシー・アダプターやレガシー・アダプター管理成果物との通信を可能にする SCA インポートとエクスポート、および必要なすべての SCA ワイヤリングが入っています。
マイグレーション・ツールは、以下の WebSphere InterChange Server の成果物/リソースについて、
WebSphere Process Server 内のリソースを構成するために wsadmin コマンド行ツールで使用可能な Jython スクリプトを作成します。
- DBConnection プール
- リレーションシップ
- スケジューラー・エントリー
マイグレーション・ツールは、以下の WebSphere InterChange Server 成果物を処理しません。
サポートされる WebSphere InterChange Server の API
WebSphere Process Server および WebSphere Integration Developer で提供される
WebSphere InterChange Server のソース成果物マイグレーション・ツールのほかに、WebSphere InterChange Server で提供されていた多くの API もサポートされています。マイグレーション・ツールは、マイグレーション時にできる限り多くのカスタム Snippet コードを保持することで、これらの WebSphere InterChange
Server の API とともに機能します。
注: これらの API は、マイグレーションされた WebSphere InterChange
Server のアプリケーションが Process Server の新しい API を使用するように変更されるまで、そのアプリケーションのサポートのためだけに提供されています。
Process Server でサポートされる WebSphere InterChange
Server の API を下にリストします。これらの API は、WebSphere InterChange
Server で提供される機能と同等の機能を WebSphere Process Server でも提供します。これらの API の機能的な説明については、WebSphere InterChange Server の資料を参照してください。
CwBiDiEngine
AppSide_Connector/
- BiDiBOTransformation(BusinessObject, String, String, boolean):BusinessObj
- BiDiBusObjTransformation(BusObj, String, String, boolean):BusObj
- BiDiStringTransformation(String, String, String):String
JavaConnectorUtil
AppSide_Connector/
- INFRASTRUCTURE_MESSAGE_FILE
- CONNECTOR_MESSAGE_FILE
- XRD_WARNING
- XRD_TRACE
- XRD_INFO
- XRD_ERROR
- XRD_FATAL
- LEVEL1
- LEVEL2
- LEVEL3
- LEVEL4
- LEVEL5
- createBusinessObject(String):BusinesObjectInterface
- createBusinessObject(String, Locale):BusinesObjectInterface
- createBusinessObject(String, String):BusinesObjectInterface
- createContainer(String):CxObjectContainerInterface
- generateMsg(int, int, int, int, int, Vector):String
- generateMsg(int, int, int, int, Vector):String
- getBlankValue():String
- getEncoding():String
- getIgnoreValue():String
- getLocale():String
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
- isBlankValue(Object):boolean
- isIgnoreValue(Object):boolean
- isTraceEnabled(int):boolean
- logMsg(String)
- logMsg(String, int)
- traceWrite(int, String)
JavaConnectorUtilDH
datahandler/
wbi/
ibm/
com/
- getSDOFromString(String inputString, String sdoName, String metaObjectName,
String mimeType)
- getStringFromSDO(DataObject sdo, String metaObjectName, String mimeType)
BusObj
Collaboration/
- BusObj(DataObject)
- BusObj(String)
- BusObj(String, Locale)
- copy(BusObj)
- duplicate():BusObj
- equalKeys(BusObj):boolean
- equals(Object):boolean
- equalsShallow(BusObj):boolean
- exists(String):boolean
- get(int):Object
- get(String):Object
- getBoolean(String):boolean
- getBusObj(String):BusObj
- getBusObjArray(String):BusObjArray
- getCount(String):int
- getDouble(String):double
- getFloat(String):float
- getInt(String):int
- getKeys():String
- getLocale():java.util.Locale
- getLong(String):long
- getLongText(String):String
- getString(String):String
- getType():String
- getValues():String
- getVerb():String
- isBlank(String):boolean
- isKey(String):boolean
- isNull(String):boolean
- isRequired(String):boolean
- keysToString():String
- set(BusObj)
- set(int, Object)
- set(String, boolean)
- set(String, double)
- set(String, float)
- set(String, int)
- set(String, long)
- set(String, Object)
- set(String, String)
- setContent(BusObj)
- setDefaultAttrValues()
- setKeys(BusObj)
- setLocale(java.util.Locale)
- setVerb(String)
- setVerbWithCreate(String, String)
- setWithCreate(String, boolean)
- setWithCreate(String, BusObj)
- setWithCreate(String, BusObjArray)
- setWithCreate(String, double)
- setWithCreate(String, float)
- setWithCreate(String, int)
- setWithCreate(String, long):
- setWithCreate(String, Object)
- setWithCreate(String, String)
- toString():String
- validData(String, boolean):boolean
- validData(String, BusObj):boolean
- validData(String, BusObjArray):boolean
- validData(String, double):boolean
- validData(String, float):boolean
- validData(String, int):boolean
- validData(String, long):boolean
- validData(String, Object):boolean
- validData(String, String):boolean
BusObjArray
Collaboration/
- addElement(BusObj)
- duplicate():BusObjArray
- elementAt(int):BusObj
- equals(BusObjArray):boolean
- getElements():BusObj[]
- getLastIndex():int
- max(String):String
- maxBusObjArray(String):BusObjArray
- maxBusObjs(String):BusObj[]
- min(String):String
- minBusObjArray(String):BusObjArray
- minBusObjs(String):BusObj[]
- removeAllElements()
- removeElement(BusObj)
- removeElementAt(int)
- setElementAt(int, BusObj)
- size():int
- sum(String):double
- swap(int, int)
- toString():String
BaseDLM
DLM/
- BaseDLM(BaseMap)
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection
- getName():String
- getRelConnection(String):DtpConnection
- implicitDBTransactionBracketing():boolean
- isTraceEnabled(int):boolean
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- raiseException(RunTimeEntityException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- releaseRelConnection(boolean)
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
CwDBConnection
CwDBConnection/
CxCommon/
- beginTransaction()
- commit()
- executePreparedSQL(String)
- executePreparedSQL(String, Vector)
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- release()
- rollback()
CwDBConstants
CwDBConnection/
CxCommon/
- PARAM_IN - 0
- PARAM_INOUT - 1
- PARAM_OUT - 2
CwDBStoredProcedureParam
CwDBConnection/
CxCommon/
- CwDBStoredProcedureParam(int, Array)
- CwDBStoredProcedureParam(int, BigDecimal)
- CwDBStoredProcedureParam(int, boolean)
- CwDBStoredProcedureParam(int, Boolean)
- CwDBStoredProcedureParam(int, byte[])
- CwDBStoredProcedureParam(int, double)
- CwDBStoredProcedureParam(int, Double)
- CwDBStoredProcedureParam(int, float)
- CwDBStoredProcedureParam(int, Float)
- CwDBStoredProcedureParam(int, int)
- CwDBStoredProcedureParam(int, Integer)
- CwDBStoredProcedureParam(int, java.sql.Blob)
- CwDBStoredProcedureParam(int, java.sql.Clob)
- CwDBStoredProcedureParam(int, java.sql.Date)
- CwDBStoredProcedureParam(int, java.sql.Struct)
- CwDBStoredProcedureParam(int, java.sql.Time)
- CwDBStoredProcedureParam(int, java.sql.Timestamp)
- CwDBStoredProcedureParam(int, Long)
- CwDBStoredProcedureParam(int, String)
- CwDBStoredProcedureParam(int, String, Object)
- getParamType():int getValue():Object
DataHandler (Abstract Class)
DataHandlers/
crossworlds/
com/
- createHandler(String, String, String):DataHandler
- getBO(InputStream, Object):BusinessObjectInterface
- getBO(Object, BusinessObjectInterface, Object)
- getBO(Object, Object):BusinessObjectInterface
- getBO(Reader, BusinessObjectInterface, Object) (Abstract Method)
- getBO(Reader, Object):BusinessObjectInterface (Abstract Method)
- getBO(String, Object):BusinessObjectInterface
- getBOName(InputStream):String
- getBOName(Reader):String
- getBOName(String):String
- getBooleanOption(String):boolean
- getEncoding():String
- getLocale():Locale
- getOption(String):String
- getStreamFromBO(BusinessObjectInterface, Object):InputStream (Abstract
Method)
- getStringFromBO(BusinessObjectInterface, Object):String (Abstract Method)
- setConfigMOName(String)
- setEncoding(String)
- setLocale(Locale)
- setOption(String, String)
- traceWrite(String, int)
NameHandler (Abstract Class)
DataHandlers/
crossworlds/
com/
- getBOName(Reader, String):String) (Abstract Method)
ConfigurationException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
MalformedDataException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
NotImplementedException (extends java.lang.Exception)
Exceptions/
DataHandlers/
crossworlds/
com/
BusinessObjectInterface
CxCommon/
- clone():Object
- dump():String
- getAppText():String
- getAttrCount():int
- getAttrDesc(int):CxObjectAttr
- getAttrDesc(String):CxObjectAttr
- getAttribute(String):Object
- getAttributeIndex(String):int
- getAttributeType(int):int
- getAttributeType(String):int
- getAttrName(int):String
- getAttrValue(int):Object
- getAttrValue(String):Object
- getBusinessObjectVersion():String
- getDefaultAttrValue(int):String
- getDefaultAttrValue(String):String
- getLocale():String
- getName():String
- getParentBusinessObject():BusinessObjectInterface
- getVerb():String
- getVerbAppText(String):String
- isBlank(int):boolean
- isBlank(String):boolean
- isIgnore(int):boolean
- isIgnore(String):boolean
- isVerbSupported(String):boolean
- makeNewAttrObject(int):Object
- makeNewAttrObject(String):Object
- setAttributeWithCreate(String, Object)
- setAttrValue(int, Object)
- setAttrValue(String, Object)
- setDefaultAttrValues()
- setLocale(Locale)
- setLocale(String)
- setVerb(String)
CxObjectAttr
CxCommon/
- BOOLEAN
- BOOLSTRING
- DATE
- DATESTRING
- DOUBLE
- DOUBSTRING
- FLOAT
- FLTSTRING
- INTEGER
- INTSTRING
- INVALID_TYPE_NUM
- INVALID_TYPE_STRING
- LONGTEXT
- LONGTEXTSTRING
- MULTIPLECARDSTRING
- OBJECT
- SINGLECARDSTRING
- STRING
- STRSTRING
- equals(Object):boolean
- getAppText():String
- getCardinality():String
- getDefault():String
- getMaxLength():int
- getName():String
- getRelationType():String
- getTypeName():String
- getTypeNum():String
- hasCardinality(String):boolean
- hasName(String):boolean
- hasType(String):boolean
- isForeignKeyAttr():boolean
- isKeyAttr():boolean
- isMultipleCard():boolean
- isObjectType():boolean
- isRequiredAttr():boolean
- isType(Object):boolean
CxObjectContainerInterface
CxCommon/
- getBusinessObject(int):BusinessObjectInterface
- getObjectCount():int
- insertBusinessObject(BusinessObjectInterface)
- removeAllObjects()
- removeBusinessObjectAt(int)
- setBusinessObject(int, BusinessObjectInterface)
DtpConnection
Dtp/
CxCommon/
- beginTran()
- commit()
- executeSQL(String)
- executeSQL(String, Vector)
- executeStoredProcedure(String, Vector)
- getUpdateCount():int
- hasMoreRows():boolean
- inTransaction():boolean
- isActive():boolean
- nextRow():Vector
- rollback()
DtpDataConversion
Dtp/
CxCommon/
- BOOL_TYPE - 4
- CANNOTCONVERT - 2
- DATE_TYPE - 5
- DOUBLE_TYPE - 3
- FLOAT_TYPE - 2
- INTEGER_TYPE - 0
- LONGTEXT_TYPE - 6
- OKTOCONVERT - 0
- POTENTIALDATALOSS - 1
- STRING_TYPE - 1
- UNKNOWN_TYPE - 999
- getType(double):int
- getType(float):int
- getType(int):int
- getType(Object):int
- isOKToConvert(int, int):int
- isOKToConvert(String, String):int
- toBoolean(boolean):Boolean
- toBoolean(Object):Boolean
- toDouble(double):Double
- toDouble(float):Double
- toDouble(int):Double
- toDouble(Object):Double
- toFloat(double):Float
- toFloat(float):Float
- toFloat(int):Float
- toFloat(Object):Float
- toInteger(double):Integer
- toInteger(float):Integer
- toInteger(int):Integer
- toInteger(Object):Integer
- toPrimitiveBoolean(Object):boolean
- toPrimitiveDouble(float):double
- toPrimitiveDouble(int):double
- toPrimitiveDouble(Object):double
- toPrimitiveFloat(double):float
- toPrimitiveFloat(int):float
- toPrimitiveFloat(Object):float
- toPrimitiveInt(double):int
- toPrimitiveInt(float):int
- toPrimitiveInt(Object):int
- toString(double):String
- toString(float):String
- toString(int):String
- toString(Object):String
DtpDate
Dtp/
CxCommon/
- DtpDate()
- DtpDate(long, boolean)
- DtpDate(String, String)
- DtpDate(String, String, String[], String[])
- addDays(int):DtpDate
- addMonths(int):DtpDate
- addWeekdays(int):DtpDate
- addYears(int):DtpDate
- after(DtpDate):boolean
- before(DtpDate):boolean
- calcDays(DtpDate):int
- calcWeekdays(DtpDate):int
- get12MonthNames():String[]
- get12ShortMonthNames():String[]
- get7DayNames():String[]
- getCWDate():String
- getDayOfMonth():String
- getDayOfWeek():String
- getHours():String
- getIntDay():int
- getIntDayOfWeek():int
- getIntHours():int
- getIntMilliSeconds():int
- getIntMinutes():int
- getIntMonth():int
- getIntSeconds():int
- getIntYear():int
- getMaxDate(BusObjArray, String, String):DtpDate
- getMaxDateBO(BusObj[], String, String):BusObj[]
- getMaxDateBO(BusObjArray, String, String):BusObj[]
- getMinDate(BusObjArray, String, String):DtpDate
- getMinDateBO(BusObj[], String, String):BusObj[]
- getMinDateBO(BusObjArray, String, String):BusObj[]
- getMinutes():String
- getMonth():String
- getMSSince1970():long
- getNumericMonth():String
- getSeconds():String
- getShortMonth():String
- getYear():String
- set12MonthNames(String[], boolean)
- set12MonthNamesToDefault()
- set12ShortMonthNames(String[])
- set12ShortMonthNamesToDefault()
- set7DayNames(String[])
- set7DayNamesToDefault()
- toString():String
- toString(String):String
- toString(String, boolean):String
DtpMapService
Dtp/
CxCommon/
- runMap(String, String, BusObj[], CxExecutionContext):BusObj[]
DtpSplitString
Dtp/
CxCommon/
- DtpSplitString(String, String)
- elementAt(int):String
- firstElement():String
- getElementCount():int
- getEnumeration():Enumeration
- lastElement():String
- nextElement():String
- prevElement():String
- reset()
DtpUtils
Dtp/
CxCommon/
- padLeft(String, char, int):String
- padRight(String, char, int):String
- stringReplace(String, String, String):String
- truncate(double):int
- truncate(double, int):double
- truncate(float):int
- truncate(float, int):double
- truncate(Object):int
- truncate(Object, int):double
BusObjInvalidVerbException (extends InterchangeExceptions)
Exceptions/
CxCommon/
IdentityRelationship
relationship/
utilities/
crossworlds/
com/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- foreignKeyLookup(String, String, BusObj, String, BusObj, String, CxExecutionContext)
- foreignKeyXref(String, String, String, BusObj, String, BusObj, String,
CxExecutionContext)
- maintainChildVerb(String, String, String, BusObj, String, BusObj, String,
CxExecutionContext, boolean, boolean)
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- updateMyChildren(String, String, BusObj, String, String, String, String,
CxExecutionContext)
MapExeContext
Dtp/
CxCommon/
- ACCESS_REQUEST - "SUBSCRIPTION_DELIVERY"
- ACCESS_RESPONSE - "ACCESS_RETURN_REQUEST"
- EVENT_DELIVERY - "SUBSCRIPTION_DELIVERY"
- SERVICE_CALL_FAILURE - "CONSUME_FAILED"
- SERVICE_CALL_REQUEST - "CONSUME"
- SERVICE_CALL_RESPONSE - "DELIVERBUSOBJ"
- getConnName():String
- getGenericBO():BusObj
- getInitiator():String
- getLocale():java.util.Locale
- getOriginalRequestBO():BusObj
- setConnName(String)
- setInitiator(String)
- setLocale(java.util.Locale)
Participant
RelationshipServices/
Server/
- Participant(String, String, int, BusObj)
- Participant(String, String, int, String)
- Participant(String, String, int, long)
- Participant(String, String, int, int)
- Participant(String, String, int, double)
- Participant(String, String, int, float)
- Participant(String, String, int, boolean)
- Participant(String, String, BusObj)
- Participant(String, String, String)
- Participant(String, String, long)
- Participant(String, String, int)
- Participant(String, String, double)
- Participant(String, String, float)
- Participant(String, String, boolean)
- getBoolean():boolean
- getBusObj():BusObj
- getDouble():double
- getFloat():float
- getInstanceId():int
- getInt():int
- getLong():long
- getParticipantDefinition():String
- getRelationshipDefinition():String
- getString():String INVALID_INSTANCE_ID
- set(boolean)
- set(BusObj)
- set(double)
- set(float)
- set(int)
- set(long)
- set(String)
- setInstanceId(int)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
- setParticipantDefinition(String)
- setRelationshipDefinition(String)
Relationship
RelationshipServices/
Server/
- addMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- addParticipant(Participant):int
- addParticipant(String, String, boolean):int
- addParticipant(String, String, BusObj):int
- addParticipant(String, String, double):int
- addParticipant(String, String, float):int
- addParticipant(String, String, int):int
- addParticipant(String, String, int, boolean):int
- addParticipant(String, String, int, BusObj):int
- addParticipant(String, String, int, double):int
- addParticipant(String, String, int, float):int
- addParticipant(String, String, int, int):int
- addParticipant(String, String, int, long):int
- addParticipant(String, String, int, String):int
- addParticipant(String, String, long):int
- addParticipant(String, String, String):int
- create(Participant):int
- create(String, String, boolean):int
- create(String, String, BusObj):int
- create(String, String, double):int
- create(String, String, float):int
- create(String, String, int):int
- create(String, String, long):int
- create(String, String, String):int
- deactivateParticipant(Participant)
- deactivateParticipant(String, String, boolean)
- deactivateParticipant(String, String, BusObj)
- deactivateParticipant(String, String, double)
- deactivateParticipant(String, String, float)
- deactivateParticipant(String, String, int)
- deactivateParticipant(String, String, long)
- deactivateParticipant(String, String, String)
- deactivateParticipantByInstance(String, String, int)
- deactivateParticipantByInstance(String, String, int, boolean)
- deactivateParticipantByInstance(String, String, int, BusObj)
- deactivateParticipantByInstance(String, String, int, double)
- deactivateParticipantByInstance(String, String, int, float)
- deactivateParticipantByInstance(String, String, int, int)
- deactivateParticipantByInstance(String, String, int, long)
- deactivateParticipantByInstance(String, String, int, String)
- deleteMyChildren(String, String, BusObj, String, CxExecutionContext)
- deleteMyChildren(String, String, BusObj, String, Object, CxExecutionContext)
- deleteParticipant(Participant)
- deleteParticipant(String, String, boolean)
- deleteParticipant(String, String, BusObj)
- deleteParticipant(String, String, double)
- deleteParticipant(String, String, float)
- deleteParticipant(String, String, int)
- deleteParticipant(String, String, long)
- deleteParticipant(String, String, String)
- deleteParticipantByInstance(String, String, int)
- deleteParticipantByInstance(String, String, int, boolean)
- deleteParticipantByInstance(String, String, int, BusObj)
- deleteParticipantByInstance(String, String, int, double)
- deleteParticipantByInstance(String, String, int, float)
- deleteParticipantByInstance(String, String, int, int)
- deleteParticipantByInstance(String, String, int, long)
- deleteParticipantByInstance(String, String, int, String)
- getNewID(String):int
- maintainCompositeRelationship(String, String, BusObj, Object, CxExecutionContext)
- maintainSimpleIdentityRelationship(String, String, BusObj, BusObj, CxExecutionContext)
- retrieveInstances(String, boolean):int[]
- retrieveInstances(String, BusObj):int[]
- retrieveInstances(String, double):int[]
- retrieveInstances(String, float):int[]
- retrieveInstances(String, int):int[]
- retrieveInstances(String, long):int[]
- retrieveInstances(String, String):int[]
- retrieveInstances(String, String, boolean):int[]
- retrieveInstances(String, String, BusObj):int[]
- retrieveInstances(String, String, double):int[]
- retrieveInstances(String, String, float):int[]
- retrieveInstances(String, String, int):int[]
- retrieveInstances(String, String, long):int[]
- retrieveInstances(String, String, String):int[]
- retrieveInstances(String, String[], boolean):int[]
- retrieveInstances(String, String[], BusObj):int[]
- retrieveInstances(String, String[], double):int[]
- retrieveInstances(String, String[], float):int[]
- retrieveInstances(String, String[], int):int[]
- retrieveInstances(String, String[], long):int[]
- retrieveInstances(String, String[], String):int[]
- retrieveParticipants(String):Participant[]
- retrieveParticipants(String, String):Participant[]
- retrieveParticipants(String, String[]):Participant[]
- retrieveParticipants(String, int):Participant[]
- retrieveParticipants(String, String, int):Participant[]
- retrieveParticipants(String, String[], int):Participant[]
- updateMyChildren(String, String, BusObj, String, String, String, String,
CxExecutionContext)
- updateParticipant(String, String, BusObj)
- updateParticipantByInstance(Participant)
- updateParticipantByInstance(String, String, int)
- updateParticipantByInstance(String, String, int, BusObj)
UserStoredProcedureParam
Dtp/
CxCommon/
- UserStoredProcedureParam(int, String, Object, String, String)
- getParamDataTypeJavaObj():String
- getParamDataTypeJDBC():int
- getParamIndex():int
- getParamIOType():String
- getParamName():String
- getParamValue():Object
- setParamDataTypeJavaObj(String)
- setParamDataTypeJDBC(int)
- setParamIndex(int)
- setParamIOType(String)
- setParamName(String)
- setParamValue(Object)
- PARAM_TYPE_IN - "IN"
- PARAM_TYPE_OUT - "OUT"
- PARAM_TYPE_INOUT - "INOUT"
- DATA_TYPE_STRING - "String"
- DATA_TYPE_INTEGER - "Integer"
- DATA_TYPE_DOUBLE - "Double"
- DATA_TYPE_FLOAT - "Float"
- DATA_TYPE_BOOLEAN - "Boolean"
- DATA_TYPE_TIME - "java.sql.Time"
- DATA_TYPE_DATE - "java.sql.Date"
- DATA_TYPE_TIMESTAMP - "java.sql.Timestamp"
- DATA_TYPE_BIG_DECIMAL - "java.math.BigDecimal"
- DATA_TYPE_LONG_INTEGER - "Long"
- DATA_TYPE_BINARY - "byte[]"
- DATA_TYPE_CLOB - "Clob"
- DATA_TYPE_BLOB - "Blob"
- DATA_TYPE_ARRAY - "Array"
- DATA_TYPE_STRUCT - "Struct"
- DATA_TYPE_REF - "Ref"
BaseCollaboration
Collaboration/
- BaseCollaboration(com.ibm.bpe.api.ProcessInstanceData)
- AnyException - "AnyException"
- AppBusObjDoesNotExist - "BusObjDoesNotExist"
- AppLogOnFailure - "AppLogOnFailure"
- AppMultipleHits - "AppMultipleHits"
- AppRequestNotYetSent - "AppRequestNotYetSent"
- AppRetrieveByContentFailed - "AppRetrieveByContent"
- AppTimeOut - "AppTimeOut"
- AppUnknown - "AppUnknown"
- AttributeException - "AttributeException"
- existsConfigProperty(String):boolean
- getConfigProperty(String):String
- getConfigPropertyArray(String):String[]
- getCurrentLoopIndex():int
- getDBConnection(String):CwDBConnection
- getDBConnection(String, boolean):CwDBConnection getLocale():java.util.Locale
- getMessage(int):String
- getMessage(int, Object[]):String
- getName():String
- implicitDBTransactionBracketing():boolean
- isCallerInRole(String):boolean
- isTraceEnabled(int):boolean
- JavaException - "JavaException"
- logError(int)
- logError(int, Object[])
- logError(int, String)
- logError(int, String, String)
- logError(int, String, String, String)
- logError(int, String, String, String, String)
- logError(int, String, String, String, String, String)
- logError(String)
- logInfo(int)
- logInfo(int, Object[])
- logInfo(int, String)
- logInfo(int, String, String)
- logInfo(int, String, String, String)
- logInfo(int, String, String, String, String)
- logInfo(int, String, String, String, String, String)
- logInfo(String)
- logWarning(int)
- logWarning(int, Object[])
- logWarning(int, String)
- logWarning(int, String, String)
- logWarning(int, String, String, String)
- logWarning(int, String, String, String, String)
- logWarning(int, String, String, String, String, String)
- logWarning(String)
- not(boolean):boolean ObjectException - "ObjectException"
- OperationException - "OperationException"
- raiseException(CollaborationException)
- raiseException(String, int)
- raiseException(String, int, Object[])
- raiseException(String, int, String)
- raiseException(String, int, String, String)
- raiseException(String, int, String, String, String)
- raiseException(String, int, String, String, String, String)
- raiseException(String, int, String, String, String, String, String)
- raiseException(String, String)
- ServiceCallException - "ConsumerException"
- ServiceCallTransportException - "ServiceCallTransportException"
- SystemException - "SystemException"
- trace(int, int)
- trace(int, int, Object[])
- trace(int, int, String)
- trace(int, int, String, String)
- trace(int, int, String, String, String)
- trace(int, int, String, String, String, String)
- trace(int, int, String, String, String, String, String)
- trace(int, String)
- trace(String)
- TransactionException - "TransactionException"
CxExecutionContext
CxCommon/
- CxExecutionContext()
- getContext(String):Object
- MAPCONTEXT - "MAPCONTEXT"
- setContext(String, Object)
CollaborationException
Collaboration/
- getMessage():String
- getMsgNumber():int
- getSubType():String
- getText():String
- getType():String
- toString():String
Filter
crossworlds/
com/
- Filter(BaseCollaboration)
- filterExcludes(String, String):boolean
- filterIncludes(String, String):boolean
- recurseFilter(BusObj, String, boolean, String, String):boolean
- recursePreReqs(String, Vector):int
Globals
crossworlds/
com/
- Globals(BaseCollaboration)
- callMap(String, BusObj):BusObj
SmartCollabService
crossworlds/
com/
- SmartCollabService()
- SmartCollabService(BaseCollaboration)
- doAgg(BusObj, String, String, String):BusObj
- doMergeHash(Vector, String, String):Vector
- doRecursiveAgg(BusObj, String, String, String):BusObj
- doRecursiveSplit(BusObj, String):Vector
- doRecursiveSplit(BusObj, String, boolean):Vector
- getKeyValues(BusObj, String):String
- merge(Vector, String):BusObj
- merge(Vector, String, BusObj):BusObj
- split(BusObj, String):Vector
StateManagement
crossworlds/
com/
- StateManagement()
- beginTransaction()
- commit()
- deleteBO(String, String, String)
- deleteState(String, String, String, int)
- persistBO(String, String, String, String, BusObj)
- recoverBO(String, String, String):BusObj
- releaseDBConnection()
- resetData()
- retrieveState(String, String, String, int):int
- saveState(String, String, String, String, int, int, double)
- setDBConnection(CwDBConnection)
- updateBO(String, String, String, String, BusObj)
- updateState(String, String, String, String, int, int)
EventKeyAttrDef
EventManagement/
CxCommon/
- EventKeyAttrDef()
- EventKeyAttrDef(String, String)
- public String keyName
- public String keyValue
EventQueryDef
EventManagement/
CxCommon/
- EventQueryDef()
- EventQueryDef(String, String, String, String, int)
- public String nameConnector
- public String nameCollaboration
- public String nameBusObj
- public String verb
- public int ownerType
FailedEventInfo
EventManagement/
CxCommon/
- FailedEventInfo()
- FailedEventInfo(String x6, int, EventKeyAttrDef[], int, int, String, String,
int)
- public String nameOwner
- public String nameConnector
- public String nameBusObj
- public String nameVerb
- public String strTime
- public String strMessage
- public int wipIndex
- public EventKeyAttrDef[] strbusObjKeys
- public int nKeys
- public int eventStatus
- public String expirationTime
- public String scenarioName
- public int scenarioState
WebSphere InterChange
Server XML からの WebSphere Process Sever DataObject のマップ
レガシー・アダプターを使用して WebSphere Process
Server に接続する場合、下のアルゴリズムを使用すると、どのようにして WebSphere Process
Sever DataObject が WebSphere InterChange Server XML から作成されたのかについて、詳しく理解することができます。この情報には、データ値が配置された場所や、WebSphere InterChange
Server で使用されていたデータ値を置換するために選択されたデータ値が示されます。
一般
- ChangeSummary に verb を設定する場合、設定はすべて markCreate/Update/Delete API を使用して行われます。
- ChangeSummary/EventSummary に verb を設定する場合、Create、Update、および Delete verb が ChangeSummary に設定され、それ以外の verb はすべて EventSummary に設定されます。
- ChangeSummary から verb を取得する場合:
- ロギングを使用可能にしている場合、意図した Update ではなく Create として DataObject が識別されることを避けるには、次の操作を行う必要があります。
- DataObject の作成中はロギングを中断する。
- DataObject の更新の場合にロギングを再開する (または、markUpdated API を使用する)。
ロード (Loading)
「ロード (Loading)」では、WebSphere InterChange
Server ランタイム XML が WebSphere Business Integration BusinessGraph AfterImage インスタンスにロードされます。
- 該当する BusinessGraph のインスタンスが作成されます。
- ChangeSummary ロギングがオンになり、後でこのロギングをオンにしてエントリーをクリアすることがないようにします。
- 不要な情報が ChangeSummary に入力されないようにするため、ChangeSummary ロギングが一時停止されます。
- 最上位の BusinessObject の属性が DataObject に作成されます (下のセクション『属性処理』を参照してください)。
- 最上位の BusinessObject に子の BusinessObject がある場合、再帰的に処理が行われます。
- 子の BusinessObject の属性が DataObject に作成されます (下のセクション『属性処理』を参照してください)。
- 最上位の BusinessObject の verb が BusinessGraph の最上位の verb に設定され、要約内にも設定されます。
- 子の BusinessObject の verb が要約内に設定されます。
保管 (Saving)
「保管 (Saving)」では、WebSphere Business
Integration BusinessGraph AfterImage インスタンスが WebSphere InterChange Server ランタイム XML に保管されます。入力された BusinessGraph が AfterImage ではない場合、例外がスローされます。
属性処理
- 下で説明されていない値はすべて ASIS としてロード/保管されます。
- ObjectEventId は EventSummary にロードされ、EventSummary から保管されます。
- CxBlank および CxIgnore の場合:
- 変換の WebSphere Business
Integration BusinessObject の側では、CxBlank および CxIgnore は次のように設定/識別されます。
- CxIgnore - NULL の Java 値で設定解除/設定を行う
- CxBlank - 下の表にあるように従属値を入力する
- 変換の WebSphere InterChange
Server XML の側では、CxBlank および CxIgnore は次のように設定/識別されます。
表 1. CxBlank および CxIgnore の設定
型 |
CxIgnore |
CxBlank |
整数 |
Integer.MIN_VALUE |
Integer.MAX_VALUE |
浮動 |
Float.MIN_VALUE |
Float.MAX_VALUE |
倍精度 |
Double.MIN_VALUE |
Double.MAX_VALUE |
ストリング/日付/長形式テキスト |
"CxIgnore" |
"" |
子の BusinessObject |
(空のエレメント) |
N/A |
第 4 章 WebSphere MQ Workflow から WebSphere Integration Developer へのマイグレーション
WebSphere Integration
Developer には、WebSphere MQ Workflow からマイグレーションするために必要なツールが用意されています。
マイグレーション・ウィザードを使用すると、WebSphere MQ Workflow の Buildtime コンポーネントからエクスポートしたビジネス・プロセスの
FDL 定義を、WebSphere Integration Developer の対応する成果物に変換することができます。生成された成果物は、ビジネス・オブジェクトの XML 定義、WSDL 定義、BPEL、インポート定義とコンポーネント定義、および TEL 定義を構成します。
変換ツールには、WebSphere MQ Workflow Buildtime からオプション
export deep によってエクスポートするプロセス・モデルのセマンティックに完全な FDL 定義が必要です。このオプションを使用すると、必要なデータ、プログラム、およびサブプロセス仕様のすべてが取り込まれます。また、WebSphere MQ
Workflow プロセス・モデルで参照されるすべてのユーザー定義プロセス実行サーバー定義 (UPES) が、WebSphere MQ
Workflow Buildtime から FDL をエクスポートするときに選択されます。
注: マイグレーション・ウィザードでは、以下のマイグレーションは行いません。
- WebSphere MQ
Workflow ランタイム・インスタンス
- WebSphere MQ
Workflow プログラム実行エージェント (PEA)、または WebSphere MQ Workflow プロセス実行サーバー (PES for z/OS(R)) によって呼び出されるプログラム・アプリケーション
FDL2BPEL 変換ツールを使用したマイグレーションについて詳しくは、WebSphere
MQ Workflow サポート・サイトを参照してください。
WebSphere MQ
Workflow から WebSphere Integration
Developer にマイグレーションする前に、環境が適切に準備されていることを最初に確認する必要があります。
マッピングのスコープと完成度は、以下のマイグレーションのガイドラインにどれだけ準拠しているかによります。
- FDL プログラム・アクティビティーは、純粋なスタッフ・アクティビティーではない場合、ユーザー定義プロセスの実行サーバー (UPES) に関連付けられます。
- WebSphere MQ
Workflow プログラム・アクティビティーのスタッフ割り当てが TEL デフォルトのスタッフ verb に準拠していることを確認してください。
- 短形式の単純名を使用して、マイグレーション済みプロセス・モデルを読みやすくします。
FDL 名が正しくない BPEL 名の場合があることに注意してください。マイグレーション・ウィザードで、自動的に FDL 名を有効な BPEL 名に変換できます。
マイグレーション・ウィザードは、実行可能なビジネス・プロセス・エディター成果物に手動で適用する必要のある、マイグレーションされない WebSphere
MQ Workflow 構成 (PEA または PES プログラム・アクティビティー、動的スタッフ割り当てなど) に対しても、構文的に正しいビジネス・プロセス・エディター構成を作成します。
下の表に、適用されるマッピング・ルールの概要を示します。
表 2. マッピング・ルール
WebSphere MQ Workflow |
WebSphere Integration Developer |
プロセス |
実行モードのプロセス: longRunning; プロセスのインバウンドおよびアウトバウンドのインターフェースのパートナー・リンク |
ソースおよびシンク |
プロセス入力およびプロセス出力の 変数; 受信 アクティビティーおよび応答 アクティビティー |
プログラム・アクティビティー |
呼び出し アクティビティー |
プロセス・アクティビティー |
呼び出し アクティビティー |
空のアクティビティー |
FMCINTERNALNOOP アクティビティー |
ブロック |
組み込み BPEL アクティビティーを持つスコープ |
アクティビティーの終了条件 |
While アクティビティー (実アクティビティーを囲む) |
アクティビティーの開始条件 |
アクティビティーの結合条件 |
アクティビティーのスタッフ割り当て |
ヒューマン・タスク ・アクティビティー |
アクティビティーの入力コンテナーおよび出力コンテナー |
呼び出し アクティビティーの入出力の指定に使用する変数 |
コントロール・コネクター; 遷移状態 |
リンク; 遷移状態 |
データ・コネクター |
割り当て アクティビティー |
グローバル・データ・コンテナー |
変数 |
注: 可能であれば、最初は小さなプロジェクトでマイグレーション・プロセスを試してください。マイグレーション・ウィザードを使用すると、WebSphere MQ Workflow プロセス・モデルをビジネス・プロセス・エディターのプロセス・モデルに簡単に変換できますが、新しいプログラミング・モデルを作成するときと同じようにプロセスを 1 対 1 でマッピングすることはできません。基礎となるプロセス仕様言語 (FDL および BPEL) のセマンティック・スコープには、互いに共通する部分がありますが、完全に重なり合うことはありません。そうでないと、ビジネス・プロセス・エディターの新しい利点が期待できなくなります。Web サービスは、期待を可能にする新しいテクノロジーであり、そこでは使用すべきではないソリューションは新しいソリューションに置き換える必要があります。
一般に、生成された成果物は常時検討し、必要に応じて変更する必要があります。マイグレーションを正常に終了するため、またはマイグレーション・タスクを完了するために、さらに作業が必要になることもあります。
マイグレーション・ウィザードを使用した WebSphere MQ Workflow のマイグレーション
マイグレーション・ウィザードを使用すると、WebSphere MQ Workflow の Buildtime コンポーネントからエクスポートしたビジネス・プロセスの
FDL 定義を、WebSphere Integration Developer の対応する成果物に変換することができます。生成された成果物は、ビジネス・オブジェクトの XML 定義、WSDL 定義、BPEL、インポート定義とコンポーネント定義、および TEL 定義を構成します。
注: マイグレーション・ウィザードでは、以下のマイグレーションは行いません。
- WebSphere MQ
Workflow ランタイム・インスタンス
- WebSphere MQ
Workflow プログラム実行エージェント (PEA)、または WebSphere MQ Workflow プロセス実行サーバー (PES for z/OS) によって呼び出されるプログラム・アプリケーション
「マイグレーション」ウィザードを使用してWebSphere MQ Workflow 成果物をマイグレーションするには、以下の手順に従ってください。
- 「ファイル」 -> 「インポート」 -> 「ビジネス・インテグレーション」 -> 「WebSphere MQ Workflow FDL ファイル」を選択してウィザードを呼び出し、「次へ」をクリックします。
または、「ようこそ」ページから「本製品のご使用経験のある方へ」アイコン
をクリックして「本製品のご使用経験のある方へ」を開くことによって、マイグレーション・ウィザードを開くこともできます (「ヘルプ」 -> 「ようこそ」をクリックすることにより、いつでも「ようこそ」ページに戻ることができます)。
「本製品のご使用経験のある方へ」ページの左側にある「マイグレーション」をクリックして、「マイグレーション」ページを開きます。「マイグレーション」ページから、「WebSphere MQ Workflow プロセスをマイグレーションする」オプション
を選択します。
- マイグレーション・ウィザードがオープンします。
FDL ファイルの絶対パスと名前を「ソース」選択フィールドに入力するか、「参照」ボタンをクリックしてファイル・システムから
FDL ファイルを選択し、ファイルへナビゲートします。モジュール名を関連フィールドに入力してください (処理可能にするためには、「モジュール名」フィールドにモジュール名を入力する必要があります)。
「次へ」をクリックします。
- 「マイグレーション・オプション」ページが開きます。ここでマイグレーションのデフォルトを受け入れるか、チェック・ボックスを選択してオプションを変更することができます。
「名前の競合をエラーとして扱う」チェック・ボックスを選択すると、インターオペラビリティー・エラーとなる可能性のある接尾部が自動的に追加されなくなります。
「事前定義データ・メンバーを初期化する」チェック・ボックスは、事前定義データ・メンバーを初期化するために、プロセスにノードを追加します。
- 「終了」をクリックします。
マイグレーション・ダイアログの下部にある進行状況表示バーに、マイグレーションの進行状況が示されます。マイグレーション・プロセスが完了すると、マイグレーション・ダイアログは消去され、「マイグレーション結果」ウィンドウが開きます。
WebSphere MQ Workflow マイグレーションの検査
マイグレーションがエラー、警告、通知メッセージのリストとともに完了した場合、それらは「マイグレーション結果」ウィンドウに表示されます。マイグレーションが正常に完了した場合は、ウィザードのウィンドウが閉じます。
マイグレーション・メッセージがマイグレーション・プロセス中に生成された場合は、次のページが表示されます。
「マイグレーション結果」ウィンドウには、マイグレーション・プロセスで生成されたマイグレーション・メッセージがリストされます。上部のメッセージ・リストからメッセージを選択すると、そのメッセージに関する詳細が「メッセージの説明」ウィンドウに表示されます。
今後の参照用にすべてのメッセージを保存しておくには、「タスクの生成」ボタンをクリックして、タスクのリストをタスク・ビューに作成するか、「別名保管...」ボタンをクリックしてファイル・システム内のテキスト・ファイルにメッセージを保管するか、またはその両方を行います。生成された予定を表示するには、「ウィンドウ」 -> 「ビューの表示」 -> 「その他... (Other...)」 -> 「一般」 -> 「タスク」をクリックして、「OK」をクリックします。「タスク」ビューが開き、生成された予定のリストがマイグレーション・プロセスから表示されます。
マイグレーション・プロセスの制限 (WebSphere MQ Workflow から)
WebSphere MQ
Workflow マイグレーション・プロセスに関連する特定の制限があります。
- FDL をマイグレーションすると、UPES アクティビティーおよび対応する WSDL の呼び出しアクティビティーが生成されます。ただし、呼び出しメッセージとその応答を関連付けるために使用する手法に関して、IBM(R) WebSphere MQ Workflow と IBM WebSphere Process Server との間ではランタイム環境に大きな違いがあります。
- IBM WebSphere MQ Workflow および IBM WebSphere Process Server のランタイム・エンジンは、未初期化データに対して異なる扱いをします。
IBM WebSphere MQ Workflow ではこれによりエラーが発生することはありませんでしたが、IBM
WebSphere Process Server はこの状況を例外として扱い、プロセスの実行を停止します。マイグレーションされたアプリケーションを IBM WebSphere Process Server で正しく実行するには、すべての変数と副構造が、割り当て、起動、スタッフ、および応答アクティビティーで使用される前に必ず初期化されるようにしてください。
第 5 章 WebSphere Studio Application Developer Integration Edition から WebSphere Integration Developer へのソース成果物のマイグレーション
ソース成果物は、WebSphere Studio Application Developer Integration Edition から
WebSphere Integration Developer にマイグレーションできます。アプリケーションでソース成果物をマイグレーションする場合は、新しい WebSphere Integration
Developer プログラミング・モデルにそれらをマイグレーションして、新しい機能やフィーチャーが使用できるようにする処理も行われます。この後、アプリケーションは WebSphere Process Server に再デプロイおよびインストールすることができます。
WebSphere Business Integration Server
Foundation 5.1 で使用可能な多くのフィーチャーは、ベースの WebSphere Application Server 6.x に移動しました。これらのフィーチャーのマイグレーションに関するヒントについては、WebSphere プログラミング・モデル拡張子 (PME) のマイグレーションを参照してください。
WebSphere Studio Application Developer Integration Edition サービス・プロジェクトを完全にマイグレーションするには、完了すべき基本作業が 3 つあります。
- マイグレーションのためのソース成果物の準備。これらのアクションは、WebSphere Studio Application Developer Integration Edition で実行することが必要である場合があります。
- マイグレーション・ウィザードまたは WSADIEServiceProjectMigration コマンド行スクリプトを使用して、ビジネス・インテグレーション・モジュール・プロジェクトへ成果物を自動的にマイグレーションする。
- WebSphere Integration Developer を使用して手動でマイグレーションを完了する。これには、自動的にはマイグレーションできなかった Java コードの修正と、マイグレーションされた成果物の再ワイヤリングの検査が含まれます。
注: ランタイム・マイグレーション (アップグレード・パス) は WebSphere Process Server 6.x では提供されないため、このソース成果物のマイグレーション・パスは、6.x で WebSphere Studio Integration Edition サービス・プロジェクトをマイグレーションする場合のみのオプションになります。
WebSphere Studio Application Developer Integration Edition からのソース成果物のマイグレーションを開始する前に、WebSphere Integration Developer によってサポートされるマイグレーション・パスを検討する必要があります。
マイグレーション・ウィザードでは、WebSphere Studio Application Developer Integration Edition バージョン 5.1 (またはそれ以上) のサービス・プロジェクトを一度に 1 つマイグレーションすることができます。ワークスペース全体のマイグレーションは行われません。
マイグレーション・ウィザードでは、アプリケーション・バイナリーはマイグレーションされません。
WebSphere Studio Application Developer Integration Edition サービス・プロジェクトにあるソース成果物のみがマイグレーションされます。
ソース成果物を WebSphere
Studio Application Developer Integration Edition から WebSphere Integration Developer にマイグレーションする前に、環境が適切に準備されていることを最初に確認する必要があります。
以下の手順では、ソース成果物を WebSphere Studio Application Developer Integration Edition から WebSphere Integration Developer にマイグレーションする前に環境を準備する方法について説明します。
- マイグレーションを試行する前に、5.1 のワークスペース全体のバックアップ・コピーを取っていることを確認します。
- Rational(R) Application Developer Information Center のマイグレーションのセクションを確認して、ワークスペース内の非 WBI 固有のプロジェクトをマイグレーションする最適な方法を決定します:
WebSphere Studio V5.1、5.1.1、または 5.1.2 からのマイグレーション
- Rational Application Developer によって提供される Web サービス機能の背景情報について、Rational Application Developer
Information Center の Web サービス・セクションを参照してください:
Developing Web services
- 該当するすべての WebSphere Integration Developer フィーチャーが使用可能になっていることを確認します。これらのフィーチャーが使用可能になっていないと、以下で説明するメニュー・オプションが表示されないことがあります。重要なフィーチャーを使用可能にするには、以下を行います。
- WebSphere Integration Developer で、「ウィンドウ」メニュー項目に進み、
「設定」を選択します。
- 「ワークベンチ」に進み、
「機能」カテゴリーを選択します。
- 以下のカテゴリーの下のすべてのフィーチャーを選択します。
- 拡張 J2EE
- エンタープライズ Java
- Integration デベロッパー
- Java デベロッパー
- Web デベロッパー (Typical)
- Web サービス・デベロッパー
- XML デベロッパー
- 「OK」をクリックします。
- WebSphere Integration
Developer 用に新しいワークスペース・ディレクトリーを使用します。サービス・プロジェクトが含まれている古い WebSphere Studio Application Developer Integration Edition ワークスペースで
WebSphere Integration Developer を開くことはお勧めしません。このプロジェクトは、WebSphere
Integration Developer が読み取ることができるフォーマットに最初にマイグレーションする必要があるためです。これを行うための推奨ステップは、以下のとおりです。
- すべての非サービス・プロジェクトを古いワークスペースから新しいワークスペースにコピーします。
5.1 のサービス・プロジェクト用にデプロイメント・コードが生成されたときに作成された 5.1 の EJB、Web、および EAR プロジェクトはコピーしないでください。
新しい 6.x のデプロイメント・コードは、BI モジュールがビルドされるときに自動的に生成されます。
- ブランクのワークスペースで WebSphere Integration Developer を開き、「ファイル」 -> 「インポート」 -> 「一般」 -> 「既存プロジェクトをワークスペースへ」をクリックしてすべての非サービス・プロジェクトをインポートし、新しいワークスペースへコピーしたプロジェクトを選択します。
- プロジェクトが J2EE プロジェクトである場合、Rational Application Developer マイグレーション・ウィザードを使用して、以下のように、そのプロジェクトを 1.4 レベルにマイグレーションする必要があります。
- プロジェクトを右クリックして、「マイグレーション」 -> 「J2EE マイグレーション・ウィザード... (J2EE Migration Wizard...)」を選択します。
- 最初のページの警告文を確認して、特に指示がない場合は「次へ」をクリックします。
- プロジェクト・リスト内の「J2EE プロジェクト (J2EE project)」にチェック・マークが付いていることを確認します。
「プロジェクト構造をマイグレーションする」および「J2EE 仕様レベルをマイグレーションする (Migrate J2EE specification level)」は、チェック・マークが付いたままにしてください。
J2EE バージョン 1.4 および「ターゲット・サーバー WebSphere Process Server v6.0」を選択します。
- J2EE プロジェクトに適切なその他のオプションがあれば選択して、
「終了」をクリックします。このステップが正常に完了すると、
「マイグレーションが正常に終了しました (Migration finished successfully)」というメッセージが表示されます。
- マイグレーション後に J2EE プロジェクトにエラーがある場合は、
v5 の .jar ファイルまたはライブラリーを参照しているすべてのクラスパス・エントリーを除去して、代わりにクラスパスに JRE システム・ライブラリーおよび WPS サーバー・ターゲット・ライブラリーを追加する必要があります (下記に説明があります)。これで、多くのエラーが解決されるはずですが、一部のエラーが解決されない場合もあります。
- 拡張メッセージング (CMM) または Container Managed Persistence over Anything (CMP/A) を使用する
WebSphere Business Integration EJB プロジェクトの場合、5.1 のプロジェクトが 6.x のワークスペースにインポートされた後で、IBM EJB JAR 拡張記述子ファイルをマイグレーションする必要があります。詳しくは、『WebSphere Business Integration EJB プロジェクトのマイグレーション』を参照してください。
- ワークスペースにインポートした非サービス・プロジェクトごとにクラスパスを修正します。クラスパスに JRE および WebSphere Process Server ライブラリーを追加するには、インポートしたプロジェクトを右クリックして、「プロパティー」を選択します。
「Java のビルド・パス」エントリーに移動して、「ライブラリー」タブを選択します。次に、以下を行います。
- 「ライブラリーの追加」 -> 「JRE システム・ライブラリー」 -> 「代替 JRE - WPS Server v6.0 JRE」 -> 「終了」を選択します。
- 次に、「ライブラリーの追加」 -> 「WPS サーバー・ターゲット」 -> 「WPS サーバー・クラスパスの構成」 -> 「終了」を選択します。
- デフォルトでは、WebSphere Integration Developer はビルド時にデプロイ・コードを生成します。
- サービス・プロジェクト内の .bpel ファイルを完全にマイグレーションするために、.bpel ファイルによって参照されるすべての .wsdl および .xsd ファイルが新しいワークスペースのビジネス・インテグレーション・プロジェクトで解決可能であることを確認する必要があります。
- .wsdl および/または .xsd ファイルが .bpel ファイルと同じサービス・プロジェクトにある場合は、これ以上のアクションは不要です。
- .wsdl ファイルまたは .xsd ファイル (あるいは、その両方) が、マイグレーションしているサービス・プロジェクトとは異なるサービス・プロジェクト内にある場合、マイグレーションの前に WebSphere Studio Application Developer Integration Edition を使用して、5.1 の成果物を再編成する必要があります。これを行う理由は、ビジネス・インテグレーション・モジュールのプロジェクトが成果物を共用できないためです。以下は、5.1 の成果物を再編成するための 2 つのオプションです。
- WebSphere Studio Application Developer Integration Edition で、すべての共通成果物を保持する新規 Java プロジェクトを作成します。複数のサービス・プロジェクトによって共用されるすべての .wsdl ファイルおよび .xsd ファイルを、この新規 Java プロジェクト内に置きます。この新規 Java プロジェクトの依存関係を、これらの共通成果物を使用するすべてのサービス・プロジェクトに追加します。
WebSphere Integration Developer で、サービス・プロジェクトをマイグレーションする前に、5.1 の共用 Java プロジェクトと同じ名前を持つ、新規ビジネス・インテグレーション・ライブラリー・プロジェクトを作成します。古い .wsdl ファイルと .xsd ファイルを、5.1 の共用 Java プロジェクトからこの新規 BI ライブラリー・プロジェクト・フォルダーに手動でコピーします。これは、BPEL サービス・プロジェクトのマイグレーションを行う前に行う必要があります。
- もう 1 つのオプションは、サービス・プロジェクト間での依存関係がない各サービス・プロジェクトで、これらの共用の .wsdl 成果物と .xsd 成果物のローカル・コピーを保持することです。
- .wsdl および/または .xsd ファイルが他のタイプのプロジェクト (通常、他の Java プロジェクト) にある場合は、
5.1 のプロジェクトと同じ名前を持つビジネス・インテグレーション・ライブラリー・プロジェクトを作成する必要があります。また、新しいライブラリー・プロジェクトのクラスパスもセットアップする必要があります。このとき、5.1 の Java プロジェクトからのエントリーがあればそれを追加します。このタイプのプロジェクトは、共用成果物の保管に役立ちます。
これでマイグレーション・プロセスを開始する準備ができました。
ソース成果物マイグレーション・プロセスの考慮事項
WebSphere Studio
Application Developer Integration Edition ソース成果物マイグレーション・プロセスには多数の考慮事項があります。
次の事例は、WebSphere
Studio Application Developer Integration Edition サービスが、新しいプログラミング・モデルに確実に正しくマイグレーションされるように設計する方法を示しています。
- 可能であれば、「割り当て」アクティビティーを使用してみてください
(これは、拡張変換が必要な場合にのみ必要とされる変換プログラム・サービスとは対照的です)。この事例を使用しなければならない理由は、
SCA モジュールが変換プログラム・サービスを呼び出すには、中間コンポーネントを構成する必要があるためです。さらに、WebSphere Integration Developer には、バージョン 5.1 で作成された変換プログラム・サービス用の特殊ツールのサポートはありません (変換プログラム・サービスの動作を変更する必要がある場合は、
WSDL または XML エディターを使用して、WSDL ファイルに組み込まれた XSLT を変更する必要があります)。
- Web サービス・インターオペラビリティー (WS-I) 仕様と 6.x 優先スタイルのとおり、WSDL メッセージあたりに 1 つのパーツを指定します。
- WSDL doc-literal スタイルは 6.x の優先スタイルであるため、これを使用してください。
- すべての複合型に名前が付いていること、およびそれぞれの複合型がそのターゲット名前空間と名前によって一意的に識別可能であることを確認してください。以下に、複合型およびその型のエレメントを定義するのに推奨される方法を示します
(複合型定義の後に、その複合型定義で使用するエレメント定義が続きます)。
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<complexType name="Duration">
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
<element name="DurationElement" type="tns:Duration"/>
</schema>
以下の例は、SDO が XML
(匿名複合型定義が含まれているエレメント) にシリアライズされるときに問題の原因となることがあるため、避けなければならない匿名複合型です。
<schema attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
<element name="DurationElement">
<complexType>
<all>
<element name="hours" type="int"/>
<element name="minutes" type="int"/>
<element name="days" type="int"/>
</all>
</complexType>
</element>
</schema>
- 外部コンシューマー向けサービスを公開する場合は (Apache SOAP/HTTP ではなく)、
IBM Web Services を使用してサービス・デプロイ・コードを生成します。これは、IBM Web Services は 6.x で直接サポートされているが、Apache Web サービスはサポートされていないためです。
- WSDL および XSD ファイルを 5.1 で編成して、マイグレーション中に実行しなければならない再編成の量を最小限にするには、2 つの方法があります。
6.x では、WSDL ファイルや XSD ファイルなどの共用成果物を BI サービスによって参照させるために、これらを BI プロジェクト
(Business Integration modules および libraries) に配置する必要があります。
- サービス・プロジェクトが参照できる Java プロジェクト内の複数のサービス・プロジェクトによって共有されるすべての WSDL ファイルを保持します。
6.x へのマイグレーションで、5.1 の共用 Java プロジェクトと同じ名前を持つ新しいビジネス・インテグレーション・ライブラリーを作成します。
5.1 の共用 Java
プロジェクトから、すべての成果物をこのライブラリーにコピーして、これらの成果物を使用するサービス・プロジェクトをマイグレーションするときに、マイグレーション・ウィザードが成果物を解決できるようにしてください。
- サービス・プロジェクトが、そのサービス・プロジェクト自体の中で参照するすべての WSDL/XSD ファイルのローカル・コピーを保持します。
WebSphere Studio Application
Developer Integration Edition サービス・プロジェクトは、WebSphere Integration Developer の Business Integration Module にマイグレーションされ、モジュールは他のモジュールとの依存関係を持つことができません (WSDL ファイルまたは XSD ファイルを共有するために別のサービス・プロジェクトと依存関係を持つサービス・プロジェクトは、クリーンにマイグレーションされません)。
- Business Process Choreographer Generic Messaging API (Generic MDB) は 6.x では提供されないため、使用しないでください。
MDB インターフェース・オファリング遅延バインディングは 6.x では使用できません。
- 特定バージョンのプロセスに特有の生成済みセッション
Bean を呼び出す代わりに、Business Process Choreographer Generic EJB API を使用してください。これらのセッション Bean は、6.x では生成されません。
- 同じ操作に対して複数の応答を持つビジネス・プロセスがある場合、いずれかにクライアント設定があれば、その操作に対するすべての応答が同じクライアント設定を持っていることを確認してください。
6.x では、操作応答ごとに 1 セットのクライアント設定のみがサポートされるためです。
- 次のガイドラインに準拠して、BPEL Java Snippet を設計してください。
- WSIFMessage パラメーターを任意のカスタム Java クラスに送らないでください。可能であれば、WSIFMessage データ・フォーマットに依存しないようにしてください。
- 可能であれば、WSIF メタデータ API を使用しないでください。
- WSDL ポート・タイプ/メッセージから生成された Java/EJB スケルトンは WSIF クラス
(WSIFFormatPartImpl など) に依存するため、トップダウンの EJB または Java
サービスを作成することはできるだけ避けてください。その代わり、Java/EJB インターフェースを作成してから、Java クラス/EJB にサービスを生成してください (ボトムアップのアプローチ)。
- soapenc:Array タイプを参照する WSDL インターフェースを作成したり、使用しないようにしてください。このタイプのインターフェースは、SCA プログラミング・モデルではネイティブにサポートされないためです。
- ハイレベル・エレメント (maxOccurs 属性が 1 より大きい) が配列型のメッセージ・タイプは作成しないようにしてください。このタイプのインターフェースは、SCA プログラミング・モデルではネイティブにサポートされていないためです。
- WSDL インターフェースは正確に定義し、
xsd:anyType タイプへの参照を持つ XSD complexTypes の使用はできるだけ避けてください。
- EJB または Java Bean から生成するすべての WSDL および XSD について、ターゲット名前空間が固有であることを確認してください (Java クラス名およびパッケージ名はターゲット名前空間によって表されます)。これは、WebSphere Process Server 6.x へマイグレーションしたときに競合を避けるためです。WebSphere Process Server 6.x では、同じ名前とターゲット名前空間を持つ 2 つの異なる WSDL/XSD 定義は許されません。この状況は、ターゲット名前空間を明示して指定しないで Web サービス・ウィザードまたは
Java2WSDL コマンドが使用される場合によく起こります
(ターゲット名前空間が EJB または
Java Bean のパッケージ名に対しては固有であるが、クラス自体に対して固有でないため、
Web サービスが同一パッケージ内で 2 つ以上の EJB
または Java Bean に対して生成される場合に問題が発生します)。この解決方法は、Web サービス・ウィザードで名前空間マッピングにカスタム・パッケージを指定するか、 -namespace Java2WSDL コマンド行オプションを使用して、生成されるファイルの名前空間が所定のクラスに対して固有となるようにすることです。
- すべての WSDL ファイルに、できるだけ固有の名前空間を使用してください。
WSDL 1.1 仕様に準拠した同一の名前空間を持つ 2 つの異なる WSDL ファイルのインポートについては制限があり、WebSphere
Integration Developer 6.x では、これらの制限が厳密に強制されます。
WebSphere Integration Developer マイグレーション・ウィザードを使用したサービス・プロジェクトのマイグレーション
WebSphere Integration
Developer マイグレーション・ウィザードを使用して、サービス・プロジェクトをマイグレーションできます。
注:
- サービス・プロジェクトを、その依存関係の順序でマイグレーションする必要があります。例えば、サービス・プロジェクト A 内の BPEL がサービス・プロジェクト B 内の BPEL に対してプロセス間呼び出しを行う場合、サービス・プロジェクト B はサービス・プロジェクト A より前にマイグレーションしなければなりません。
そうしないと、プロセス間呼び出しを正しく構成できません。
- WebSphere Integration Developer Migration 6.0.2 以降では、自動ビルドを使用不可にする必要はありません。自動ビルドは、マイグレーション・プロセス中に自動的にオフになります。
マイグレーション・ウィザードは、以下を行います。
- 新規ビジネス・インテグレーション・モジュールを作成します (モジュール名は定義済みです)。
- サービス・プロジェクトのクラスパス・エントリーを新しいモジュールにマイグレーションします。
- すべての WebSphere Business
Integration Server Foundation ソース成果物を、選択されているソース・プロジェクトからこのモジュールにコピーします。
- WSDL ファイル内の BPEL 拡張機能をマイグレーションします。
- ビジネス・プロセス (.bpel ファイル) を BPEL4WS バージョン 1.1 から WebSphere Process Server でサポートされている新しいレベルにマイグレーションします。これは、今度の WS-BPEL バージョン 2.0 仕様の主要な機能を備えた BPEL4WS バージョン 1.1 に組み込まれています。
- .bpel プロセスごとに SCA コンポーネントを作成します。
- WebSphere Studio Application
Developer Integration Edition からデフォルト・モニター動作を保存するために BPEL プロセスごとにモニター .mon ファイルを生成します (必要な場合)。
- WebSphere Studio Application Developer Integration Edition で選択されたデプロイ・オプションに応じて、インポートおよびエクスポートを作成します。
- BPEL コンポーネントをそのパートナー・リンク (インポート、エクスポート、および Java コンポーネント) にワイヤリングします。
WebSphere Integration Developer Migration ウィザードを使用してサービス・プロジェクトをマイグレーションするには、以下の手順に従います。
- 「ファイル」 -> 「インポート」 -> 「ビジネス・インテグレーション」 -> 「WebSphere Studio Application Developer Integration Edition サービス・プロジェクト」を選択してウィザードを呼び出し、「次へ」をクリックします。
または、「ようこそ」ページから「本製品のご使用経験のある方へ」アイコン
をクリックして「本製品のご使用経験のある方へ」を開くことによって、マイグレーション・ウィザードを開くこともできます (「ヘルプ」 -> 「ようこそ」をクリックすることにより、いつでも「ようこそ」ページに戻ることができます)。
「本製品のご使用経験のある方へ」ページの左側にある「マイグレーション」をクリックして、「マイグレーション」ページを開きます。「マイグレーション」ページから、「Integration Edition 5.1 サービス・プロジェクトをマイグレーションする」オプション
を選択します。
- マイグレーション・ウィザードがオープンします。「ソース選択」にパスを入力するか、または 「参照」ボタンをクリックしてパスを見つけます。また、マイグレーションする WebSphere Studio Application Developer Integration Edition サービス・プロジェクトのロケーションのモジュール名を入力します。
注:
サービス・プロジェクトの名前にはモジュール名を選択することをお勧めします。これは、WebSphere Studio Application Developer Integration Edition ワークスペース内にこのプロジェクトに従属する他のプロジェクトがある場合、これらの従属プロジェクトを WebSphere Integration Developer にインポートした後に、従属プロジェクトのクラスパスを更新する必要がなくなるためです。
- 「マイグレーション」オプションから、「オリジナルの BPEL Java Snippet をコメントに保存する」チェック・ボックスを選択します。
「終了」をクリックします。
- マイグレーション・プロセスが完了すると、「マイグレーション結果」ウィンドウが開きます。
これらのマイグレーション・メッセージを含むログ・ファイルが、
6.x のワークスペースの .metadata フォルダーに自動的に生成されます。ログ・ファイルの名前は「.log」になります。
マイグレーション・ウィザードの完了後、作成されたビジネス・インテグレーション・モジュールをビルドし、ビルド・エラーがあれば解決を試みます。すべてのマイグレーション済み .bpel ファイルを検査します。ファイルが完全にマイグレーションされていて、WebSphere Integration Developer BPEL エディターで開くことができることを確認します。
BPEL Java Snippet には、自動的にマイグレーションできないものもあります。
BPEL Java Snippet にエラーを見つけた場合は、エラーの修正に必要なステップについて、『SCA プログラミング・モデルへのマイグレーション』を参照してください。また、マイグレーション・ウィザードを使用してサービス・プロジェクトを BI モジュールにマイグレーションする場合、モジュール依存関係エディターを開き、依存関係が正しく設定されていることを確認します。これを行うには、ビジネス・インテグレーション・パースペクティブに切り替えて、「ビジネス・インテグレーション・モジュール・プロジェクト」をダブルクリックします。ここでビジネス・インテグレーション・ライブラリー・プロジェクト、Java プロジェクト、および J2EE プロジェクトへの依存関係を追加できます。
WSADIEServiceProjectMigration を使用したサービス・プロジェクトのマイグレーション
WSADIEServiceProjectMigration コマンドを使用すると、サービス・プロジェクトのマイグレーションを行うことができます。
マイグレーション・コマンドは、以下を行います。
- 新規ビジネス・インテグレーション・モジュールを作成します (モジュール名は定義済みです)。
- サービス・プロジェクトのクラスパス・エントリーを新しいモジュールにマイグレーションします。
- すべての WebSphere Business
Integration Server Foundation ソース成果物を、選択されているソース・プロジェクトからこのモジュールにコピーします。
- WSDL ファイル内の BPEL 拡張機能をマイグレーションします。
- ビジネス・プロセス (.bpel ファイル) を BPEL4WS バージョン 1.1 から WebSphere Process Server でサポートされている新しいレベルにマイグレーションします。これは、今度の WS-BPEL バージョン 2.0 仕様の主要な機能を備えた BPEL4WS バージョン 1.1 に組み込まれています。
- .bpel プロセスごとに SCA コンポーネントを作成します。
- WebSphere Studio Application
Developer Integration Edition からデフォルト・モニター動作を保存するために BPEL プロセスごとにモニター .mon ファイルを生成します (必要な場合)。
- WebSphere Studio Application Developer Integration Edition で選択されたデプロイ・オプションに応じて、インポートおよびエクスポートを作成します。
- BPEL コンポーネントをそのパートナー・リンク (インポート、エクスポート、および Java コンポーネント) にワイヤリングします。
注: サービス・プロジェクトを、その依存関係の順序でマイグレーションする必要があります。例えば、サービス・プロジェクト A 内の BPEL がサービス・プロジェクト B 内の BPEL に対してプロセス間呼び出しを行う場合、サービス・プロジェクト B はサービス・プロジェクト A より前にマイグレーションしなければなりません。そうしないと、プロセス間呼び出しを正しく構成できません。
WSADIEServiceProjectMigration スクリプトを実行するには、以下の手順に従ってください。
- WebSphere Integration Developer のインストール時に指定した共用フォルダーを開いて、スクリプトを見つけます。例えば、スクリプトは次の場所に置かれています。SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0
- 次のようにしてスクリプトを呼び出します。WSADIEServiceProjectMigration
-e eclipse_dir -s source_project_dir -d workspace [-t target_project_name]
[-preserveSnippets true|false] [-debug]
パラメーターの定義:
- -e eclipse_dir
- Eclipse フォルダー (Eclipse ランタイム) のロケーション。
- -s source_project_dir
- WebSphere Studio Application Developer Integration Edition 5.1 サービス・プロジェクトへの絶対パス。
- -d workspace
- 新しいビジネス・インテグレーション・モジュールを作成するワークスペース。
- -t target_project_name
- 作成する新しいビジネス・インテグレーション・モジュールの名前。デフォルトは、マイグレーションされる WebSphere Studio Application Developer Integration Edition 5.1 プロジェクトと同じです。
- -preserveSnippets flag
- コメント化された既存の BPEL Java Snippet の保存を有効または無効にします。デフォルトは true です。
- -debug flag
- デバッグ出力を有効にします。
例:
WSADIEServiceProjectMigration -e WID_HOME¥eclipse" -d "¥myWIDworkspace" -s
"¥¥MyServiceProject" -t "MyBIModuleName" -preserveSnippets false -debug
- コマンドが完了した後、WebSphere Integration Developer で新しいワークスペースを開始します。
- 作成されたビジネス・インテグレーション・モジュールをビルドし、ビルド・エラーがあれば解決を試みます。すべてのマイグレーション済み .bpel ファイルを検査します。ファイルが完全にマイグレーションされていて、WebSphere Integration Developer BPEL エディターで開くことができることを確認します。
BPEL Java Snippet には、自動的にマイグレーションできないものもあります。
BPEL Java Snippet でエラーが表示された場合は、『SCA プログラミング・モデルへのマイグレーション』でエラーの修正に必要な手順を参照してください。
- モジュール依存関係エディターを開き、依存関係が正しく設定されていることを確認します。これを行うには、ビジネス・インテグレーション・パースペクティブに切り替えて、「ビジネス・インテグレーション・モジュール・プロジェクト」をダブルクリックします。ここでビジネス・インテグレーション・ライブラリー・プロジェクト、Java プロジェクト、および J2EE プロジェクトへの依存関係を追加できます。
アプリケーションのマイグレーションの完了
マイグレーション・ウィザードで成果物を新しいビジネス・インテグレーション・モジュールに正常にマイグレーションした後で、成果物をワイヤリングして SCA モデルに準拠するアプリケーションを作成する必要があります。マイグレーション・ウィザードが成果物を正常にマイグレーションしようとした場合でも、手動による検査は行うべきです。このセクションにある情報は、マイグレーションが正しかったことを確認するために使用できます。
- WebSphere Integration
Developer を開き、ビジネス・インテグレーション・パースペクティブに切り替えます。マイグレーション・ウィザードによって作成されたモジュール (マイグレーションされたサービス・プロジェクトごとに 1 つのモジュール) が表示されます。モジュール・プロジェクトの下にリストされた最初の成果物は、モジュールのアセンブリー・ファイルです (これはモジュールと同じ名前を持ちます)。
- アセンブリー・ファイルをダブルクリックしてアセンブリー・エディターで開きます。このエディターで SCA コンポーネントを作成およびワイヤリングすれば、バージョン 5.1 アプリケーションと同様の機能を得ることができます。
WebSphere Studio Application
Developer Integration Edition サービス・プロジェクトに BPEL プロセスがあれば、マイグレーション・ウィザードはこのプロセスごとにデフォルト SCA コンポーネントを作成しているので、そのコンポーネントがアセンブリー・エディターに表示されます。
- コンポーネントを選択し、「プロパティー」ビューに移動します。このビューでは、「説明」、「詳細」、および「実装」プロパティーが表示され、それらを編集することができます。
一部のプロジェクトでは、マイグレーションの後、5.1 で接続されていたとおりにサービスを再接続するために、何らかの再ワイヤリングが必要です。次の情報では、WebSphere Integration Developer に用意されたツールを使用してアプリケーションを手動で再ワイヤリングする方法について詳しく説明します。
再ワイヤリングのためにアプリケーション内のサービス用 SCA コンポーネントおよび SCA インポートを作成
マイグレーションされたすべてのビジネス・プロセスを、そのビジネス・パートナーにワイヤリングする必要があります。その他のすべてのサービス・タイプ用に、SCA コンポーネントまたはインポートを作成する必要があります。プロジェクトの外部にあるシステムまたはエンティティーと対話する WebSphere Studio Application Developer Integration Edition サービス・プロジェクトでは、マイグレーションされたプロジェクトが、
SCA モデルに従ってこれらのエンティティーにサービスとしてアクセスするために、
SCA インポートを作成することができます。
注: マイグレーション・ユーティリティーは、これを自動的に行おうとしますが、以下の情報を参照して、ツールが何を行うかを確認することができます。
プロジェクト内のエンティティー (例えば、ビジネス・プロセス、変換プログラム・サービス、または Java クラス) と対話する WebSphere Studio Application Developer Integration Edition サービス・プロジェクトでは、マイグレーションされたプロジェクトが、
SCA モデルに従ってこれらのエンティティーにサービスとしてアクセスするために、
SCA インポートを作成することができます。
以下のセクションでは、マイグレーションする必要のあるサービスのタイプに基づいて作成する SCA インポートまたは SCA コンポーネントの詳細を説明します。
Java サービスのマイグレーション
Java
サービスを SCA Java コンポーネントにマイグレーションすることができます。
WebSphere Studio Application Developer Integration Edition サービス・プロジェクトが他の Java プロジェクトに依存していた場合は、既存のプロジェクトを新しいワークスペース・ディレクトリーにコピーし、
「ファイル」 -> 「インポート」 -> 「一般」 -> 「既存プロジェクトをワークスペースへ」ウィザードを使用して、それらの既存プロジェクトを WebSphere Integration Developer にインポートします。
WebSphere Studio Application Developer Integration Edition では、既存の Java クラスから新規の Java サービスを生成するときに、以下のオプションが提供されます。
- 複合データ型の XSD スキーマを作成する
- インターフェース WSDL ファイル内に
- データ型ごとに新規ファイルとして
- エラー処理機能をサポートする
- バインディングおよびサービス名などを生成するサービスに関する他の詳細
データ・マッピング、インターフェース・メディエーション、ビジネス・ステート・マシン、セレクター、ビジネス・ルールなど、新しい機能を提供する多くの新規コンポーネントがあります。まず最初に、これらの新規コンポーネントのいずれかでカスタム Java コンポーネントを置き換えることができるかどうかを判断します。それが不可能な場合は、下記のマイグレーション・パスに従ってください。
マイグレーション・ウィザードを使用してサービス・プロジェクトをインポートします。この結果、ビジネス・インテグレーション・モジュールが作成され、
WSDL メッセージ、ポート・タイプ、バインディング、およびサービスが WebSphere Studio Application Developer Integration Edition に生成されます。
ビジネス・インテグレーション・パースペクティブでモジュールを展開し、内容を参照します。モジュール・プロジェクトの下にある最初の項目をダブルクリックしてアセンブリー・エディターを開きます (これはプロジェクトと同じ名前になります)。
以下のオプションがあります。
カスタム Java コンポーネントの作成: オプション 1
推奨されるマイグレーション手法は、Java サービスを 1 つの SCA コンポーネントとして表せるようにする、WebSphere Integration Developer Java コンポーネント・タイプを使用するものです。マイグレーション時に、SCA Java インターフェース・スタイルと既存の Java コンポーネントのインターフェース・スタイルの間で変換されるように、カスタム Java コードが作成されている必要があります。
カスタム Java コンポーネントを作成するには、以下の手順に従ってください。
- モジュール・プロジェクトで、「インターフェース」を展開して、WebSphere Studio Application Developer Integration 内のこの Java クラス用に生成された WSDL インターフェースを選択します。
- このインターフェースをアセンブリー・エディターにドラッグ・アンド・ドロップします。作成するコンポーネントのタイプを選択するように求めるダイアログがポップアップ表示されます。
「実装タイプのないコンポーネント」を選択して、
「OK」をクリックします。
- アセンブリー・ダイアグラムに、汎用コンポーネントが表示されます。そのコンポーネントを選択して、「プロパティー」ビューに進みます。
- 「記述」タブで、コンポーネントの名前を変更して、より分かりやすい名前で表示することができます。
- 「詳細」タブで、このコンポーネントに 1 つのインターフェース (アセンブリー・エディターにドラッグ・アンド・ドロップしたインターフェース) があることが分かります。
- アクセスを試みている Java クラスがサービス・プロジェクト自体の中に含まれていない場合は、そのクラスがサービス・プロジェクトのクラスパス上にあることを確認します。
- モジュール・プロジェクトを右クリックして、
「依存関係エディターを開く...」を選択します。
「Java」セクションで、古い Java クラスが含まれているプロジェクトがリストされていることを確認します。リストされていない場合は、「追加...」をクリックして追加します。
- アセンブリー・エディターに戻り、作成したばかりのコンポーネントを右クリックして、
「実装の生成...」 -> 「Java」を選択します。
Java の実装が生成されるパッケージを選択します。これにより、SCA プログラミング・モデル (複合型は commonj.sdo.DataObject であるオブジェクトによって表され、単純型はそれと同等の Java オブジェクトによって表される) に準拠した WSDL インターフェースに従ったスケルトン Java サービスが作成されます。
下記のコードの例は、以下を示しています。
- 5.1 の WSDL インターフェースからの関連する定義
- WSDL に対応する WebSphere Studio Application Developer Integration Edition 5.1 Java メソッド
- 同じ WSDL 用の WebSphere Integration Developer 6.x Java メソッド
以下のコードは、5.1 の WSDL インターフェースからの関連する定義を示しています。
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://migr.practice.ibm.com/"
xmlns:xsd1="http://migr.practice.ibm.com/">
<complexType name="StockInfo">
<all>
<element name="index" type="int"/>
<element name="price" type="double"/>
<element name="symbol" nillable="true"
type="string"/>
</all>
</complexType>
</schema>
</types>
<message name="getStockInfoRequest">
<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
<part name="result" type="xsd1:StockInfo"/>
</message>
<operation name="getStockInfo" parameterOrder="symbol">
<input message="tns:getStockInfoRequest"
name="getStockInfoRequest"/>
<output message="tns:getStockInfoResponse"
name="getStockInfoResponse"/>
</operation>
以下のコードは、WSDL に対応する WebSphere Studio Application Developer Integration Edition 5.1 Java メソッドを示しています。
public StockInfo getStockInfo(String symbol)
{
return new StockInfo();
}
public void setStockPrice(String symbol, float newPrice)
{
// 何かを設定する
}
以下のコードは、同じ WSDL 用の WebSphere Integration Developer 6.x Java メソッドを示しています。
public DataObject getStockInfo(String aString) {
//TODO 実装する必要がある
return null;
}
public void setStockPrice(String symbol, Float newPrice) {
//TODO 実装する必要がある
}
ここで、生成された Java 実装クラスの中の「//TODO」タグで示されている部分に、コードを入力する必要があります。次の 2 つのオプションがあります。
- ロジックをオリジナルの Java クラスからこのクラスに移動し、DataObject を使用するように適合させます。
- WebSphere Studio Application Developer Integration Edition でトップダウン・アプローチを選択しており、Java コンポーネントに DataObject パラメーターを扱わせたい場合には、これが推奨されるオプションです。
WebSphere Studio Application Developer Integration Edition の WSDL 定義から生成された Java クラスが、除去する必要がある WSIF 依存関係を持っているため、この再作業が必要になります。
- この生成済み Java クラスの内側に、古い Java クラスの専用インスタンスを作成し、以下のことを行うためのコードを作成します。
- 生成された Java 実装クラスのすべてのパラメーターを、古い Java クラスが期待するパラメーターに変換する。
- 変換されたパラメーターを使用して、古い Java クラスの専用インスタンスを呼び出す。
- 古い Java クラスの戻り値を、生成された Java 実装メソッドで宣言されている戻り値の型に変換する。
- このオプションは、新しい 6.x スタイルの Java コンポーネントが WSIF サービス・プロキシーを利用する必要がある利用シナリオで、推奨されます。
上記のオプションの 1 つが完了したら、Java サービスを再ワイヤリングする必要があります。参照は存在しないはずであるため、必要なのは Java コンポーネントのインターフェースの再ワイヤリングのみです。
- このサービスが同じモジュール内のビジネス・プロセスによって呼び出される場合は、該当するビジネス・プロセス参照からこの Java コンポーネントのインターフェースへのワイヤーを作成します。
- このサービスが別のモジュール内のビジネス・プロセスによって呼び出される場合は、
SCA バインディング付きエクスポートを作成し、このエクスポートを他のモジュールからそのモジュールのアセンブリー・エディターにドラッグ・アンド・ドロップして、対応する SCA バインディング付きインポートを作成します。該当するビジネス・プロセス参照をそのインポートにワイヤリングします。
- このサービスが、外部での公開のために WebSphere Studio Application Developer Integration Edition で公開されていた場合、サービスの再公開の方法については、セクション『マイグレーション済みサービスにアクセスするために SCA エクスポートを作成』を参照してください。
Java Web サービスの作成: オプション 2
考慮すべき代替オプションは、Java クラスに Web サービスを作成できる、Rational Application Developer Web サービス・ツールです。
注: このオプションでは、Web サービス・ウィザードを呼び出す前に、WebSphere Integration Developer を介して Web サービス・ランタイムが構成されていることが必要です。
WebSphere Studio Application Developer Integration Edition でボトムアップのアプローチを使用して Java クラスに WSDL を生成する場合は、以下の手順を実行してください。
- 新しい Web プロジェクトを作成し、この Web プロジェクトの Java ソース・フォルダーに、サービスをビルドする Java クラスをコピーします。
- サービスを作成している Java クラスのコンテナーであるエンタープライズ・アプリケーション・プロジェクトを右クリックします。
- 「プロパティー」を選択し、「サーバー」プロパティーで、「ターゲット・ランタイム」が「WebSphere Process Server v6.1」に設定され、「デフォルト・サーバー」が、インストール済みの「WebSphere Process Server v6.1」に設定されていることを確認します。
- テスト・サーバーを開始し、そのサーバーにこのアプリケーションをデプロイして、正常に開始されるようにします。
- 次に、サービスを作成したい Java クラスを右クリックして、「Web サービス」 -> 「Web サービスの作成」を選択します。
- 「Web サービス・タイプ (Web Service Type)」について、
「Java Bean Web サービス (Java bean Web Service)」を選択し、
Web サービスを今すぐにデプロイしたい場合を除き、
「Web プロジェクトの Web サービスを開始」オプションのチェック・マークを外します。オプションで、クライアント・プロキシーの生成も選択できます。
「次へ」をクリックします。
- 右クリックした Java クラスが表示されるので、
「次へ」をクリックします。
- ここで、サービス・デプロイメント・オプションを構成する必要があります。
「編集...」をクリックします。サーバー・タイプには、「WPS Server v6.1」を選択し、Web サービス・ランタイムには、「IBM WebSphere」および「J2EE バージョン 1.4 (J2EE version 1.4)」を選択します。これを行うことで有効な組み合わせを選択できない場合は、v1.4 レベルへの J2EE プロジェクトのマイグレーションについて、セクション『マイグレーションの準備』を参照してください。「OK」をクリックします。
- サービス・プロジェクトについて、Web プロジェクトの名前を入力します。また、該当する EAR プロジェクトも選択します。
「次へ」をクリックします。このとき、数分間待たなければならない場合があります。
- 「Web サービス Java Bean の識別」パネルで、
WSDL 定義を入れる WSDL ファイルを選択します。
Web サービスで公開したいメソッドを選択し、該当するスタイル/エンコード
(文書/リテラル、RPC/リテラル、または RPC/エンコード) を選択します。
「パッケージから名前空間へのカスタム・マッピングを定義する」オプションを選択し、この Java クラスのインターフェースで使用するすべての
Java
パッケージについて、マイグレーションされる Java クラス内で固有な名前空間を選択します
(デフォルトの名前空間は、パッケージ名が固有ですが、同じ Java
クラスを使用する別の Web サービスを作成する場合に、競合が発生する可能性があります)。適宜、その他のパラメーターを入力します。
- 「次へ」をクリックし、「Web サービスのパッケージから名前空間へのマッピング」パネルで「追加」をクリックし、作成される行に Java Bean のパッケージ名を入力してから、この Java
クラスを一意的に識別するカスタム名前空間を追加します。
Java Bean インターフェースで使用するすべての Java パッケージに対して、マッピングの追加を続行します。
- 「次へ」をクリックします。このとき、数分間待たなければならない場合があります。
- 「終了」をクリックします。サービス・プロジェクトが Java サービスのコンシューマーであった場合には、ウィザードが完了した後、
Java サービスを記述する生成済み WSDL ファイルをビジネス・インテグレーション・モジュール・プロジェクトにコピーする必要があります。このプロジェクトは、フォルダー WebContent/WEB-INF/wsdl の下の生成済みルーター Web プロジェクトの中にあります。ビジネス・インテグレーション・モジュール・プロジェクトの更新/再ビルドを行ってください。
- ビジネス・インテグレーション・パースペクティブに切り替え、モジュールを展開して、次に「Web サービス・ポート」論理カテゴリーを展開します。
- 前のステップで作成されたポートを選択し、そのポートをアセンブリー・エディターにドラッグ・アンド・ドロップして、
Web サービス・バインディング付きインポートの作成を選択します。プロンプトが出されたら、Java クラスの WSDL インターフェースを選択します。これで、5.1 で Java コンポーネントを利用する SCA コンポーネントをこのインポートにワイヤリングして、手動による再ワイヤリングのマイグレーション・ステップを完了することができます。
このインターフェースは 5.1 のインターフェースと多少の違いがあり、
5.1 コンシューマーと新しいインポートの間にインターフェース・メディエーション・コンポーネントを挿入することが必要な場合があります。これを行うためには、アセンブリー・エディターでワイヤー・ツールをクリックして、
SCA ソース・コンポーネントを、この新しい Web サービス・バインディング付きインポートにワイヤリングします。インターフェースが異なるため、
「ソース・ノードとターゲット・ノードにマッチング・インターフェースがありません。」というプロンプトが出されます。
ソース・ノードとターゲット・ノードの間にインターフェース・マッピングを作成することを選択します。アセンブリー・エディターで作成されたマッピング・コンポーネントをダブルクリックします。これにより、マッピング・エディターが開きます。インターフェース・マッピングの作成についての説明は、インフォメーション・センターを参照してください。
WebSphere Studio Application Developer Integration Edition でトップダウンのアプローチを使用していた場合は、
WSDL 定義から Java クラスを生成した後、以下の手順を実行してください。
- 新しい Web プロジェクトを作成し、Java スケルトンにしたい WSDL ファイルを、この Web プロジェクトのソース・フォルダーにコピーします。
- Java スケルトンの生成元にしたいポート・タイプが含まれている WSDL ファイルを右クリックして、
「Web サービス」 -> 「Java bean スケルトンを生成 (Generate Java bean skeleton)」を選択します。
- Web サービスのタイプ「スケルトン Java bean Web サービス (Skeleton Java bean Web Service)」を選択して、ウィザードを完了します。
ウィザードを完了した後は、サービス・インターフェースを実装する
Java クラスが作成され、それは WSIF API に依存したものではないはずです。
各 Java サービス再ワイヤリング・オプションの利点と欠点
Java サービス再ワイヤリング・オプションにはそれぞれ、利点と欠点があります。
以下のリストで、両方のオプションと、それぞれの利点および欠点について説明します。
- 最初のオプションでは、Web サービスが Java コンポーネントより遅い速度で呼び出されるため、実行時のパフォーマンスが向上する可能性があります。
- 最初のオプションはコンテキストを伝搬することができますが、
Web サービスの呼び出しでは同じようにコンテキストを伝搬することはできません。
- 2 番目のオプションには、カスタム・コードの作成が含まれません。
- Java サービスの生成には制限があるため、
2 番目のオプションは一部の Java インターフェース定義には使用可能でない場合があります。
Rational Application Developer の資料 Web サービスの制限を参照してください。
- 2 番目のオプションでは、結果としてインターフェースが変更され、そのために SCA コンシューマーにも変更が生じる可能性があります。
- 2 番目のオプションでは、WebSphere Process Server 6.x サーバーがインストールされ、WebSphere Integration Developer と連動するように構成されている必要があります。
WebSphere Integration Developer と連動するように構成されているインストール済みランタイムを調べるには、「ウィンドウ」 -> 「設定」 -> 「サーバー」 -> 「インストール済みランタイム」に進み、「WebSphere Process Server v6.1」エントリーがあれば選択し、それが製品のインストールされているロケーションを指していることを確認します。サーバーが存在する場合にはこのエントリーにチェックマークが付けられ、このサーバーが実際にはインストールされていない場合にはチェックマークが外されていることを確認してください。また、「追加...」をクリックして、別のサーバーを追加することもできます。
- Java コンポーネントが、WSDL から Java スケルトンを生成するトップダウンのアプローチを使用して WebSphere Studio Application Developer Integration Edition に組み込まれている場合は、この Java クラス内外のパラメーターはおそらく WSIFFormatPartImpl をサブクラス化します。このような場合は、オプション 1 を選択してオリジナルの WSDL/XSD から新しい SCA スタイルの Java スケルトンを生成するか、またはオプション 2 を選択してオリジナルの WSDL インターフェースから (WSIF または DataObject API に依存しない) 新しい汎用 Java スケルトンを生成してください。
EJB サービスのマイグレーション
EJB サービスをステートレス・セッション Bean バインディング付き SCA インポートにマイグレーションできます。
WebSphere Studio Application Developer Integration Edition サービス・プロジェクトが別の EJB、EJB クライアント、または Java プロジェクトに依存していた場合は、「ファイル」 -> 「インポート」 -> 「一般」 -> 「既存プロジェクトをワークスペースへ」ウィザードを使用して、それらの既存プロジェクトをインポートします。これは、EJB がサービス・プロジェクトから参照される場合の通常のケースでした。サービス・プロジェクトから参照される WSDL または XSD ファイルが別のタイプのプロジェクトに存在する場合、古い非サービス・プロジェクトと同じ名前を使用して新しいビジネス・インテグレーション・ライブラリーを作成し、成果物をすべてこのライブラリーにコピーします。
マイグレーション・ウィザードを使用してサービス・プロジェクトをインポートします。この結果、ビジネス・インテグレーション・モジュールが作成され、
WSDL メッセージ、ポート・タイプ、バインディング、およびサービスが WebSphere Studio Application Developer Integration Edition に生成されます。
ビジネス・インテグレーション・パースペクティブでモジュールを展開し、内容を参照します。モジュール・プロジェクトの下にある最初の項目をダブルクリックしてアセンブリー・エディターを開きます (これはプロジェクトと同じ名前になります)。
以下のオプションがあります。
カスタム EJB コンポーネントの作成: オプション 1
推奨されるマイグレーション手法は、
SCA コンポーネントとしてステートレス・セッション EJB を呼び出すことができるようにする、ステートレス・セッション・バインディング・タイプの WebSphere Integration Developer Import を使用することです。マイグレーション時に、SCA Java インターフェースのスタイルと既存の EJB インターフェースのスタイルの間で変換されるように、カスタムの Java コードが作成されている必要があります。
注: マイグレーション・ツールは自動的にこれを処理しますが、マイグレーション後に、EJB インターフェースに含まれるインターフェースとデータ型 (ビジネス・オブジェクト) に行った変更は、ここに記されている変換コードに対する手動更新を必要とします。行った変更のタイプによっては、WebSphere Integration Developer でエラーが表示されます。
カスタム EJB コンポーネントを作成するには、以下の手順に従ってください。
- モジュール・プロジェクトの下で、「インターフェース」を展開して、WebSphere Studio Application Developer Integration 内でこの EJB 用に生成された WSDL インターフェースを選択します。
- このインターフェースをアセンブリー・エディターにドラッグ・アンド・ドロップします。作成するコンポーネントのタイプを選択するように求めるダイアログがポップアップ表示されます。
「実装タイプのないコンポーネント」を選択して、
「OK」をクリックします。
- アセンブリー・ダイアグラムに、汎用コンポーネントが表示されます。そのコンポーネントを選択して、「プロパティー」ビューに進みます。
- 「記述」タブで、コンポーネントの名前を変更して、より分かりやすい名前で表示することができます。
EJB の名前に類似した名前を選択してください。ただし、このコンポーネントは WebSphere Studio Application Developer Integration の EJB 用に生成された WSDL インターフェースと、その EJB の Java インターフェースとの間を仲介する
Java コンポーネントになるため、その名前に「JavaMed」などの接尾部を付加します。
- 「詳細」タブで、このコンポーネントに 1 つのインターフェース (アセンブリー・エディターにドラッグ・アンド・ドロップしたインターフェース) があることが分かります。
- アセンブリー・エディターに戻り、作成したばかりのコンポーネントを右クリックして、
「実装の生成...」 -> 「Java」を選択します。
Java の実装が生成されるパッケージを選択します。これにより、SCA プログラミング・モデル (複合型は commonj.sdo.DataObject であるオブジェクトによって表され、単純型はそれと同等の Java オブジェクトによって表される) に準拠した WSDL インターフェースに従ったスケルトン Java サービスが作成されます。
下記のコードの例は、以下を示しています。
- 5.1 の WSDL インターフェースからの関連する定義
- WSDL に対応する WebSphere Studio Application Developer Integration Edition 5.1 Java メソッド
- 同じ WSDL 用の WebSphere Integration Developer 6.x Java メソッド
以下のコードは、5.1 の WSDL インターフェースからの関連する定義を示しています。
<types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="qualified"
elementFormDefault="unqualified"
targetNamespace="http://migr.practice.ibm.com/"
xmlns:xsd1="http://migr.practice.ibm.com/">
<complexType name="StockInfo">
<all>
<element name="index" type="int"/>
<element name="price" type="double"/>
<element name="symbol" nillable="true"
type="string"/>
</all>
</complexType>
</schema>
</types>
<message name="getStockInfoRequest">
<part name="symbol" type="xsd:string"/>
</message>
<message name="getStockInfoResponse">
<part name="result" type="xsd1:StockInfo"/>
</message>
<operation name="getStockInfo" parameterOrder="symbol">
<input message="tns:getStockInfoRequest"
name="getStockInfoRequest"/>
<output message="tns:getStockInfoResponse"
name="getStockInfoResponse"/>
</operation>
以下のコードは、WSDL に対応する WebSphere Studio Application Developer Integration Edition 5.1 Java メソッドを示しています。
public StockInfo getStockInfo(String symbol)
{
return new StockInfo();
}
public void setStockPrice(String symbol, float newPrice)
{
// 何かを設定する
}
以下のコードは、同じ WSDL 用の WebSphere Integration Developer 6.x Java メソッドを示しています。
public DataObject getStockInfo(String aString) {
//TODO 実装する必要がある
return null;
}
public void setStockPrice(String symbol, Float newPrice) {
//TODO 実装する必要がある
}
生成された Java 実装クラスの中の「//TODO」タグで示されている部分には、最終的に実際のコードを入力する必要があります。まず最初に、この Java コンポーネントから実際の EJB への参照を作成して、これが SCA プログラミング・モデルに従って EJB にアクセスできるようにする必要があります。
- アセンブリー・エディターを開いたままにして、J2EE パースペクティブに切り替えます。サービスの作成対象の EJB が含まれている EJB プロジェクトを見つけます。
- その「デプロイメント記述子: <project-name> (Deployment Descriptor: <project-name>)」項目を展開して、
EJB を見つけます。これをアセンブリー・エディターにドラッグ・アンド・ドロップします。更新を必要としているプロジェクト依存関係に関する警告が出された場合は、
「モジュール依存関係エディターを開き、... (Open
the module dependency editor...)」チェック・ボックスを選択して、
「OK」をクリックします。
- J2EE セクションの下に、EJB プロジェクトがリストされていることを確認し、リストされていない場合は、「追加...」をクリックして追加します。
- モジュール依存関係を保管し、そのエディターを閉じます。新しいインポートがアセンブリー・エディターに作成されていることが分かります。そのインポートを選択し、「記述」タブの「プロパティー」ビューに進み、そのインポートの名前を変更して、より分かりやすい名前で表示できます。「バインディング」タブでは、インポート・タイプが自動的に「ステートレス・セッション Bean バインディング」に設定され、すでに EJB の JNDI 名が適切に設定されていることが分かります。
- アセンブリー・エディターのパレットから、ワイヤー・ツールを選択します。
- Java コンポーネントをクリックして、マウスを放します。
- 次に、「EJB インポート」をクリックして、マウスを放します。
- 「ソース・ノード上にマッチング参照が作成されます。続行しますか?」が表示されたら、
「OK」をクリックします。これにより、2 つのコンポーネント間にワイヤーが作成されます。
- アセンブリー・エディター内および「詳細」タブの「プロパティー」ビューで
Java コンポーネントを選択し、「参照」を展開して、作成したばかりの EJB への参照を選択します。生成された名前があまり分かりやすくないか、適切でない場合は、参照の名前を更新できます。この参照の名前は、将来の利用のために覚えておいてください。
- アセンブリー・ダイアグラムを保管します。
生成された Java クラスから EJB を呼び出すためには、SCA プログラミング・モデルを使用する必要があります。生成された Java クラスを開き、以下の手順に従って、EJB サービスを呼び出すコードを作成します。生成された Java 実装クラスについて、以下のようにします。
- 次の private 変数 (タイプがリモート EJB インターフェースのもの) を作成します。
private YourEJBInterface ejbService = null;
- EJB インターフェースに複合型がある場合は、BOFactory 用の private 変数も作成します。
private BOFactory boFactory = (BOFactory)
ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo
/BOFactory");
- Java 実装クラスのコンストラクターで、SCA API を使用して、
EJB 参照を解決し (前のステップで作成した EJB 参照の名前を入力してください)、この参照と等しい private 変数を設定します。
// EJB サービスを見つける
this.ejbService = (YourEJBInterface)
ServiceManager.INSTANCE.locateService("name-of-your-ejb-reference");
生成された Java 実装クラスの中にあるそれぞれの「//TODO」について、以下のようにします。
- すべてのパラメーターを、EJB が期待するパラメーター・タイプに変換します。
- SCA プログラミング・モデルを使用して、EJB 参照上の該当メソッドを呼び出し、変換されたパラメーターを送信します。
- EJB の戻り値を、生成された
Java 実装メソッドによって宣言された戻り値の型に変換します。
/**
* Method generated to support the implementing WSDL port type named
* "interface.MyBean".
*/
public DataObject getStockInfo(String aString) {
DataObject boImpl = null;
try {
// EJB メソッドを呼び出す
StockInfo stockInfo = this.ejbService.getStockInfo(aString);
// 戻す SCA データ・オブジェクトを組み立てる
boImpl = (DataObject)
this.boFactory.createByClass(StockInfo.class);
// EJB 戻りの型からのすべてのデータを戻す SCA
// データ・オブジェクトに手動で変換する
boImpl.setInt("index", stockInfo.getIndex());
boImpl.setString("symbol", stockInfo.getSymbol());
boImpl.setDouble("price", stockInfo.getPrice());
} catch (RemoteException e) {
e.printStackTrace();
}
return boImpl;
}
/**
* Method generated to support the implementing WSDL port type named
* "interface.MyBean".
*/
public void setStockPrice(String symbol, Float newPrice) {
try {
this.ejbService.setStockPrice(symbol, newPrice.floatValue());
} catch (RemoteException e) {
e.printStackTrace();
}
}
EJB Web サービスの作成: オプション 2
考慮すべき代替オプションは、EJB に Web サービスを作成できる、Rational Application Developer Web サービス・ツールです。
注: このオプションでは、Web サービス・ウィザードを呼び出す前に、WebSphere Integration Developer を介して Web サービス・ランタイムが構成されていることが必要です。
EJB に Web サービスを作成するには、以下の手順に従ってください。
- サービスを作成している EJB のコンテナーであるエンタープライズ・アプリケーション・プロジェクトを右クリックします。
- 「プロパティー」を選択し、「サーバー」プロパティーで、「ターゲット・ランタイム」が「WebSphere Process Server v6.1」に設定され、「デフォルト・サーバー」が、インストール済みの「WebSphere Process Server v6.1」に設定されていることを確認します。
- テスト・サーバーを開始し、そのサーバーにこのアプリケーションをデプロイして、正常に開始されるようにします。
- J2EE パースペクティブで、「プロジェクト・エクスプローラー」ビューの「EJB プロジェクト」を展開します。
「デプロイメント記述子 (Deployment Descriptor)」を展開し、次に「セッション Bean」カテゴリーを展開します。
Web サービスを生成する Bean を生成します。
- 右クリックして、「Web サービス」 -> 「Web サービスの作成」を選択します。
- 「Web サービス・タイプ (Web Service Type)」について、
「EJB Web サービス」を選択し、Web サービスを今すぐにデプロイしたい場合を除いて
「Web プロジェクトの Web サービスを開始 (Start Web service in Web project)」オプションのチェック・マークを外します。
「次へ」をクリックします。
- 右クリックした EJB がここで選択されていることを確認して、
「次へ」をクリックします。
- ここで、サービス・デプロイメント・オプションを構成する必要があります。
「編集...」をクリックします。サーバー・タイプには、「WPS Server v6.1」を選択し、Web サービス・ランタイムには、「IBM WebSphere」 および「J2EE バージョン 1.4 (J2EE version 1.4)」を選択します。これを行うことで有効な組み合わせを選択できない場合は、
v1.4 レベルへの J2EE プロジェクトのマイグレーションについて、セクション『マイグレーションの準備』を参照してください。
「OK」をクリックします。
- サービス・プロジェクトについて、EJB が含まれている EJB プロジェクトの名前を入力します。また、該当する EAR プロジェクトも選択します。
「次へ」をクリックします。このとき、数分間待たなければならない場合があります。
- 「Web サービス EJB の構成」パネルで、使用する該当ルーター・プロジェクトを選択します
(作成したいルーター Web プロジェクトの名前を選択すると、このプロジェクトは、オリジナルの EJB と同じエンタープライズ・アプリケーションに追加されます)。希望するトランスポート (「HTTP 上の SOAP」または 「JMS 上の SOAP」) を選択します。
「次へ」をクリックします。
- WSDL 定義を入れる WSDL ファイルを選択します。
Web サービスで公開したいメソッドを選択し、該当するスタイル/エンコード
(文書/リテラル、RPC/リテラル、または RPC/エンコード) を選択します。
「パッケージから名前空間へのカスタム・マッピングを定義する」オプションを選択し、
EJB で使用するすべての
Java
パッケージについて、マイグレーションされる EJB 内で固有な名前空間を選択します
(デフォルトの名前空間は、パッケージ名が固有ですが、同じ Java
クラスを使用する別の Web サービスを作成する場合に、競合が発生する可能性があります)。適宜、その他のパラメーターを入力します。それぞれのスタイル/エンコードの組み合わせには、制限があります。詳しくは、次の制限を参照してください: Web サービスの制限
- 「次へ」をクリックし、「Web サービスのパッケージから名前空間へのマッピング」パネルで「追加」をクリックし、作成される行に EJB のパッケージ名を入力してから、この EJB を一意的に識別するカスタム名前空間を追加します。EJB インターフェースで使用するすべての Java パッケージに対して、マッピングの追加を続行します。
- 「次へ」をクリックします。このとき、数分間待たなければならない場合があります。
- 「終了」をクリックします。サービス・プロジェクトが EJB サービスのコンシューマーであった場合には、ウィザードが完了した後、
EJB サービスを記述する生成済み WSDL ファイルをビジネス・インテグレーション・モジュール・プロジェクトにコピーする必要があります。このプロジェクトは、フォルダー WebContent/WEB-INF/wsdl の下の生成済みルーター Web プロジェクトの中にあります。ビジネス・インテグレーション・モジュール・プロジェクトの更新/再ビルドを行ってください。
- ビジネス・インテグレーション・パースペクティブに切り替え、マイグレーションされたモジュールを展開し、次に「Web サービス・ポート」論理カテゴリーを展開します。
- 前のステップで生成されたポートを選択し、そのポートをアセンブリー・エディターにドラッグ・アンド・ドロップして、
Web サービス・バインディング付きインポートの作成を選択します。プロンプトが出されたら、EJB の WSDL インターフェースを選択します。これで、5.1 で EJB を利用する SCA コンポーネントをこのインポートにワイヤリングして、手動による再ワイヤリングのマイグレーション・ステップを完了することができます。
WebSphere Studio Application Developer Integration Edition でトップダウンのアプローチを使用していた場合は、
WSDL 定義から EJB スケルトンを生成した後、以下の手順を実行してください。
- 新しい Web プロジェクトを作成し、EJB スケルトンの生成元にしたい WSDL ファイルを、この Web プロジェクトのソース・フォルダーにコピーします。
- EJB スケルトンの生成元にしたいポート・タイプが含まれている WSDL ファイルを右クリックして、
「Web サービス」 -> 「Java bean スケルトンを生成」を選択します。
- Web サービスのタイプ「スケルトン EJB Web サービス」を選択して、ウィザードを完了します。
ウィザードを完了した後は、サービス・インターフェースを実装する EJB が作成され、それは WSIF API に依存したものではないはずです。
このインターフェースは 5.1 のインターフェースと多少の違いがあり、
5.1 コンシューマーと新しいインポートの間にインターフェース・メディエーション・コンポーネントを挿入することが必要な場合があります。これを行うためには、アセンブリー・エディターでワイヤー・ツールをクリックして、
SCA ソース・コンポーネントを、この新しい Web サービス・バインディング付きインポートにワイヤリングします。インターフェースが異なるため、
「ソース・ノードとターゲット・ノードにマッチング・インターフェースがありません。」というプロンプトが出されます。
ソース・ノードとターゲット・ノードの間にインターフェース・マッピングを作成することを選択します。アセンブリー・エディターで作成されたマッピング・コンポーネントをダブルクリックします。これにより、マッピング・エディターが開きます。インターフェース・マッピングの作成についての説明は、インフォメーション・センターを参照してください。
これが完了したら、EJB サービスを再ワイヤリングする必要があります。参照は存在しないはずであるため、必要なのは Java コンポーネントのインターフェースの再ワイヤリングのみです。
- このサービスが同じモジュール内のビジネス・プロセスによって呼び出される場合は、該当するビジネス・プロセス参照からのこの EJB コンポーネントへのワイヤーを作成します。
- このサービスが別のモジュール内のビジネス・プロセスによって呼び出される場合は、SCA バインディング付きエクスポートを作成し、このエクスポートを他のモジュールからそのモジュールのアセンブリー・エディターにドラッグ・アンド・ドロップして、対応する SCA バインディング付きインポートを作成します。該当するビジネス・プロセス参照をそのインポートにワイヤリングします。
- このサービスが、外部での公開のために WebSphere Studio Application Developer Integration Edition で公開されていた場合、サービスの再公開の方法については、セクション『マイグレーション済みサービスにアクセスするために SCA エクスポートを作成』を参照してください。
各 EJB サービス再ワイヤリング・オプションの利点と欠点
EJB サービス再ワイヤリング・オプションにはそれぞれ、利点と欠点があります。
以下のリストで、両方のオプションと、それぞれの利点および欠点について説明します。
- 最初のオプションでは、Web サービスが EJB より遅い速度で呼び出されるため、実行時のパフォーマンスが向上する可能性があります。
- 最初のオプションはコンテキストを伝搬することができますが、
Web サービスの呼び出しでは同じようにコンテキストを伝搬することはできません。
- 2 番目のオプションには、カスタム・コードの作成が含まれません。
- EJB サービスの生成には制限があるため、
2 番目のオプションは一部の EJB インターフェース定義には使用可能でない場合があります。
Rational Application
Developer の資料 Web サービスの制限を参照してください。
- 2 番目のオプションでは、結果としてインターフェースが変更され、そのために SCA コンシューマーにも変更が生じる可能性があります。
- 2 番目のオプションでは、WebSphere Process Server 6.x サーバーがインストールされ、WebSphere Integration Developer と連動するように構成されている必要があります。
WebSphere Integration Developer と連動するように構成されているインストール済みランタイムを調べるには、「ウィンドウ」 -> 「設定」 -> 「サーバー」 -> 「インストール済みランタイム」に進み、「WebSphere Process Server v6.1」エントリーがあれば選択し、それが製品のインストールされているロケーションを指していることを確認します。サーバーが存在する場合にはこのエントリーにチェックマークが付けられ、このサーバーが実際にはインストールされていない場合にはチェックマークが外されていることを確認してください。また、「追加...」をクリックして、別のサーバーを追加することもできます。
- Java コンポーネントが、WSDL から EJB スケルトンを生成するトップダウンのアプローチを使用して WebSphere Studio Application Developer Integration Edition に組み込まれている場合は、この Java クラス内外のパラメーターはおそらく WSIFFormatPartImpl をサブクラス化します。このような場合は、オプション 2 を選択してオリジナルの WSDL インターフェースから (WSIF または DataObject API に依存しない) 新しい汎用 EJB スケルトンを生成してください。
ビジネス・プロセス・サービス呼び出しへのビジネス・プロセスのマイグレーション
このシナリオは、別のビジネス・プロセスを呼び出すビジネス・プロセスに適用されます。この場合、2 番目のビジネス・プロセスは、WSIF プロセス・バインディングを使用して呼び出されます。本セクションでは、ワイヤーまたは SCA バインディング付きインポート/エクスポートを使用して、
BPEL を BPEL サービス呼び出しにマイグレーションする方法を説明します。
アウトバウンド・サービス・マイグレーション用のプロセス (BPEL) バインディング・サービス・プロジェクトをマイグレーションするには、以下の手順に従います。
- ビジネス・インテグレーション・パースペクティブでモジュールを展開し、内容を参照します。モジュール・プロジェクトの下にある最初の項目をダブルクリックしてアセンブリー・エディターを開きます (これはプロジェクトと同じ名前になります)。
- BPEL プロセスが別の BPEL プロセスを呼び出すことができるシナリオは複数あります。以下のシナリオから、ご使用のアプリケーションに適用されるものを見つけてください。
- 呼び出される BPEL が同じモジュール内にある場合、最初の BPEL コンポーネント上の該当する参照から、ターゲット BPEL コンポーネント上の該当するインターフェースへのワイヤーを作成します。
- 呼び出される BPEL が別のモジュールにある場合
(もう一方のモジュールがマイグレーション済みサービス・プロジェクトの場合)、以下のようにします。
- モジュールのアセンブリー・ダイアグラムに、2 番目のビジネス・プロセスの SCA バインディング付きエクスポートを作成します。
- 「ビジネス・インテグレーション」ビューのナビゲーターで、
2 番目のモジュールのアセンブリー・アイコンを展開します。作成したばかりのエクスポートが表示されます。
- 2 番目のモジュールの「ビジネス・インテグレーション」ビューから、最初のモジュールの開いているアセンブリー・エディターにエクスポートをドラッグ・アンド・ドロップします。これによって、最初のモジュール内に SCA バインディング付きインポートが作成されます。このサービスが、外部での公開のために WebSphere Studio Application Developer Integration Edition で公開されていた場合は、セクション『マイグレーション済みサービスにアクセスするために SCA エクスポートを作成』を参照してください。
- 最初のビジネス・プロセスの該当する参照から、モジュール内に作成したばかりのインポートにワイヤリングします。
- アセンブリー・ダイアグラムを保管します。
- 2 番目のビジネス・プロセスを呼び出す際に遅延バインディングを行うには、以下のようにします。
- 1 番目のビジネス・プロセス・コンポーネントの参照をワイヤリングされていないままにします。
BPEL エディターで 1 番目のプロセスを開き、
「参照パートナー」セクションの下で、遅延バインディングを使用して呼び出す 2 番目の BPEL プロセスに対応するパートナーを選択します。
- 「記述」タブの「プロパティー」ビューで、
2 番目のビジネス・プロセスの名前を「プロセス・テンプレート (Process Template)」フィールドに入力します。
- ビジネス・プロセスを保管します。これで、遅延バインド呼び出しのセットアップを終了しました。
Web サービスのマイグレーション (SOAP/JMS)
Web サービス (SOAP/JMS) を、Web サービス・バインディング付き SCA インポートにマイグレーションできます。
アウトバウンド・サービス・マイグレーション用の SOAP/JMS サービス・プロジェクトをマイグレーションするには、以下の手順に従ってください。
- 最初に、マイグレーション・ウィザードを使用してサービス・プロジェクトをインポートする必要があります。この結果、ビジネス・インテグレーション・モジュールが作成され、WSDL メッセージ、ポート・タイプ、バインディング、およびサービスが WebSphere Studio
Application Developer Integration Edition に生成されます。このアプリケーションが起動する IBM Web サービス (SOAP/JMS) も、マイグレーションされる WebSphere Studio Application Developer Integration Edition Web サービスである場合には、マイグレーション時に Web サービスへの更新が行われた可能性があります。 その場合、ここでは Web サービスのマイグレーション済み WSDL ファイルを使用してください。
- ビジネス・インテグレーション・パースペクティブでモジュールを展開し、内容を参照できるようにします。 モジュール・プロジェクトの下にある最初の項目をダブルクリックしてアセンブリー・エディターを開きます (これはプロジェクトと同じ名前になります)。
- 次に、インポートを追加して、アプリケーションが SCA プログラミング・モデルに従って IBM Web サービスと (SOAP/JMS を介して) 対話できるようにします。
WSDL インターフェース、バインディング、およびサービス定義が、マイグレーションされたモジュール内、またはマイグレーションされたモジュールが従属するライブラリー内に存在することを確認してください。
- ビジネス・インテグレーション・パースペクティブで、マイグレーションされたモジュールを展開し、そのアセンブリー・ダイアグラムをアセンブリー・エディター内で開きます。
- 「Web サービス・ポート」論理カテゴリーを展開して、呼び出したいサービスに対応するポートをアセンブリー・エディターにドラッグ・アンド・ドロップします。
- Web サービス・バインディング付きインポートの作成を選択します。
- インポートを作成した後、そのインポートをアセンブリー・エディター内で選択して、「プロパティー」ビューに進みます。「バインディング」タブの下に、そのインポートがバインドされるポートとサービスが表示されます。
- アセンブリー・ダイアグラムを保管します。
これが完了したら、以下のようにして、サービスを再ワイヤリングする必要があります。
- このサービスが同じモジュール内のビジネス・プロセスによって呼び出される場合は、該当するビジネス・プロセス参照からこのインポートへのワイヤーを作成します。
- このサービスが別のモジュール内のビジネス・プロセスによって呼び出される場合は、
SCA バインディング付きエクスポートを作成し、このエクスポートを他のモジュールからそのモジュールのアセンブリー・エディターにドラッグ・アンド・ドロップして、対応する SCA バインディング付きインポートを作成します。該当するビジネス・プロセス参照をそのインポートにワイヤリングします。
- アセンブリー・ダイアグラムを保管します。
Web サービスのマイグレーション (SOAP/HTTP)
Web サービス (SOAP/HTTP) を、Web サービス・バインディング付き SCA インポートにマイグレーションすることができます。
アウトバウンド・サービス・マイグレーション用の SOAP/HTTP サービス・プロジェクトをマイグレーションするには、以下の手順に従ってください。
- 最初に、マイグレーション・ウィザードを使用してサービス・プロジェクトをインポートする必要があります。この結果、ビジネス・インテグレーション・モジュールが作成され、WSDL メッセージ、ポート・タイプ、バインディング、およびサービスが WebSphere Studio
Application Developer Integration Edition に生成されます。このアプリケーションが起動する IBM Web サービス (SOAP/HTTP) も、マイグレーションされる WebSphere Studio Application Developer Integration Edition Web サービスである場合には、マイグレーション時に Web サービスへの更新が行われた可能性があります。 その場合、ここでは Web サービスのマイグレーション済み WSDL ファイルを使用してください。
- ビジネス・インテグレーション・パースペクティブでモジュールを展開し、内容を参照できるようにします。 モジュール・プロジェクトの下にある最初の項目をダブルクリックしてアセンブリー・エディターを開きます (これはプロジェクトと同じ名前になります)。
- 次に、インポートを追加して、アプリケーションが SCA プログラミング・モデルに従って IBM Web サービスと (SOAP/HTTP を介して) 対話できるようにします。
WSDL インターフェース、バインディング、およびサービス定義が、マイグレーションされたモジュール内、またはマイグレーションされたモジュールが従属するライブラリー内に存在することを確認してください。
- ビジネス・インテグレーション・パースペクティブで、マイグレーションされたモジュールを展開し、そのアセンブリー・ダイアグラムをアセンブリー・エディター内で開きます。
- 「Web サービス・ポート」論理カテゴリーを展開して、呼び出したいサービスに対応するポートをアセンブリー・エディターにドラッグ・アンド・ドロップします。
- Web サービス・バインディング付きインポートの作成を選択します。
- インポートを作成した後、そのインポートをアセンブリー・エディター内で選択して、「プロパティー」ビューに進みます。「バインディング」タブの下に、そのインポートがバインドされるポートとサービスが表示されます。
- アセンブリー・ダイアグラムを保管します。
これが完了したら、以下のようにして、サービスを再ワイヤリングする必要があります。
- このサービスが同じモジュール内のビジネス・プロセスによって呼び出される場合は、該当するビジネス・プロセス参照からこのインポートへのワイヤーを作成します。
- このサービスが別のモジュール内のビジネス・プロセスによって呼び出される場合は、
SCA バインディング付きエクスポートを作成し、このエクスポートを他のモジュールからそのモジュールのアセンブリー・エディターにドラッグ・アンド・ドロップして、対応する SCA バインディング付きインポートを作成します。該当するビジネス・プロセス参照をそのインポートにワイヤリングします。
- アセンブリー・ダイアグラムを保管します。
JMS サービスのマイグレーション
JMS サービスを JMS バインディング付き SCA インポートにマイグレーションすることができます。
注: JMS メッセージが WebSphere Business Integration Adapter に送信される場合は、下のリンクにあるセクション『WebSphere Business Integration Adapter との相互作用のマイグレーション』を参照してください。
アウトバウンド・サービス・マイグレーション用の JMS サービス・プロジェクトをマイグレーションするには、以下の手順に従ってください。
- 最初に、マイグレーション・ウィザードを使用してサービス・プロジェクトをインポートする必要があります。この結果、ビジネス・インテグレーション・モジュールが作成され、WSDL メッセージ、ポート・タイプ、バインディング、およびサービスが WebSphere Studio
Application Developer Integration Edition に生成されます。
- ビジネス・インテグレーション・パースペクティブでモジュールを展開し、内容を参照できるようにします。モジュール・プロジェクトの下にある最初の項目をダブルクリックしてアセンブリー・エディターを開きます (これはプロジェクトと同じ名前になります)。
- 次に、インポートを追加して、アプリケーションが SCA プログラミング・モデルに従って JMS キューと対話できるようにします。
- アセンブリー・エディターで、マイグレーションされたモジュール・プロジェクトを展開し、
「インターフェース」カテゴリーを展開して、アプリケーションが呼び出す Web サービスを記述する WSDL ポート・タイプを見つけます。これをアセンブリー・エディターにドラッグ・アンド・ドロップします。
- 「コンポーネントの作成」ダイアログでは、作成するコンポーネントのタイプを選択できます。
「バインディングのないインポート」を選択します。
- アセンブリー・エディターで作成された新しいインポートが表示され、そのインポートを選択して、「記述」タブの「プロパティー」ビューに進めば、インポートの名前を変更して、より分かりやすい名前で表示できます。
- 5.1 の WSDL バインディングおよびサービス・ファイルを参照して、マイグレーションする JMS サービスについての詳細を見つけ、それらを使用して 6.x の「JMS バインディング付きインポート」の詳細を入力することができます。
5.1 のサービス・プロジェクト内で、5.1 の JMS バインディングおよびサービスの WSDL ファイル
(通常、*JMSBinding.wsdl および *JMSService.wsdl という名前です) を見つけてください。そこに収集されているバインディングとサービスの情報を検査してください。バインディングからは、テキスト・メッセージとオブジェクト・メッセージのどちらが使用されたか、およびカスタム・データ・フォーマット・バインディングが使用されたかどうかを判別できます。これらが使用されていた場合には、6.x の「JMS バインディング付きインポート」にカスタム・データ・バインディングを作成することを検討する必要もあります。サービスからは、初期コンテキスト・ファクトリー、JNDI 接続ファクトリー名、
JNDI 宛先名、および宛先スタイル (キュー) を見つけることができます。
- そのインポートを右クリックして、「バインディングの生成 (Generate Binding)」を選択し、次に「JMS バインディング」を選択します。以下のパラメーターの入力を求めるプロンプトが出されます。
- JMS メッセージング・ドメインの選択:
-
- Point-to-Point
- Publish-Subscribe
- Domain-Independent
- ビジネス・オブジェクトおよび JMS メッセージ間でのデータのシリアライズ方法の選択:
-
- 「ユーザー提供」を選択した場合、以下のようにします。
- com.ibm.websphere.sca.jms.data.JMSDataBinding 実装クラスの完全修飾名を指定します。ご使用のアプリケーションが、「JMS インポート・バインディング」で通常は使用できない JMS ヘッダー・プロパティーの設定を必要とする場合は、ユーザー定義のデータ・バインディングを指定する必要があります。この場合は、標準 JMS データ・バインディング com.ibm.websphere.sca.jms.data.JMSDataBinding
を拡張するカスタム・データ・バインディング・クラスを作成し、カスタム・コードを追加して JMSMessage に直接アクセスすることができます。下のリンク先にある『インポートおよびエクスポート・コンポーネントのバインディングの作成および変更』で JMS の例を参照してください。
- インバウンド接続がデフォルト JMS 関数セレクター・クラスを使用している:
- <selected> または <deselected>
- いま作成したインポートを選択します。「プロパティー」ビューの「バインディング」タブに移動します。そこにリストされたすべてのバインディング情報に、WebSphere Studio Application Developer Integration Edition で以前に指定したものと同じ値を手動で入力できます。指定可能なバインディング情報には以下があります。
- JMS インポート・バインディング (これが最重要)
- 接続
- リソース・アダプター
- JMS 宛先
- メソッド・バインディング
これが完了したら、以下のようにして、サービスを再ワイヤリングする必要があります。
- このサービスが同じモジュール内のビジネス・プロセスによって呼び出される場合は、該当するビジネス・プロセス参照からこのインポートへのワイヤーを作成します。
- このサービスが別のモジュール内のビジネス・プロセスによって呼び出される場合は、
SCA バインディング付きエクスポートを作成し、このエクスポートを他のモジュールからそのモジュールのアセンブリー・エディターにドラッグ・アンド・ドロップして、対応する SCA バインディング付きインポートを作成します。該当するビジネス・プロセス参照をそのインポートにワイヤリングします。
- アセンブリー・ダイアグラムを保管します。
J2C-IMS サービスのマイグレーション
J2C-IMS サービスを、EIS バインディング付き SCA インポートまたは Web サービス・バインディング付き SCA インポートにマイグレーションできます。
この IMS(TM) サービス用に生成された
WebSphere Studio Application Developer Integration Edition の成果物は使用しないでください。
WebSphere Integration Developer で使用可能なウィザードを使用してサービスを再作成し、手動でアプリケーションの再ワイヤリングを行う必要があります。
注: 自動ビルドをオンにするか、またはモジュールを手動でビルドしてください。
以下のオプションがあります。
注: どちらのオプションでも、BPEL サービスがこの IMS サービスを呼び出す場合は、BPEL を多少変更する必要があります。これは、EIS サービスによって公開されるインターフェースは旧 5.1 インターフェースと多少異なるためです。これを行うには、BPEL エディターを開き、EIS サービスに対応するパートナー・リンクを調整して、上記のステップを実行したときに生成された新しいインターフェース (WSDL ファイル) を使用します。
EIS サービスの新しい WSDL インターフェースに関して、BPEL アクティビティーに変更が必要であれば、それを行います。
IMS サービスを呼び出す SCA インポートの作成: オプション 1
IMS システムと通信するためにメッセージ/データを保管する DataObject を使用する、
EIS バインディング付き SCA インポートを作成できます。
IMS サービスを呼び出す SCA インポートを作成するには、以下の手順に従ってください。
- この新しい IMS サービスを収容するために、新しいビジネス・インテグレーション・モジュール・プロジェクトを作成します。
- EIS サービスを再作成するために、「ファイル」 -> 「新規」 -> 「その他」 -> 「ビジネス・インテグレーション」 -> 「外部サービス」と進みます。
- このウィザードを使用して、EIS システムからサービスをインポートできます。これは、5.1 で WSIF ベースの EIS サービスを作成した、WebSphere Studio Application Developer Integration Edition ウィザードに非常によく似ています。このウィザードで、新しい J2C IMS リソース・アダプターをインポートできます。
WebSphere Integration Developer がインストールされているディレクトリーを参照して、
「リソース・アダプター (Resource Adapters)」 -> 「ims15」 -> 「imsico9102.rar」とドリルダウンする必要があります。
注: プロパティーおよび操作パネルの保管の実行について詳しくは、インフォメーション・センターを参照してください。「外部サービス」ウィザードで操作を追加するときに、操作の入力データ型または出力データ型のビジネス・オブジェクトを作成することもできます。このためには、WebSphere Studio Application Developer Integration Edition ウィザードで使用した、
C または COBOL ソース・ファイルが必要です。古いサービス・プロジェクトにあるソース・ファイルをポイントできるように、これらのファイルをそのプロジェクトにコピーしておく必要があります。また、別のウィザード、「ファイル」 -> 「新規」 -> 「その他」 -> 「ビジネス・インテグレーション」 -> 「外部データ」を使用して、ビジネス・オブジェクトをインポートすることもできます。
- ウィザードを完了したら、ビジネス・インテグレーション・パースペクティブを開き、モジュールを展開して、その内容を確認できるようにします。モジュールの「データ型」に新しいビジネス・オブジェクトがリストされ、「インターフェース」に新しいインターフェースがリストされます。
- モジュール・プロジェクトの下にある最初の項目をダブルクリックしてアセンブリー・エディターを開きます (これはプロジェクトと同じ名前になります)。キャンバス上にインポートが存在し、このインポートに EIS バインディングがあり、作成したばかりのサービスを表していることが分かります。
このサービスを利用者に公開する方法については、『マイグレーション済みサービスにアクセスするために SCA エクスポートを作成』というセクションを参照してください。
J2C サービスへの Web サービスの作成: オプション 2
J2C Web サービスを作成することができ、そのサービスのコンシューマーが
SCA コンポーネントである場合は、そのサービスを
IBM Web サービス (SOAP/HTTP または SOAP/JMS) として利用することができます。
J2C サービスに Web サービスを作成するには、以下の手順に従ってください。
- 「ファイル」 -> 「新規」 -> 「J2C」 -> 「J2C Java Bean」とクリックすることにより、
J2C Java Bean を作成します。
- IMS Connector for Java の 1.5 バージョンを選択して、
「次へ」をクリックします。
- 「管理接続 (Managed Connection)」にチェック・マークを付け、
JNDI ルックアップ名を入力します。
「次へ」をクリックします。
- 新しい Java Bean のプロジェクト、パッケージ、および名前を指定します。この Bean は、1 つのインターフェースと 1 つの実装クラスから構成されます。
「次へ」をクリックします。
- EIS からアクセスしたいそれぞれの関数またはサービスごとに、Java メソッドを追加します。追加のメソッドは、Java ソース・エディターで「Snippet」ビューを使用して後で追加できます。
「追加...」ボタンをクリックし、そのメソッドの名前を選択して、「次へ」をクリックします。
- これで、「参照...」を選択して、既存の型を再利用するか、または「新規...」を選択して、入出力データ型について CICS/IMS Java データ・バインディング・ウィザード (ここで、
COBOL または C のソース・ファイルを参照できます) を起動できます。
- Java メソッドの作成を終了したら、
「次へ」をクリックします。
- このウィザードの残りのステップを完了して、J2C Java Bean を作成します。
- 「ファイル」 -> 「新規」 -> 「J2C」 -> 「Web ページ、Web サービス、または J2C Java Bean からの EJB (Web Page, Web Service, or EJB from J2C Java Bean)」とクリックすることで Web サービスを作成して、
J2C Java Bean に Web サービスを作成します。
- ウィザードを完了します。
これで、このサービスのコンシューマーは、このウィザードによって生成された WSDL サービスを使用して IMS サービスを呼び出すことができます。
各 J2C-IMS サービス再ワイヤリング・オプションの利点と欠点
J2C-IMS サービス再ワイヤリング・オプションにはそれぞれ、利点と欠点があります。
以下のリストで、両方のオプションと、それぞれの利点および欠点について説明します。
- 最初のオプションは、標準 SCA コンポーネントを使用して IMS サービスを呼び出します。
- 最初のオプションには、以下のようにいくつかの制限事項があります。
- SDO バージョン 1 仕様の API は、COBOL または C のバイト配列へのアクセスを提供しません。これは、IMS 複数セグメントを操作する顧客に影響することになります。
- シリアライゼーション用 SDO バージョン 1 仕様は、COBOL 再定義または C 共用体をサポートしません。
- 2 番目のオプションでは標準 JSR 109 の方法を使用して IMS サービスに接続します。この機能は、Rational Application Developer の一部として使用できます。
J2C-CICS ECI サービスのマイグレーション
J2C-CICS ECI サービスを EIS バインディング付き SCA インポートまたは Web サービス・バインディング付き SCA インポートにマイグレーションできます。
トピック『J2C-IMS サービスのマイグレーション』に記載された手順に従いますが、必ず IMS RAR ファイルの代わりに 、次の RAR ファイルをインポートしてください。
- WebSphere Integration Developer がインストールされているディレクトリーを参照し、
「リソース・アダプター (Resource Adapters)」 -> 「cics15」 -> 「cicseci.rar」までドリルダウンします。
2 番目のオプションに従って J2C Web サービスを作成する場合は、J2C Java Bean 作成ウィザードの 2 番目のパネルで v 1.5 の ECIResourceAdapter を選択します。
トピック『J2C-IMS サービスのマイグレーション』も参照してください。
J2C-CICS EPI サービスのマイグレーション
WebSphere Integration Developer には、J2C-CICS EPI サービスに対する直接サポートはありません。
SCA モジュールからこのサービスにアクセスするには、
利用シナリオ を使用してマイグレーションを行う必要があります。
このサービス・タイプを WebSphere Integration Developer
にマイグレーションするための説明については、トピック『サービス・マイグレーションの利用シナリオ』を参照してください。
J2C-HOD サービスのマイグレーション
WebSphere Integration Developer には、J2C-HOD サービスに対する直接サポートはありません。
SCA モジュールからこのサービスにアクセスするには、
利用シナリオ を使用してマイグレーションを行う必要があります。
このサービス・タイプを WebSphere Integration Developer
にマイグレーションするための説明については、トピック『サービス・マイグレーションの利用シナリオ』を参照してください。
可能な部分について、変換プログラム・サービスを SCA データ・マップおよびインターフェース・マップにマイグレーションできます。
利用シナリオ を使用して、SCA モジュールからこのサービスにアクセスすることもできます。
データ・マップとインターフェース・マップのコンポーネントは、バージョン 6.0 の新機能です。これらのコンポーネントは、5.1 からの変換プログラム・サービスと類似した機能を提供しますが、完全な XSL 変換の機能は持っていません。ご使用の変換プログラム・サービスをこれらのコンポーネントのいずれかで置き換えることができない場合は、
WebSphere Integration Developer には変換プログラム・サービスに対する直接のサポートがないため、利用シナリオを使用してマイグレーションを行う必要があります。『サービス・マイグレーションの利用シナリオ』セクションで説明されている手順に従って、SCA モジュールからこのサービスにアクセスしてください。
サービス・マイグレーションの利用シナリオ
WebSphere Studio Application Developer Integration Edition サービス・タイプに直接対応するサービス・タイプがない場合、 WebSphere Integration Developer でアプリケーションを再設計するときに古い WebSphere Studio Application Developer Integration Edition サービスをそのまま利用するには、利用シナリオが必要になります。
マイグレーション・ウィザードを呼び出す前 に、WebSphere Studio Application Developer Integration Edition で以下の手順を実行してください。
- このクライアント・プロキシー・コードを保持するための新しい Java プロジェクトを作成します。このクライアント・プロキシー・コードをサービス・プロジェクトに書き込まないでください。バージョン 5.1 スタイルで生成されたメッセージおよび Java Bean クラスは、サービス・プロジェクトをマイグレーションする自動マイグレーション・ウィザードでスキップされるためです。
- WebSphere Studio Application Developer Integration Edition を開き、変換プログラム・バインディングおよびサービスが含まれる WSDL ファイルを右クリックして、
「エンタープライズ・サービス (Enterprise Services)」 -> 「サービス・プロキシーの生成 (Generate Service Proxy)」を選択します。作成するプロキシーのタイプを確認されますが、
「Web Services Invocation Framework (WSIF)」のみが選択可能です。
「次へ」をクリックします。
- ここで、作成するサービス・プロキシー Java クラスのパッケージおよび名前を指定できます (現行サービス・プロジェクト内にプロキシーを作成することになります)。
「次へ」をクリックします。
- ここで、プロキシー・スタイルを指定できます。
「クライアント・スタブ (Client Stub)」を選択して、プロキシーに組み込む目的の操作を選択し、「終了」をクリックします。これによって、
WebSphere
Studio Application Developer Integration Edition サービスと同じメソッドを公開する Java クラスが作成されます。このクラスでは、
Java
メソッドへの引数はソース WSDL メッセージのパーツとなります。
ここで、WebSphere Integration Developer へのマイグレーションを行うことができます。
- クライアント・プロキシー Java プロジェクトを新しいワークスペースにコピーし、
「ファイル」 -> 「インポート」 -> 「既存プロジェクトをワークスペースへ」に進んで、このプロジェクトをインポートします。
- マイグレーション・ウィザードを使用してサービス・プロジェクトをインポートします。この結果、ビジネス・インテグレーション・モジュールが作成され、WSDL メッセージ、ポート・タイプ、バインディング、およびサービスが WebSphere Studio
Application Developer Integration Edition に生成されます。
- ビジネス・インテグレーション・パースペクティブでモジュールを展開し、内容を参照できるようにします。モジュール・プロジェクトの下にある最初の項目をダブルクリックしてアセンブリー・エディターを開きます (これはプロジェクトと同じ名前になります)。
- カスタム Java コンポーネントを作成するには、モジュール・プロジェクトの下にある「インターフェース」を展開し、WebSphere Studio Application Developer Integration Edition でこの変換プログラム・サービスについて生成された WSDL インターフェースを選択します。
- このインターフェースをアセンブリー・エディターにドラッグ・アンド・ドロップします。作成するコンポーネントのタイプを選択するように求めるダイアログがポップアップ表示されます。
「実装タイプのないコンポーネント」を選択して、
「OK」をクリックします。
- アセンブリー・ダイアグラムに、汎用コンポーネントが表示されます。そのコンポーネントを選択して、「プロパティー」ビューに進みます。
- 「説明」タブで、コンポーネントの名前を変更して、より分かりやすい名前を表示できます (この場合、ご使用の EJB の名前に類似した名前を付けますが、このコンポーネントは、WebSphere Studio Application Developer Integration Edition で変換プログラム・サービスについて生成された WSDL インターフェースと変換プログラム・クライアント・プロキシーの Java インターフェースとの間を仲介する Java コンポーネントになるため、「JavaMed」などの接尾部を付加します)。
- 「詳細」タブで、このコンポーネントに 1 つのインターフェース (アセンブリー・エディターにドラッグ・アンド・ドロップしたインターフェース) があることが分かります。
- アセンブリー・エディターに戻り、作成したばかりのコンポーネントを右クリックして、
「実装の生成...」 -> 「Java」を選択します。
Java の実装が生成されるパッケージを選択します。これにより、SCA プログラミング・モデル (複合型は commonj.sdo.DataObject であるオブジェクトによって表され、単純型はそれと同等の Java オブジェクトによって表される) に準拠した WSDL インターフェースに従ったスケルトン Java サービスが作成されます。
ここで、生成された Java 実装クラスの中の「//TODO」タグで示されている部分に、コードを入力する必要があります。次の 2 つのオプションがあります。
- ロジックをオリジナルの Java クラスからこのクラスに移動し、新しいデータ構造に適合させます。
- この生成済み Java クラスの内側に、古い Java クラスの専用インスタンスを作成し、以下のことを行うためのコードを作成します。
- 生成された Java 実装クラスのすべてのパラメーターを、古い Java クラスが期待するパラメーターに変換する。
- 変換されたパラメーターを使用して、古い Java クラスの専用インスタンスを呼び出す。
- 古い Java クラスの戻り値を、生成された Java 実装メソッドで宣言されている戻り値の型に変換する。
上記のオプションを完了した後、クライアント・プロキシーを再ワイヤリングする必要があります。参照は存在しないはずであるため、必要なのは Java コンポーネントのインターフェースの再ワイヤリングのみです。
- このサービスが同じモジュール内のビジネス・プロセスによって呼び出される場合は、該当するビジネス・プロセス参照からこの Java コンポーネントのインターフェースへのワイヤーを作成します。
- このサービスが別のモジュール内のビジネス・プロセスによって呼び出される場合は、
SCA バインディング付きエクスポートを作成し、このエクスポートを他のモジュールからそのモジュールのアセンブリー・エディターにドラッグ・アンド・ドロップして、対応する SCA バインディング付きインポートを作成します。該当するビジネス・プロセス参照をそのインポートにワイヤリングします。
- このサービスが、外部での公開のために WebSphere Studio Application Developer Integration Edition で公開されていた場合、サービスの再公開の方法については、セクション『マイグレーション済みサービスにアクセスするために SCA エクスポートを作成』を参照してください。
マイグレーション済みサービスにアクセスするために SCA エクスポートを作成
WebSphere
Studio Application Developer Integration Edition
サービス・プロジェクトにデプロイメント・コードを生成したすべてのサービスの SCA モデルに従って、外部コンシューマーがマイグレーション済みサービスを使用できるようにするためには、
SCA エクスポートを作成する必要があります。これには、アプリケーション外部のクライアントが呼び出すすべてのサービスが含まれます。
注: マイグレーション・ユーティリティーは、これを自動的に行おうとしますが、以下の情報を参照して、ツールが何を行うかを確認することができます。
WebSphere Studio
Application Developer Integration Edition から、BPEL プロセスまたは他の Service WSDL を右クリックして、「エンタープライズ・サービス (Enterprise Services)」 -> 「デプロイメント・コードの生成」を選択した場合は、次の手動マイグレーション・ステップを実行する必要があります。
WebSphere Integration Developer は、すべてのデプロイメント・オプションを保管するという点で、WebSphere Studio Application Developer Integration Edition と異なります。プロジェクトがビルドされると、デプロイメント・コードは、生成済み EJB と Web プロジェクトで自動的に更新されるため、手動で「デプロイメント・コードの生成」を行うためのオプションはなくなりました。
「BPEL デプロイメント・コードの生成」ウィザードの「パートナー用インターフェース (Interfaces for Partners)」セクションには 5 つのバインディング・オプションがありました。以下のインバウンド BPEL サービス・マイグレーション情報には、WebSphere Studio Application Developer Integration Edition で選択されたデプロイメント・バインディング・タイプに基づいて作成するエクスポートのタイプおよびプロパティーに関する詳細があります。
- EJB
- IBM Web サービス (SOAP/JMS)
- IBM Web サービス (SOAP/HTTP)
- Apache Web サービス (SOAP/HTTP)
- JMS
EJB および EJB プロセス・バインディングのマイグレーション
EJB および EJB プロセス・バインディングは、推奨 SCA 構成にマイグレーションすることができます。
WebSphere Studio
Application Developer Integration Edition で、このバインディング・タイプは、EJB を呼び出すことによって、クライアントによる BPEL プロセスや他のサービスとの通信を可能にしました。マイクロプロセスの場合、このバインディング・タイプはオプションではなかったことに注意してください。生成済み EJB が他のバインディング・タイプによって内部的に使用されるために、必ず選択されていました。
生成済み EJB の JNDI 名は、BPEL の名前、ターゲット名前空間、および開始日付タイム・スタンプの組み合わせとして自動的に生成されました。例えば、これらの属性は、「説明」および「サーバー」のコンテンツ・タブにおいて BPEL エディターで BPEL プロセスのプロパティーを調べることによって見つけることができます。
表 3. 生成済み名前空間
プロセス名 |
MyService |
ターゲット名前空間 |
http://www.example.com/process87787141/ |
開始日付 |
Jan 01 2003 02:03:04 |
この例の生成済み名前空間は com/example/www/process87787141/MyService20030101T020304 です。
WebSphere Studio Application
Developer Integration Edition では、EJB バインディングがデプロイメント・タイプとして選択された場合、指定されるオプションはありませんでした。
WebSphere Studio Application
Developer Integration Edition プロセス・バインディングをマイグレーションするには、4 つのオプションがあります。サービスにアクセスするクライアントのタイプによって、次のどのマイグレーション・オプションが実行されるかが決まります。
注: 手動マイグレーション・ステップの完了後、クライアントも新しいプログラミング・モデルにマイグレーションする必要があります。次のクライアント・タイプについては、該当するトピックを参照してください。
表 4. クライアントのマイグレーションに関する詳細情報
クライアント・タイプ |
詳細については以下を参照 |
生成済みセッション Bean を呼び出す EJB クライアント。このようなクライアントは、呼び出す BPEL 操作に対応する EJB メソッドを呼び出します。 |
「EJB クライアントのマイグレーション」 |
EJB プロセス・バインディングを使用する WSIF クライアント |
「EJB プロセス・バインディング・クライアントのマイグレーション」 |
汎用 business process choreographer EJB API |
「Business Process Choreographer 汎用 EJB API クライアントのマイグレーション」 |
汎用 business process choreographer Messaging API |
「Business Process Choreographer 汎用 Messaging API クライアントのマイグレーション」 |
同じモジュール内の他の BPEL プロセス |
N/A: コンポーネント・アセンブリー・エディターをともに使用するワイヤー BPEL コンポーネント |
異なるモジュール内の別の BPEL プロセス |
N/A: 参照元モジュールに SCA バインディング付きインポートを作成して、次のオプション 1 で作成する SCA バインディング付きインポートをポイントするようにそのバインディングを構成します。 |
EJB および EJB プロセス・バインディングのマイグレーション・オプション 1
WebSphere Studio
Application Developer Integration Edition EJB プロセス・バインディングの最初のマイグレーション・オプションは、ビジネス・プロセスによる同じモジュール内の別コンポーネントのアクセスを可能にします。
アセンブリー・エディターで、この別コンポーネントを BPEL コンポーネントにワイヤリングするには、以下の手順に従ってください。
- ツールバーから 「ワイヤー」項目を選択します。
- 他のコンポーネントをクリックして、ワイヤーのソースとして選択します。
- 「BPEL SCA」コンポーネントをクリックして、ワイヤーのターゲットとして選択します。
- アセンブリー・ダイアグラムを保管します。
EJB および EJB プロセス・バインディングのマイグレーション・オプション 2
WebSphere Studio
Application Developer Integration Edition EJB プロセス・バインディングの 2 番目のマイグレーション・オプションは、ビジネス・プロセスによる他の SCA モジュールおよびクライアントのアクセスを可能にします。
注: 以下の手順は、汎用 business process choreographer API がビジネス・プロセスの起動に使用される場合に必須です。
SCA バインディング付きエクスポートは、他の SCA モジュールによる SCA コンポーネントのアクセスを可能にします。
SCA バインディング付きエクスポートを作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- EJB バインディングが WebSphere Studio Application Developer Integration Edition に生成された
BPEL プロセス・インターフェースごとに、SCA バインディング付きエクスポートを作成します。
- アセンブリー・エディターで BPEL コンポーネントを右クリックします。
- 「エクスポート...」を選択します。
- 「SCA バインディング」 を選択します。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- SCA エクスポートが作成されたら、アセンブリー・エディターと「プロパティー」ビューでエクスポートを選択し、
「説明」コンテンツ・ペインを選択します。エクスポートの名前と説明がリストされ、必要であれば変更できます。
- アセンブリー・ダイアグラムを保管します。
EJB および EJB プロセス・バインディングのマイグレーション・オプション 3
WebSphere Studio
Application Developer Integration Edition EJB プロセス・バインディングの 3 番目のマイグレーション・オプションは、非 SCA エンティティー (例えば JSP や
Java クライアント) によるモジュールのアクセスを可能にします。
スタンドアロン参照は、外部クライアントによる SCA コンポーネントのアクセスを可能にします。スタンドアロン参照を作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- EJB バインディングが WebSphere Studio Application Developer Integration Edition に生成された
BPEL プロセス・インターフェースごとに、スタンドアロン参照を作成します。
- ツールバーから「スタンドアロン参照」項目を選択します。
- アセンブリー・エディターのキャンバスをクリックして、スタンドアロン参照 SCA エンティティーを作成します。
- ツールバーから 「ワイヤー」項目を選択します。
- 「スタンドアロン参照」 エンティティーをクリックして、ワイヤーのソースとして選択します。
- 「BPEL SCA」コンポーネントをクリックして、ワイヤーのターゲットとして選択します。
- アラート「ソース・ノード上にマッチング参照が作成されます。続行しますか? (Matching reference will be
created on the source node. Would you like to continue?)」が表示されたら、
「OK」をクリックします。
- 作成したばかりの「スタンドアロン参照」エンティティーを選択して、「プロパティー」ビューで「説明」コンテンツ・ペインを選択します。
- 「参照」リンクを展開して、いま作成したリファレンスを選択します。リファレンスの名前と説明がリストされ、必要であれば変更できます。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- アセンブリー・ダイアグラムを保管します。
EJB および EJB プロセス・バインディングのマイグレーション・オプション 4
WebSphere Studio Application Developer Integration Edition EJB
プロセス・バインディングの 4 番目のマイグレーション・オプションは、
Web サービス・クライアントによるビジネス・プロセスのアクセスを可能にします。
Web サービス・バインディング付きエクスポートは、外部 Web サービス・クライアントによる SCA コンポーネントのアクセスを可能にします。
Web サービス・バインディング付きエクスポートを作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- EJB バインディングが WebSphere Studio Application Developer Integration Edition に生成された
BPEL プロセス・インターフェースごとに、SCA バインディング付きエクスポートを作成します。
- アセンブリー・エディターで BPEL コンポーネントを右クリックします。
- 「エクスポート...」を選択します。
- 「Web サービス・バインディング」を選択します。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- トランスポート、soap/http または soap/jms を選択します。
- Web サービス付きエクスポートが作成されたら、アセンブリー・エディターと「プロパティー」ビューでエクスポートを選択し、「説明」コンテンツ・ペインを選択します。エクスポートの名前と説明がリストされ、必要であれば変更できます。
- アセンブリー・ダイアグラムを保管します。
JMS および JMS プロセス・バインディングのマイグレーション
JMS および JMS プロセス・バインディングは、推奨 SCA 構成にマイグレーションすることができます。
WebSphere Studio
Application Developer Integration Edition では、このバインディング・タイプは、クライアントに対して、メッセージを
MDB に送信することによって BPEL プロセスや他のサービスと通信する機能を与えます。このバインディング・タイプは、長期実行プロセスのオプションではなく、必ず選択されていたことに注意してください。事実、このバインディング・タイプは、長期実行プロセスの要求/応答インターフェース用に許可された、
唯一のバインディング・タイプでした。その他のサービス・タイプについては、MDB が生成され、これが該当するサービスを呼び出します。
JMS バインディングによって使用される JNDI 名は、BPEL の名前、ターゲット名前空間、および開始日付タイム・スタンプの組み合わせでした。
WebSphere Studio Application
Developer Integration Edition では、JMS バインディングが BPEL プロセスのデプロイメント・タイプとして選択された場合、以下のオプションが与えられました。
- JNDI 接続ファクトリー - デフォルトは jms/BPECF です (これは、ターゲット・ビジネス・プロセス・コンテナーのキュー接続ファクトリーの JNDI 名です)。
- JNDI 宛先キュー - デフォルトは jms/BPEIntQueue です (これは、ターゲット・ビジネス・プロセス・コンテナーの内部キューの JNDI 名です)。
- JNDI プロバイダー URL: サーバー提供またはカスタム - アドレスを入力する必要があります。 デフォルトは iiop://localhost:2809 です。
WebSphere Studio
Application Developer Integration Edition JMS プロセス・バインディングのマイグレーションには、5 つのオプションがあります。サービスにアクセスするクライアントのタイプによって、次のどのマイグレーション・オプションが実行されるかが決まります。
注: 手動マイグレーション・ステップの完了後、クライアントも新しいプログラミング・モデルにマイグレーションする必要があります。次のクライアント・タイプについては、該当するトピックを参照してください。
表 5. クライアントのマイグレーションに関する詳細情報
クライアント・タイプ |
詳細については以下を参照 |
JMS プロセス・バインディングを使用する WSIF クライアント |
「Business Process Choreographer 汎用 Messaging API クライアントおよび JMS プロセス・バインディング・クライアントのマイグレーション」 |
汎用 business process choreographer EJB API |
「Business Process Choreographer 汎用 EJB API クライアントのマイグレーション」 |
ビジネスをマイグレーションする汎用 business process choreographer Messaging API |
「Business Process Choreographer 汎用 Messaging API クライアントのマイグレーション」 |
同じモジュール内の他の BPEL プロセス |
N/A: コンポーネント・アセンブリー・エディターをともに使用するワイヤー BPEL コンポーネント |
異なるモジュール内の別の BPEL プロセス |
N/A: 参照元モジュールに SCA バインディング付きインポートを作成して、次のオプション 1 で作成する
SCA バインディング付きインポートをポイントするようにそのバインディングを構成します。 |
JMS および JMS プロセス・バインディングのマイグレーション・オプション 1
WebSphere Studio
Application Developer Integration Edition JMS プロセス・バインディングの最初のマイグレーション・オプションは、ビジネス・プロセスによる同じモジュール内の別コンポーネントのアクセスを可能にします。
アセンブリー・エディターで、この別コンポーネントを BPEL コンポーネントにワイヤリングするには、以下の手順に従ってください。
- ツールバーから 「ワイヤー」項目を選択します。
- 他のコンポーネントをクリックして、ワイヤーのソースとして選択します。
- 「BPEL SCA」コンポーネントをクリックして、ワイヤーのターゲットとして選択します。
- アセンブリー・ダイアグラムを保管します。
JMS および JMS プロセス・バインディングのマイグレーション・オプション 2
WebSphere Studio
Application Developer Integration Edition JMS プロセス・バインディングの 2 番目のマイグレーション・オプションは、ビジネス・プロセスによる他の SCA モジュールおよびクライアントのアクセスを可能にします。
SCA バインディング付きエクスポートは、他の SCA モジュールによる SCA コンポーネントのアクセスを可能にします。
SCA バインディング付きエクスポートを作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- JMS バインディングが WebSphere Studio Application Developer Integration Edition に生成された
BPEL プロセス・インターフェースごとに、SCA バインディング付きエクスポートを作成します。
- アセンブリー・エディターで BPEL コンポーネントを右クリックします。
- 「エクスポート...」を選択します。
- 「SCA バインディング」 を選択します。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- SCA エクスポートが作成されたら、アセンブリー・エディターと「プロパティー」ビューでエクスポートを選択し、
「説明」コンテンツ・ペインを選択します。エクスポートの名前と説明がリストされ、必要であれば変更できます。
- アセンブリー・ダイアグラムを保管します。
JMS および JMS プロセス・バインディングのマイグレーション・オプション 3
WebSphere Studio
Application Developer Integration Edition JMS プロセス・バインディングの 3 番目のマイグレーション・オプションは、非 SCA エンティティー (例えば JSP や
Java クライアント) によるビジネス・プロセスのアクセスを可能にします。
スタンドアロン参照は、外部クライアントによる SCA コンポーネントのアクセスを可能にします。スタンドアロン参照を作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- JMS バインディングが WebSphere Studio Application Developer Integration Edition に生成された
BPEL プロセス・インターフェースごとに、スタンドアロン参照を作成します。
- ツールバーから「スタンドアロン参照」項目を選択します。
- アセンブリー・エディターのキャンバスをクリックして、スタンドアロン参照 SCA エンティティーを作成します。
- ツールバーから 「ワイヤー」項目を選択します。
- 「スタンドアロン参照」 エンティティーをクリックして、ワイヤーのソースとして選択します。
- 「BPEL SCA」コンポーネントをクリックして、ワイヤーのターゲットとして選択します。
- アラート「ソース・ノード上にマッチング参照が作成されます。続行しますか? (Matching reference will be
created on the source node. Would you like to continue?)」が表示されたら、
「OK」をクリックします。
- 作成したばかりの「スタンドアロン参照」エンティティーを選択して、「プロパティー」ビューで「説明」コンテンツ・ペインを選択します。
- 「参照」リンクを展開して、いま作成したリファレンスを選択します。リファレンスの名前と説明がリストされ、必要であれば変更できます。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- アセンブリー・ダイアグラムを保管します。
JMS および JMS プロセス・バインディングのマイグレーション・オプション 4
WebSphere Studio
Application Developer Integration Edition JMS プロセス・バインディングの 4 番目のマイグレーション・オプションは、Web サービス・クライアントによるビジネス・プロセスのアクセスを可能にします。
Web サービス・バインディング付きエクスポートは、外部 Web サービス・クライアントによる SCA コンポーネントのアクセスを可能にします。
Web サービス・バインディング付きエクスポートを作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- JMS バインディングが WebSphere Studio Application Developer Integration Edition に生成された
BPEL プロセス・インターフェースごとに、SCA バインディング付きエクスポートを作成します。
- アセンブリー・エディターで BPEL コンポーネントを右クリックします。
- 「エクスポート...」を選択します。
- 「Web サービス・バインディング」を選択します。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- トランスポート、soap/http または soap/jms を選択します。
- Web サービス付きエクスポートが作成されたら、アセンブリー・エディターと「プロパティー」ビューでエクスポートを選択し、「説明」コンテンツ・ペインを選択します。エクスポートの名前と説明がリストされ、必要であれば変更できます。
- アセンブリー・ダイアグラムを保管します。
JMS および JMS プロセス・バインディングのマイグレーション・オプション 5
WebSphere Studio
Application Developer Integration Edition JMS プロセス・バインディングの 5 番目のマイグレーション・オプションは、JMS クライアントによるビジネス・プロセスのアクセスを可能にします。
JMS バインディング付きエクスポートは、外部 JMS クライアントによる SCA コンポーネントのアクセスを可能にします。
JMS バインディング付きエクスポートを作成するには、以下の手順に従ってください。
- BPEL サービスの場合、5.1 JMS プロセス・バインディングが標準 5.1 JMS バインディングとはまったく異なっていたため、新しいキュー・リソースを作成および参照する必要があります。非 BPEL サービスの場合、JMSBinding.wsdl
および JMSService.wsdl という名前の WSDL ファイルを、生成された EJB プロジェクトの ejbModule/META-INF
フォルダーの下の該当するパッケージ内で見つけ、バインディングおよびサービス情報がそこに収集されていることを検査することによって、
WebSphere Studio Application Developer Integration Edition 5.1
の JMS デプロイメント・コード用に選択した値を見つけることができます。バインディングからは、テキスト・メッセージとオブジェクト・メッセージのどちらが使用されたか、およびカスタム・データ・フォーマット・バインディングが使用されたかどうかを判別できます。これらが使用されていた場合には、6.x の「JMS バインディング付きエクスポート」用のカスタム・データ・バインディングを作成することを検討する必要もあります。サービスからは、初期コンテキスト・ファクトリー、JNDI 接続ファクトリー名、
JNDI 宛先名、および宛先スタイル (キュー) を見つけることができます。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- アセンブリー・エディターで BPEL コンポーネントを右クリックして、JMS バインディングが
WebSphere Studio Application
Developer Integration Edition に生成された BPEL プロセス・インターフェースごとに、JMS バインディング付きエクスポートを作成します。
- 「エクスポート...」を選択します。
- 「JMS バインディング」 を選択します。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- 次のパネル (JMS エクスポート・バインディング属性) で、「JMS メッセージング・ドメイン」を選択します。この属性を「Point-to-Point」として定義してください。
- 「ビジネス・オブジェクトおよび JMS メッセージ間でのデータのシリアライズ方法 (how data is serialized
between Business Object and JMS Message)」を選択し、以下の値を入力します (「オブジェクト」ではなく、
「テキスト」を選択することが推奨されます。テキストは、通常 XML であり、ランタイムから独立しており、異種システム間のサービス統合を可能にするためです)。
- 「テキスト」に「デフォルトの JMS 関数セレクター」 を選択するか、FunctionSelector 実装クラスの完全修飾名を入力します。
- 「オブジェクト」に「デフォルトの JMS 関数セレクター」 を選択するか、FunctionSelector 実装クラスの完全修飾名を入力します。
- 「ユーザー提供」に JMSDataBinding 実装クラスの完全修飾名を入力します。ご使用のアプリケーションが、「JMS インポート・バインディング」ですぐには使用できない
JMS ヘッダー・プロパティーへのアクセスを必要とする場合は、
「ユーザー提供」を選択する必要があります。この場合には、標準 JMS データ・バインディング
com.ibm.websphere.sca.jms.data.JMSDataBinding
を拡張するカスタム・データ・バインディング・クラスを作成し、カスタム・コードを追加して JMSMessage に直接アクセスする必要があります。その後で、カスタム・クラスの名前をこのフィールドに入力します。下のリンク先にある『インポートおよびエクスポート・コンポーネントのバインディングの作成および変更』で JMS の例を参照してください。
- 「ユーザー提供」に「デフォルトの JMS 関数セレクター」 を選択するか、FunctionSelector 実装クラスの完全修飾名を入力します。
- JMS バインディング付きエクスポートが作成されたら、アセンブリー・エディターと「プロパティー」ビューでエクスポートを選択し、「説明」コンテンツ・ペインを選択します。エクスポートの名前と説明がリストされ、必要であれば変更できます。
- 「バインディング」コンテンツ・ペインを選択すると、さらに多くのオプションが表示されます。
- アセンブリー・ダイアグラムを保管します。
IBM Web サービス・バインディング (SOAP/JMS) のマイグレーション
BPEL プロセスまたは他のサービス・タイプ用
IBM
Web サービス・バインディング (SOAP/JMS) は、推奨される SCA 構成にマイグレーションできます。
WebSphere
Studio Application Developer Integration Edition では、このバインディング・タイプは、クライアントに対して、
IBM
Web サービスを呼び出すことによって BPEL プロセスまたは他のサービス・タイプと通信する機能を与えました。この場合、通信プロトコルは JMS でメッセージは SOAP エンコード・ルールに準拠していました。
以下は、5.1 BPEL サービス用 IBM Web サービス (SOAP/JMS) を生成する際に使用される規則の例です。生成済み IBM Web サービスの
JNDI 名は、BPEL の名前、ターゲット名前空間、および開始日付タイム・スタンプの組み合わせであり、インターフェース (デプロイメント・コードが生成された対象の WSDL ポート・タイプ) の名前でもありました。例えば、これらの属性は、「説明」および「サーバー」のコンテンツ・タブで、
BPEL エディター内で BPEL プロセスのプロパティーを調べることによって見つけることができます。
表 6. 生成済み名前空間
プロセス名 |
MyService |
ターゲット名前空間 |
http://www.example.com/process87787141/ |
開始日付 |
Jan 01 2003 02:03:04 |
インターフェース |
ProcessPortType |
この例の生成済み名前空間は com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT です。
WebSphere
Studio Application Developer Integration Edition では、
IBM
Web サービス・バインディング (SOAP/JMS) が BPEL
プロセスまたは他のサービス・タイプのデプロイメント・タイプとして選択されると、以下のオプションが与えられました。
- 文書スタイルのデフォルトは、「DOCUMENT / その他のオプション: RPC (DOCUMENT / other option:
RPC)」です。
- 文書使用のデフォルトは、「LITERAL / その他のオプション: ENCODED (LITERAL / other option: ENCODED)」です。
- JNDI プロバイダー URL の場合、これは「サーバー提供 (Server supplied)」または「カスタム」のどちらかになります (アドレスは入力する必要があり、デフォルトは iiop://localhost:2809 です)。
- 宛先スタイルのデフォルトは、「キュー / その他のオプションはトピック (queue / other option
was topic)」です。
- JNDI 接続ファクトリーの場合、デフォルトは「jms/qcf」です (これは、生成済み MDB キューのキュー接続ファクトリーの JNDI 名です)。
- JNDI 宛先キューの場合、デフォルトは「jms/queue」です (これは、生成済み MDB キューの JNDI 名です)。
- MDB リスナー・ポートの場合、デフォルトは <サービス・プロジェクト名>MdbListenerPort でした。
IBM Web サービス
SOAP/JMS バインディングとサービスを指定する WSDL ファイルは、サービス・プロジェクト自体ではなく、生成済み EJB プロジェクトに作成されます。これはつまり、IBM
Web サービス・クライアント・コードを変更する必要がある場合は、このファイルを手動で配置して、ビジネス統合モジュール・プロジェクトにコピーしなければならないということです。デフォルトでは、この WSDL ファイルは、ejbModule/META-INF/wsdl/<ビジネス・プロセス名
>_ <ビジネス・プロセス・インターフェース・ポート・タイプ名>_JMS.wsdl にある
EJB プロジェクトの中に作成されます。
ビジネス・プロセス・インターフェースの WSDL ポート・タイプとメッセージは、サービス・プロジェクトに定義された既存の
WSDL ポート・タイプとメッセージを参照するのではなく、実際にはこの WSDL ファイルにもコピーされます。
IBM
Web サービス・クライアント・コードをマイグレーション後も変更しないでおく必要がある場合は、このファイルの情報が次の手動マイグレーション・ステップに必要です。
WebSphere Studio Application
Developer Integration Edition SOAP/JMS プロセス・バインディングのマイグレーションには、2 つのオプションがあります。クライアントを SCA プログラミング・モデルにマイグレーションするか、web サービス・クライアントとして残すかを選択する必要があります。
注: 手動マイグレーション・ステップの完了後、クライアントも新しいプログラミング・モデルにマイグレーションする必要があります。次のクライアント・タイプについては、該当するトピックを参照してください。
表 7. クライアントのマイグレーションに関する詳細情報
クライアント・タイプ |
詳細については以下を参照 |
IBM Web サービス・クライアント |
「IBM Web サービス (SOAP/JMS) クライアントのマイグレーション」 |
IBM Web サービス・バインディング
(SOAP/JMS) のマイグレーション・オプション 1
WebSphere Studio Application Developer Integration Edition SOAP/JMS
バインディングの最初のマイグレーション・オプションは、
Web サービス・クライアントによるサービスのアクセスを可能にすることです。
Web サービス・バインディング付きエクスポートは、外部 Web サービス・クライアントによる SCA コンポーネントのアクセスを可能にします。
Web サービス・バインディング付きエクスポートを作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- WebSphere Studio Application Developer Integration Edition で、サービス・インターフェース用に生成された
IBM Web サービス (SOAP/JMS) バインディングを持つそれぞれのサービス・インターフェースごとに、
SCA バインディング付きエクスポートを作成します。
- アセンブリー・エディターで SCA コンポーネントを右クリックします。
- 「エクスポート...」を選択します。
- 「Web サービス・バインディング」を選択します。
- コンポーネントに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- トランスポート soap/jms を選択します。
- Web サービス・エクスポートが作成されたら、アセンブリー・エディターと「プロパティー」ビューでエクスポートを選択し、「説明」コンテンツ・ペインを選択します。エクスポートの名前と説明がリストされ、必要であれば変更できます。
- アセンブリー・ダイアグラムを保管します。
- 「バインディング」コンテンツ・ペインを選択すると、IBM Web サービス WSDL バインディングおよびサービスが、モジュールのプロジェクト・フォルダーに直接生成されているのが分かります。これは、エクスポートされたコンポーネント Export WSDL ポート・タイプ名 Jms_Service.wsdl と命名されます。このファイルを調べると、文書/リテラル・ラップ済みバインディングがデフォルトで使用されていることが分かります。これは、6.x の優先スタイルです。これは、IBM Web サービス・クライアントがサービスの呼び出しに使用する WSDL です。
- クライアント・コードの保存を希望する場合、以下の手順に従って、新規の Web サービス・バインディングとサービスを生成します。
- ejbModule/META-INF/wsdl/ビジネス・プロセス名/ビジネス・プロセス・インターフェース・ポート・タイプ名 JMS.wsdl にある 5.1 で生成された EJB プロジェクトから、
5.1 WSDL ファイルをビジネス・インテグレーション・モジュール・プロジェクトにコピーします。
- ファイルをコピーして、モジュールを再ビルドした後、Web サービスによって使用された XML スキーマ型、
WSDL メッセージ、および WSDL ポート・タイプが、5.1 の IBM Web サービス WSDL ファイルで重複するために、エラー・メッセージが表示されることがあります。このエラーを修正するには、これらの重複する定義を IBM Web サービスのバインディング/サービス WSDL から削除して、その場所に、実際のインターフェース WSDL 用の WSDL インポートを追加します。
注: WebSphere Studio Application Developer
Integration Edition が IBM Web サービスのデプロイメント・コードを生成したときに、一部のケースでスキーマ定義を変更することに注意することが重要です。これにより、IBM Web サービス WSDL を使用する既存のクライアントで、不整合が発生する可能性があります。例えば、「elementFormDefault」スキーマ属性は、オリジナルのスキーマ定義が qualified ではなくても、
IBM Web サービス WSDL で生成されたインライン・スキーマでは「qualified」に設定されます。これによって、実行時に「WSWS3047E: エラー: エレメントをデシリアライズできません (WSWS3047E: Error: Cannot deserialize element)」というエラーが生成されます。
- ビジネス・インテグレーション・モジュールにコピーしたばかりのこの WSDL ファイルを右クリックして、
「アプリケーションから開く」を選択し、次に「WSDL エディター」を選択します。
- 「ソース」タブに進みます。このファイルの WSDL ポート・タイプおよび定義されたメッセージをすべて削除します。
- これで、「'<binding>' バインディングに指定した '<portType> ポート・タイプが未定義です
(The '<portType>' port type specified for the '<binding>' binding is undefined)」というエラーが表示されます。エラーを修正するには、「グラフ」タブの WSDL エディターで「インポート」セクションを右クリックし、「インポートの追加」を選択します。
- 「一般」タブの「プロパティー」ビューで、「ロケーション」フィールドの右側にある「...」 ボタンをクリックします。
WSDL メッセージとポート・タイプ定義があるインターフェース WSDL を参照し、
「OK」をクリックして、インターフェース WSDL をサービス/バインディング WSDL にインポートします。
- WSDL ファイルを保管します。
- プロジェクトの更新/再ビルドを行います。ビジネス・インテグレーション・パースペクティブに切り替えます。モジュールのアセンブリー・ダイアグラムをアセンブリー・エディターで開きます。
- プロジェクト・エクスプローラー・ビューで、マイグレーションするモジュールを展開して、
「Web サービス・ポート」論理カテゴリーを展開します。これで、バインディング/サービス WSDL に存在するポートがリスト表示されます。これをアセンブリー・エディターにドラッグ・アンド・ドロップします。
- Web サービス・バインディング付きエクスポートを作成することを選択して、該当するポート名を選択します。これにより、古いバインディング/サービスを使用するエクスポートが作成され、既存の Web サービス・クライアントを変更する必要はありません。アセンブリー・エディターで作成したばかりのエクスポートを選択して「プロパティー」ビューに進んだ場合、「バインディング」タブには、5.1 のポートとサービスの名前がすでに入力されていることが分かります。
- 変更をすべて保管します。
- アプリケーションをデプロイする直前に、生成された Web プロジェクトの構成を、
5.1 のサービス・アドレスに一致するように変更できます (これらの変更は、このファイルが再生成される原因となった SCA モジュールの変更を行うたびに実行する必要があります)。
5.1 から再使用している IBM Web サービス WSDL サービス 定義を調べている場合は、
5.1 のクライアントで <wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/> とコーディングされたサービス・アドレスが表示されます。
- 6.x で生成された Web プロジェクト成果物がこの古いサービス・アドレスと一致するようにするには、生成された Web プロジェクトのデプロイメント記述子を変更する必要があります。
WebSphere Integration Developer でデプロイメント記述子を開き、「サーブレット (Servlets)」タブで、そのエクスポート用の既存の URL マッピングと非常に良く似た追加の URL マッピングを、同じサーブレット名で異なる URL パターンを指定して追加します。
- また、オリジナルのサービス・アドレスのコンテキスト・ルート (この例では、コンテキスト・ルートは「MyServiceWeb」です) と一致するように、この Web プロジェクトのコンテキスト・ルートを変更する必要がある場合は、この Web プロジェクトが入っている J2EE エンタープライズ・アプリケーションのデプロイメント記述子を開いて、古いサービス・アドレスのコンテキスト・ルートと一致するように、その Web モジュールのコンテキスト・ルートを変更します。
「CHKJ3017E: Web プロジェクト: <WEB PROJ NAME> が、EAR プロジェクト: <APP NAME> 内の無効なコンテキスト・ルート: <NEW CONTEXT ROOT> にマップされています。(CHKJ3017E: Web Project: <WEB PROJ NAME> is mapped to an invalid Context root: <NEW CONTEXT ROOT> in EAR Project: <APP NAME>.)」 というエラーが表示されますが、無視できます。
IBM Web サービス・バインディング
(SOAP/JMS) のマイグレーション・オプション 2
WebSphere Studio
Application Developer Integration Edition SOAP/JMS プロセス・バインディングの 2 番目のマイグレーション・オプションは、ビジネス・プロセスによる SCA 以外のエンティティー (例えば JSP または Java クライアント) のアクセスを可能にします。
スタンドアロン参照は、外部クライアントによる SCA コンポーネントのアクセスを可能にします。スタンドアロン参照を作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- IBM Web サービス
(SOAP/JMS) バインディングが WebSphere Studio Application Developer Integration Edition に生成された
BPEL プロセス・インターフェースごとに、スタンドアロン参照を作成します。
- ツールバーから「スタンドアロン参照」項目を選択します。
- アセンブリー・エディターのキャンバスをクリックして、スタンドアロン参照 SCA エンティティーを作成します。
- ツールバーから 「ワイヤー」項目を選択します。
- 「スタンドアロン参照」 エンティティーをクリックして、ワイヤーのソースとして選択します。
- 「BPEL SCA」コンポーネントをクリックして、ワイヤーのターゲットとして選択します。
- アラート「ソース・ノード上にマッチング参照が作成されます。続行しますか? (Matching reference will be
created on the source node. Would you like to continue?)」が表示されたら、
「OK」をクリックします。
- 作成したばかりの「スタンドアロン参照」エンティティーを選択して、「プロパティー」ビューで「説明」コンテンツ・ペインを選択します。
- 「参照」リンクを展開して、いま作成したリファレンスを選択します。リファレンスの名前と説明がリストされ、必要であれば変更できます。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- アセンブリー・ダイアグラムを保管します。
IBM Web サービス・バインディング (SOAP/HTTP) のマイグレーション
BPEL プロセスまたは他のサービス・タイプ用
IBM
Web サービス・バインディング (SOAP/HTTP) は、推奨される SCA 構成にマイグレーションできます。
WebSphere
Studio Application Developer Integration Edition では、このバインディング・タイプは、クライアントに対して、
IBM
Web サービスを呼び出すことによって BPEL プロセスまたは他のサービス・タイプと通信する機能を与えました。この場合、通信プロトコルは HTTP で、メッセージは SOAP エンコード・ルールに準拠していました。
以下は、5.1 BPEL サービス用 IBM Web サービス (SOAP/HTTP) を生成する際に使用される規則の例です。生成済み IBM Web サービスの
JNDI 名は、BPEL の名前、ターゲット名前空間、および開始日付タイム・スタンプの組み合わせであり、インターフェース (デプロイメント・コードが生成された対象の WSDL ポート・タイプ) の名前でもありました。例えば、これらの属性は、「説明」および「サーバー」のコンテンツ・タブで、
BPEL エディター内で BPEL プロセスのプロパティーを調べることによって見つけることができます。
表 8. 生成済み名前空間
プロセス名 |
MyService |
ターゲット名前空間 |
http://www.example.com/process87787141/ |
開始日付 |
Jan 01 2003 02:03:04 |
インターフェース |
ProcessPortType |
この例の生成済み名前空間は com/example/www/process87787141/MyService20030101T020304_ProcessPortTypePT です。
WebSphere
Studio Application Developer Integration Edition では、
IBM
Web サービス・バインディング (SOAP/HTTP) が BPEL
プロセスまたは他のサービス・タイプのデプロイメント・タイプとして選択されると、以下のオプションが与えられました。
- 文書スタイルのデフォルトは、「RPC / その他のオプション: DOCUMENT (RPC / other option: DOCUMENT)」です。
- 文書使用のデフォルトは、「ENCODED / その他のオプション: LITERAL (ENCODED / other option: LITERAL)」です。
- ルーター・アドレスのデフォルトは、http://localhost:9080 です。
IBM Web サービス
SOAP/HTTP バインディングとサービスを指定する WSDL ファイルは、サービス・プロジェクト自体ではなく、生成済み Web および
EJB プロジェクトに作成されます。これはつまり、IBM
Web サービス・クライアント・コードを変更する必要がある場合は、このファイルを手動で配置して、ビジネス統合モジュール・プロジェクトにコピーしなければならないということです。デフォルトでは、この WSDL ファイルは、
WebContent/WEB-INF/wsdl/<ビジネス・プロセス名>_<ビジネス・プロセス・インターフェース・ポート・タイプ名>_HTTP.wsdl にある Web プロジェクトの中に作成されました。
ビジネス・プロセス・インターフェースの WSDL ポート・タイプとメッセージは、サービス・プロジェクトに定義された既存の
WSDL ポート・タイプとメッセージを参照するのではなく、実際にはこの WSDL ファイルにもコピーされます。
IBM
Web サービス・クライアント・コードをマイグレーション後も変更しないでおく必要がある場合は、このファイルの情報が次の手動マイグレーション・ステップに必要です。
WebSphere Studio Application
Developer Integration Edition SOAP/HTTP プロセス・バインディングのマイグレーションには、2 つのオプションがあります。クライアントを SCA プログラミング・モデルにマイグレーションするか、Web サービス・クライアントとして残すかを選択する必要があります。
注: 手動マイグレーション・ステップの完了後、クライアントも新しいプログラミング・モデルにマイグレーションする必要があります。次のクライアント・タイプについては、該当するトピックを参照してください。
表 9. クライアントのマイグレーションに関する詳細情報
クライアント・タイプ |
詳細については以下を参照 |
IBM Web サービス・クライアント |
「IBM Web サービス (SOAP/HTTP) クライアントのマイグレーション」 |
IBM Web サービス
(SOAP/HTTP) バインディングのマイグレーション・オプション 1
WebSphere Studio
Application Developer Integration Edition SOAP/HTTP プロセス・バインディングの最初のマイグレーション・オプションは、Web サービス・クライアントによるビジネス・プロセスのアクセスを可能にします。
Web サービス・バインディング付きエクスポートは、外部 Web サービス・クライアントによる SCA コンポーネントのアクセスを可能にします。
Web サービス・バインディング付きエクスポートを作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- アセンブリー・エディターで BPEL コンポーネントを右クリックして、WebSphere Studio Application Developer Integration Edition で生成された
IBM Web Service
(SOAP/HTTP) バインディングのある BPEL プロセスのインターフェースごとに、SCA バインディング付きエクスポートを作成します。
- 「エクスポート...」を選択します。
- 「Web サービス・バインディング」を選択します。
- コンポーネントに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- トランスポート soap/http を選択します。
- Web サービス・エクスポートが作成されたら、アセンブリー・エディターと「プロパティー」ビューでエクスポートを選択し、「説明」コンテンツ・ペインを選択します。エクスポートの名前と説明がリストされ、必要であれば変更できます。
- アセンブリー・ダイアグラムを保管します。
- クライアント・コードの保存を希望する場合、以下の手順に従って、新規の Web サービス・バインディングとサービスを生成します。
- ejbModule/META-INF/wsdl/ビジネス・プロセス名/ビジネス・プロセス・インターフェース・ポート・タイプ名_HTTP.wsdl にある 5.1 で生成された EJB プロジェクトから、
5.1 の WSDL ファイルをビジネス・インテグレーション・モジュール・プロジェクトにコピーします。
- ファイルをコピーして、モジュールを再ビルドした後、
Web サービスによって使用される XML スキーマ型、WSDL メッセージ、および WSDL ポート・タイプが、
5.1 の IBM Web サービス WSDL ファイルで重複するために、エラー・メッセージが表示されることがあります。このエラーを修正するには、これらの重複する定義を IBM Web サービスのバインディング/サービス WSDL から削除して、その場所に、実際のインターフェース WSDL 用の WSDL インポートを追加します。
注: WebSphere Studio Application Developer
Integration Edition が IBM Web サービスのデプロイメント・コードを生成したときに、一部のケースでスキーマ定義を変更することに注意することが重要です。これにより、IBM Web サービス WSDL を使用する既存のクライアントで、不整合が発生する可能性があります。例えば、「elementFormDefault」スキーマ属性は、オリジナルのスキーマ定義が qualified ではなくても、
IBM Web サービス WSDL で生成されたインライン・スキーマでは「qualified」に設定されます。これによって、実行時に「WSWS3047E: エラー: エレメントをデシリアライズできません (WSWS3047E: Error: Cannot deserialize element)」というエラーが生成されます。
- ビジネス・インテグレーション・モジュールにコピーしたばかりのこの WSDL ファイルを右クリックして、
「アプリケーションから開く」を選択し、次に「WSDL エディター」を選択します。
- 「ソース」タブに進みます。このファイルの WSDL ポート・タイプおよび定義されたメッセージをすべて削除します。
- これで、「'<binding>' バインディングに指定した '<portType> ポート・タイプが未定義です
(The '<portType>' port type specified for the '<binding>' binding is undefined)」というエラーが表示されます。エラーを修正するには、「グラフ」タブの WSDL エディターで「インポート」セクションを右クリックし、「インポートの追加」を選択します。
- 「一般」タブの「プロパティー」ビューで、「ロケーション」フィールドの右側にある「...」 ボタンをクリックします。
WSDL メッセージとポート・タイプ定義があるインターフェース WSDL を参照し、
「OK」をクリックして、インターフェース WSDL をサービス/バインディング WSDL にインポートします。
- WSDL ファイルを保管します。
- プロジェクトの更新/再ビルドを行います。ビジネス・インテグレーション・パースペクティブに切り替えます。モジュールのアセンブリー・ダイアグラムをアセンブリー・エディターで開きます。
- プロジェクト・エクスプローラー・ビューで、マイグレーションするモジュールを展開して、
「Web サービス・ポート」論理カテゴリーを展開します。これで、バインディング/サービス WSDL に存在するポートがリスト表示されます。これをアセンブリー・エディターにドラッグ・アンド・ドロップします。
- Web サービス・バインディング付きエクスポートを作成することを選択して、該当するポート名を選択します。これにより、古いバインディング/サービスを使用するエクスポートが作成され、既存の Web サービス・クライアントを変更する必要はありません。アセンブリー・エディターで作成したばかりのエクスポートを選択して「プロパティー」ビューに進んだ場合、「バインディング」タブには、5.1 のポートとサービスの名前がすでに入力されていることが分かります。
- 変更をすべて保管します。
- アプリケーションをデプロイする直前に、生成された Web プロジェクトの構成を、
5.1 のサービス・アドレスに一致するように変更できます (これらの変更は、このファイルが再生成される原因となった SCA モジュールの変更を行うたびに実行する必要があります)。
5.1 から再使用している IBM Web サービス WSDL サービス定義を調べている場合は、
5.1 のクライアントで <wsdlsoap:address location="http://localhost:9080/MyServiceWeb/services/MyServicePort"/> とコーディングされたサービス・アドレスが表示されます。
- 6.x で生成された Web プロジェクト成果物がこの古いサービス・アドレスと一致するようにするには、生成された Web プロジェクトのデプロイメント記述子を変更する必要があります。
WebSphere Integration Developer でデプロイメント記述子を開き、「サーブレット (Servlets)」タブで、そのエクスポート用の既存の URL マッピングと非常に良く似た追加の URL マッピングを、同じサーブレット名で異なる URL パターンを指定して追加します。
- また、オリジナルのサービス・アドレスのコンテキスト・ルート (この例では、コンテキスト・ルートは「MyServiceWeb」です) と一致するように、この Web プロジェクトのコンテキスト・ルートを変更する必要がある場合は、この Web プロジェクトが入っている J2EE エンタープライズ・アプリケーションのデプロイメント記述子を開いて、古いサービス・アドレスのコンテキスト・ルートと一致するように、その Web モジュールのコンテキスト・ルートを変更します。
「CHKJ3017E: Web プロジェクト: <WEB PROJ NAME> が、EAR プロジェクト: <APP NAME> 内の無効なコンテキスト・ルート: <NEW CONTEXT ROOT> にマップされています。(CHKJ3017E: Web Project: <WEB PROJ NAME> is mapped to an invalid Context root: <NEW CONTEXT ROOT> in EAR Project: <APP NAME>.)」 というエラーが表示されますが、無視できます。
IBM Web サービス
(SOAP/HTTP) バインディングのマイグレーション・オプション 2
WebSphere Studio
Application Developer Integration Edition SOAP/HTTP プロセス・バインディングの 2 番目のマイグレーション・オプションは、ビジネス・プロセスによる SCA 以外のエンティティー (例えば JSP または Java クライアント) のアクセスを可能にします。
スタンドアロン参照は、外部クライアントによる SCA コンポーネントのアクセスを可能にします。スタンドアロン参照を作成するには、以下の手順に従ってください。
- マイグレーション・ウィザードによって作成されたモジュールをアセンブリー・エディターで開きます。
- IBM Web サービス
(SOAP/HTTP) バインディングが WebSphere Studio Application Developer Integration Edition に生成されたインターフェースごとに、スタンドアロン参照を作成します。
- ツールバーから「スタンドアロン参照」項目を選択します。
- アセンブリー・エディターのキャンバスをクリックして、スタンドアロン参照 SCA エンティティーを作成します。
- ツールバーから 「ワイヤー」項目を選択します。
- 「スタンドアロン参照」 エンティティーをクリックして、ワイヤーのソースとして選択します。
- 「SCA」 コンポーネントをクリックして、ワイヤーのターゲットとして選択します。
- アラート「ソース・ノード上にマッチング参照が作成されます。続行しますか? (Matching reference will be
created on the source node. Would you like to continue?)」が表示されたら、
「OK」をクリックします。
- 作成したばかりの「スタンドアロン参照」エンティティーを選択して、「プロパティー」ビューで「説明」コンテンツ・ペインを選択します。
- 「参照」リンクを展開して、いま作成したリファレンスを選択します。リファレンスの名前と説明がリストされ、必要であれば変更できます。
- プロセスに複数のインターフェースがある場合は、このバインディング・タイプでエクスポートするインターフェースを選択します。
- アセンブリー・ダイアグラムを保管します。
Apache Web サービス・バインディング (SOAP/HTTP) のマイグレーション
BPEL プロセスまたは他のサービス・タイプ用の Apache Web サービス・バインディング (SOAP/HTTP) は、推奨される SCA 構成にマイグレーションできます。
WebSphere
Studio Application Developer Integration Edition では、このバインディング・タイプは、クライアントに対して、
Apache Web サービスを呼び出すことによって BPEL プロセスまたは他のサービス・タイプと通信する機能を与えました。
WebSphere Studio Application Developer Integration Edition では、Apache Web サービス・バインディングが BPEL
プロセスまたは他のサービス・タイプのデプロイメント・タイプとして選択されると、以下のオプションが与えられました。
- 文書スタイルでは RPC (他のオプションは使用できません) です。
- SOAP アクションでは URN:WSDL ポート・タイプ名 です。
- アドレスでは http://localhost:9080/サービス・プロジェクト名 Web/servlet/rpcrouter です。
- 使用エンコードのデフォルトは はい です (はい の場合、エンコード・スタイルは http://schemas.xmlsoap.org/soap/encoding/ に設定されます)。
Apache SOAP バインディングとサービスを指定する WSDL ファイルは、サービス・プロジェクトに作成されます。デフォルトでは、このファイルは、
<ビジネス・プロセス名>_<ビジネス・プロセス・インターフェース・ポート・タイプ名>_SOAP.wsdl という名前でラッピングされた、サービスと同じディレクトリーに作成されます。ビジネス・プロセス・インターフェースの WSDL ポート・タイプとメッセージは、このバインディングとサービスによって、直接使用されます。マイグレーション後は、バージョン 6.x で生成される新しい WSDL 内の同じ名前空間、ポート、およびサービス名を使用する以外は、この WSDL をどんなものにも使用してはなりません。
WebSphere Studio Application
Developer Integration Edition Web サービス・バインディングのマイグレーションには、2 つのオプションがあります。クライアントを SCA プログラミング・モデルにマイグレーションするか、IBM Web サービス・プログラミング・モデルとして残すかを選択する必要があります。
Apache Web サービス (SOAP/HTTP) バインディング・タイプと同等のバインディングは、6 SCA プログラミング・モデルにはありません。
IBM Web サービス・エンジンを使用するには、この Apache Web サービスをマイグレーションする必要があります。このマイグレーションを実行して、IBM Web サービス (SOAP/HTTP) を作成する方法については、トピック『IBM Web サービス・バインディング (SOAP/HTTP) のマイグレーション』を参照してください。
WebSphere Studio
Application Developer Integration Edition サービスと対話するフリー・フォーム Java コードについて、本セクションでは、WSIF プログラミング・モデルから新しい SCA プログラミング・モデル (ここでは、アプリケーションで使用されるデータが Eclipse Service Data Object (SDO) に保管される) にマイグレーションする方法を説明します。また、もっとも一般的なクライアント・タイプを新しいプログラミング・モデルに手動でマイグレーションする方法についても説明します。
本セクションでは、Java Snippet が含まれている BPEL プロセスについて、古い Java Snippet API から、アプリケーションで使用されるデータが Eclipse Service Data Object (SDO) に保管される新しい Java Snippet API へのマイグレーション方法を説明します。可能な場合はいつでも、Snippet はマイグレーション・ウィザードによって自動的にマイグレーションされますが、マイグレーション・ウィザードが完全にはマイグレーションできない Snippet があります。つまり、マイグレーションを完了するには人手によるステップが必要となります。
以下に、プログラミング・モデルの変更点を要約します。
- V5.1 プログラミング・モデル
-
- WSIF および WSDL ベース
- サービスについて生成されたプロキシー
- タイプの Bean およびフォーマット・ハンドラー
- V6.x プログラミング・モデル (より Java 中心)
-
- ドックレット・タグを使用した SDO ベースの SCA サービス
- サービス用インターフェース・バインディング
- タイプ用 SDO およびデータ・バインディング
SDO API への WSIFMessage API 呼び出しのマイグレーション
以下のセクションでは、古い WebSphere
Business Integration Server Foundation バージョン 5.1 プログラミング・モデル
(アプリケーションで使用されるデータが、強く型付けされた生成済みインターフェースを使用して
WSIFMessage オブジェクトとして表される) から、新しい WebSphere Process
Server プログラミング・モデル
(データが Service Data Object (SDO) として表され、強く型付けされたインターフェースは生成されない) にマイグレーションする方法について説明します。
表 10. SDO API への WSIFMessage API 呼び出しのマイグレーションに関する変更点およびソリューション
変更 |
ソリューション |
WSDL メッセージ・タイプについて、WSIFMessage ベースのラッパー・クラスが生成されなくなり、複合スキーマ型について、Java Bean ヘルパー・クラスが生成されなくなりました。 |
SCA サービスと相互作用するコードを作成するときは、汎用 SDO API を使用して、アプリケーションで使用されるデータを保持する commonj.sdo.DataObject メッセージを操作する必要があります。
単一の単純型のパーツを持つ WSDL メッセージ定義は、実データにラッパーを使用する代わりに、直接そのパーツを表す単純 Java タイプによって表されるようになりました。単一メッセージ・パーツが複合型の場合、このデータは、複合型定義に従う DataObject として表されます。
現在、複数パーツを持つ WSDL メッセージ定義は、すべてのメッセージ・パーツのプロパティーを持つ DataObject に対応しています。この定義では、complexTypes は親 DataObject の「reference-type」プロパティーとして表され、
complexTypes には、getDataObject および setDataObject メソッドを使用してアクセスできます。 |
WSIFMessage パーツの強く型付けされた getter メソッドおよび生成された Java Bean は、使用してはなりません。 |
DataObject プロパティーを取得するには、弱く型付けされた SDO API を使用する必要があります。 |
BPEL 変数のメッセージ・パーツの強く型付けされた setter メソッドは、使用できなくなりました。 |
DataObject プロパティーを設定するには、弱く型付けされた SDO API を使用する必要があります。 |
WSIFMessage プロパティーの弱く型付けされた getter メソッドは、使用できなくなりました。 |
DataObject プロパティーを設定するには、弱く型付けされた SDO API を使用する必要があります。 |
WSIFMessage プロパティーの弱く型付けされた setter メソッドは、使用されなくなりました。 |
DataObject プロパティーを設定するには、弱く型付けされた SDO API を使用する必要があります。 |
可能な場合は、すべての WSIFMessage API 呼び出しを SDO API にマイグレーションします。 |
可能な場合は、この呼び出しを同等の SDO API 呼び出しにマイグレーションします。可能でない場合は、ロジックを再設計します。 |
WebSphere Business Integration Server Foundation クライアント・コードのマイグレーション
本セクションでは、WebSphere Business Integration Server Foundation 5.1 サービス・タイプとして考えられるさまざまなクライアント・タイプをマイグレーションする方法を説明します。
EJB クライアントのマイグレーション
このトピックでは、
EJB インターフェースを使用してサービスを呼び出すクライアントのマイグレーション方法を示します。
- SCA バインディング付きエクスポートを、マイグレーション済みのモジュールからこの新しいモジュールのアセンブリー・エディターにドラッグ・アンド・ドロップします。これにより、SCA バインディング付きインポートが作成されます。クライアントがこのインポートを参照できるようにするには、スタンドアロン参照を作成する必要があります。
- パレットでスタンドアロン参照項目を選択します。アセンブリー・エディターのキャンバスを一回クリックして、この新規モジュールの新しいスタンドアロン参照を作成します。
- ワイヤー・ツールを選択し、サービス参照をクリックしてから「インポート」をクリックします。
- ソース・ノード上にマッチング参照が作成されるというアラートが表示されたら、「OK」をクリックします。
- 「Java クライアントが Java インターフェースを使用するには、この参照を使用するほうが簡単です。WSDL 参照を互換性のある Java 参照に変換しますか? (It is easier for a Java client to use a Java interface with this reference -
would you like to convert the WSDL reference to a compatible Java reference?)」という質問が出されます。
- クライアントがこのサービスをルックアップして Java クラスとしてキャストし、Java インターフェースを使用して呼び出すようにするには、
「はい」と答えます。この新しい Java インターフェースは WSDL ポート・タイプから名前を取得します。インターフェースのパッケージは WSDL ポート・タイプの名前空間から派生します。
WSDL ポート・タイプに定義された操作ごとにメソッドが定義され、それぞれの WSDL メッセージ・パーツはインターフェース・メソッドに対する引数として表されます。
- クライアントがこのサービスをルックアップし、汎用 com.ibm.websphere.sca.Service インターフェースを使用して、これを汎用 SCA サービスとしての呼び出し操作で呼び出すようにするには、
「いいえ」と答えます。
- アセンブリー・エディターでスタンドアロン参照のコンポーネントを選択して、スタンドアロン参照の名前をより分かりやすい名前にします (該当する場合)。「プロパティー」ビューの「詳細」タブに移動し、作成した参照にドリルダウンし、それを選択して名前を変更します。
com.ibm.websphere.sca.ServiceManager インスタンスの locateService メソッドを呼び出すときに、クライアントがこの名前を使用する必要があるため、この参照で選択した名前を覚えておいてください。
- 「保管」をクリックして、アセンブリー・ダイアグラムを保管します。
サーバーで実行されているマイグレーション済み EJB モジュールにアクセスするために、クライアントはこの新規モジュールをローカル・クラスパス上に持つ必要があります。
以下に、「CustomerInfo」タイプのサービスでのクライアント・コードの例を示します。
// 新規 ServiceManager を作成する
ServiceManager serviceManager = ServiceManager.INSTANCE;
// CustomerInfo サービスの位置を指定する
CustomerInfo customerInfoService = (CustomerInfo) serviceManager.locateService
("<name-of-standalone-reference-from-previous-step");
// CustomerInfo サービスを呼び出す
System.out.println(" [getMyValue] getting customer info...");
DataObject customer = customerInfoService.getCustomerInfo(customerID);
クライアントは、メッセージの構成方法を変更する必要があります。以前、メッセージは WSIFMessage クラスに基づいていましたが、現在は commonj.sdo.DataObject クラスに基づいています。
EJB プロセス・バインディング・クライアントのマイグレーション
このトピックでは、WSIF EJB プロセス・バインディングを使用して
BPEL サービスにアクセスするクライアントのマイグレーション方法を示します。
EJB プロセス・バインディングを使用してビジネス・プロセスを呼び出していたクライアントは、
SCA API (マイグレーション済みビジネス・プロセスに SCA バインディング付きエクスポートがあることが必要) または IBM Web サービス・クライアント API (マイグレーション済みビジネス・プロセスに Web サービス・バインディング付きエクスポートがあることが必要) のいずれかを使用してサービスを呼び出すようになりました。
このようなクライアントを生成する方法について詳しくは、『EJB クライアントのマイグレーション』、『IBM Web サービス (SOAP/JMS) クライアントのマイグレーション』、または『IBM Web サービス (SOAP/HTTP) クライアントのマイグレーション』の各トピックを参照してください。
IBM Web サービス (SOAP/JMS) クライアントのマイグレーション
このトピックでは、Web サービス API (SOAP/JMS)
を使用してサービスを呼び出すクライアントのマイグレーション方法を示します。
マイグレーション時に、既存のクライアントのマイグレーションを行う必要はありません。生成された Web プロジェクトを手動で変更する必要があり (新しいサーブレット・マッピングを作成する)、
WebSphere Business Integration Server Foundation で公開されていたアドレスとまったく同じアドレスにサービスを公開するために、エンタープライズ・アプリケーション・デプロイメント記述子で Web プロジェクトのコンテキスト・ルートを変更しなければならない場合もあることに注意してください。トピック『IBM Web サービス・バインディング (SOAP/JMS) のマイグレーション』を参照してください。
重要な点として、WSIF または RPC クライアント・プロキシーを生成することができたバージョン 5.1 とは異なり、バージョン 6.x では、WSIF API ではなく RPC が 6.x 優先 API であるため、ツールは RPC クライアント生成しかサポートしないことに注意してください。
注:
WebSphere
Integration Developer から新しいクライアント・プロキシーを生成するには、
WebSphere Process
Server または WebSphere Application Server がインストールされている必要があります。
- WebSphere Process Server または WebSphere Application Server
がインストールされていることを確認してください。
- 「リソース」または Java パースペクティブで、
「Web サービス・バインディング付きエクスポート (Export with Web Service Binding)」に対応する WSDL ファイルを見つけて右クリックし、
「Web サービス」 -> 「クライアントを生成」を選択します (このウィザードは 5.1 のウィザードによく似ています)。
- クライアント・プロキシー・タイプとして「Java プロキシー」を選択し、
「次へ」をクリックします。
- WSDL のロケーションを入力します。
「次へ」をクリックします。
- 次に、Web サービス・ランタイムおよびサーバー、J2EE バージョン、クライアント・タイプ (Java、EJB、Web、アプリケーション・クライアント) をはじめとした、ご使用のクライアント環境構成を指定するために、該当するオプションを選択する必要があります。
「次へ」をクリックします。
- 残りのステップを完了して、クライアント・プロキシーを生成します。
IBM Web サービス (SOAP/HTTP) クライアントのマイグレーション
このトピックでは、Web サービス API (SOAP/HTTP)
を使用してサービスを呼び出すクライアントのマイグレーション方法を示します。
マイグレーション時に、既存のクライアントのマイグレーションを行う必要はありません。生成された Web プロジェクトを手動で変更する必要があり (新しいサーブレット・マッピングを作成する)、
WebSphere Business Integration Server Foundation で公開されていたアドレスとまったく同じアドレスにサービスを公開するために、エンタープライズ・アプリケーション・デプロイメント記述子で Web プロジェクトのコンテキスト・ルートを変更しなければならない場合もあることに注意してください。トピック『IBM Web サービス・バインディング (SOAP/HTTP) のマイグレーション』を参照してください。
設計の変更があったときに新しいクライアント・プロキシーを生成したい場合は、次の手順に従ってください。重要な点として、WSIF または RPC クライアント・プロキシーを生成することができたバージョン 5.1 とは異なり、バージョン 6.x では、WSIF API ではなく RPC が 6.x 優先 API であるため、ツールは RPC クライアント生成しかサポートしないことに注意してください。
注:
WebSphere
Integration Developer から新しいクライアント・プロキシーを生成するには、
WebSphere Process
Server または WebSphere Application Server がインストールされている必要があります。
- WebSphere Process Server または WebSphere Application Server
がインストールされていることを確認してください。
- 「Web サービス・バインディング付きエクスポート (Export with Web Service
Binding)」に対応する WSDL ファイルを選択して右クリックし、
「Web サービス」 -> 「クライアントを生成」 を選択します (このウィザードは 5.1 のウィザードによく似ています)。
- クライアント・プロキシー・タイプとして「Java プロキシー」を選択し、
「次へ」をクリックします。
- WSDL のロケーションを入力します。
「次へ」をクリックします。
- 次に、Web サービス・ランタイムおよびサーバー、J2EE バージョン、クライアント・タイプ (Java、EJB、Web、アプリケーション・クライアント) をはじめとした、ご使用のクライアント環境構成を指定するために、該当するオプションを選択する必要があります。
「次へ」をクリックします。
- 残りのステップを完了して、クライアント・プロキシーを生成します。
Apache Web サービス (SOAP/HTTP) クライアントのマイグレーション
Apache Web サービス・クライアント API は、WebSphere Integration Developer サービスの起動には適していません。 IBM Web サービス (SOAP/HTTP) クライアント API を使用するには、クライアント・コードをマイグレーションする必要があります。
詳しくは、トピック『IBM Web サービス (SOAP/HTTP) クライアントのマイグレーション』を参照してください。
5.1 では、クライアント・プロキシーが自動的に生成された場合、そのプロキシーは WSIF API を使用してサービスと相互作用していました。
6.x では、WSIF API ではなく RPC が 6.x 優先 API であるため、ツールは RPC クライアント生成のみをサポートします。
注:
WebSphere
Integration Developer から新しいクライアント・プロキシーを生成するには、
WebSphere Process
Server または WebSphere Application Server がインストールされている必要があります。
- WebSphere Process Server または WebSphere Application Server
がインストールされていることを確認してください。
- 「Web サービス・バインディング付きエクスポート (Export with Web Service
Binding)」に対応する WSDL ファイルを選択して右クリックし、
「Web サービス」 -> 「クライアントを生成」 を選択します (このウィザードは 5.1 のウィザードによく似ています)。
- クライアント・プロキシー・タイプとして「Java プロキシー」を選択し、
「次へ」をクリックします。
- WSDL のロケーションを入力します。
「次へ」をクリックします。
- 次に、Web サービス・ランタイムおよびサーバー、J2EE バージョン、クライアント・タイプ (Java、EJB、Web、アプリケーション・クライアント) をはじめとした、ご使用のクライアント環境構成を指定するために、該当するオプションを選択する必要があります。
「次へ」をクリックします。
- 残りのステップを完了して、クライアント・プロキシーを生成します。
JMS クライアントのマイグレーション
JMS API (JMS メッセージをキューに送信) を介して 5.1 サービスと通信するクライアントは、手動マイグレーションを必要とする場合があります。このトピックでは、JMS API (JMS メッセージをキューに送信)
を使用してサービスを呼び出すクライアントのマイグレーション方法を示します。
前のステップで作成した「JMS バインディング付きエクスポート (Export with JMS Binding)」 が、このテキスト・メッセージまたはオブジェクト・メッセージを変更せずに受け入れることができることを確認する必要があります。これを果たすために、カスタム・データ・バインディングを作成する必要がある場合があります。詳しくは、『JMS および JMS プロセス・バインディングのマイグレーション』のセクションを参照してください。
クライアントは、メッセージの構成方法を変更する必要があります。 以前、メッセージは WSIFMessage クラスに基づいていましたが、現在は commonj.sdo.DataObject クラスに基づいています。 この手動マイグレーションを行う方法について詳しくは、セクション『SDO API への WSIFMessage API 呼び出しのマイグレーション』を参照してください。
Business Process Choreographer 汎用 EJB API クライアントのマイグレーション
このトピックでは、5.1 Process Choreographer 汎用 EJB API を使用して
BPEL サービスを呼び出すクライアントのマイグレーション方法を示します。
メッセージ・フォーマットとして DataObjects を使用する汎用 EJB API の新しいバージョンがあります。クライアントは、メッセージの構成方法を変更する必要があります。以前、メッセージは WSIFMessage クラスに基づいていましたが、現在は commonj.sdo.DataObject クラスに基づいています。
ClientObjectWrapper が特定のメッセージ・フォーマットにメッセージ・ラッパーをまだ使用しているため、汎用 EJB API はあまり変更されませんでした。
Ex: DataObject dobj = myClientObjectWrapper.getObject();
String result = dobj.getInt("resultInt");
WSIFMessage オブジェクトを使用する古い汎用 EJB の JNDI 名は、以下のとおりです。
GenericProcessChoreographerEJB
JNDI Name: com/ibm/bpe/api/BusinessProcessHome
Interface: com.ibm.bpe.api.BusinessProcess
6.0 ではヒューマン・タスク操作を別々の EJB として使用できるため、
2 つの汎用 EJB があります。これらの汎用 EJB の 6.0 JNDI 名は、以下のとおりです。
GenericBusinessFlowManagerEJB
JNDI Name: com/ibm/bpe/api/BusinessFlowManagerHome
Interface: com.ibm.bpe.api.BusinessFlowManager
HumanTaskManagerEJB
JNDI Name: com/ibm/task/api/TaskManagerHome
Interface: com.ibm.task.api.TaskManager
Business Process Choreographer 汎用 Messaging API クライアントおよび JMS プロセス・バインディング・クライアントのマイグレーション
WebSphere Process Server には、汎用 Messaging API がありません。『JMS および JMS プロセス・バインディングのマイグレーション』のセクションを参照して、ビジネス・プロセスをコンシューマーに公開するための別の方法を選択し、選択されたバインディングに応じてクライアントを書き直してください。
Business Process Choreographer Web クライアントのマイグレーション
このトピックでは、5.1 Process Choreographer Web クライアント設定とカスタム JSP
のマイグレーション方法を示します。
マイグレーション・ウィザードは 5.1 Web クライアント設定を保存しており、ヒューマン・タスク・エディターでこれらの設定を編集することはできません。
WebSphere Integration Developer 6.x を使用して、新しい Web クライアント設定および JSP を作成する必要があります。
- Web クライアント変更のマイグレーション
- 5.1 では、Struts ベースの Web クライアントの JSP Header.jsp
およびスタイル・シート dwc.css を変更することによって、そのルック・アンド・フィールを変更することができました。
6.x の Web クライアント (名前を「Business Process Choreographer エクスプローラー」に変更) は、
Struts ではなく Java Server Faces (JSF) に基づいているため、
Web クライアント変更を自動的にマイグレーションすることはできません。そのため、このアプリケーションの 6.x バージョンをカスタマイズする方法の詳細については、「Business Process Choreographer エクスプローラー」の資料を参照することをお勧めします。
ビジネス・プロセスおよびスタッフ・アクティビティーについてユーザー定義 JSP を定義することができます。
Web クライアントはこれらの JSP を使用して、プロセスおよびアクティビティーの入出力メッセージを表示します。
これらの JSP は特に、以下の場合に役立ちます。
- メッセージのデータ構造の使用可能度を向上させるために、メッセージに非プリミティブ・パーツがあるとき。
- Web クライアントの能力を拡張したいとき。
6.x プロセスの Web クライアント設定を指定するときに使用可能なオプションは数も種類も増えているため、以下のように WebSphere Integration Developer を使用して、マイグレーション済みプロセスおよびアクティビティーの Web クライアント設定を再設計する必要があります。
- プロセス・キャンバスまたはプロセス内のアクティビティーを選択します。
- 「プロパティー」ビューで、「クライアント」タブを選択し、
Web クライアント設定を再設計します。
- ユーザー定義 JSP をすべて手動でマイグレーションします。
- プログラミング・モデルの変更点については、『SCA プログラミング・モデルへのマイグレーション』のセクションを参照してください。
- Web クライアントは、汎用 API を使用してビジネス・プロセスと相互作用します。これらの汎用 API の呼び出しをマイグレーションする方法を示すセクションを参照してください。
- プロセスについて、6.x Web クライアント設定で新しい JSP の名前を指定します。
注: DataObjects はカスタム・マッピングを必要としないため、
6.x Business Process Choreographer エクスプローラーでは JSP のマッピングは必要ありません。
WebSphere Business Integration Server Foundation BPEL Java Snippet のマイグレーション
Java Snippet が含まれている BPEL プロセスについて、本セクションでは、古い Java Snippet API から新しい Java Snippet API (ここでは、アプリケーションで使用されるデータが Eclipse Service Data Object (SDO) として保管される) へのマイグレーション方法を詳しく説明します。
WSIFMessage から SDO への遷移に特有のマイグレーション・ステップについては、『SDO API への WSIFMessage API 呼び出しのマイグレーション』のセクションを参照してください。
可能な場合はいつでも、Snippet はマイグレーション・ウィザードによって自動的にマイグレーションされますが、マイグレーション・ウィザードが完全にはマイグレーションできない Snippet があります。 この場合、マイグレーションを完了するには、追加の手動ステップが必要になります。 手動でマイグレーションする必要がある Java Snippet のタイプについて詳しくは、『制限』のトピックを参照してください。これらの Snippet のいずれかが検出されると、マイグレーション・ウィザードは、自動的にマイグレーションできない理由を説明し、警告またはエラー・メッセージを発行します。
以下の表で、Process Choreographer バージョン 5.1 から 6.x への BPEL Java Snippet プログラミング・モデルおよび API の変更点を詳しく説明します。
表 11. WebSphere Business Integration Server Foundation BPEL Java Snippet のマイグレーションに関する変更点およびソリューション
変更 |
ソリューション |
WSDL メッセージ・タイプについて、WSIFMessage ベースのラッパー・クラスが生成されなくなり、複合スキーマ型について、Java Bean ヘルパー・クラスが生成されなくなりました。 |
BPEL 変数は、名前により直接的にアクセスできます。
WSDL メッセージ定義に単一パーツがある BPEL 変数は、実データにラッパーを使用する代わりに、直接そのパーツを表すようになったことに注意してください。メッセージ・タイプに複数のパーツがある変数は、これらのパーツに DataObject ラッパーを使用します (WebSphere Application Developer Integration Edition でのラッパーは、WSIFMessage でした)。
6.x Snippet では BPEL 変数を直接使用できるため、5.1 での場合よりローカル変数の必要が少なくなっています。
BPEL 変数の強く型付けされた getter は、暗黙的にメッセージ・パーツの WSIFMessage ラッパー・オブジェクトを初期化していました。現在、WSDL メッセージ定義に単一のパーツしかない BPEL 変数には「ラッパー」オブジェクトはありません。この場合、BPEL 変数はそのパーツを直接表します (単一パーツが XSD 単純型で、
BPEL 変数が java.lang.String、java.lang.Integer などの Java オブジェクト・ラッパー・タイプとして表される場合)。複数パーツ WSDL メッセージ定義を持つ BPEL 変数は、異なる方法で処理されます。依然としてパーツにラッパーがあり、この DataObject ラッパーが前の操作で設定されていない場合は、
6.x Java Snippet コードで明示的に初期化される必要があります。
5.1 Snippet のローカル変数が BPEL 変数と同じ名前を持っている場合には、競合が発生する可能性があるため、可能であればこの状態を修正してください。 |
WSIFMessage オブジェクトは、BPEL 変数を表すために使用されなくなりました。 |
Java Snippet から呼び出されるカスタム Java クラスに WSIFMessage パラメーターがある場合、そのクラスは、DataObject を受け入れる/戻すようにマイグレーションする必要があります。 |
BPEL 変数の強く型付けされた getter メソッドは、使用できなくなりました。 |
変数は、名前により直接的にアクセスできます。
WSDL メッセージ定義に単一パーツがある BPEL 変数は、実データにラッパーを使用する代わりに、直接そのパーツを表すようになったことに注意してください。メッセージ・タイプに複数のパーツがある変数は、これらのパーツに DataObject ラッパーを使用します (WebSphere Application Developer Integration Edition でのラッパーは、WSIFMessage でした)。 |
BPEL 変数の強く型付けされた setter メソッドは、使用できなくなりました。 |
変数は、名前により直接的にアクセスできます。
WSDL メッセージ定義に単一パーツがある BPEL 変数は、実データにラッパーを使用する代わりに、直接そのパーツを表すようになったことに注意してください。メッセージ・タイプに複数のパーツがある変数は、これらのパーツに DataObject ラッパーを使用します (WebSphere Application Developer Integration Edition でのラッパーは、WSIFMessage でした)。 |
WSIFMessage を戻す BPEL 変数の弱く型付けされた getter メソッドは、使用できなくなりました。 |
変数は、名前により直接的にアクセスできます。
WSDL メッセージ定義に単一パーツがある BPEL 変数は、実データにラッパーを使用する代わりに、直接そのパーツを表すようになったことに注意してください。メッセージ・タイプに複数のパーツがある変数は、これらのパーツに DataObject ラッパーを使用します (WebSphere Application Developer Integration Edition でのラッパーは、WSIFMessage でした)。
getVariableAsWSIFMessage メソッドには、2 つのバリエーションがあったことに注意してください。
getVariableAsWSIFMessage(String variableName)
getVariableAsWSIFMessage(String variableName,
boolean forUpdate)
Java Snippet アクティビティーの場合、デフォルトのアクセスは読み取り/書き込みです。変数名のリストを使用して Snippet 内のコメントに @bpe.readOnlyVariables
を指定することによって、デフォルトのアクセスを読み取り専用に変更することができます。例えば、以下のように、変数 B と変数 D を読み取り専用に設定することができます。
variableB.setString("/x/y/z", variableA.getString
("/a/b/c"));
// @bpe.readOnlyVariables names="variableA"
variableD.setInt("/x/y/z", variableC.getInt
("/a/b/c"));
// @bpe.readOnlyVariables names="variableC"
さらに、Java Snippet が条件内にある場合、デフォルトでは、変数は読み取り専用ですが、
@bpe.readWriteVariables... を指定することによって、変数を読み取り/書き込みにすることができます。 |
BPEL 変数の弱く型付けされた setter メソッドは、使用できなくなりました。 |
変数は、名前により直接的にアクセスできます。
WSDL メッセージ定義に単一パーツがある BPEL 変数は、実データにラッパーを使用する代わりに、直接そのパーツを表すようになったことに注意してください。メッセージ・タイプに複数のパーツがある変数は、これらのパーツに DataObject ラッパーを使用します (WebSphere Application Developer Integration Edition でのラッパーは、WSIFMessage でした)。 |
BPEL 変数メッセージ・パーツの弱く型付けされた getter メソッドは単一パーツのメッセージには適切ではなく、複数パーツ・メッセージ用に変更されています。 |
BPEL 変数 (DataObject) プロパティーの弱く型付けされた getter メソッドにマイグレーションします。
WSDL メッセージ定義に単一パーツがある BPEL 変数の場合、
BPEL 変数はそのパーツを直接表すこと、および、この変数には getter メソッドを使用せずに直接アクセスする必要があること注意してください。
getVariablePartAsObject メソッドには、2 つのバリエーションがありました。
getVariablePartAsObject(String variableName,
String partName)
getVariablePartAsObject(String variableName,
String partName,boolean forUpdate)
複数パーツ・メッセージの場合、
6.x の次のメソッドによって同等の機能が提供されています。
getVariableProperty(String variableName, QName
propertyName);
6.x では、読み取り専用アクセスに変数を使用するという概念はありません (これは、
5.1 では、上記の最初のメソッドおよび forUpdate=' false' を使用する 2 番目のメソッドの場合に該当します)。変数は 6.x Snippet で直接使用され、常に更新することが可能です。 |
BPEL 変数のメッセージ・パーツに弱く型付けされた setter メソッドは単一パーツのメッセージには適切ではなく、複数パーツ・メッセージ用に変更されています。 |
BPEL 変数 (DataObject) プロパティーの弱く型付けされた setter メソッドにマイグレーションします。
WSDL メッセージ定義に単一パーツがある BPEL 変数の場合、
BPEL 変数はそのパーツを直接表すこと、および、この変数には setter メソッドを使用せずに直接アクセスする必要があること注意してください。
次のメソッドの呼び出しをマイグレーションする必要があります。
setVariableObjectPart(String variableName,
String partName, Object data)
複数パーツ・メッセージの場合、
6.x の次のメソッドによって同等の機能が提供されています。
setVariableProperty(String variableName,
QName propertyName, Serializable value); |
BPEL パートナー・リンクの強く型付けされた getter メソッドは、使用できなくなりました。 |
BPEL パートナー・リンクの弱く型付けされた getter メソッドにマイグレーションします。 |
BPEL パートナー・リンクの強く型付けされた setter メソッドは、使用できなくなりました。 |
BPEL パートナー・リンクの弱く型付けされた setter メソッドにマイグレーションします。 |
BPEL 相関の強く型付けされた getter メソッドは、使用できなくなりました。 |
- V5.1 Snippet:
-
String corrSetPropStr =
getCorrelationSetCorrSetAProperty
CustomerName();
int corrSetPropInt =
getCorrelationSetCorrSetBProperty
CustomerId();
- V6.x Snippet:
-
String corrSetPropStr = (String)
getCorrelationSetProperty
("CorrSetA", new QName("CustomerName"));
int corrSetPropInt = ((Integer)
getCorrelationSetProperty
("CorrSetB", new QName("CustomerId"))).
intValue();
|
BPEL アクティビティー・カスタム・プロパティーの弱く型付けされた getter メソッドに必要な追加パラメーター。 |
- V5.1 Snippet:
-
String val = getActivityCustomProperty
("propName");
- V6.x Snippet:
-
String val = getActivityCustomProperty
("name-of-current-activity", "propName");
|
BPEL アクティビティー・カスタム・プロパティーの弱く型付けされた setter メソッドに必要な追加パラメーター。 |
- V5.1 Snippet:
-
String newVal = "new value";
setActivityCustomProperty
("propName", newVal);
- V6.x Snippet:
-
String newVal = "new value";
setActivityCustomProperty("name-of-current-
activity","propName", newVal);
|
raiseFault(QName faultQName, Serializable message) メソッドはなくなりました。 |
可能な場合は、raiseFault(QName faultQName, String variableName) にマイグレーションします。可能でない場合は、raiseFault(QName faultQName) メソッドにマイグレーションするか、またはシリアライズ可能オブジェクト用の新しい BPEL 変数を作成してください。 |
WebSphere Business Integration Adapter との相互作用のマイグレーション
JMS クライアントが WebSphere Business Integration Adapter である場合は、「外部サービス」ツールを使用して JMS バインディング付きインポートを作成しなければならないときがあります。このインポートは、WebSphere Business Integration
Adapter が要求する正確なフォーマットに SDO をシリアライズするために、特殊なデータ・バインディングを使用します。
「外部サービス」ツールにアクセスするには、以下の手順に従ってください。
- 「ファイル」 -> 「新規」 -> 「その他」 -> 「ビジネス・インテグレーション」と進み、「外部サービス」を選択します。「次へ」をクリックします。
- 「アダプター」を選択します。「次へ」をクリックします。
- WebSphere Business Integration Adapter の構成ファイル (.cfg)、およびアダプターが使用するビジネス・オブジェクトの XML スキーマが含まれるディレクトリーへのパスを入力します。
「次へ」をクリックします。
- 生成された照会を調べて、正しければ「照会の実行」をクリックします。
「照会で検出されたオブジェクト」リストで、追加するオブジェクトを (1 つずつ) 選択して、>>「追加」ボタンをクリックします。
- ビジネス・オブジェクト用の構成パラメーターを受け入れて、
「OK」をクリックします。
- ビジネス・オブジェクトのそれぞれについて繰り返します。
- 「次へ」をクリックします。
- 「ランタイム・ビジネス・オブジェクト・フォーマット」で、
「SDO」を選択します。
「ターゲット・プロジェクト」で、マイグレーションしたばかりのモジュールを選択します。
「フォルダー」フィールドはブランクのままにしてください。
- 「終了」をクリックします。
このツールは、古い XSD を、特殊データ・バインディングが期待するフォーマットにマイグレーションします。そのため、古い WebSphere Business Integration Adapter の XSD
をモジュールから除去して、新しい XSD を使用してください。モジュールがアダプターからのメッセージを受信しない場合は、このツールが生成したエクスポートを削除してください。モジュールがアダプターにメッセージを何も送信しない場合は、インポートを削除してください。このフィーチャーについての詳細は、インフォメーション・センターを参照してください。
SOAP エンコード配列型を持つ WSDL インターフェースのマイグレーション
本セクションでは、
SOAP エンコード配列型を持つ XML スキーマをマイグレーションまたは処理する方法について説明します。
RPC スタイルを持つ SOAP エンコード配列型は、
6.x では具象型のアンバインド済みシーケンスとして処理されます。プログラミング・モデルは、RPC スタイルの代わりに文書/リテラル・ラップ済みスタイルに移行されるため、どのような方法でも、soapend:Array タイプを参照する XSD タイプを作成することは推奨されません (これは変更される可能性があります)。
SCA アプリケーションが、soapend:Array タイプを使用する外部サービスを呼び出す必要があるケースも出てきます。場合によっては、これを避ける方法がないため、このような状態を処理する方法を次に示します。
サンプル WSDL コード:
<xsd:complexType name="Vendor">
<xsd:all>
<xsd:element name="name" type="xsd:string" />
<xsd:element name="phoneNumber" type="xsd:string" />
</xsd:all>
</xsd:complexType>
</xsd:schema>
<xsd:complexType name="Vendors">
<xsd:complexContent mixed="false">
<xsd:restriction base="soapenc:Array">
<xsd:attribute wsdl:arrayType="tns:Vendor[]" ref="soapenc:arrayType"
xmlnxsd:wsdl="http://schemas.xmlsoap.org/wsdl/" />
</xsd:restriction>
</xsd:complexContent>
<xsd:complexType name="VendorsForProduct">
<xsd:all>
<xsd:element name="productId" type="xsd:string" />
<xsd:element name="vendorList" type="tns:Vendors" />
</xsd:all>
</xsd:complexType>
<xsd:complexType name="Product">
<xsd:all>
<xsd:element name="productId" type="xsd:string" />
<xsd:element name="productName" type="xsd:string" />
</xsd:all>
</xsd:complexType>
<message name="doFindVendorResponse">
<part name="returnVal" type="tns:VendorsForProduct" />
</message>
<operation name="doFindVendor">
<input message="tns:doFindVendor" />
<output message="tns:doFindVendorResponse" />
</operation>
この Web サービスのクライアント用サンプル・コード:
// ベンダー・サービスを探し、doFindVendor 操作を見つける
Service findVendor=(Service)ServiceManager.INSTANCE.locateService("vendorSearch");
OperationType doFindVendorOperationType=
findVendor.getReference().getOperationType("doGoogleSearch");
// 入力 DataObject を作成する
DataObject doFindVendor=DataFactory.INSTANCE.create
(doFindVendorOperationType.getInputType());
doFindVendor.setString("productId", "12345");
doFindVendor.setString("productName", "Refrigerator");
// FindVendor サービスを呼び出す
DataObject FindVendorResult = (DataObject)findVendor.invoke
(doFindVendorOperationType, doFindVendor);
// 結果を表示する
int resultProductId=findVendorResult.getString("productId");
DataObject resultElements=findVendorResult.getDataObject("vendorList");
Sequence results=resultElements.getSequence(0);
for (int i=0, n=results.size(); i
for (int i=0, n=results.size(); i
以下のもう 1 つの例は、データ・オブジェクトのルート・タイプが soapenc:Array である場合です。
sampleElements DataObject が、上にリストされた 2 番目のスキーマを使用し、どのように作成されるかに注目してください。最初に DataObject のタイプが取得され、次に sampleStructElement のプロパティーが取得されています。これは実際はプレースホルダー・プロパティーで、
DataObjects をシーケンスに追加するときに使用する有効なプロパティーを取得するためのみに使用されます。このようなパターンをシナリオで使用することができます。
サンプル WSDL コード:
<s:schema elementFormDefault="qualified" targetNamespace="http://soapinterop.org/xsd">
<s:import namespace="http://schemas.xmlsoap.org/soap/encoding/" />
<s:import namespace="http://schemas.xmlsoap.org/wsdl/" />
<s:complexType name="SOAPStruct">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" form="unqualified"
name="varInt" type="s:int" />
<s:element minOccurs="1" maxOccurs="1" form="unqualified"
name="varString" type="s:string" />
<s:element minOccurs="1" maxOccurs="1" form="unqualified"
name="varFloat" type="s:float" />
</s:sequence>
</s:complexType>
<s:complexType name="ArrayOfSOAPStruct">
<s:complexContent mixed="false">
<s:restriction base="soapenc:Array">
<s:attribute wsdl:arrayType="s0:SOAPStruct[]" ref="soapenc:arrayType" />
</s:restriction>
</s:complexContent>
</s:complexType>
</s:schema>
<wsdl:message name="echoStructArraySoapIn">
<wsdl:part name="inputStructArray" type="s0:ArrayOfSOAPStruct" />
</wsdl:message>
<wsdl:message name="echoStructArraySoapOut">
<wsdl:part name="return" type="s0:ArrayOfSOAPStruct" />
</wsdl:message>
<wsdl:operation name="echoStructArray">
<wsdl:input message="tns:echoStructArraySoapIn" />
<wsdl:output message="tns:echoStructArraySoapOut" />
</wsdl:operation>
<schema targetNamespace="http://sample/elements"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://sample/elements">
<element name="sampleStringElement" type="string"/>
<element name="sampleStructElement" type="any"/>
</schema>
この Web サービスのクライアント用サンプル・コード:
// 入力 DataObject を作成し、任意のエレメントの SDO シーケンス
// を取得する
DataFactory dataFactory=DataFactory.INSTANCE;
DataObject arrayOfStruct = dataFactory.create
("http://soapinterop.org/xsd","ArrayOfSOAPStruct");
Sequence sequence=arrayOfStruct.getSequence("any");
// シーケンスを移植するために、ここで使用したいサンプル・エレメントの
// SDO プロパティーを取得する
// このエレメントは XSD ファイルに定義済み。SampleElements.xsd を参照
DataObject sampleElements=dataFactory.create("http://sample/elements",
"DocumentRoot");
Property property = sampleElements.getType().getProperty("sampleStructElement");
// エレメントをシーケンスに追加する
DataObject item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 1);
item.setString("varString", "Hello");
item.setFloat("varFloat", 1.0f);
sequence.add(property, item);
item=dataFactory.create("http://soapinterop.org/xsd", "SOAPStruct");
item.setInt("varInt", 2);
item.setString("varString", "World");
item.setFloat("varFloat", 2.0f);
sequence.add(property, item);
// echoStructArray 操作を呼び出す
System.out.println("[client] invoking echoStructArray operation");
DataObject echoArrayOfStruct = (DataObject)interopTest.invoke("echoStructArray",
arrayOfStruct);
// 結果を表示する
if (echoArrayOfStruct!=null) {
sequence=echoArrayOfStruct.getSequence("any");
for (int i=0, n=sequence.size(); i<n; i++) {
item=(DataObject)sequence.getValue(i);
System.out.println("[client] item varInt = "+
item.getInt("varInt")+"
varString="+item.getString("varString")+"
varFloat="+item.getFloat("varFloat"));
WebSphere Business Integration EJB プロジェクトのマイグレーション
WebSphere
Studio Application Developer Integration Edition では、
EJB プロジェクトが拡張メッセージング (CMM) および CMP/A (Component-Managed Persistence Anywhere)
などの特殊な WebSphere
Business Integration フィーチャーを持つ場合があります。そのようなプロジェクトのデプロイメント記述子はマイグレーションする必要があるため、本セクションでは、そうしたマイグレーションを実行する方法を説明します。
このマイグレーションを実行するには、以下の手順に従ってください。
- WebSphere Business Integration EJB プロジェクトを新しいワークスペースにコピーし、これを「ファイル」 -> 「インポート」 -> 「既存プロジェクトをワークスペースへ」ウィザードを使用して WebSphere Integration Developer にインポートします。オプションで、J2EE マイグレーション・ウィザードを実行することもできます。
- 6.x ワークスペースで実行中のすべての WebSphere Integration Developer インスタンスを閉じます。
- 次のスクリプトを実行して、EJB プロジェクト内の WebSphere Business Integration デプロイメント記述子をマイグレーションします。
- Windows の場合:
-
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/
WSADIEEJBProjectMigration.bat
- Linux の場合:
-
SHARED_FOLDER_HOME/plugins/com.ibm.wbit.migration.wsadie_6.1.0/
WSADIEEJBProjectMigration.sh
以下のパラメーターがサポートされています。ワークスペースとプロジェクト名は必須です。
使用法: WSADIEEJBProjectMigration.bat
[-e eclipse-folder] -d workspace -p project
eclipse-folder: Eclipse フォルダーのロケーション (通常は「eclipse」)
製品インストール・フォルダーの下にあります。
workspace: マイグレーションする WSADIE EJB プロジェクトが含まれるワークスペース
project: マイグレーションするプロジェクトの名前
例:
WSADIEEJBProjectMigration.bat -e "C:¥IBM¥WID6¥eclipse" -d "d:¥my60workspace"
-p "MyWBIEJBProject"
- WebSphere Integration Developer を開くときに、更新されたファイルを取得するために EJB プロジェクトを更新する必要があります。
- EJB プロジェクト内の ibm-web-ext.xmi ファイルを検索します。ファイルが検出されたら、ファイル内のエレメントの下に、以下の行があることを確認します。
<webappext:WebAppExtension> element:
<webApp href="WEB-INF/web.xml#WebApp"/>
- 5.1 で生成された古いデプロイメント・コードを除去します。
WebSphere Application Server ガイドラインの該当する手順に従って、デプロイメント・コードを再生成します。
5.1 Web Services Invocation Framework (WSIF) 定義の手動削除
ソース成果物のマイグレーションを完了した後、今後は使用されないすべての 5.1 WSIF バインディングおよびサービス WSDL 定義を、
6.x プロジェクトから削除する必要があります。サービス・マイグレーションの利用シナリオは、
WSIF バインディングまたはサービスがまだ使用される唯一のケースです。
以下の WSDL 名前空間は、バインディングまたはサービス定義が 5.1 WSIF サービスであり、今後使用されることがない場合、廃棄してもかまわないということを示します。
- EJB WSIF 名前空間:
- http://schemas.xmlsoap.org/wsdl/ejb/
- Java WSIF 名前空間:
- http://schemas.xmlsoap.org/wsdl/java/
- JMS WSIF 名前空間:
- http://schemas.xmlsoap.org/soap/jms/
- ビジネス・プロセス WSIF 名前空間:
- http://schemas.xmlsoap.org/wsdl/process/
- 変換プログラム WSIF 名前空間:
- http://schemas.xmlsoap.org/wsdl/transformer/
- IMS WSIF 名前空間:
- http://schemas.xmlsoap.org/wsdl/ims/
- CICS-ECI WSIF 名前空間:
- http://schemas.xmlsoap.org/wsdl/cicseci/
- CICS-EPI WSIF 名前空間:
- http://schemas.xmlsoap.org/wsdl/cicsepi/
- HOD WSIF 名前空間:
- http://schemas.xmlsoap.org/wsdl/hod3270/
ソース成果物マイグレーションの検査
マイグレーションがエラー、警告、通知メッセージのリストとともに完了した場合、それらは「マイグレーション結果」ウィンドウに表示されます。マイグレーションが正常に完了した場合は、ウィザードのウィンドウが閉じます。
マイグレーション・メッセージがマイグレーション・プロセス中に生成された場合は、次のページが表示されます。
「マイグレーション結果」ウィンドウで、マイグレーション・プロセス中に生成されたマイグレーション・メッセージを見ることができます。上部のメッセージ・リストからメッセージを選択すると、そのメッセージに関する詳細が「メッセージの説明」ウィンドウに表示されます。
今後の参照用にすべてのメッセージを保存しておくには、「タスクの生成」ボタンをクリックして、タスクのリストをタスク・ビューに作成するか、「別名保管...」ボタンをクリックしてファイル・システム内のテキスト・ファイルにメッセージを保管するか、またはその両方を行います。それぞれのメッセージを調べて、完全にマイグレーションできなかった成果物を即時に修正するためにアクションを実行する必要があるかどうかを確認します。生成された予定を表示するには、「ウィンドウ」 -> 「ビューの表示」 -> 「その他... (Other...)」 -> 「一般」 -> 「タスク」をクリックして、「OK」をクリックします。「タスク」ビューが開き、生成された予定のリストがマイグレーション・プロセスから表示されます。
マイグレーションの一部が完了していることを検査するために、ビジネス・インテグレーション・パースペクティブに切り替えて、古いサービス・プロジェクトからのすべてのプロセスおよび WSDL インターフェースが新規モジュール内に現れることを確認します。プロジェクトをビルドし、プロジェクトのビルドを妨げるエラーがあればそのエラーを修正します。
ビジネス・インテグレーション・アプリケーションのマイグレーションを完了するために必要な手動マイグレーション・ステップを実行した後で、そのアプリケーションを EAR ファイルとしてエクスポートし、それを
WebSphere Process Server にインストールして、該当するリソースを構成します。
任意のクライアント・コードをマイグレーションするために必要な手動マイグレーション・ステップを実行するか、または
WebSphere Integration Developer を使用して新規のクライアント・コードを生成します。クライアントがアプリケーションにアクセスできること、およびアプリケーションが以前のランタイム環境と同じように動作することを確認してください。
ソース成果物マイグレーション失敗時の作業
WebSphere Studio
Application Developer Integration Edition からのソース成果物マイグレーションが失敗した場合、これに対処するさまざまな方法があります。
可能性のあるソース成果物マイグレーションの失敗を以下にいくつか示します。
このメッセージが表示されずにマイグレーション・ウィザードが完了した場合でも、情報メッセージ、警告メッセージ、およびエラー・メッセージのリストが表示されます。これらのメッセージは、サービス・プロジェクトの一部を自動的にマイグレーションできなかったため、マイグレーションを完了するには手動で変更を行う必要があることを示します。
マイグレーション・プロセスの制限 (ソース成果物マイグレーション)
WebSphere Studio
Application Developer Integration Edition ソース成果物マイグレーション・プロセスには、特定の制限があります。
以下のリストでは、ソース成果物マイグレーションのマイグレーション・プロセスの一部の制限について詳しく説明します。
一般的制限
- WSDL とプロジェクト内の他の成果物との間の整合性は、WebSphere Studio Application Developer Integration Edition では厳密にとられていませんでした。
WebSphere Integration Developer はより厳密になり、WebSphere Studio Application Developer Integration Edition が報告しなかった不整合を報告するようになりました (また、これは WebSphere Business Integration Server Foundation ランタイムでは問題なく実行されていました)。
- WebSphere Studio Application Developer Integration Edition は複数の同一 Web サービス・バインディングとサービス定義 (名前および名前空間) を許可しますが、WebSphere Integration Developer は許可しません。このような重複は、マイグレーションの前 (WebSphere Studio Application Developer Integration Edition の場合) またはマイグレーションの後
(WebSphere Integration Developer の場合) に、手動で解決する必要があります。例えば WebSphere Studio Application Developer Integration Edition では、名前の異なる (末尾が _EJB、_JMS など) WSDL ファイルに生成されたサービス定義はすべて、次のようになります。
<service name="OrderProcessIntfcService">
重複は、バインディング・タイプを名前属性に追加するだけで修正できます。
*_EJB.wsdl ファイルの場合は、次のように変更します。
<service name="OrderProcessIntfcServiceEJB">
*_JMS.wsdl ファイルの場合は、次のように変更します。
<service name="OrderProcessIntfcServiceJMS">
ただし、この名前を変更した場合は、このサービスを使用するために WebSphere Integration Developer で生成したエクスポートも、正しい名前を使用するように変更することが必要になります。
- このマイグレーション・ウィザードでは、
WebSphere Studio Application Developer Integration Edition
のワークスペース全体を処理することはできません。これは、一度に 1 つの WebSphere
Studio Application Developer Integration Edition サービス・プロジェクトをマイグレーションすることを意味します。
- マイグレーション・ウィザードでは、アプリケーション・バイナリーはマイグレーションされません。
WebSphere Studio Application Developer Integration Edition
サービス・プロジェクトにあるソース成果物のみがマイグレーションされます。
- ビジネス・ルール Bean は、WebSphere Process Server 6.x で使用すべきではありませんが、WebSphere Process Server のインストール時に、使用すべきではないビジネス・ルール Bean のサポートをインストールするためのオプションがあります。これによって、ビジネス・ルール Bean が WebSphere Process
Server 6.x サーバー上で「現状どおり」実行されます。古いビジネス・ルール Bean 用のツール・サポートはありませんが、古いビジネス・ルール Bean の成果物をツールでコンパイルしたい場合は、
WebSphere Integration Developer の資料に従って、これらの使用すべきではないフィーチャーを、組み込みの WebSphere
Process Server 6.x テスト・サーバー上にインストールしてから、推奨されない JAR ファイルを外部 JAR としてプロジェクト・クラスパスに手動で追加する必要があります。
WebSphere Integration Developer で使用可能な新しいビジネス・ルールのツールを使用して、
6.x 仕様に従ったビジネス・ルールを再作成する必要があります。
- 拡張メッセージング・サポートは WebSphere Process Server 6.x で使用すべきではありませんが、 WebSphere Process Server のインストール時に、使用すべきではない拡張メッセージング・フィーチャーのサポートをインストールするためのオプションがあります。これによって、既存のアプリケーションが
WebSphere Process
Server 6.x サーバー上で「現状どおり」実行できます。古い拡張メッセージング・フィーチャー用のツール・サポートはありませんが、古い拡張メッセージングの成果物をツールでコンパイルしたい場合は、
WebSphere Integration
Developer の資料に従って、これらの使用すべきではないフィーチャーを、組み込みの WebSphere Process Server 6.x テスト・サーバー上にインストールしてから、使用すべきではない JAR ファイルを「外部 JAR」としてプロジェクト・クラスパスに手動で追加する必要があります。
- 標準で提供されている JMS データ・バインディングは、カスタム JMS ヘッダー・プロパティーへのアクセスを提供しません。カスタム JMS ヘッダー・プロパティーにアクセスするには、
SCA サービス用にカスタム・データ・バインディングを作成する必要があります。
SCA プログラミング・モデルの制限
- SDO バージョン 1 仕様は、COBOL または C のバイト配列へのアクセスを提供しません。これは、IMS 複数セグメントを処理するユーザーに影響することになります。
- シリアライゼーション用 SDO バージョン 1 仕様は、COBOL 再定義または C 共用体をサポートしません。
- SCA プログラミング・モデルに従ってソース成果物を再設計するときは、文書/リテラル・ラップ済み WSDL スタイル (WebSphere Integration Developer ツールを使用して作成される新規成果物のデフォルト・スタイル) は、メソッドの多重定義をサポートしないことに注意してください。その他の WSDL スタイルは引き続きサポートされているため、このような場合は、文書/リテラル・ラップ済み以外の WSDL スタイル/エンコードを使用することをお勧めします。
- 配列のネイティブ・サポートは限定されています。
soapenc:Array タイプの WSDL インターフェースを公開する外部サービスを呼び出すには、「maxOccurs」属性が 1 より大きいエレメントを定義する WSDL インターフェースを作成する必要があります
(これは、配列タイプの設計で推奨される方法です)。
BPEL マイグレーション・プロセスの技術的な制限
- 1 つの BPEL 操作での複数の応答 - WebSphere Business Integration Server Foundation では、ビジネス・プロセスは同じ操作に対して 1 つの受信アクティビティーと複数の応答アクティビティーを持つことができました。 同じ操作に対して複数の応答を持つビジネス・プロセスがある場合、いずれかにクライアント設定があれば、その操作に対するすべての応答が同じクライアント設定を持っていることを確認してください。
6.x では、操作応答ごとに 1 セットのクライアント設定のみがサポートされるためです。
- BPEL Java Snippet マイグレーションの制限 - プログラミング・モデルは WebSphere Studio Application Developer Integration
Edition から WebSphere Integration
Developer に著しく変更されていて、サポートされている WebSphere Studio Application Developer Integration Edition API の一部は、対応する WebSphere Integration Developer API に直接マイグレーションできません。自動マイグレーション・ツールが各 Java Snippet を新しいプログラミング・モデルに変換できないように、Java ロジックは BPEL Java Snippet にあります。標準 Snippet API 呼び出しの多くは、5.1 Java Snippet プログラミング・モデルから 6.x Java Snippet プログラミング・モデルに自動的にマイグレーションされます。可能な場合、WSIF API 呼び出しは DataObject API 呼び出しにマイグレーションされます。
WSIFMessage オブジェクトを受け入れるカスタム Java クラスは、commonj.sdo.DataObject オブジェクトを代わりに受け入れて戻すように手動のマイグレーションを必要とします。
- WSIFMessage metadata APIs - 一部の WSIFMessage メタデータと他の WSIF API には、手動マイグレーションが必要になる場合があります。
- EndpointReference/EndpointReferenceType API - これらのクラスは自動的にはマイグレーションされません。パートナー・リンク getter/setter メソッドは 5.1 の
com.ibm.websphere.srm.bpel.wsaddressing.EndpointReferenceType オブジェクトの代わりに
commonj.sdo.DataObject オブジェクトを処理するため、手動のマイグレーションが必要になります。
- 重複名を持つ複合型 - 同一の名前空間とローカル名を持つか、または名前空間は異なるが同一のローカル名を持つ複合型を (WSDL または XSD で) アプリケーションが宣言する場合、このタイプを使用する Java
Snippet が正しくマイグレーションされない場合があります。マイグレーション・ウィザードが完了した後で Snippet が正しいかどうか検査してください。
- java.lang パッケージ内の Java クラスと同一のローカル名を持つ複合型 - J2SE 1.4.2 の java.lang パッケージ内のクラスと同一のローカル名を持つ複合型を (WSDL または XSD で) アプリケーションが宣言する場合、対応する java.lang クラスを使用する Java Snippet が正しくマイグレーションされない場合があります。 マイグレーション・ウィザードが完了した後で Snippet が正しいかどうか検査してください。
- 読み取り専用および読み取り/書き込みの BPEL 変数 - どの 5.1
Java Snippet コードでも、BPEL 変数を「読み取り専用」に設定することが可能でした。つまり、このオブジェクトに行われた変更は、BPEL 変数の値にまったく影響を与えません。また BPEL 変数を「読み取り/書き込み」に設定することも可能でした。つまり、オブジェクトに行われた変更はすべて、BPEL 変数自体に反映されます。以下に、任意の 5.1 BPEL Java Snippet で、
Java Snippet に「読み取り専用」としてアクセスできる 4 つの方法を示します。
getMyInputVariable()
getMyInputVariable(false)
getVariableAsWSIFMessage("MyInputVariable")
getVariableAsWSIFMessage("MyInputVariable", false)
以下に、任意の 5.1 BPEL
Java Snippet で、
BPEL 変数に「読み取り/書き込み」としてアクセスできる 2 つの方法を示します。
getMyInputVariable(true)
getVariableAsWSIFMessage("MyInputVariable", true)
6.x では、
BPEL 変数に対する読み取り専用および読み取り/書き込みのアクセスは、「Snippet ごとに」に処理されます。つまり、特別なコメントを BPEL Java Snippet に追加して、Snippet が実行を終了した後、BPEL 変数に対する更新を、廃棄するかまたは保持するかを指定できます。以下に、6.x BPEL Java
Snippet タイプに対するデフォルトのアクセス設定を示します。
BPEL Java Snippet Activity
Default Access: read-write
Override Default Access with comment containing:
@bpe.readOnlyVariables names="variableA,variableB"
BPEL Java Snippet Expression (Used in a Timeout, Condition, etc)
Default Access: read-only
Override Default Access with comment containing:
@bpe.readWriteVariables names="variableA,variableB"
マイグレーション時に、変数が 6.x でのデフォルトではない方法でアクセスされた場合、これらのコメントが自動的に作成されます。競合が存在する場合
(つまり、同一 Snippet 内で BPEL 変数が「読み取り専用」および「読み取り/書き込み」としてアクセスされた場合)、警告が出され、アクセスは「読み取り/書き込み」に設定されます。そのような警告を受け取った場合は、
BPEL 変数アクセスを「読み取り/書き込み」に設定することが、ご使用の状態にとって正しいことであるか確認してください。これが正しくない場合は、WebSphere Integration Developer BPEL エディターを使用して、手動で訂正する必要があります。
- 複合型の多値プリミティブ・プロパティー - 5.1 では、多値プロパティーはプロパティー・タイプの配列によって表されます。そういうものだから、プロパティーを取得および設定する呼び出しは、配列を使用します。
6.x では、これを表すために java.util.List が使用されます。自動マイグレーションは、多値プロパティーが、あるタイプの Java オブジェクトであるケースをすべて処理しますが、プロパティー・タイプが Java プリミティブ (整数、長形式、短形式、バイト、文字、浮動小数点、倍精度、およびブール) である場合には、配列全体を取得および設定する呼び出しは変換されません。このような場合の手動マイグレーションでは、残りの Snippet で使用するために、対応する Java ラッパー・クラスで、またはそこからプリミティブ (整数、長形式、短形式、バイト、文字、浮動小数点、倍精度、およびブール) をラップ/アンラップするためのループを追加することが必要になる場合があります。
- 複合型を表す生成済みクラスのインスタンス化 - 5.1 では、アプリケーションに定義されている複合型の生成済みクラスは、引数なしのデフォルト・コンストラクターを使用して Java Snippet で容易にインスタンス化できました。例えば、次のようになります。
MyProperty myProp = new MyProperty();
InputMessageMessage myMsg = new InputMessageMessage();
myMsg.setMyProperty(myProp);
6.x では、特殊なファクトリー・クラスを使用してこれらのタイプをインスタンス化する必要があります。または、収容型のインスタンスを使用してサブタイプを作成できます。
BPEL プロセス変数 InputVariable がタイプ InputMessage を持つと定義された場合、上記 Snippet の 6.x バージョンは以下のようになります。
com.ibm.websphere.bo.BOFactory boFactory=
(com.ibm.websphere.bo.BOFactory)
com.ibm.websphere.sca.ServiceManager.INSTANCE.locateService(
"com/ibm/websphere/bo/BOFactory");
commonj.sdo.DataObject myMsg =
boFactory.createByType(getVariableType("InputVariable"));
commonj.sdo.DataObject myProp =
myMsg.createDataObject("MyProperty");
Snippet コンバーターはこの変更を試行しますが、オリジナルのインスタンス化が行われる順序が親から子へのパターンに従わない場合には、手動のマイグレーションが必要になります (すなわち、コンバーターは、Snippet 内のインスタンス化ステートメントを自ら再配列しようとはしません)。
- WebSphere Business
Integration Server Foundation 5.1 では、動的参照は、名前空間のタイプ EndpointReferenceType またはエレメント EndpointReference の WSDL メッセージ・パーツとして表されました。
http://wsaddressing.bpel.srm.websphere.ibm.com
このような参照は、標準ビジネス・プロセス名前空間から標準 service-ref エレメント・タイプにマイグレーションされます。
http://schemas.xmlsoap.org/ws/2004/03/business-process/
http://schemas.xmlsoap.org/ws/2004/08/addressing
すべての参照が正しく解決されるようにこれらのスキーマ定義をプロジェクトに手動でインポートする手順については、
BPEL エディターの資料を参照してください。
- BPEL 変数メッセージ・タイプ - WSDL メッセージ・タイプは、
Java Snippet で使用されるすべての BPEL 変数に対して指定する必要があります。「messageType」属性を指定せずに BPEL 変数にアクセスする Java Snippet は、マイグレーションすることができません。
特記事項
本書は米国 IBM が提供する製品およびサービスについて作成したものであり、本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。本書で IBM(R) 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。
IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。
〒106-8711
東京都港区六本木 3-2-12
日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外
以下の保証は、国または地域の法律に沿わない場合は、適用されません。
IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任または保証条件は適用されないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。
この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。
IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。
本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。
IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。
本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。
Intellectual Property Dept. for WebSphere Integration Developer
IBM Canada Ltd.
8200 Warden Avenue
Markham, Ontario L6G 1C7
Canada
本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。
本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。
この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。
IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。
IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。
本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。
著作権使用許諾:
本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。お客様は、IBM のアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。
それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作物にも、次のように、著作権表示を入れていただく必要があります。
(C)
(お客様の会社名) (西暦年). このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。
(C) Copyright IBM Corp. 2000, 2007. All rights reserved.
この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。
プログラミング・インターフェース情報
プログラミング・インターフェース情報は、プログラムを使用してアプリケーション・ソフトウェアを作成する際に役立ちます。
一般使用プログラミング・インターフェースにより、お客様はこのプログラム・ツール・サービスを含むアプリケーション・ソフトウェアを書くことができます。
ただし、この情報には、診断、修正、および調整情報が含まれている場合があります。診断、修正、調整情報は、お客様のアプリケーション・ソフトウェアのデバッグ支援のために提供されています。
警告: 診断、修正、調整情報は、変更される場合がありますので、プログラミング・インターフェースとしては使用しないでください。
商標
IBM、IBM Logo、CICS(R)、DB2(R)、developerWorks(R)、IMS、Lotus(R)、Passport
Advantage(R)、Rational、Redbooks(TM)、Tivoli(R)、Universal Database DB2、WebSphere、および z/OS は、IBM Corporation の米国およびその他の国における商標です。
UNIX(R) は The Open Group の米国およびその他の国における登録商標です。
Java およびすべての Java 関連の商標およびロゴは Sun Microsystems, Inc. の米国およびその他の国における商標です。
Microsoft(R) および Windows(R) は、Microsoft Corporation の米国およびその他の国における商標です。
Linux(R) は、Linus Torvalds の米国およびその他の国における商標です。
Adobe は、Adobe Systems Incorporated の米国およびその他の国における登録商標または商標です。
他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。
ご利用条件
これらの資料は、以下の条件に同意していただける場合に限りご使用いただけます。
個人使用: これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、非商業的な個人による使用目的に限り複製することができます。ただし、IBM の明示的な承諾をえずに、これらの資料またはその一部について、二次的著作物を作成したり、配布 (頒布、送信を含む) または表示 (上映を含む) することはできません。
商業的使用: これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、お客様の企業内に限り、複製、配布、および表示することができます。ただし、IBM の明示的な承諾をえずにこれらの資料の二次的著作物を作成したり、お客様の企業外で資料またはその一部を複製、配布、または表示することはできません。
ここで明示的に許可されているもの以外に、資料や資料内に含まれる情報、データ、ソフトウェア、またはその他の知的所有権に対するいかなる許可、ライセンス、または権利を明示的にも黙示的にも付与するものではありません。
資料の使用が IBM の利益を損なうと判断された場合や、上記の条件が適切に守られていないと判断された場合、IBM はいつでも自らの判断により、ここで与えた許可を撤回できるものとさせていただきます。
お客様がこの情報をダウンロード、輸出、または再輸出する際には、米国のすべての輸出入関連法規を含む、すべての関連法規を遵守するものとします。
IBM は、これらの資料の内容についていかなる保証もしません。これらの資料は、特定物として現存するままの状態で提供され、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任なしで提供されます。
(C) Copyright IBM Corporation
2005, 2007. All Rights Reserved.