No idea what WCF is, but all I do is put send JSON as the message and call it done. I've found that to be fast enough for most of my work, and it's a combination that's understood by everything.
Re:PyCon 2011: Interview with Zed Shaw
by alexgartrell on Friday February 18, 2011 @01:27PM
(#2236589)
You might want to check out Thrift http://wiki.apache.org/thrift/
It supports a ton of languages and provides an entire RPC interface.
Just out of interest, if you're going to need to talk between C#, C++ and Python, why not just use HTTP and JSON? Unless you have truly crazy performance requirements that should be more than fast enough for most purposes, and it's really easy to work with (debug in the browser etc).
HTTP is designed for a single request, single response in order. ZeroMQ messages can be sent without waiting for each messages response, thus a single socket connection can push drastically more information then a single http connection (not that you are limited to a single http connection).
Connection Pooling HTTP starts bringing in a lot of overhead, but doesn't provide some of the other features ZeroMQ does (multi-honed etc) without some additional effort (load balancers on the network).
I've personally been pondering a variation of JSON-RPC that operates over a TCP socket not over the HTTP layer.
ZeroMQ is easier than HTTP. Much, much easier. Take it from a guy who has actually written a web server that also uses 0MQ.
You can use http://code.google.com/p/protobuf/ for serialization with ZeroMQ. We are using ICE http://zeroc.com which offers similar features.
I encountered resistance because of WCF handles not only the serialization, but the method routing on both ends of a service (by means of a proxy class, which would be hard to set up in C++/Python anyhow). My reading on ZeroMQ leads me to believe I could set up one socket as a front end which routes message to a different publisher dedicated to each method?
Is this a good way to do it?