Request-Response メッセージング
要求/応答メッセージ方式では、送信側が要求メッセージを送信し、受信側が応答メッセージを返します。 要求/応答処理の一般的な使用例としては、HTTP アダプターを使用した Web サーバーとブラウザー間の対話処理、および、Simple Object Access Protocol (SOAP) アダプターを使用した Web サービス処理の 2 つがあります。 BizTalk Serverでは、要求メッセージと応答メッセージの両方が一般的なパブリッシュ/サブスクライブ方法で処理されます。 このことは、BizTalk アプリケーションのパフォーマンス調整を行うときの重要な注意事項です。高いスループットを必要とするシステムは、個々のメッセージの待ち時間を短くする必要のあるシステムとは異なる構成が行われる可能性があるためです。
要求/応答形式の受信アダプターでメッセージを受信する場合、BizTalk Server は、最初に要求メッセージをメッセージ ボックス データベースに公開します。 次に、適切なサブスクライバー (受信ポートにバインドされているオーケストレーションの可能性が高い) がこのメッセージを受信します。 このサブスクライバーは、応答メッセージを作成し、要求元の受信ポートに応答メッセージを返信するプロパティと一緒にメッセージ ボックス データベースに応答メッセージを公開します。 最後に、要求元のパブリッシャー (要求を送信した受信アダプター) が応答メッセージを受け取ってから、呼び出し元のアプリケーションに応答メッセージが返されます。 次の図は、これらの手順の詳細を示しています。
SOAP アダプター
SOAP アダプターが受け取る要求/応答メッセージの流れ
SOAP アダプターは、メッセージをエンドポイント マネージャーに送信します。
エンドポイント マネージャーは、メッセージをメッセージ ボックス データベースに公開します。
受信ポートにバインドされている (メッセージにサブスクリプションを含む) オーケストレーションは、メッセージを受信して処理します。
オーケストレーションは、メッセージ ボックス データベースに公開されている応答メッセージを送信します。
エンドポイント マネージャーは、応答メッセージを受け取ります。
エンドポイント マネージャーは、応答を SOAP アダプターに返します。
内部の実装を理解していない場合、パフォーマンスに対するこのような動作の影響は見過ごされがちです。 BizTalk Server は、当初は、高スループット シナリオ用にチューニングされていますが、低いスループットや少ない待機時間 (特に要求/応答シナリオ) に合わせた環境の構成も行うことができます。 このシナリオに合わせて、いくつかのコンポーネントを考慮する必要があります。 最初に、サブスクライバーは、ポーリング機構を通じて公開されたメッセージを取得します。 ポーリング間隔が大きすぎると、要求/応答形式の対話処理の待機時間が長くなる可能性があります。
このシナリオでは 2 つのサブスクリプション (最初のメッセージのサブスクリプションと応答メッセージのサブスクリプション) を使用していることに注意してください。これにより、このポーリング間隔の影響が大きくなります。 次に、受信アダプターを構成して、さまざまなサイズのバッチ単位で、メッセージ ボックス データベースにメッセージを挿入します。 ほとんどのアダプターでは、通常のアダプター構成インターフェイス、BizTalk Server のパラメーター、またはレジストリを使用して、バッチ サイズを構成できます。 バッチ サイズが大きすぎると、個々のメッセージの待機時間が長くなる可能性があります。 BizTalk Serverのパフォーマンス特性の詳細については、「継続的なパフォーマンスの計画」を参照してください。