I need to break up my duplex service and would like to encapsulate the large transfers into one service and retrieve from other(s). I used to have it all in one service but now need to switch from buffered to streaming to account for size/memory accommodations. I have seen a few questions here and here but they are quite old
What would I use for IPC between services, a namedPipe?
Service A exposes 2 methods
Stream Download(Guid) and uses net.tcp streaming, this is working well,
Now I would like to persist to Service B? Would this be the namedPipe WCF?
Service C --> Business layer --> Service B with
Guid, retrieve and do calculations on item, persist back to B
My question is what to use for persistence/Service B
From the clients perspective
Yes you can use Named Pipes as a WCF Binding as long as comunicating processes are run on the same server. Basically you create WCF service just as if you were using any other binding like TCP/IP, but you'll need to configure your endpoint to use
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
Dictionary<Guid, SomeLargeItem> would be enough.
So your flow would look like:
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.
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. Switching from buffered to streaming communication doesn't require you to split your logic into more services.
And if you want true scalability, consider using queues (for example MSMQ) and separate machines for each service.