Attempting to use WCF Data Service as a relay for another OData Service

Question

I have an ASP.NET Web API 2.0 OData service project which I am trying to relay via a service reference + WCF Data Service (5.6) through an ASP.NET MVC project—the reason I am doing this is so users browsers’ can access the service without worrying about CORS for IE8 and IE9— so they will have the same host.

After some tinkering, this setup mostly works however there are some problems, my setup:

Service Project

1) ASP.NET Web API 2.0 OData endpoint

2) WCF Data Services 5.6 OData endpoint + Entity Framework 6.0.2 (EntityFrameworkDataService<DBContext>) using WCF Data Services Entity Framework Provider (1.0.0-alpha-2)

When I directly access both of these services they perform flawlessly with whatever I throw at them—both through a service reference, LINQPad, and raw URLs. Then I setup the ASP.NET MVC project:

ASP.NET MVC Project (relaying service references above): WCF Data Services 5.6, (DataService<ServiceReference-1-or-2>)

The problems come when I try to perform the same queries on the WCF Service acting as a relay:

Relaying (1) with $inlinecount=allpages gives me: “An error occurred while processing this request.”

Relaying (1) and (2) with $select=... both give me: “Not Implemented”.

When I relay a dummy POCO context through the reflection provider all of the operations work flawlessly on the relay WCF Data Service, which leads me to suspect that the problem is in the combination of WCF Data Services and the Service Reference, as they both work without problems independently… Perhaps the WCF Data Service is examining the LINQ Provider for the service reference and arbitrarily deciding that it does not support the operations? I could live without $select but not having $inlinecount is a deal-breaker. There are a couple of alternate solutions I could take but I would really like to make this approach work: any ideas?

Answer 1

This was very similar to: WCF Data Service - Proxy mid-tier service

In a nutshell: you can have a relay by either

1) Making the service believe it is at a different URL than it is (so it is effectively broken for all access except through the proxy).

or

2) By writing another service which manually does the relaying to the service reference...

I chose none of the above and restructured my service as Web API Owin middleware. I lost the ability to have a separate service deployment but can easily swap in another piece of middlware and it makes CORS issues non-existent.