新しいメッセージが到着したときに、TIBCOEMSキューとそれらのキューのTIBCOBWリスナーを使用して、いくつかの.NETWCFサービスを呼び出す予定です。私たちの組織におけるENSの現在の設定は、queeuコンテンツのデータベースストレージではなくファイルストレージです。
そのようなインフラストラクチャが処理できるワークロードの経験と証拠を持っている人はいますか？ネットワークとサーバーが過負荷にならない限り、ほぼリアルタイムで発生すると想定していたときに、新しいメッセージがキューに入れられたときにBWが.NETエンドポイントを呼び出すのに数秒かかる可能性があるという懸念があります。何かご意見は？ありがとう。
トムが言うように、そしてあなたが思うように、これはほぼリアルタイム（確かに<1秒）であるはずですが、メッセージサイズ、オペレーティングシステム、インフラストラクチャ、ネットワークなどの関連する要因について解決する必要があります。
ただし、TIBCOにはEMS用のWCFバインディングがあり、これによりWCFエンドポイントをEMSキューに直接公開できることを指摘しておく価値があると思います。これにより、BWの「ブリッジ」クライアントを中央に配置する必要がなくなる可能性があり、そもそもこの会話の必要性が確実に軽減されます。
あなたが説明したことに基づいて（EMSとSOAPサービス間のプロトコルブリッジとしてBWを使用）、「数秒」かかることはありません。1秒未満である必要があります。もちろん、実際に知る唯一の方法は自分でテストすることですが、状況に非常に異常なことがない限り、高速である必要があります。