Most Compatible Inter-Process Communication protocol

Question

I am working on an media application for which I would like to provide an external API library that would allow another application to communicate with mine an query status information. My application is written in C# and the API DLL will be the same. Initially my thought was to simply use WCF and Named Pipes since it would provide an extremely easy way to code up the whole interface.

However, I realized that doing this would pretty much preclude any other languages or platforms from communicating with the application if I ever wanted to make, for example, an android or Web remote for it.

So, what protocol could I use that would allow a fast and simple interface from within my C# code, but also allow APIs to be written in other platforms.

Basic requirements are:

• Local and Remote communication
• Low overhead
• Procedure Calls
• File transfer (to send media)
• Pre-Existing C#, open source library would be nice.

I've looked at a lot of the options, used XML-RPC and JSON-RPC before, but would like to know what the community thinks is the best option.

Answer 1

I think using WCF it's the best way to do what you want. It will be simple in maintenance, cover all your requirements and easy to extend. Just don't restrict the access to your API only by net.pipe. I think you should use net.pipe, net.tcp and maybe basic http as primary bindings. I mean several endpoints for each service. So, a client app, no matter what language it is written, will be able to choose what binding to use to access your API server.

For example:

• C# client app on the same machine - use net.pipe
• PHP client app in web - use basic http
• Java client app on another machine - use net.tcp

As an example:

http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html