Can you use WCF Data Services (ne OData, ne Astoria, ne ADO.NET Data Service) with NetTcpBinding?

Question

I'm looking at creating a data query WCF service over a slow satellite connection and I really like WCF Data Services. The problem I see is that HTTP is a very verbose format and since everything I'm doing is internal and .NET, is it possible to use NetTcpBinding instead to reduce some of the overhead?

Is this even possible? Advisable?

Answer 1

While researching this on my own, i ran across the MSDN article on Self-Hosted WCF Data Services. This article notes that you can host the service with DataServiceHost which still requires HTTP (it's derived from WebServiceHost).

But you can also roll your own host using IDataServiceHost. Here's an excerpt from the MSDN article:

For cases where the WCF host implementation is too restrictive, you can also define a custom host for a data service. Any class that implements IDataServiceHost interface can be used as the network host for a data service. A custom host must implement the IDataServiceHost interface and be able to handle the following basic responsibilities of the data service host:

• Provide the data service with the service root path.
• Process request and response headers information to the appropriate IDataServiceHost member implementation.
• Handle exceptions raised by the data service.
• Validate parameters in the query string.

The article seems to suggest that MS has properly segrated data-service responsibilities from network interface responsibilities. If that's so, then I should be able to write a NetTcpDataServiceHost. Has anyone ever written a IDataServerHost? Any suggestions?

Answer 2

No, WCF Data Services are built on top of REST, and REST itself is very intimately and completely based on the HTTP verbs like GET, PUT, POST etc. - you cannot run those over NetTcp, since those are intrinsically tied to the HTTP protocol stack.

Maybe there are other options for you to reduce the data being transmitted? Tweak your objects - trim the fat, if you can - both on the number of rows retrieved at once, and the number of attributes/data fields transmitted. That's probably you're most promising approach.