サービス間でデータを共有

Question

デュプレックスサービスを分割する必要があり、大きな転送を1つのサービスにカプセル化し、他のサービスから取得したいと考えています。私は以前は1つのサービスですべてを持っていましたが、今はサイズ/メモリの調整のためにバッファリングからストリーミングに切り替える必要があります。 私はいくつかの質問hereとhereを見ましたが、かなり古くなっています

私はサービス間のIPCのために何を使用しますか？

サービスAは今、私はサービスBに固執したい、

を、2つの方法Guid Upload(stream)を公開Stream Download(Guid)とnet.tcpストリーミングを使用して、これがうまく機能していますか？これはnamedPipe WCFですか？

サービスC - >ビジネス層 - >サービスBGuidと、項目の計算を取得して行う、バックB

に固執私の質問は、永続性/ サービスBのために使用するものです

クライアントの観点から

1. クライアントがServiceA_Proxy.Upload(someLargeItem)リターンを呼び出しますGuid
2. クライアントは、ServiceC_Proxy.DoSomeWork(GuidFromCall_1)
3. クライアントはその後、エンドユーザーへServiceA_Proxy.Download(GuidFromCall_1)
4. クライアントのディスプレイを呼び出す呼び出す

Answer 1

はい、あなたは上で実行されているcomunicatingプロセス限りバインディングWCFとして名前付きパイプを使用することができます同じサーバー。基本的には、TCP/IPのようなバインディングを使用しているかのようにWCFサービスを作成しますが、netNamedPipeBindingを使用するようにエンドポイントを設定する必要があります。

データを永続化/保存する場合は、要件に応じてファイルまたはデータベースに保存することができます。 ServiceCが呼び出すまでデータを保持したければ、Dictionary<Guid, SomeLargeItem>で十分です。

のようにだからあなたの流れが見えるでしょう：クライアントはServiceA_Proxy.Upload（someLargeItemが）のGuid

サービスAがServiceB_Proxy.Upload（GuidFromCall_1、someLargeItem）

クライアントは、その後（ServiceC_Proxy.DoSomeWorkを呼び出して呼び出し、返す呼び出す

1. GuidFromCall_1）（最初にアップロードが完了していることを確認する必要があります）
2. ServiceC呼び出しServiceB_Proxy.Download（GuidFromCall_1）
3. サービスコールDoSomeWorkサービスコールのServiceB_Proxy.Upload（GuidFromCall_1、someLargeItemProcessed）
4. クライアントはServiceA_Proxyを呼び出します。ダウンロード（GuidFromCall_1）（処理が終了したことを再度確認する必要があります）
5. ServiceAはServiceB_Proxy.Download（GuidFromCall_1）を呼び出し、クライアントに戻ります。
6. クライアントは

は私が混乱何かをしませんでしたかわからないENDUSERし表示します。ご覧のとおり、これはかなり複雑になっています。 これはこれが行く方法であることを自分自身に尋ねる必要があります。このようにサービスを分割すると、実際にはスケーラビリティが向上しますか？すべての処理が同じマシン上に残るように、NamedPipesを使用する予定です。

本当にデザインを考慮する必要があります。たぶんfuncionalityをいくつかの* .dllに分割し、直接呼び出すだけで十分でしょうか？このようにして、レイヤーの論理的分離を実現します。 バッファ型通信からストリーミング通信に切り替えても、ロジックをより多くのサービスに分割する必要はありません。

そして、あなたは真スケーラビリティをしたい場合は、キュー（例えばMSMQ）および各サービスの別々のマシンを使用することを検討してください。