WebSphere InterChange Server マイグレーション・プロセスのベスト・プラクティス

以下のガイドラインは、WebSphere® InterChange Server 向けのインテグレーション成果物の開発に役立つことを目的としています。 これらのガイドラインに従うことで、WebSphere InterChange Server 成果物の WebSphere Process Server に容易にマイグレーションできます。

これらの推奨事項は、 新しいインテグレーション・ソリューションの開発のためのガイドとしてのみ使用されることを意図したものです。 既存の内容は、これらのガイドラインに従っていない場合もあります。 また、これらのガイドラインから逸脱しなければならない場合があることも理解してください。 これらの場合には、成果物のマイグレーションに必要な再作業の量を最小化するために、 逸脱の範囲を制限するように注意を払う必要があります。 ここで概説されるガイドラインは、WebSphere InterChange Server 成果物一般の開発向けのベスト・プラクティスを網羅しているわけではないという点に注意してください。 それよりむしろ、将来、成果物をマイグレーションする場合の容易さに影響する考慮事項に範囲を限定しています。

一般的開発

ほとんどのインテグレーション成果物に広く適用される考慮事項がいくつかあります。 一般に、ツールによって提供される機能を活用し、 ツールによって強制されるメタデータ・モデルに準拠する成果物は、 最も円滑にマイグレーションされます。 また、大幅な拡張と外部依存を持つ成果物は、マイグレーション時に、 より多くの手動介入を必要とする傾向にあります。
以下のリストでは、将来のマイグレーションを容易にするために役立つ、WebSphere InterChange Server ベースのソリューションの一般的開発についてのベスト・プラクティスを要約します。
  • リアルタイムの自動化されたプロセスのインテグレーション・ソリューションに対して、WebSphere InterChange Server を使用する
  • システムおよびコンポーネントの設計を文書化する
  • 開発ツールを使用してインテグレーション成果物を編集する
  • ツールおよび Java™ 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 コンテナー機能を使用するように手動で変換する必要があります。

成果物用の製品ドキュメンテーションで公開されている API のみを使用してください。 これらは、WebSphere InterChange Server の開発ガイドに概要が詳しく説明されています。 多くの場合、互換性 API が WebSphere Process Server で提供されますが、 公開済みの API のみが組み込まれます。 WebSphere InterChange Server には、開発者が使用したくなる内部インターフェースがたくさん含まれていますが、 将来に向かってサポートされるという保証はありません。

マップおよびコラボレーション・テンプレートでビジネス・ロジックおよび変換ルールを設計する場合は、 可能な範囲で Activity Editor ツールを使用してください。 これにより、ロジックは、 より容易に新しい成果物に変換可能なメタデータを使用して記述されるようになります。 ツールで再利用したい操作の場合は、Activity Editor の「My Collections」フィーチャーを可能な限り使用してください。 WebSphere InterChange Server のクラスパスでは、Java アーカイブ (*.jar) ファイルとして組み込まれる、 フィールド開発の共通コード・ユーティリティー・ライブラリーは避けるようにしてください。 これらは、手動でマイグレーションする必要があります。

開発する必要がある Java コード Snippet では、 コードは、可能な限り単純かつ最小単位になるようにすることが推奨されます。 Java コードにおける複雑さのレベルは、スクリプト記述 (基本的な評価、演算、および計算を含む) の順序、 データのフォーマット設定、型変換などによって決まるはずです。 1より包括的または複雑なアプリケーション・ロジックが必要な場合は、 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 リソースとして提供され、基本機能は同じです。 しかし、接続およびトランザクションの管理方法は異なる場合があります。

将来の移植性を最大化するために、コラボレーション・テンプレートまたはマップ内の複数の Java Snippet ノードに渡ってデータベース・トランザクションをアクティブに保持することは避けてください。 例えば、接続の取得、トランザクションの開始と終了、 および接続の解放に関連するコードは、1 つのコード Snippet に入れてください。

ビジネス・オブジェクト

ビジネス・オブジェクトの開発での主要な考慮事項は、 成果物を構成するために提供されているツールのみを使用すること、 データ属性に対して明示的なデータ型と長さを使用すること、 および文書化された API のみを使用することです。

WebSphere Process Server 内のビジネス・オブジェクトは、 強く型付けされたデータ属性を使用する Service Data Object (SDO) を基にしています。 WebSphereInterChange 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 ビジネス・プロセス・コンポーネントとして提供される場合に、 割り込み可能フローとして選択的にデプロイされることがあるコラボレーション内で必要となります。 この場合、プロセスはいくつかの別々のトランザクションで構成され、 状態およびグローバル変数の情報のみがアクティビティー間で受け渡されます。 これらの複数のプロセス・トランザクションに渡るシステム接続または関連トランザクションのコンテキストは失われます。

コラボレーション・テンプレートのプロパティー名には、 特殊文字を使用しないでください。 これらの特殊文字は、マイグレーション先の BPEL プロパティー名では無効です。 マイグレーションで生成される BPEL での構文エラーを避けるため、 マイグレーション前に、プロパティーを名前変更してこれらの特殊文字を除去してください。

「this.」を使用して変数を参照しないでください。 例えば、「this.inputBusObj」ではなく、「inputBusObj」を使用してください。

変数には、シナリオのスコープを持つ変数の代わりに、 クラス・レベルのスコープを使用してください。 シナリオのスコープは、マイグレーション時に転送されません。

Java Snippet に宣言されたすべての変数を、 デフォルト値で初期化してください。 例えば、"Object myObject = null;" のようにします。 マイグレーション前に、宣言で、必ずすべての変数を初期化してください。

コラボレーション・テンプレートのユーザー変更可能セクションに、 Java import 文がないことを確認してください。 コラボレーション・テンプレートの定義で、インポート・フィールドを使用して、 インポートする Java パッケージを指定してください。

マップ

コラボレーション・テンプレートに関して説明したガイドラインの多くは、 マップにも適用されます。

マップがメタデータを使用して適切に記述されるようにするために、 マップの作成および変更には、 常に 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 Snippet 内では、Java 修飾子 final、transient、および native の使用は避けてください。

ビジネス・オブジェクト内で配列を使用する場合は、 「マップ」内で配列に索引付けする際に、配列の順序に依存することはできません。 WebSphere Process Server 内にマイグレーションされる構成では、 特にエントリーが削除される場合、索引順序を保証しません。

将来の移植性を最大化するために、 「ユーザー定義のデータベース接続プール」での明示的な接続解放呼び出し、 および明示的なトランザクション・ブラケット操作 (すなわち、明示コミットおよび明示ロールバック) の使用は避けてください。 その代わりに、コンテナーが管理する暗黙接続クリーンアップ、 および暗黙トランザクション・ブラケット操作を使用してください。 また、複数の変換ノード境界に渡って、Java Snippet 内でシステム接続およびトランザクションをアクティブに保つことは避けてください。 これは、外部システムへのすべての接続のほか、 ユーザー定義のデータベース接続プールにもあてはまります。 先に述べたように、外部 EIS 内の操作はアダプター内で管理する必要があり、 データベース操作に関連するコードは 1 つのコード Snippet 内に含まれている必要があります。

関係

関係については、 関係定義は WebSphere Process Server で使用するためにマイグレーションが可能であると同時に、 関係テーブル・スキーマおよびインスタンス・データは、 WebSphere Process Server による再使用、および WebSphere InterChange Server と WebSphere Process Server 間での並行した共用も可能であることに注目してください。

関係についての主な考慮事項は、 関連するコンポーネントを構成するために提供されているツールのみを使用すること、 およびインテグレーション成果物内での関係に、 公開されている API のみを使用するということです。

関係定義の編集には、Relationship Designer ツールのみを使用することが重要です。 さらに、関係定義のデプロイメント時に自動的に生成される関係スキーマの構成は、 WebSphere InterChange Server にのみ許可してください。 データベース・ツールまたは SQL スクリプトを使用して関係テーブル・スキーマを直接に変更することは、 しないでください。

また、関係テーブル・スキーマ内の関係インスタンス・データを手動で変更する必要がある場合は、 必ず、Relationship Designer によって提供されている機能を使用してください。

先に述べたように、インテグレーション成果物内の関係に対しては、 公開されている API のみを使用することが重要です。

フレームワーク・クライアントへのアクセス

CORBA IDL インターフェース API を採用して新規クライアントを開発することは、 しないでください。 これは、WebSphere Process Server ではサポートされていません。
関連タスク
WebSphere InterChange Server マイグレーションの検査
WebSphere InterChange Server からのマイグレーション失敗時の作業

Feedback
(C) Copyright IBM Corporation 2005, 2006. All Rights Reserved.
(C) Copyright IBM Japan 2006