I have a scenario regarding these two technologies. I am building an API where there is a transactional piece that can be used in a client.exe while there's a data piece that gets loaded into a third party exe. I've been working with WCF as the messaging communication means between the two. Basically it just needs to communicate requests to read with the entity data read from the third party exe returned or communicate the need to commit data changes to the third party exe. In either case, custom object data needs to be passed back and forth. Conceptually the idea is very simple since my current WCF service doesn't have to do much more than pass data back and forth regarding a specific request (Write/Read). I just found out about NamedPipeServerStreams today though and it seems to be a very direct and simple approach... I think anyways... Since this is communications internal to an API, it seems to make more sense than WCF, but to be honest I'm ignorant about what makes the two different and whether or not it really would be best in this scenario. Being that this is an API, communications on the same machine or across the network between two processes is acceptable. If I needed to go beyond this, I would wrap API transaction calls with a WCF http configuration for sure.
Now that you have an idea of where I'm coming from, my questions are:
I just want to make sure before I go any deeper whether I should be switching to NamedPipeServerStream or stay the direction of WCF.
Now that you have an idea of where I'm coming from, my questions are:
- What's the difference between the two?
- Does this seem to be an application more fitting to one or the other?
- If not, what are the best fits for NamedPipeServerStream over WCF?
I just want to make sure before I go any deeper whether I should be switching to NamedPipeServerStream or stay the direction of WCF.
