Data exchange between services
I need to split my duplex service and would like to encapsulate large transfers into one service and receive from the other (s). I've used it all in one service, but now I need to switch from buffering to streaming to accounting for size / memory allocation. I've seen several questions here and here , but they are quite old
What will I use for IPC between services, namedPipe?
Service A provides 2 methods Guid Upload(stream)
, Stream Download(Guid)
and uses net.tcp streams, this works well,
Now, would I like to keep service B ? Will it be namedPipe WCF?
Service C -> Business layer -> Service B c Guid
, retrieve and perform calculations on an item, save to B
My question is what to use for persistence / Service B
From a customer perspective
- Client calls
ServiceA_Proxy.Upload(someLargeItem)
returnsGuid
- The client then calls
ServiceC_Proxy.DoSomeWork(GuidFromCall_1)
- The client then calls
ServiceA_Proxy.Download(GuidFromCall_1)
- Client displays enduser
source to share
Yes, you can use Named Pipes as WCF binding if communication processes are running on the same server. Basically you create a WCF service in the same way as if you were using any other binding such as TCP / IP, but you need to configure the endpoint to use netNamedPipeBinding
.
If you want to store / save the data, you can store it in files or even a database depending on your requirements. If you just wanted to keep the data until ServiceC calls it, then that Dictionary<Guid, SomeLargeItem>
's enough.
So your stream will look like this:
- Client calls ServiceA_Proxy.Upload (someLargeItem) returns Guid
- ServiceA calls ServiceB_Proxy.Upload (GuidFromCall_1, someLargeItem)
- Then the client calls ServiceC_Proxy.DoSomeWork (GuidFromCall_1) (first you need to make sure the download is complete)
- ServiceC calls ServiceB_Proxy.Download (GuidFromCall_1)
- DoSomeWork service calls (GuidFromCall_1) (internally)
- ServiceC calls ServiceB_Proxy.Upload (GuidFromCall_1, someLargeItemProcessed)
- The client then calls ServiceA_Proxy.Download (GuidFromCall_1) (again, you have to make sure the processing is complete)
- ServiceA calls ServiceB_Proxy.Download (GuidFromCall_1) and returns to the client.
- Client displays enduser
I'm not sure if I haven't messed up anything. As you can see, this is getting pretty tricky. You have to ask yourself what is the way to go, and if splitting your service in this way will actually make it more scalable? You plan to use NamedPipes, so all processing will still be on the same machine.
You should really consider your design. Maybe splitting funcionality into some * .dlls and accessing them directly would be enough? This will achieve a logical separation of the layers. Switching between buffering and streaming doesn't require splitting your logic into more services.
And if you want true scalability , consider using queues (like MSMQ ) and separate machines for each service.
source to share