I’ve had a chance to look at RIA Services over the last few months and thought it would be good to clear up some of the confusion over where RIA Services stands in relation to other related technologies like ADO.NET Data Services and WCF.
In some respects RIA Services are similar to WCF Services. You write the service code, host it on a server, create some proxy classes on your client and away you go. In fact, if you look at how you implement the same service in each technology it’s almost identical.
In WCF,
[ServiceContract]
public class SpeechService : ISpeechService
{
[OperationContract]
public CreateWavStreamResponse CreateWavStream(CreateWavStreamRequest request)
{
...
}
}
In RIA Services,
[EnableClientAccess()]
public class SpeechDomainService : DomainService , ISpeechService
{
[ServiceOperation]
public CreateWavStreamResponse CreateWavStream(CreateWavStreamRequest request)
{
...
}
}
In both cases a proxy class is created when the service is referenced. In the case of RIA Services the proxy (DomainContext) is created automatically when you compile your Silverlight solution. For WCF the proxy is created when you explicitly reference the service via, for example, the Add Service menu option in Visual Studio.
In this example the main difference between the two technologies is in the way the messages are constructed and sent between the client and service. In the case of WCF you get to choose your binding (HTTP, HTTPS, TCP) and transport (usually SOAP but REST is possible if the length of this white paper doesn’t put you off!). The current version of RIA Services (July 2009 CTP) only supports HTTP, REST-style services that use JSON to package the contents of the messages. The current implementation follows a very similar pattern to that used by ADO.Net Data Services. In fact Tim Heuer states the next version will adopt ADO.Net Data Services completely.
And even further down the track it looks like they’ll be incorporating some of the power of WCF into the transport layer. For example, Brad Abrams mentions,
“We also expect to eventually provide full access to all the power and flexibility from the underlying WCF services such as highly optimized binary serialization. “
RIA Services aligns further with ADO.Net Data Services by automatically allowing you to generate CRUD style operations against data stores. Simply point to a data store and away you go. Doing this in RIA Services results in a (server-side) service that looks something like,
[EnableClientAccess()]
public class BlogDomainService : LinqToSqlDomainService<BlogDataDataContext>
{
public IQueryable<Category> GetCategories() ...
public void InsertCategory(Category category) ...
public void UpdateCategory(Category currentCategory) ...
public void DeleteCategory(Category category) ...
public IQueryable<Comment> GetComments() ...
public void InsertComment(Comment comment) ...
public void UpdateComment(Comment currentComment) ...
public void DeleteComment(Comment comment) ...
...
}
The implementation of the service is based on LinqToSQL – this is likely be extended over time.
The operations of which, can be called from the client, via an auto-generated proxy, using REST-style web requests that look very much like ADO.Net Data Service requests. For example, a request for all Postings would be constructed as a GET request to a URI like,
http://[yoursite]/ClientBin/DataService.axd/[yourRIAServicename/GetPostings
RIA Services processes this request and returns an HTTP Response where the contents of the response are serialised using JSON.
Note: The above screen-shot is from Nikhilk’s IE browser extension, Web Development Helper that seemed to be one of the few HTTP traffic capture tools that allows you to view JSON output in a tree-view.
Of course, RIA Services is more than another way of simplifying distributed data transfer. It contains many other features that have nothing to do with either ADO.Net Services or WCF including,
- Integration with ASP.NET’s security model – forget about the complexity of WCF security, this is how easy securing services should be!
- Client-side Validation – all validations defined on your server-side entities (using familiar Data Annotations) will be automatically transferred to the client.
- Silverlight Control Support - because of the way Data Annotations are used a number of Silverlight controls will honour the validation rules also. For example, the DataGrid and DataForm will both display validation error messages without you doing a thing.
- Offline Support – all changes to your entities are batched within ChangeSets that can be saved to IsolatedStorage when not online.
So, there you have it. Be confused no more ;-)
