title: protocol buffers and actual transport options - sockets or middleware
body: <p>I am developing a client/server application for which I am evaluating a few options for the communications layer.</p>
  
  <p>As part of this communication framework, I am contemplating using google's protocol buffer (PB) for representation of the transport data instead of re-inventing my own binary structure.</p>
  
  <p>Now coming on to the actual transport, I am wondering if one should use plain sockets to send/receive these binary messages or use some form of middleware. Using a middleware has certain obvious advantages over sockets. A few that I care about include: communication models - publish/subscribe, request/response and fail over.</p>
  
  <p>On the other hand, using sockets has the advantage of low overhead compared to the middleware approach and will deliver better performance.</p>
  
  <p>One can also think of using the RPC libraries available with protocol buffers (third party add-ons on google's protocol buffer wiki) to communicate between the client and the server.  Though it abstracts from the low level socket, it still does not support the middleware features.</p>
  
  <p>At the moment, my client is an Adobe Flex GUI and two server side processes (One java and another C++). In the future, the client and server side can potentially have other services developed in other languages as well such as .NET</p>
  
  <p>What do the experts feel about these choices and from experience what works well without compromising on performance. Are there other alternatives that developers go with?</p>
  
  <p>Thanks 
  Dece</p>