WCF, Data Services and RIA Services Alignment Questions and Answers

Windows Communication Foundation (WCF) is the heart of the Microsoft Developer story around services. WCF is the unified programming model for working with services in the enterprise and across the Internet in .NET applications.

As highlighted in sessions at this year’s PDC, .NET Framework 4 makes it easier for developers to work with services from their managed code applications. With .NET 4, the WCF technology provides several different types of services to start from, based on your particular needs, but they all share the same underlying infrastructure. 

· SOAP Services – Allows full flexibility for building operation-centric services. This includes industry standard interoperability, as well as channel and host plug-ability. Use this for operation-based services which need to do things such as interoperability with Java, be consumed by multiple clients, flow transactions, use message based security, use transports or channels in addition to HTTP, or host in processes outside of IIS. WCF has supported SOAP services since its initial release in .NET Framework 3.0, and .NET 4 adds additional WS-* support and default bindings to make it easier than ever to build SOAP services using WCF.

· WebHttp Services – Is best when you are exposing operation-centric HTTP services to be deployed at web scale or are building a RESTful service and want full control over the URI/format/protocol. Support for HTTP services was added to WCF in .NET Framework 3.5 and generally referred to as “WCF REST”. A number of significant improvements, such as content negotiation have been added in .NET Framework 4.

· Data Services –Data Services are best when you are exposing your data model and associated logic through a RESTful interface; it includes a full implementation of the Open Data (OData) Protocol for .NET (more on this below) to make this process very easy. . WCF Data Services was originally released as ‘ADO.NET Data Services’ with the release of .NET Framework 3.5 SP1;

· Workflow Services – Is best for long running, durable operations or where the specification and enforcement of operation sequencing is important. Workflow services are implemented using Windows Workflow Foundation (WF) activities that can make use of WCF for sending and receiving WCF-based service requests.

· RIA Services – is best for building an end-to-end Silverlight application. WCF RIA services will be released with Silverlight 4, and is built upon WCF.

The important thing to remember is that each of the above service options builds on the WCF service model and should not be thought of as binary choices. These service options provide developers with a starting point that makes the job of accomplishing common tasks much easier; allowing any of the above services to be customized and extended using the power of the same WCF service model. We expect many applications will leverage multiple models for building out their applications and their developer's knowledge will easily transfer from one model to the other, allowing developers to use one skill set across solution types.

So what does this mean to you as a developer? It means that WCF can be conceptualized using the following stack diagram:

Also of note in the above diagram is the appearance of the Open Data (OData) Protocol in the protocol box of the channel model. The OData Protocol made its initial splash as the protocol used by the Data Services programming model to present and interact with data. It is a protocol that defines how a client can query, navigate, and make changes to data in an open, RESTful manner. Data Services fully implements this protocol today, and RIA Services will (soon) expose an endpoint that supports this protocol.

Feedback from folks at PDC, after the sessions and at the booth, was very positive. General comments was that this made service development in .NET much more straightforward, changing the decision from ‘which .NET technology do I use?’ to ‘which part of WCF fits best to what I want to do?’ Today, This also provides more messaging consistency to products that share a common technology foundation. Over the coming years, this indicates the direction towards tighter technical consistency for the .NET developer.

That being said, we did receive a bunch of common questions at PDC; and we thought it was worth sharing them, along with the answers, here.

Why did we rebrand ADO.NET Data Services and .NET RIA Services at PDC? And how do they relate to WCF?

You told us that it was confusing having different communication technologies being built and shipped by different groups. In this case, ADO.NET Data Services (also known by the codename ‘Astoria’) was falling under the ADO.NET brand and coming out of the Data group, while.NET RIA Services was being built and shipped with Silverlight. At PDC, and with the release of .NET Framework and Windows Server AppFabric, we are working to better align and simplify the developer experience on the .NET stack. This rebranding is the first step in bringing better alignment and simplification to the .NET communication stack that is WCF. Unifying these services offerings around WCF allows developers to use one set of skills when using services, in the short term this means being able to use these different service types with a dramatically shortened learning curve, and the long term this means getting full reuse of skills and code as the entire stack is aligned for these two technologies.

Technically speaking, these technologies share the same underlying programming model provided by WCF, but they are designed to meet different use cases. Data Services focuses on exposing your data model and associated logic through a RESTful interface, and RIA Services focuses on building end-to-end Silverlight applications.

Both WCF WebHTTP Services and WCF Data Services expose RESTful Services; how do they relate to one another?

The WebHTTP Service and Data Service technologies both share the same underlying programming model provided by WCF, but they are intended to meet different use cases. WebHTTP services are focused on operation-centric HTTP services to be deployed at web scale or when users are building a RESTful service and want full control over the URI/format/protocol.

Data Services on the other hand are focused on exposing your data model and associated logic through a RESTful interface. Today, Data Services is where you’ll find the richest implementation of the Open Data Protocol (OData), though in future releases of the .NET Framework, we plan on bringing OData support, as well as the declarative data model of Data Services, to WebHttp WCF Services.

How does a developer decide what service type my client should use to communicate with my Service?

If you are writing a “RIA Services Enabled” Silverlight application, the RIA Services tooling will automatically create the right client components for your RIA Services Domain Service.

If you are writing a client to an existing Service using Visual Studio, use “Add Service Reference” and the right client will be selected for you; a WCF Data Services Client for accessing a WCF Data Service or a WCF Client for accessing a WCF SOAP Service. Users can also use “Add Service Reference” to a WCF RIA Services Domain Service.

Are we deprecating any of these service types {SOAP Services, RIA Services, Data Services or Workflow Services}?

No; all of these technologies are core to our vision moving forward and each has a clearly defined use case for developers today. By bringing them all together within WCF, we provide developers with a clear place to start when building and using services. We also provide the developer with a collection of common concepts and extensibility point across these technologies, allowing you to be quickly productive using technologies with simple starting points while providing a powerful foundation should you need additional flexibility of the larger WCF stack.

If you are using one of these stacks today, we would like to reassure you that it still makes sense for you to continue to use what you are developing with. The stacks will get improved in the future, and the continuing unification story will provide you with additional benefits of the others, but none of these stacks are currently planned for deprecation.

If a key value proposition of RIA Services is its simplicity, how is this balanced with the flexibility for WCF?

WCF is a very powerful and flexible technology. What RIA Services provides is a prescriptive pattern that defaults many of those options for the best experience in the common cases. Early feedback on RIA Services has been that it makes it extremely easy to get an end-to-end solution up and running, by effectively hiding a lot of the WCF flexibility.  However, if need arises, developers are able to configure a RIA Services Domain Service like any WCF service with all the power and expressiveness they have come to expect from WCF.