Optimizing Windows Azure Services using WCF, REST and JSON

When XML was first proposed it must have been a spoof.  The problem is, nobody got the joke.  Let’s say we had a database of pets and we wanted to export some data.  One choice could be a comma-separated file.  The data might look something like this:

The first row is for the headers.  If someone decided to repeat the headers before every row, everyone would think they were crazy.  The genius of XML is not that the headers are repeated with every row.  Rather the headers are repeated with every row twice.  Here’s the same data as XML:

For more evidence the XML people were joking, look at the namespaces in the screenshot above.  I’m sure there were two guys in a bar one night trying to figure out what crazy thing to suggest next and one said, “Hey, let’s tell them namespaces should be written in the form of URL’s”.  Then the other guy laughed and said, “Yeah, and we’ll call them URI’s.  That would confuse everyone!”.  They had a good laugh, ordered another round and since then the rest of us have been confused.

When moving to Azure, we’re likely to create services using WCF.  WCF is infested with XML.  It is used for data transport, for service description and for configuration.  Configuration in XML, that’s another good one.  Luckily, we can get rid of it all.  Let’s see how.

To get rid of the configuration, in Visual Studio right-click on the service and select View Markup.  Then add the code that is highlighted in the screenshot below:

Now the service configuration can be deleted from the Web.config file (no joke).

Next use a different transfer format.  It would be too old-fashioned to use CSV, so we’ll use Json.  To do that, add the [WebGet] attribute to the service methods as shown below.  Notice the ResponseFormat property is set to Json and the return type is just a generic List of Pet objects.  That’s it.

Below is what the Json data looks like:

Now the headers are only sent once with every row 🙂

At the client we don’t need any configuration either.  Just invoke the service via Http.  The code sample below is from a Silverlight application, but any application that can make an Http request can call the service.

Consuming the Json is easy thanks to the DataContractJsonSerializer class in .NET.  Check out the code below.  Just take the response and convert it back into Pet objects at the client.  There’s no WSDL, no SOAP, no service references, no proxies or client configuration.

Getting rid of the XML makes services more efficient, easier to write and easier to use.

The only downside I can think of is fewer billable hours.  For consultants like me, that might be a big problem.  Hey, come to think of it, maybe they weren’t joking after all.

We cover this and lots of other cloud-related coding in Learning Tree course 2602: Windows® Azure™ Platform Introduction.

Doug

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.