The Windows Communication Foundation (WCF) Data Services (originally known as ADO.NET Data Services) is a framework for exposing data layers in a REST-ful manner, using JSON or Atom as the output format. While the technology is relatively new, it addresses a number of common use cases for developers, including:
- Allow AJAX applications access to the database via HTTP without writing a Web service as a proxy.
- Provide access to data to third-parties in a standardized, vendor neutral fashion.
- Create a REST-ful data access system without the baggage of other Web service systems.
The technology automatically creates a REST-ful Web service that emits JSON or Atom based on a provided configuration. This means that the developer is now off the hook for writing an entire Web service, serializing the data to JSON or Atom, and so on, which can save significant amounts of time.
At its basic level of functionality, the developer passes a configuration generator connection information to the database, and it creates a configuration that directly maps functions to the database structure that was provided. This is fine if you don't mind providing unlimited access to your database, but it's probably not what you want to do. You can use this configuration as a basis for modification, such as adding the appropriate security and adding additional data logic, trigger-like functionality, and more.
When I first saw WCF Data Services demoed at the MSDN Southern Fried Roadshow, I asked the presenter, Brian Hitney, why this technology is useful. He explained that it provides a really easy way for AJAX applications and other client-side applications to access the data behind your firewall, without having to go through the effort of writing an entire Web service. He used mashups as an example of an application that could use this type of access. He also pointed out that, with a traditional Web service acting as a proxy to database, you either need to write a very complicated system that allows the developer of the consuming side to effectively pass queries, or you need to fully anticipate their needs with the functionality you provide. With WCF Data Services, you set your access and authentication much like you would with a database that clients directly communicate with, and then allow the application developer to perform the operations that he needs. As a result, business logic can be moved out of the service and to the client, although it can stay on the server side as well if desired.
I was initially a bit dubious about this technology. I thought, "great, some developers are just going to expose the whole database with full permissions out of ignorance or laziness," followed by, "why don't you just open up the database to ODBC access through the firewall and call it a day?" But the more I think about it, the more it makes sense.
Yes, there are major security concerns if you use the default configuration that automatically generates and run the service as a user with full permissions to the database; however, this would be a problem with any client application accessing the database via ODBC (or some other connection technology) as well. That said, the responsibility for ensuring the proper access shifts significantly to the developer and away from the DBA. You can still (and probably should) keep a double-layered approach to security, where the Data Service user has the bare minimum rights to the database. In terms of the actual functionality, I can see where accessing data over HTTP would be preferable to ODBC (or some other lower level of access), particularly where firewalls come into play. In addition, it allows the client to be extremely lightweight, only needing an HTTP request mechanism and a JSON or Atom parser, as opposed to a whole data access stack.
WCF Data Services is available for .NET 3.5 (as ADO.NET Data Services) and .NET 4 (as WCF Data Services). If you're currently writing a lot of Web services to act as proxies to the database, you'll definitely want to check out this technology.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
———————————————————————————————————————————-Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!
Justin James is the Lead Architect for Conigent.