Tagged with Web Services
I started writing services in websites back in the .NET 1.0 days. Originally I was doing just POX (Plain Old XML) services in a very crude way so we could get the job done for our internal systems back in the early 2000's.
This means I've been through the "new tech" crazy with services for a long time. I've spent much of the last year digging into different tech for services to interact with websites (though many of the same issues are for rich clients and IoT). I'm not done and don't know how right my assumptions are yet, but I thought I'd try to start a conversation.
While I've lived through POX, SOAP, and REST...I don't think this is another wave. I think this is a widening of options for services. But what does the service ecosystem look like right now? (Caveat: I'm going to miss your favorite idea, so feel free to add to the discussion below.)
So as some of you know, I’ve spent a lot of the last year working on a web project. I’ve been using ASP.NET MVC3 and it’s going well. I am at the point where we are creating the mobile apps. I service them, I need an API (which will eventually be available as a public API too). I had started creating using MVC and simple routes but I was urged to look at the new Web API stack that is installed with the new ASP.NET MVC4 installer.
Adding WebAPI to your Project
If you're a regular reader of my blog, you'll probably remember my pithy blog post where I stated that "It all depends..." to the question "Which Data Access Should I Use for Silverlight 3?" The reality is that much like the similar question I am confronted with at user groups for the past decade ("What data access should I use in my .NET app?"). The reasons for picking a strategy are wide and varied so I will not try to analyze all possible outcomes, but I think the different strategies need to be explained better.
The three major candidates in Silverlight 3 are Web Services (WCF/ASMX), ADO.NET Data Services and RIA Services. In any situation, any of these will work. But they are suited to different styles and requirements. Here's the abridged differences between the stacks:
Let's dive deeper into explaining these differences and why that might matter.
The goal of Project Niagara is to democratize the validation support. The project wants to help developers add validation support to ADO.NET Data Services as well as Web Services in Silverlight. In addition, it has the goal of allowing multiple ways to supply the validation metadata to the different data access strategies. As it is my opinion that there are scenarios where attributes are not the best idea.
The deliverables for this project will include:
I was trading tweets today with @pauliom about whether RIA Services would solve some Auth problems he was having out of the browser. While RIA does do some interesting things with roles/users, I mentioned that typical Forms Auth out of the box should just work.
To that end I have created a simple example of how to protected WCF Services with Forms Auth (works with ADO.NET Data Services as well BTW). Because I wanted to support it out of the browser as well, I used the new Forms Auth service. To do so, just add a new .svc file to your project and put this in the body:
I just saw that John Papa's excellent book ( Data-Driven Services with Silverlight 2) is now available for an impressive 40% off. If you are doing Silverlight, I recommend you get this book. I tech-reviewed the book for John and think he's got a winner on his hands. It covers how to do server communication of all sorts with Silverlight. The Promo Code DD224 for 40% off the cover price. Offer expires 2/19/09. It is good for the print or the e-book version of the book.
If you missed me in Bulgaria's DevReach conference, the video of my Silverlight Data Access talk is now available. The original talk's description was:
In this session, we will explore the different methods for dealing with data in your Silverlight 2 applications including LINQ, ASMX, WCF, REST, Astoria and WebClient calls. The session covers both how to consume data as well as how to expose data to Silverlight 2.
After reading Rocky's blog about DataSets and Web Services, I am afraid that he is falling into the same trap that other's have (including the emminently qualified Tim Ewald) with respect to DataSets. DataSets work well in Web Services but not by default. As I mentioned in:
When I first read the SOAP specification I could not decide whether it was meant to be a replacement for DCOM/RPC or whether it was a messaging protocol. I loved the fact that the ligua franca of SOAP was XML. But at the same time, Section 5 supported the RPC view of SOAP. Unfortunately this section seemed to just confuse the issue between the RPC world and the document/literal world.
In a great MSDN Article, Tim Ewald argues against support for Section 5 support. I guess I haven't been keeping up, but I am excited to hear that Section 5 support is now optional in SOAP 1.2 specification. Yeah...but will Section 5 really ever die?
As I started playing with .NET's Web Services Framework some years back, I was excited and dishearted at the same time. It supported doc/literal by default, but it seemed to want to hide the fact we were using XML in any fashion. How unfortunate.
I just attended the second day of Chris Sells' and Tim Ewald's great Web Services DevCon East and had a great time. Yasser Shohoud gave a wonderful talk on "The Right Way to Build Web Services". He echoed something I have been thinking of for some time. Sure, I didn't want to learn how to write WSDL. At the same time I know that the WSDL that is generated by using the '?wsdl' syntax of ASP.NET's .asmx files does not let me design the interface first. I changed my mind and learned to write WSDL. WSDL really isn't too difficult to write. It is too bad that we cannot disable the ?wsdl syntax and just use a static WebService.WSDL URL to have our customer's get our WSDL files.
My natural inclination is still influenced by my days developing COM components in ATL. I want to define the interface up front like we did with IDL. In the early days of ATL, I had been doing MFC work and did not want to hand-code my own IDL either. You would think I would have learned by now that by starting with interface is the better development model. By writing our own WSDL we can define our interfaces (both the calling convention and the schema of the message) and run WSDL.exe to build a skeleton class for us to implement the service.
Unfortunately .NET just makes it much too simple to annotate the Web Service's methods with [WebMethod] and let the XML Serialization do all the rest. I am hoping we all remember the heartache we suffered the first time we did this in Visual Basic or MFC back in the COM days.
Why is everyone so down on using DataSets in .NET Web Services? Sure, I’ll admit that using DataSets directly as Web Service parameters are indeed a problem. But why throw the baby out with the bath water?
For the uninitiated, DataSets are a problem as Web Service parameters because XML that is automatically generated as the parameter is a DiffGram of the DataSet. Unfortunately DiffGrams are simply not interop-friendly. At the end of the day the obvious use of DataSets in .NET Web Services are simply a bad idea.
But if we deal with DataSets as XML instead of a class to be serialized we can actually achieve some real benefits. If you have experienced DataSets, you know that you can specify an .xsd as the schema of the DataSet. What that means is that you can deliver the contents of the DataSet with relevant schema as an XML document. Since the resulting XML document can refer to a specific schema, the consumers of the Web Service (whether they are using Java, WebSphere, or .NET) will receive a self-describing, strongly typed piece of information.