Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Yes you can use Named Pipes as a <strong>WCF Binding</strong> <em>as long as comunicating processes are run on the same server</em>. Basically you create WCF service just as if you were using any other binding like TCP/IP, but you'll need to configure your <strong>endpoint</strong> to use <code>netNamedPipeBinding</code>.</p> <p>If you want to persist/save the data then you can save it to files or even database, depending on your requirements. If you just wanted to keep the data until ServiceC calls for it, then <code>Dictionary&lt;Guid, SomeLargeItem&gt;</code> would be enough.</p> <p>So your flow would look like:</p> <ol> <li>Client calls ServiceA_Proxy.Upload(someLargeItem) returns Guid</li> <li>ServiceA calls ServiceB_Proxy.Upload(GuidFromCall_1, someLargeItem)</li> <li>Client then calls ServiceC_Proxy.DoSomeWork(GuidFromCall_1) (you need first to make sure that upload is finished)</li> <li>ServiceC calls ServiceB_Proxy.Download(GuidFromCall_1)</li> <li>ServiceC calls DoSomeWork(GuidFromCall_1) (Internally)</li> <li>ServiceC calls ServiceB_Proxy.Upload(GuidFromCall_1, someLargeItemProcessed)</li> <li>Client then calls ServiceA_Proxy.Download(GuidFromCall_1) (again, you need to make sure that processing is finished)</li> <li>ServiceA calls ServiceB_Proxy.Download(GuidFromCall_1), and returns to Client.</li> <li>Client displays to enduser</li> </ol> <p>I'm not sure I didn't mess something up. As you can see, this is getting pretty complex. You need to ask yourself it this is the way to go and if splitting your service this way will really make it more scalable? You plan to use NamedPipes so all the processing would still be on the same machine.</p> <p>You should really consider your design. Maybe splitting the funcionality into some *.dlls and calling them directly would be enough? This way you'll achieve logical separation of layers. <strong>Switching from buffered to streaming communication doesn't require you to split your logic into more services.</strong></p> <p>And if you want <strong>true</strong> scalability, consider using <em>queues</em> (for example <strong>MSMQ</strong>) and separate machines for each service.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload