Monday, April 30, 2012

Using WCF Data Services Tutorial - Part 1

With the recent release of WCF Data Services 5.0 a few weeks ago, I thought it would be a good idea to introduce the technology to those of you that have not seen it before. 

WCF Data Services for those of you used to creating traditional SOAP based or REST services using WCF has a different purpose and use. It builds upon the Open Data Protocol (OData) that Microsoft created to expose data as resources that are addressable by URIs. OData builds upon the AtomPub protocol to represent data in a standardized method and then makes it accessible via HTTP. Through REST based services you can access any type of data using the standard HTTP verbs (GET, POST, PUT, DELETE).

These services offer a powerful way to quickly expose your data as services without a lot of the manual work involved otherwise. In addition the services are customizable via service operations and interceptors. The OData protocol is something not confined to .NET either. The idea is an open protocol for exposing your data in a platform agnostic manner via HTTP. There are a slew of .NET OData client libraries that sit atop of data services for accessing the data, and there are even libraries in other languages like Java and its OData4J library.

So why is this good? Well 1st off we are exposing data using a known and standardized protocol in OData. Think of the alternative using a traditional WCF service with a webHttpBinding to create a RESTful service. You would be creating from scratch how your data is being exposed and only you and your clients understand this model; it is not a standard. If you being on new clients to consume your services, you have to explain (typically through documentation) on how your data looks when exposed. This is obviously not as easy as telling clients that your services expose data that is built upon the AtomPub format in OData which is a standard. The other main attraction of data services is how much custom and manual plumbing work that gets cut out and streamlines. As you will see below, in just minutes I can have my relational data exposed and accessible via HTTP in a RESTful manner via URIs mapped to my entities.

In my example I am going to expose some relational data via WCF Data Services from the 'AdventureWorks' database on my local SQL Server instance. I just want you to get up and running to see the possibilities, so we will go through all the steps to preform a simple GET on some of the entities we will expose.

First let's start off by creating an Entity Framework model for the AdventureWorks database. If you want to follow along and do not have the Adventureworks database you can download it from CodePlex here: ( Begin by going to 'Add -> New Item' and under the 'Data' category on the left select 'ADO.NET Entity Data Model'.

For this example I am using the AdventureWorks database, so I select 'Generate from database' and then navigate through the wizard to set up a connection, naming conventions (I use the default values for this example), and then I selected all the tables before completing the Entity Framework Model.

Now that our EF model is created, we can create our WCF Data Service. I have the new WCF Data Services 5.0 installed which is built upon the OData v3.0 specification, and you can download it from here as well: In Solution Explorer on your project, select 'Add -> New Item' and under the 'Web' category on the left select 'WCF Data Service (for OData v3)', or similar option if you have an older version of WCF Data Services installed.

This will create a new WCF Data Service with it's default class and 'InitializeService' method. On this class we must Implement the Entity Framework model we created earlier. The default line below instructs you to do so:
public class WcfDataService1 : DataService< /* TODO: put your data source class name here */ >
For this example let's Implement the 'AdventureWorksEntities' class we created earlier like below:
public class WcfDataService1 : DataService<AdventureWorksEntities>
The next step requires us to be explicit on which entities we want to expose and with what level of permissions too. Just to give you a feel of what the exposed data representation looks like in the browser, lets go ahead and expose all entities using the asterisk with 'AllRead' permission:
config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
Before viewing the data in the browser, I recommend selecting the browser for VS.NET to use to Google Chrome instead of IE. IE9 at least does not display AtomPub data properly, and upon doing a GET on the entities you not be able to view the data. To do this, right-click the WCF Data Service item in Solution Explorer and select: 'Browse With...' as shown below. Select 'Google Chrome' and the browser will display all of the entities that have been exposed. You can also permanently switch the default browser used in this dialog as well by pressing 'Set as Default'

As you see above, all of the 'Collections' from our EF model are exposed. Let's go ahead and only expose the 'Employees' entity by modifying the code to look as follows:

//Only allow the Employees entity collection to be exposed:
config.SetEntitySetAccessRule("Employees", EntitySetRights.AllRead);

Now when run in the browser we see only the Employees collection is exposed. Let's explore and expose what information we can get back on this collection by modifying the URI. If I want to get back the Employee with ID '1', I can simply request this using the URI below:

Upon making the GET request, you can see that I get back all of the information just for the Employee with the ID of '1'. 

One other nice feature is the ability to query the entity with some predetermined query string options. For example, when we did a GET for the Employee with an ID=1, you could see there were some related entities 'Employee1' and 'Employee2'. If we use the 'expand' query string option, we can expand on this employee to see related entity information. Modifying the URI to be as follows to expand on the 'Employee1' many to many relationship:

Upon making the GET request with the expand query option you will see the additional related entity information. Try the same procedure for expanding on 'Employee2' to see additional related entity information.

So look at this - in just a few minutes we are up and running by exposing our relational data accessible via HTTP in a RESTful manner using a know open protocol. Pretty cool if you ask me, and even better - really useful. This has just barely scraped the surface of what can be done with WCF Data Services. In the future I will expand on this tutorial getting a little more in depth with some of the additional functionality offered.

Wednesday, April 25, 2012

The Future of Creating Line of Business and Metro Applications in Windows 8

So with Windows 8 right around the corner and a software community racing hard to adopt and create new Metro style applications, I thought it would be a good time to focus on Line of Business applications in the future. My posts on Windows 8 evolve with my increased exposure to the new OS, and it is fun to see how my opinions evolve as well.

I get Windows 8 and I am sold. But guess what? I am a software engineer. Even if I did not like Windows 8 (which is not a problem because I do) I would end up adopting it anyways any new OS from Microsoft will make its presence known... eventually and in 1 way or another. 

However this is somewhat a radical change to current Microsoft OS interaction experiences from the last several OS releases dating back to Windows 95. In fact I made that observation myself in an older post, and many in the industry say as well that: "This is the biggest change to an OS from Microsoft since Windows 95." I even hear examples trying to pull parallels to how people didn't understand how to use a mouse back in Windows 3.1 and everyone had to be taught on its use. Thus trying to draw the line that we just need to educate people on the new changes and ways of thinking in Windows 8. I have a problem I have with that analogy - most people had little if no personal computer experience back in the early 90's and nothing to draw on or compare to so everything was new.

This isn't the case this go around. Roughly 80% of households have a computer in the U.S. and the majority of them are probably running Windows XP or Windows 7. People are getting comfortable and are used to "a way" of doing things on their Windows computer. A lot of that at least from an interaction standpoint will change with Windows 8. Most industry tech people and software engineers will have no problem adapting. It's the 65 year old user that is still asking: "Why are my folders sorted from Z-A all of the sudden??" that is going to have a problem with radical change. This too will spill over into the workplace and into LOB applications.

There is a familiarity with most LOB applications whether web or desktop that users feel comfortable with. Metro style applications will shake up that feeling of comfort if corporations begin to move to Windows 8. The natural slowness of larger corporations to change their OS will actually help ease this new (and improved) look and feel of Windows 8 into general society 1st through home computers, tablets, and mobile phones. This will allow users to become more familiar with Windows 8 and its Metro interface well before it is rolled out in large use in the corporate world in my opinion.

So will the new Metro style work for LOB applications? The answer: absolutely. Challenges? absolutely. Will Windows 8 and its new metro interface catch on to the masses? I believe it will and also hope it will. I think Microsoft has done a good job in what I have seen of Windows 8 and I’m definitely a proponent of it. However I am a realist as well and know (as they do too) the challenges we face.

Challenge 1: Bend our (software developers) minds to create Metro style LOB applications. OK, so how many developers out there have ever said: "I am not a UI guy/gal." Well if you are lucky enough to work on a ginormous team that has front end developers, then Windows 8 will offer not much for change in that aspect. However for most of us that are involved with end to end development you are going to have to bend your mind to learn the new 'Metro' style.

VS.NET 2011 has provided templates for guiding those of us deficient in UI design on creating Metro style apps and this will help. But even a template will not undo 10-20 years of the way we have done web and desktop development for LOB applications. You know the old 'File' menu at the top, close button on the top-right, status bar at the bottom. Gone or construed into something new and not totally 1:1 in translation when creating a metro app. Essentially the 'Chrome' of today's applications is gone and a dirty word in Windows 8. I have heard and quote (loosely) Rocky Lhotka at VSLive! say repeatedly when working with XAML and joking about himself not being a UI guy stating: "I know one color: Battleship Grey, so yeah I appreciate the designers." Well a lot of us are going to be in this boat (no pun intended). Metro style apps place a great emphasis on the UI interaction and design and being good at this will be important. No longer will slapping a lot of text boxes and labels on a form suffice, if we want to move forward and truly use Metro applications. This is a good segue into my next challenge below.

Challenge 2: Switching back to the classic desktop and applications in Windows 8. So the 1st adopters of Windows 8 in the business world will obviously not have enough time to redesign their application portfolio into Metro style applications. So what will happen? Upon clicking a ‘tile’ on the Metro Start screen for your LOB application, you will be reverted to the traditional Windows Desktop and existing application. This switching back between the Metro Start menu and the classic desktop is something that I believe will annoy and confuse the general use population. It's not a big deal and happens somewhat seamlessly, and is absolutely necessary for backwards capability of existing applications. Like Microsoft keeps stating: "If it runs on Windows 7, it will run on Windows 8."The problem is some of these behemoths of LOB enterprise applications may never be converted to a Metro style app (might still be half a million lines of code in VB6!) so this switching back and forth needs to be looked at by the community and feedback given as to make this as seamless as possible.

I honestly think eventually after enough pushback from users of the annoyance and how some may never want to adopt the Metro interface (not saying I agree, just being a realist), that Microsoft would serve up an option in its 1st service pack (SP1) for Windows 8 to switch permanently to 'Classic' mode or even have an install switch for 'Classic Only' mode. It would not surprise me 1 bit if they felt the squeeze and sales were low due to the new interface to make a move like this. However I think this would only happen as a move of desperation for sales. Microsoft will want to drive users to their new interface and get users to stop thinking of the 'old way' of doing things. I would not be surprised either way, and it will be interesting to see.

Challenge 3: Users becoming familiar with Metro style applications. No more application 'Chrome'. No more minimize, maximize, file menu, 'x' button to exit, etc. Start learning to 'swipe' your finger or mouse instead for menus that slide out from the top and bottom and left and right. I'm cool with that. Is everyone else? The obvious answer is no. I listen to a local AM radio computer show on my way to bowling on Tuesday night and you should hear the questions asked on the air: "What's this email about inheriting 90 million from Nigeria?" "How do I save a file from my granddaughter sent to me in an email?" "Where is MyDocuments in Windows 7?" Yeah... that's your general use population. Tell them: "Swipe your finger from the side to view more applications." The response? "Do I do this on my keyboard or in the air? My 14" dell monitor is not responding when I touch the glass on the screen..."

Of course then you have the folks that camp out in N.Y. 2 weeks before the next iPhone release so as a whole we are getting more tech savvy. These are the type of folks that will help move Windows 8 along, in addition to a strong following in the development community from people such as me. The tech group adopting Windows 8 will have no issue with its new look and feel and will probably enjoy it immensely.

On the LOB application front, users in the corporate world will have to adopt Metro applications using a mouse more than likely because any sort of touch device from a cubical that is sat in for 8 hours a day is not practical. Now for apps that need mobility (i.e. shipping, inventory, medical, etc. out on the floor or in a warehouse) Windows 8 is going to be positioned well. It's all these diverse groups with their experience and the minds to make large scale IT decisions in the business world that will determine how quickly Windows 8 and Metro applications catch on in that environment.

Challenge 4: Not getting stuck in the past and moving forward. This is a big hurdle. Why do we need this fancy new doodad of an interface (says the user that loves their stable Windows XP machine)? Well we don't technically need it but it really is aligning with where technology is and has moved. Look at everyone with smart phones today. If you enjoy any type of smart phone with touch capability, then Windows 8 will fall right in line and even expand on that use to all needs. In the business world where things tend to be a little more conservative (like using Windows 95 in 2002 for a company I worked for with 125,000+ employees), it will take more time. In addition this is not just "another OS".

Windows 8 and its Metro start menu and interface with redesigned and rethought applications are radically different. However at the end of the day they serve up the same functionality you get today; just in a prettier and cooler interface (along with superior OS engineering under the covers). I see a divide with Windows 8 in the corporate world and LOB applications and think it will be slow to catch on for larger existing applications. Once companies do make the switch, I think there will be a great hunger though from the software developers to create new development using Metro style applications. This will ultimately help move us all forward.

So what does all of this add up to? I think for the corporate world and most users of the Windows Operating system, full on Metro interaction with 100% Metro applications (or close to it) is many, many years down the road. In fact right now there is so much focus on getting developers to create a Metro application for the Windows Marketplace (to sell or download for free) to compete with Apple and Android market share that not as much focus is on complex LOB applications and development. The Marketplace isn't really applicable to internal corporate LOB HR or Accounting applications for example, so there isn't much talk on this front from what I can see. The push is to increase Windows market share and make Windows 8 a "one size fits all, touch first [tablet first if you ask me]" OS.

I think Metro style LOB applications will happen but will be much slower to be commonplace, and will follow behind the next 'HappyBunny' or 'AngryBirds' Metro app downloadable from the Marketplace. And to be honest there is nothing wrong with this. Microsoft needs to position itself well and be competitive in a niche right now that they know and I believe them to be behind. LOB applications are not going away and are safe, so the focus has shifted away a bit from any primary development discussions or new technology buzz. The real purpose of this post was just to provide some idea or insight as to how this new Metro style world will eventually make its way into the larger and broader corporate world and development in the years to come. Just be patient because it will take some time.