0

私は現在、単一のプロセス空間にあるシステムに取り組んでいます。これをいくつかのプロセスに分割し、最初は同じボックスで実行しますが、最終的には複数の別々のマシンに分散します。私は、ESB (NServiceBus、Rhino ESB) を使用するか、WCF + キューを使用して自分自身をロールバックして、アプリのパブ/サブおよび要求/応答シナリオを処理することに傾いています。

ただし、抽象化に苦労しています。さまざまなコンポーネントがバスを介して話していることを認識したくありません。さまざまなサービスを接続する現在の API は、この種のモデルにうまく変換されますが、クライアント側とサーバー側からそれを隠したいと考えています。クライアントとサーバー用の多くのカスタム プロキシ コードを記述する以外に、これにアプローチするより良い方法はありますか? WCF がサービス定義に基づいてプロキシを自動生成できることは理解していますが、(たとえば) rhino サービスバスで得られる他の機能のいくつかが本当に気に入っています。

理想的には、IoC を使用するだけで (ESB/メッセージング層の有無にかかわらず) さまざまな実装を交換できるようにしたいと考えています (インターフェイスを介して渡すことができるものについて、慣習によって制限が課される必要があることを知っています)。どこに行けばいいのかわからない。現在のインターフェイスのすべてのメソッド呼び出しを独自の個別のメッセージ クラスに変更する必要もありません。

これを行うのに役立つリソース/パターン/ツールはありますか? わからないことがあれば質問してください。ありがとう。

4

1 に答える 1

1

役立つ可能性のあるソリューション/既製のコンポーネントが 1 つもない場合があります。

問題 1: ESB は場所の透過性とサービス集約
を提供するため、基本的な問題は ESB によって解決できます。通常の ESBは、サービス コンシューマーとサービス プロバイダーの間でリクエストを仲介/仲介します。 簡単な例を見てみましょう:

Service_A は Service_B に依存します  
Service_C は Service_B に依存します  
Service_B は Service_D に依存します

このシナリオでは、進行するための最良の方法は次のとおりです。

  1. services 、 、およびService_BでService_D外部依存関係(おそらく Web サービスとして、ESB は複数のプロトコルをサポートします)によって公開されるコントラクトを定義し、ESB を介して消費します。 Service_AService_CService_B
  2. Service_BESB では、まず、これらのサービスをService_D同じインスタンスに ルーティングします。
  3. Service_D別の場所に移行Service_Bする場合はService_Dx、Service_Bx新しい場所にルーティングするように ESB を再構成できます。また、ESB は、一連のパラメーターにルーティングするService_Bか、それService_Bxに基づいて構成することもできます (たとえば、テスト データを にService_B、本番データを にService_Bx) 。

問題 2:
IOC の問題を達成するのはおそらく難しいでしょう。必要がないかもしれません。
クライアントには、既知の場所から消費するのではなく、サービスの場所の所在が注入されていると思います。これにより、実際には構成がクライアント側に転送されます。これにより、システムに追加された新しいクライアントごとに、個別の構成制御が必要になります。これにより、物流上の問題が発生する可能性があります。

あなたのアプローチを知ることに非常に興味がある、あなたの最終的な解決策を投稿してください。

于 2011-04-25T20:52:04.110 に答える