0

次の構成要素があるアーキテクチャがあります。

  1. 外部アプリケーション (EA) - WCF サービスに要求を行うサード パーティ
  2. WCF サービス (WS) - すべてのビジネス ロジック
  3. Pub-Sub Service (PSS) - パブリッシュとサブスクリプションを処理します
  4. 内部アプリケーション (IA) - Pub-Sub へのサブスクライブまたはサブスクライブ解除 (CallBacks を使用)

概要

外部アプリケーション (EA) は WCF サービス (WS) を参照し、特定のメソッドを呼び出します。すべての内部アプリケーション (IA) は、Pub-Sub サービス (PSS) を通じて通知を受ける必要があります。

私が抱えている問題は、ある WCF サービス (WS) を別の WCF サービス (Pub-Sub サービス) と通信させることが実現可能か、またはベスト プラクティスであるかを判断することです。リクエストが同期的に処理され、サービスの提供に矛盾が生じる可能性があることを考えると、これは良い考えではないことを読みました。

それに基づく私の具体的な質問は、2つのWCFサービスが互いに通信できるようにすることの長所と短所を誰かが共有できるかということです。またはこれは問題ではありませんか？

ありがとう

4

2 に答える 2

1

他の回答には同意しますが、メッセージ指向のアプローチは利用可能なリソースでは実行できないため、このように言います。

WCF サービスがクライアント (「WS」) およびサーバー (「PSS」) として機能している限り、クライアント/サーバー アプリケーションの落とし穴を共有します。ただし、これはいくつかのことを前提としています。

a) あなたの 'WS' は、あなたの 'EA' に対して一方向操作、つまり「ファイア アンド フォーゲット」を実装します。こちらを参照してください: One-Way Calls, Callbacks, And Events について知っておくべきこと. そうしないと、「EA」は「PSS」への内部呼び出しが完了するまで待機する必要があります。

b) 一方向操作は実際には非同期ではないため、'WS' チャネルが構成され、負荷を処理するのに十分なリソースがあります。チャネルが負荷を処理できない場合、呼び出しはキューに入れられ、リソースが解放されて実行が続行できるようになるまでクライアントをブロックします。

c) 保証された、トランザクションまたは順序付けられた配信、またはその他のメッセージングのような動作に関する制約は必要ありません。

しかし、この種のシナリオでは、メッセージ ベースのアーキテクチャが実際に必要であると前に述べました。いくつかの障害点があり、この一連の依存関係のトラブルシューティングは楽しくありません。

于 2013-07-09T13:48:20.560 に答える