Coordinated Request Reply サンプルの拡張

元の要求メッセージの ReplyToQ および ReplyToQmgr 値を後で取り出せるよう、これらの値を WebSphere MQ メッセージに保管する 際には、ReplyToQ および ReplyToQMgr の詳細情報のみが保管されるのではなく、要求メッセージの MQMD 全体が保管されます。 その理由は、要求メッセージの ReplyToQ、ReplyToQmgr、および CorrelID の 3 つの値を保管して取り出す必要があるにも かかわらず、MQGet ノードが保管して取り出せるのは 1 つの値のみだからです。 この MQGet ノードの動作から考えて、個々の値を保管する代わりに、必要な値の入った構造を保管しなければなりません。 異なる値を保管するようにサンプルに変更を加える際には、この MQGet ノードの動作を考慮する必要があります。

Coordinated Request Reply サンプルは、このサンプルで提供されているサブフローのインプリメンテーションの代わりに、Request および Reply フローで使用される異なるサブフローのインプリメンテーションを使用できるように設計されています。たとえば、1 つの異なる インプリメンテーションでは、最初の要求メッセージの ReplyToQ と ReplyToQmgr を保管するためにデータベースを使用するようになっているかもしれません。ただし、これはパフォーマンス向上の手段としては推奨できません。代わりに、 要求メッセージの ReplyToQ、ReplyToQmgr、および CorrelID を WebSphere MQ メッセージに保管して取り出すためのサブフローを、他のメッセージ・フローで使用できます。

サブフロー StoreOriginalMQMD_Sub の再利用

サブフロー StoreOriginalMQMD_Sub を他のメッセージ・フローで使用して、要求メッセージの MQMD を WebSphere MQ メッセージに保管するという同じ機能を実行するのは簡単です。そのためには、メッセージ・フローの中でこのサブフローを使用する適切なポイントに、これを組み込みます。サブフローに変更を加えずに組み込むこともできますが、その結果として問題が生じる可能性があります。

変更が必要かもしれないキー・パラメーターは上に示したとおりですが、サブフロー内のノードのパラメーター設定を全部検討し、ご自分の要件と互換性のある設定になっているかどうかを確認するようお勧めします。

サブフロー StoreOriginalMQMD_Sub の代替インプリメンテーションの使用

代わりのデータ保管機能を使用するようにサブフローに変更を加える方法は複数あります。例えば、代わりの機能の 1 つとして、データベースを使用することがあります。その場合、サブフローは WebSphere MQ メッセージに書き込みを行う代わりに、データベースにデータを挿入しなければならないことになります。

保管の機能に変更を加えると、サブフローのパフォーマンス特性が変わることに注意する必要があります。選択したインプリメンテーションの特性がメッセージ・フローのパフォーマンス要件にかなったものかどうかを確認することは重要です。データベースを使用して情報を保持すると、データベースに挿入するたびにデータベース・マネージャー・ログへの書き込みが必要になるので、メッセージ・フローの処理が入出力制約を受ける可能性は高くなります。

代わりの保管機能を使用すると、サブフローのトランザクションのプロパティーにも変化が生じるかもしれません。WebSphere MQ メッセージを使ってデータを保管する場合、この WebSphere MQ メッセージのために使用されるリソース・マネージャーは、メッセージ・フローの別の箇所で読み取られる WebSphere MQ メッセージのために使用されるリソース・マネージャーと同一です。メッセージ・フローに WebSphere MQ メッセージの処理しかないなら、関係するのは 1 つのリソース・マネージャーだけです。データベースまたは他のリカバリー可能リソース・マネージャーを使用する場合、データ保全性を確実なものとするため、Message Broker キュー・マネージャーと、データ保管先のデータベースのデータベース・マネージャーとの間で、2 フェーズ・コミット・リカバリー・プロトコルを使用することが必要になるでしょう。

変更を加える際には、サブフロー内のノードのパラメーター設定をすべて検討し、ご自分の要件と互換性のある設定になっているかどうかを確認するようお勧めします。

サブフロー RestoreOriginalMQMD_Sub の再利用

サブフロー RestoreOriginalMQMD_Sub を他のメッセージ・フローで使用して、WebSphere MQ メッセージから初期要求メッセージの MQMD を取り出すという同じ機能を実行するのは簡単です。そのためには、メッセージ・フローの中でこのサブフローを使用する適切なポイントに、これを組み込みます。 サブフローに変更を加えずに組み込むこともできますが、その結果として問題が生じる可能性があります。

変更が必要かもしれないキー・パラメーターは上に示したとおりですが、サブフロー内のノードのパラメーター設定を全部検討し、ご自分の要件と互換性のある設定になっているかどうかを確認するようお勧めします。

サブフロー RestoreOriginalMQMD_Sub の代替インプリメンテーションの使用

代わりのデータ保管機能を使用するようにサブフローに変更を加える方法は複数あります。例えば、代わりの機能の 1 つとして、データベースを使用することがあります。サブフローは、MQGet ノードを使用して WebSphere MQ メッセージを読み取る代わりに、データベースからデータを読み取ることができるかもしれません。

保管の機能に変更を加えると、サブフローのパフォーマンス特性が変わることに注意する必要があります。 選択したインプリメンテーションの特性がメッセージ・フローのパフォーマンス要件にかなったものかどうかを確認することは 重要です。 データベースを使用して情報を保持すると、インプリメンテーションに応じてさまざまなオーバーヘッドが加わる可能性があります。 データベース・インプリメンテーションの場合、読み取りを使ってデータを取り出し、更新や削除は行わないようにすれば、 オーバーヘッドは最小限になります。 しかし、データベースからデータを削除しないと、データベースのサイズは大きくなり続け、ハウスキーピングを実行しないと 使用時に次第に低速になります。 データが取り出されたことを示すために行を更新することや、行を削除することが取り出しプロセスに含まれている場合、 データベース・マネージャー・ログへの書き込みが関係することになり、結果として読み取り専用の場合よりはるかに大きな 処理オーバーヘッドが生じます。

代わりの保管機能を使用すると、サブフローのトランザクションのプロパティーにも変化が生じるかもしれません。WebSphere MQ メッセージを使ってデータを保管する場合、この WebSphere MQ メッセージのために使用されるリソース・マネージャーは、メッセージ・フローの別の箇所で読み取られる WebSphere MQ メッセージのために使用されるリソース・マネージャーと同一です。メッセージ・フローに WebSphere MQ メッセージの処理しかないなら、関係するのは 1 つのリソース・マネージャーだけです。データベースまたは他のリカバリー可能リソース・マネージャーを使用する場合、データ保全性を確実なものとするため、Message Broker キュー・マネージャーと、データ保管先のデータベースのデータベース・マネージャーとの間で、2 フェーズ・コミット・リカバリー・プロトコルを使用することが必要になるでしょう。

変更を加える際には、サブフロー内のノードのパラメーター設定をすべて検討し、ご自分の要件と互換性のある設定になっているかどうかを確認するようお勧めします。

メインページのアイコン   サンプルのホームに戻る