Devs Blast Microsoft Turnaround on WCF Data Services and OData

Developers today were still weighing in on a recent Microsoft decision to switch directions on OData support to focus on ASP.NET Web API instead of WCF Data Services, angering many who had invested much work into the latter.

OK, this is somewhat involved, but I think it deserves a close look because it touches on so many issues developers have with Microsoft's support of new products and technologies and changes in direction. In this case, data devs in particular.

In a nutshell, Microsoft last week announced it will shift its OData-related development tool efforts from WCF Data Services to ASP.NET Web API, moving WCF Data Services to open source for further development. That angered many frontline developers whose teams or companies have invested a lot of work in WCF Data Services and now feel abandoned. They now have to consider their options and move forward with a new strategy. Sound familiar?

First, to get everybody on the same page regarding terminology, including those readers who might not be data developers, I'll provide brief descriptions of the terms.

WCF Data Services lets data devs easily build services that use the open OData protocol to expose and consume data over the Web using REST semantics.

REST is an architectural style relying on a stateless, cacheable communications protocol, basically HTTP. Instead of using SQL commands, for example, you can get a list of customers from the sample OData Northwind database service's Customers table by sending the URL: http://services.odata.org/Northwind/Northwind.svc/Customers

OData is an open, standardized protocol for providing and consuming data APIs using HTTP and REST.

ASP.NET Web API is described by Microsoft as an ideal platform for creating RESTful applications on the Microsoft .NET Framework.

OData recently advanced to version 4.0. Microsoft began work on WCF Data Services to support the new features. It ran into two major problems, as explained in the announcement blog by Michael Pizzo, principal architect, Microsoft OData Team:

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.

Long story short: Microsoft is putting its OData weight behind ASP.NET Web API as the tool of choice for creating OData services. Using the model-view-controller (MVC) pattern, service developers have much more control over data requests by implementing custom controllers for each route. This will require developers to write more code, Pizzo admitted, but much of that is boilerplate code and developers can get a head start writing it via controller scaffolding.

"We didn't make this decision lightly," Pizzo said, adding that Microsoft has been moving over internal services dependent upon WCF Data Services to ASP.NET Web API. The amount of work required varies, he said, though teams using Entity Framework or who have already implemented custom data handlers find it an easier task.

"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," Pizzo said.

Most of the work to upgrade WCF Data Services to handle features OData 4.0 has already been done, but some of the features still wouldn't be available because of the "monolithic nature" of WCF Data Services.

Thus Microsoft is moving the project to open source so developers can customize it to suit their own needs. Pizzo asked developers if Microsoft should invest more work in the product to make it more OData version 4.0-compliant before moving it to open source or just do it immediately and let the open source community finish the upgrade work.

Developers weighed in, and many weren't happy:

• I don't think it really matters when you release the source code. No one is going to care when the owner has stated it's dead. It's a shame I had put a lot of time and investment into WCF Data Services.
• This is very sad news indeed.
• Very disappointing.
• Not telling us until so recently is lame, epic lame.
• I have no faith in the Web API team prioritizing this issue very high and I fear we end up waiting a long time on the Web API team to catch up -- history shows this to be correct.
• I know MS wants people to adopt OData and now the people that have are being screwed over. Really not happy with this decision or the thought process that went into it.

Several commenters said Microsoft was erring by focusing on consumer development instead of enterprise development and eroding the trust of front-line coders in the latter camp.

"They need something that can hook to Twitter, Facebook and other Web sources," one commenter said. "In the end, WCF Data Services is just another casualty in Microsoft's pursuit of part of the pie that Google and Apple are getting most of right now."

Others, however, were supportive, and offered their opinions on which way Microsoft should go in open sourcing WCF Data Services, which was the point of Pizzo's blog post.

Pizzo addressed some of the questions and concerns in his own comment on the blog post.

And in response to a query from me, the team provided this:

First, it's important to note that WCF Data Services as it stands today will continue to be supported, including continued support for existing OData 3.0 in WCF Data Services.

We are currently planning to release OData V4 compatibility in WCF Data Services through Open Source, enabling the community to drive the feature set as appropriate.

At the same time, we will be taking the feedback provided to make Web API OData easier to use for scenarios where developers might prefer WCF Data Services today, as well as to make it easier for developers who have invested in WCF Data Services and chose to migrate in order to get the benefits of Web API + OData to do so.

Besides comments in blog posts, much of the feedback provided by developers comes in suggestions on the UserVoice site that Microsoft uses to gather feedback, features suggestions and so on.

A recent entry to the User Voice site is titled "Don't abandon WCF Data Services" and implored the OData team to reconsider the plan outlined in Pizzo's blog post. It had 52 votes today.

Pizzo responded and said the team would consider his feedback "as we prioritize work between enhancing WCF Data Services and providing better support for new features in the WebAPI OData libraries."

I asked the poster of that UserVoice item, Adam Caviness, a senior developer, to expound further. This is what he wrote me:

We were not expecting this news. Based on UserVoice tickets and team blog posts we believed that Microsoft was investing in WCF Data Services alongside of Web API.

In fact, the UserVoice page and Blog were actually named with the WCF Data Services moniker. Microsoft has a tendency to provide multiple offerings of a similar story to their own detriment--just consider why we have the Blend designer in Visual Studio. This is another case where multiple offerings is not a commitment but rather an experiment. Wait, am I a lab rat?

After getting further feedback from the OData Team, we discovered they had been working with internal teams to migrate for some time while we were left in the dark. The OData team also stated twice in posts that "part of our charter is to help Microsoft align behind the OData protocol." I can only gather that Microsoft is making a good technical decision to switch to OData internally, but what meets our needs is more or less a coincidence.

This is a decision they should have contacted the community over and it shouldn't have been mentioned in such a nonchalant [way] in a blog post. WCF Data Services is still listed on MSDN as a viable N-Tier OData strategy so I suppose new unsuspecting developers are even unaware of this direction.

We are investigating the impact of moving to Web API and OWIN. The strategy to reorient Microsoft to a more consumer-centric company is eroding away our confidence in building long-term dependable solutions for this platform.

Me? I can see both sides of this thing. On one hand, you see some of the behavior that leads to such prevalent animosity toward Microsoft on the part of developers who invest in a technology for long-term, line-of-business applications and then see the company going in another direction.

On the other hand, the new direction seems to provide developers with more control and opportunity for customization and might benefit them in the long run. And Microsoft team members are noting the feedback and are answering questions from developers and journalists like me, even though they were quite preoccupied with the just-started Build conference.

Still, I can't help feeling that if I were an enterprise developer as described above, I might hearken back to the immortal words of Johnny Rotten at the end of the Sex Pistols' last concert before the punk band imploded: "Ever get the feeling you've been cheated? Good night!"

What direction do you think Microsoft should go in sending WCF Data Services to open source for OData 4.0 support? Please comment here or drop me a line.

Posted by David Ramel on 04/02/2014