WCF Data Services

Microsoft initially released WCF Data Services as an easy way to implement an OData service over queryable data sources. This made it very easy to expose a model backed by the Entity Framework as an OData Service, and included a data provider model for plugging in other types of queryable data sources. WCF Data Services abstracted away all of the details of HTTP, OData, and the various payload formats, and the data provider was responsible for executing the underlying queries and returning the raw results to be serialized in the appropriate format.

This framework worked well for exposing a core set of OData features over data sources that supported fairly rich query functionality, but had two major limitations. First, it required that the underlying data source support fairly rich query semantics. This made it difficult to implement over diverse sources of data such as data returned from a function invocation or collected from other services. Even for queryable sources, computing the best query to perform on the underlying store was often difficult because the query passed to the data provider lacked a lot of the context of the initial request. Second, because WCF Data Services was somewhat of a monolithic "black box", services had no way to expose new features until supported for each feature was added to the WCF Data Services stack. Adding support to WCF Data Services often in turn required defining new interfaces that each data provider would then have to implement before the functionality was available to the service.

Web API OData Support

In order to give developers more control, we decided to invest in a better factored approach to building OData services using the Web API OData libraries. The Web API OData libraries, built on the popular model-view-controller (MVC) pattern, give the service developer much more control over how each request is processed by allowing the developer to implement custom controllers for each "route".  The methods exposed by these controllers have all the necessary context to satisfy the request, regardless of where and how the data is obtained. And, the better factoring of Web API makes it easier to implement new functionality without waiting for one or more external components to add support the feature.

Giving the developer the ability to implement custom controllers does mean added code for the developers. Most of this code, though, is fairly boilerplate, and things like scaffolding in Web API controllers make it easy to generate default code for handling these requests.

Supporting OData Version 4.0

In implementing support for the new OData version 4.0 Standard, we started by building OData V4 complaint versions of the low-level libraries use by both WCF Data Services and Web API for parsing URLs and serializing/deserializing payloads,. At the same time we released a common OData Client for consuming OData version 4.0 compliant services.

In order to give developers the most flexibility to build on a core set of features, we next prioritized adding core OData version 4.0 support to Web API.

We didn't make this decision lightly. Microsoft has a lot of services internally that are implemented using WCF Data Services. We are investing time in helping internal teams move to using Web API to expose their OData services. Through that process we are finding that the amount of work necessary varies depending on the level of investment the team has in WCF Data Services; teams that built on top of entity framework have the least amount of work to do, and teams that have already implemented custom data providers have incremental work to expose their queries through controller methods. So far, though, the migrations have gone well with the teams enjoying the benefits of more control in how requests are processed, and in the features they expose through their service.

So what becomes of WCF Data Services?

We have actually done the bulk of the work to implement the existing WCF Data Services functionality according to the version 4.0 protocol, but because of the monolithic nature of WCF Data Services it still wouldn't be possible to take advantage of the many compelling new features of OData version 4.0. Most of the new features would require additional work across WCF Data Services, as well as each individual data provider, before they could be used by a service built with WCF Data Services.

Rather than be a bottleneck to the features that WCF Data Service developers want to expose in their services, we are looking at providing an OData 4.0 compatible version of WCF Data Services as Open Source. This option allows developers to extend and adapt the code as appropriate for their individual use, and leverage the community to evolve the functionality much faster than we could ourselves.

We would love feedback on this approach. How far should we take the WCF Data Services code before releasing it as Open Source? Is it better to release it sooner and have the Open Source community finish the work to make the basic functionality fully compliant to the OData 4.0 protocol specification, or should we wait until we've had a chance to clean up the code and make it more compliant with the new standard?

Thoughts and feedback genuinely appreciated.

Thanks,

Michael Pizzo
Principal Architect, Microsoft OData Team