並列処理の設計

InterChange Server Express は並列処理環境を提供します。つまり、複数のコラボレーションを個別のスレッドで並行して実行できます。また、1 つのコラボレーション内の複数のスレッドを実行することもできます (マルチスレッド化と呼ばれます)。

重要:
コラボレーションのスレッド・プールは、イベント・トリガー・フローに対してのみ 使用され、呼び出しによって起動されるフローには使用されません。ただし、呼び出しによって起動されるフローも、IBM Java Object Request Broker (ORB) のスレッド・プールを使用するという点において、その実行はマルチスレッド化されます。

マルチスレッド化機能

各サーバーでは、ビジネス・オブジェクトのサブスクリプションを処理するために同時に発生させることのできるスレッドの最大数が決まっています。またユーザーは、それぞれの状況と、パフォーマンスの観点から最適と判断される条件に基づいて、発生させるスレッドの最大数を設定することができます。当然ながら、ユーザーが設定するスレッドの最大数がサーバーの許容最大数を超えることはできません。

作成可能なスレッドの最大数を設定するには、System Manager でスレッド数を指定します。

注:
宛先コネクターが並列処理用に構成されている場合は、要求が正常にアプリケーションに送信されたことを確認するようにコラボレーション・テンプレートをコーディングしてください。そのコードは、サービス呼び出しの例外遷移リンクの直後のノードに追加してください。詳細については、CollaborationException クラスgetSubType() を参照してください。
要確認:
宛先コネクターが単一スレッドの場合は、マルチスレッドに対応するコラボレーションを生かすために、宛先コネクターを並列処理できるように構成する必要があります。詳細については、「WebSphere InterChange Server システム・インプリメンテーション・ガイド」を参照してください。

並行処理の問題点

並行処理環境では、データの矛盾が生じる危険性が常にあります。データの矛盾は、並行処理が複数のプロセスまたは複数のスレッドのいずれによって行われる場合にも発生します。2 つのプログラムまたは 2 つのスレッドが同じデータに同時にアクセスすると、一方がデータを変更し、それによって他方のプログラムまたはスレッドの動作に予期しない悪影響が及ぶという可能性が常にあります。並行処理環境では、共有データへのアクセスを同期することによってこの問題に対応します。つまりスレッドまたはプロセスは、データの一部をロックして、別のスレッドまたはプロセスが同時にそのデータにアクセスできないようにします。

ビジネス・インテグレーション環境で発生する可能性のあるこの問題の単純な例として、以下の状況を考えます。

InterChange Server Express には、データの整合性を確保してこの問題に対処するための以下の機能が用意されています。

イベント順序付け

イベント順序付け では、同じコラボレーションの 2 つのスレッドが同じデータを同時に操作することがなくなります。複数のイベントが同じビジネス・オブジェクト・タイプとキー値を持つ場合、サーバーはこれらをキューに入れ、到着の順にデリバリーします。最初のイベントを受け取ったコラボレーション・スレッドは、コラボレーションが次のイベントを受け取る前に完了する必要があります。このためイベント順序付けでは、マルチスレッドによる実行が存在してさまざまなスレッドがさまざまな速度で実行される場合でも、実行順序が維持されます。

イベント順序付けを使用するために特別な方法でコラボレーションを設計する必要はありません。イベント順序付けは自動的に行われます。

イベント分離

イベント分離 では、2 つのコラボレーションが同じデータを並行して操作することがなくなります。場合によっては、複数のコラボレーションが同じタイプのビジネス・オブジェクトを処理することがあります。 1 つのイベントが到着して、特定のコラボレーションを起動します。このコラボレーションはその実行を開始し、実行中は、InterChange Server Express 内のそのビジネス・オブジェクトのインスタンスに排他的にアクセスします。このとき同じデータに関連する別のイベントが到着すると、新たに到着したイベントは、実行中のコラボレーションが最初のイベントの処理を完了するまで InterChange Server Express によってキューに格納されます。この機能には以下に説明するような、いくつかの制約があります。

InterChange Server Express は、イベント分離を自動的に実行しません。コラボレーション開発者は、イベント分離を利用するための特定の方法によってテンプレートを設計する必要があります。このセクションでは、規則について説明し、この目標を達成するために設計時に決定するいくつかの事例を示します。

注:
このセクションの指針は、複数のコラボレーションが使用される環境で動作し、データを変更する操作を実行するコラボレーションにのみあてはまります。開発しているコラボレーションが検索操作のみを実行し、サーバー上でそのビジネス・オブジェクト・タイプを使用する唯一のコラボレーションの場合には、このセクションの指針は無視してかまいません。

イベント分離が適用される場合

イベント分離が適用されるかどうかは、到着するイベントとアクティブなコラボレーションのポートを InterChange Server Express が分析して実行時に決定されます。イベント分析の基準は、イベント順序付けの場合と同じで、ビジネス・オブジェクト・タイプとキー値が同じ場合にはイベントは同じであるとみなされます。

アクティブなコラボレーションの分析では、コネクターにバインドされている各コラボレーションの一連のポートが考慮されます。ポート・マッチング において、InterChange Server Express は以下のことを確認します。

例えば、2 つのコラボレーションの両方が以下のようにポートにバインドされている場合、これらのコラボレーションはマッチング・ポートを持ちます。

コネクター 1/ビジネス・オブジェクト・タイプ A

コネクター 2/ビジネス・オブジェクト・タイプ B

入力されるイベントと出力される要求/応答のいずれかにポートが使用されるかは問題ではありません。コネクター・バインディングとビジネス・オブジェクトのタイプのみが重要です。

イベント分離が適用されるコラボレーションを決定するときに、他のコラボレーションにバインドされているポートは考慮されません。

ポート・マッチング例: マッチングするポート

図 16 に、イベント分離が適用される 2 つのコラボレーション X と Y を示します。コラボレーションの端の小さな長方形はポートを示します。

図 16. マッチングするポート


図 16 で、X には 2 つ、Y には 3 つのポートがあります。しかし、ポート・マッチングでは、コネクターにバインドされている Y の 2 つのポートのみが考慮されます。コラボレーション Z にバインドされているポートは無視されます。いずれのコラボレーションも、コネクターにバインドされている以下のポートがあります。

この例は、イベント分離の基準を満たすため、サーバーは入力イベントまたはトリガー・イベントを分離します。このため、イベント A のインスタンスはこれら 2 つのコラボレーションにおける分離の対象になります。

ポート・マッチング例: マッチングしないポート

コラボレーションが比較されるとき、サーバーでは、すべてのポートが考慮されます。ポート・マッチングの分析対象となるポートは、トリガー・イベントを受け取るポートに限定されません。2 つのコラボレーションが同じコネクターから同じタイプのイベントを受け取るが、2 つの異なるコネクターに出力ビジネス・オブジェクトを送信する場合、これらのコラボレーションのイベントは分離されません。

図 17 に、出力ポートが異なるコネクターにバインドされている 2 つのコラボレーションを示します。これらのイベントのインスタンスは分離されません。

図 17. マッチングしないポート


設計規則

イベント・インスタンスの分離機能を利用する場合には、コラボレーションを特定の方法で設計する必要があります。このセクションでは、以下の方法について説明します。

代行の使用

ビジネス・オブジェクトを変更する各コラボレーション・テンプレートは、そのタイプのビジネス・オブジェクトのみを変更するように設計する必要があります。コラボレーションが、子ビジネス・オブジェクトなど別のタイプのビジネス・オブジェクトを変更する必要がある場合は、その別のタイプのビジネス・オブジェクトの変更のみを目的とする個別のコラボレーションを作成する必要があります。つまり、最初のコラボレーションは、他のビジネス・オブジェクトを変更するために、第 2 のコラボレーションに代行させる (渡す) ことになります。

1 つのコラボレーションが 1 種類のビジネス・オブジェクトのみを変更するようにする規則は、データの整合性を維持するうえで役立ちます。これにより、複数のコラボレーションが同じタイプのビジネス・オブジェクトの同じインスタンスを並行して変更することが防止されます。代行により、子ビジネス・オブジェクトのデータの整合性が、別のコラボレーションによって処理される同じビジネス・オブジェクトのインスタンスに関して維持されます。ビジネス・オブジェクトは 1 つのコンテキストでは子として使用し、別のコンテキストでは自身として使用することができます。

ビジネス・オブジェクト A と、これに子ビジネス・オブジェクトとして関連付けられている一連の情報 B とを扱うビジネス・プロセスを書く必要があるとします。この場合のビジネス・オブジェクトの構造は、図 18 に示すようになり、B ビジネス・オブジェクトは A ビジネス・オブジェクトの子オブジェクトです。

図 18. 階層ビジネス・オブジェクトの例


B ビジネス・オブジェクトを処理するコラボレーションがすでに存在する場合、B 子ビジネス・オブジェクトに対する操作をそのコラボレーションに代行させる必要があります。または、別のコラボレーションを作成する必要が生じることがあります。

A ビジネス・オブジェクトに関連付けられているデータを操作するときには、A ビジネス・オブジェクトとその一連の B データ (つまり子ビジネス・オブジェクト) の両方を操作する必要があります。このため、2 種類のコラボレーション・テンプレート (一方のコラボレーションはビジネス・オブジェクト A を変更し、他方は子ビジネス・オブジェクト B を変更する) を作成することになります。また場合によっては、これらの 2 つのテンプレートをコラボレーション・グループに結合することになります。各コラボレーション・テンプレートは、それぞれ 1 つのビジネス・オブジェクトに対する操作を処理します。

図 19 に、A プロセッサー・コラボレーションと B プロセッサー・コラボレーションが含まれるコラボレーション・グループ A/B を示します。A プロセッサー・コラボレーションは、A ビジネス・オブジェクトを処理します。A プロセッサー・コラボレーションが B 子ビジネス・オブジェクトを変更する必要があるとき、A プロセッサー・コラボレーションはサービス呼び出しを使用して B ビジネス・オブジェクトを B プロセッサー・コラボレーションに送信します。図 19 で、点線は代行を表します。

図 19. 子ビジネス・オブジェクトの代行


参照値を持つビジネス・オブジェクトとして子ビジネス・オブジェクトを処理する

代行された子ビジネス・オブジェクト (図 19 の B プロセッサー・コラボレーションの場合など) をコラボレーションが受け取ると、そのコラボレーションはそのビジネス・オブジェクトを、参照値を持つビジネス・オブジェクトとして処理する必要があります。参照値を持つビジネス・オブジェクト には、ビジネス・オブジェクトの基本キーとして定義されている属性の値のみが含まれます。

これに対して、完全な値を持つビジネス・オブジェクト にはその他の属性値が含まれます。

この章の中の図では、参照値を持つビジネス・オブジェクトは (r) の印が付き、完全な値を持つビジネス・オブジェクトは (f) の印が付いています。図 20 は、参照値子ビジネス・オブジェクトを持つビジネス・オブジェクトの例です。

図 20. 参照値子ビジネス・オブジェクトを持つ階層ビジネス・オブジェクト


発信元コネクターに応じて、イベントは参照値子ビジネス・オブジェクトまたは完全な値を持つ子ビジネス・オブジェクトによって送信できます。このため、代行された子ビジネス・オブジェクトを受け取るコラボレーションは、その属性値すべてを受け取るか、または基本キー値のみを受け取ります。しかし、コラボレーションは、受信する代行された子ビジネス・オブジェクトを常に参照値を持つビジネス・オブジェクトとして処理する必要があります。基本キー値が正しい場合のみを想定し、基本キー以外の属性値は無視する必要があります。

コラボレーションが子ビジネス・オブジェクトのキー以外の属性に対する操作を実行する必要がある場合、ソース・アプリケーションからビジネス・オブジェクトの完全な値を持つバージョンを検索することによって参照を解決する必要があります。子ビジネス・オブジェクトが参照値を持つビジネス・オブジェクトの場合、検索操作により追加の属性値が取得されます。子ビジネス・オブジェクトが完全な値を持つビジネス・オブジェクトの場合、現在有効な関連データが検索されます。

図 19 に、参照値を持つビジネス・オブジェクトとしての B の代行と、ソース・コラボレーションからの検索による参照の解決を示します。

図 21. 参照の解決


Copyright IBM Corp. 2004