One of our strong practices here at Syndicated Methods is design and implementation of Service Oriented Architectures (SOA). When people immediately hear SOA, they think SOAP and bloated contracts. Yes, SOA boasts some grandiose goals with its standards, and with those goals comes a complex implementation. I have seen SOA make sense of many enterprises, and like any loyal developer ready to fight for their technology, this mantra has always rubbed me the wrong way. As of the release of .NET 4.0 however, and the rise of REST services, it has become quite clear that SOA isn’t the only way. It has actually changed how I think of our practice. So much so that I make sure to tell clients and folks that I talk to that our practice specializes in “Distributed Architectures”. I have come to realize that we can take all of those lessons learned in SOA and apply them to any number of manners for exposing enterprise data in a distributed fashion applying the most suitable manner for clients.
After reading a recent article on WCF Data Services, it got me thinking about how to spread the word for such technologies. Oh yeah, did you know Syndicated Methods has a blog! So, I want to start a series on the Syndicated Blogs titled ”Distributed Architectures”. The first candidate … you guessed it. WCF Data Services.
WCF Data Services
There are certain scenarios where the development overhead associated with SOA is just not necessary. For example, you have an analytics group that needs to have open access to a data store. Or, you have an application that allows the user to shape and export data how they see fit. Maybe you do a lot of prototyping and are looking for a turnkey solution for getting to your data. Such business problems have been solved by the Open Data Protocol (i.e. OData). Those familiar with RESTful services will immediately understand. The idea is to expose a repository of data over a standard pathing system, such as urls. WCF Data Services takes these concepts and allows you to define a WCF Service (without the contracts of course) over an Entity Data Model. You can expose your data in just a couple of easy steps.
Step 1 – Create a new Web Project on your local file system. Any name for the site should do.
Step 2 – Next we need an Entity Data Model of the standard Sql Server Nothwind database. You will want to create a new Entity Data Model pointed to a local instance of Northwind. Go ahead and run all of the default configurations (make sure you place this in the App_Code section of the project). You should end up with a Entity Data Model that looks similar to the following diagram:
Step 3 –Now it’s time create your service. Create a new WCF Data Service in the root of the website. Now we are going to have to write a little bit of code here. We only want to expose the Employees table for this exercise, so we need to tell the WCF Data Service to expose the Employee table. In a real world implementation this could be done for all of the data tables / data sources required. The code is rather trivial and is represented below:
Step 4 – Now for the fun stuff. Let’s get your data! You can easily pull your Employee data from the service by pointing DataServiceQuery at the endpoint. Pretty neat! No messy configurations, no service endpoints to deal with, and better yet you get your data in 4 or less easy steps. I will let you play around with your services to get an idea of what it’s like to pull this data. Below is sample code for consuming the endpoint.
Before I close out this post, I want to just show you something that you may have missed. I know that I missed it the first time through, so I want to just call it out. WCF Data Services are employing the power of .net and WCF to allow you to address your data. Users of the system only need to know the schema of the database. We accessed the data by pointing to the following url:
http://localhost/WcfDataService.svc/Employees
This url basically says, use this service repository location, and show me all of the employees. If we wanted the Customer data (assuming it was exposed in the WCF Data Service) we only need to access the following url:
http://localhost/WcfDataService.svc/Customers
And keeping true to the RESTful theme, if you want to narrow your data down you can pass a query along with this path like so:
http://localhost/WcfDataService.svc/Customers('ALFKI')/Orders?$filter=Freight gt 50
This will capture Customers with the id of ALFKI and will then filter those by getting freight values that are Greater Than 50. Pretty neat. Using these powerful data services allows you to get to a repository of data by simply "asking" for data in a standardized format. If you are wondering how all of this data gets transferred, under the hood .NET will serialize this data in POX or JSON format. The following screenshot verifies our transport data as depicted in Fiddler
As you can see the output is a standard ATOM Xml format. Internet Explorer will conveniently display this as a RSS feed. Anyone that is tasked with exposing data in a distributed fashion should definitely put this one in their toolbox!
{Happy Coding}
Subscribe