I would just like to say that I am glad to see WCF being continued. I am not a huge fan of the whole REST movement. I mean, I get it, but I do not think it’s as cool/powerful as WCF. WCF is tops. Its configuration was pretty involved, and actually pretty terrible when you account for .NET configuration in general, but overall, you had RPC-style operations and resulting great cross-application boundary design because of it.
My vote would be to improve/remove DataContract opt-in attribute design. This made things messy and burdensome. I also believe a greater focus should be placed on interfaces and not proxy-generation. The REST crowd knocks web services for its code generation. Which I don’t exactly agree with (you don’t have to deal with that code), but the fact that it is there bothers them. Meanwhile, they don’t have any proxies and their code looks like a** full of parsed strings and URIs.
In any case, proper/preferred WCF design gets around this by using contracts/interfaces/channel factories. I think this should be the focus going forward.
Finally, speaking of configuration and attributes, a better, alternative design is to provide WCF configuration with POCO elements that describe how WCF should be configured within an application boundary. These POCO elements should be serializable and be able to load in from local disk or even a remote source. Basically a “WCF Application Profile” of sorts. And PLEASE account for different serialization formats, not just JSON, and XML (both having poor tooling support), but Xaml as well. Yes, Xaml. For editing server-side objects. .NET Xaml was made to define any POCO object. In fact, here is an example of Xaml POCO editing that I put together over this past weekend for Tile Notifications:
It would be nice to have this on the server-side for server-side components and yes(!) WCF. <3
Of course, in order to do this, Core .NET team will have to provide Xaml as a first-class citizen of its new package suite. Related thread here: Nature of Core.NET / System.Xaml