All About Interop : .NET

Many many LINQ Providers

DotNetInterop — Fri, 12 Sep 2008 18:28:00 GMT

When LINQ shipped, it included a provider model, to encourage people to make other systems and data stores accessible from the coolness-that-is-LINQ.

Back in February, Charlie Calvert published a long list of LINQ providers. In July, Robert Shelton later reblogged it. Charlie also has a list of LINQ Links. Nice to see. By my count there are 33 different LINQ providers listed. I'll bet there are more by now.

You can also search for more on LINQ providers.

Using the WSDL-First design approach with WCF services

DotNetInterop — Fri, 05 Sep 2008 17:07:00 GMT

Couple of helpful posts from the archives for you.

If you are care about interop, then you probably want to use a contract-first or WSDL-first design for your web services. In other words, you will not simply decorate server-side code annotations (in Java) or attributes (in .NET) and generate WSDL dynamically from that running code. That approach works in demonstrations, but it does not lend itself to good interoperability in the long run.

So you start with WSDL. Since you are WCF-savvy, you are confining yourself to the subset of XML Schema that is friendly to WCF. The restriction isn't too onerous, though, especially as it improves interoperability significantly, and also simplifies your life since you don't have to read and understand all of the XML Schema spec! Ok, so following those rules, you write the WSDL. And then you generate from that WSDL the server-side stub code, and the client-side proxy code, using the web services toolkits of your choice. On the .NET side, that toolkit is obviously WCF (and the tool itself is svcutil.exe); on the Java side, maybe the JAXWS reference implementation, or AXIS2, and so on. But the trick is, the generated code on the .NET side is muy bueno if you write your WSDL following a few additional simple rules, which are not mentioned in the above linked doc.

For example, if you want to pass a collection in your interface, and you will be using WCF on one or both ends of the wire, then you want to use an explicit complexType for the array in the WSDL/XSD. This is not required by WSI Basic Profile, nor is it mentioned anywhere in the official WCF doc as far as I know. Nonetheless, follow this rule for best results. Do not define your arrays with an element and a @maxOccurs="unbounded" attribute in your schema; if you do, you will get the XmlSerializer with WCF, rather than the DataContract serializer, and that is probably not what you want. More on this tip here.

Also, use only one part in each wsdl:message (to comply with WS-I Basic Profile) and set the message part attribute @name = "parameters" to make the messages document/literal wrapped, versus bare. If you're not sure, you want wrapped.

Finally, another tip: when using collections in service interfaces (or more specifically, data contracts), you can use the svcutil.exe tool to specify that collections be represented in the generated .NET code as one of the Generic collection types, rather than a vanilla array. This is done with the /collectionType option on the svcutil.exe command line. See this post for more detail on that idea.

I think there might be a similar codegen hint on other web services toolkits but I could not find the right switch on AXIS2.

Web services interop with WCF - Relevant Forum Questions

DotNetInterop — Thu, 04 Sep 2008 17:45:00 GMT

I was just browsing the WCF forum on MSDN. Here's a summary of the recent interesting threads dealing with interop:

Check it out.

How to Build REST apps on .NET using WCF

DotNetInterop — Fri, 22 Aug 2008 19:03:00 GMT

There's a new screencast series on building services using the WCF part of .NET.

The first few are already available. The first one is the basic "Hello World" example, the next couple cover REST:

How to build a WCF Service using Visual Studio 2008, and .NET 3.5. (10 minutes)

Creating a HI-REST GET Service with WCF 3.5 sp1 (15 minutes)

Consuming a HI-REST GET Service From Silverlight 2 (Beta 2)

How to Shape the URI in REST services built on WCF (See also, the accompanying blog post.)

There will be more to come, too, covering Content Negotiation, Atom, and more. Stay tuned!

Content-Type negotiation and REST (and how WCF fits in)

DotNetInterop — Fri, 28 Mar 2008 23:06:00 GMT

Just had a comment-exchange on my prior post on How to build a REST app in WCF. I thought I would reproduce and elaborate on it a bit here, in a post.

Kyle Beyer asked how to make WCF honor a content-type header (Accept header) in the request, and then modify the result of the REST request based on that header. At least that's what I think he's asking for.

My response is basically this - In REST, the URI dictates the result. Roy Fielding, the guy who coined the term REST in his doctoral thesis, says "all important resources must have URIs." I am no REST expert, but I am inclined to agree with Roy's view on this.

The issue of content-type negotiation within the realm of REST architectures is one that comes up often, but seems to me Fielding has been pretty consistent in saying that such negotiation is problematic and usually not very RESTful. The URI/URL itself maps to a response, including the content type of the response. In practice, you don't have a single URI that maps to a PDF file or an HTML file, depending on the Accept: header. You have two similar but distinct URIs, one for the PDF doc, and one for the HTML. The information within the two documents may be equivalent from a human perspective, but they are two distinct resources. That's the REST model.

If you have as a goal, is to have a single service that supports multiple content types from the same URL, I think that is not very RESTful. At the very least, whether and how REST systems should perform content-type negotiation is not at all settled. Not at all. It would be very presumptuous of Microsoft to embed into WCF and the .NET Franework in general, a model for content-type negotiation in REST exchanges, without first obtaining formal or informal consensus on the matter via some sort of standard or at least agreement on the REST discussion group. That would be a no-no! Not very polite.

This does not discount the validity of the desire - I can see why people would want to have this capability. What I am saying is that the REST approach, specified as it is today, does not encourage content-type negotiation. A reasonable conclusion to the premise that "All important resources must have URIs" is that content-type negotiation just isn't done.

In another spot, Fielding offers

We encourage resource owners to only use true content negotiation (without redirects) when the only difference between formats is mechanical in nature.

So I concede there is a gray area (or is it grey?). Let's look at a practical example: suppose your URI is http://server/Customer/18292 and you design your app so that if there is an Accept header that says "XML", the service delivers an XML doc of the customer data for the customer with ID 18292. That data might include name, address, and so on. If the content-type says "application/x-javascript" then the service delivers a JSON serialization with the same information. And finally if the Accept: header says image/jpeg, the service renders a photo of the customer.

It seems like the first option is allowable - XML to JSON is a mechanical transformation. But the third option (image/jpeg) seems to be outside the bounds of REST philosophy. That's not a mechanical transformation - it's a totally different resource.

Today, WCF doesn't handle the first, the acceptable approach. Today, when you use WCF to build a REST service, you specify the XML or JSON response type, not at runtime but in your application code, at compile time. It is possible to vary the content-type of the response to a WCF request. I'll work up an example of that soon. But the easy path within the WCF REST framework is to NOT do content-type negotiation. The easy part is to stuff the desired content-type in the URI itself. For example. http://server/Customer/18292/jpeg versus http://server/Customer/18292/record . If you think this is a huge issue with WCF, that is to say, you would like a single URI to return different content based on the Accept: header in the request, please let me know. As I said earlier, I don't think we (Microsoft) can unilaterally make decisions on how WCF ought to behave on that issue, but it would be good for us to hear your concerns. An additional option to you is to jump into that REST discussion group and hash this out with the community.

Cheers!

Where were we 3 years ago? "Java apps don't interop with apps built on MS technology."

DotNetInterop — Fri, 28 Mar 2008 21:26:00 GMT

Ha! I wrote recently about the history of .NET Interop in the industry, and how perceptions in the industry have changed so much.

I was looking for some old benchmark code (dirty little secret - I do not use a project management and code versioning system, but the more code I write, and the older I get, the more i need one. . . hmmm, do you think I could get a deal on Visual Studio's Team Foundation Server? hee hee) anyway while I was looking for the old code, I came upon a text file containing an dialogue from an old javalobby thread, from May 2005. I participated in the thread as part of the run-up to JavaOne 2005, in which Microsoft was participating formally, with a booth, and some sessions, and so on (and yes, I was one of the 3 or 4 people from Microsoft who were going to be there.) Here is one part that was written to me. The context was around .NET, and why it is at least interesting to "Java developers" or devs who use Java primarily. I had stated that interop was one key reason that .NET should be interesting to Java devs. Here's what I got back:

I think you're underestimating the size of the wall between MS and the rest of the development community. The MS shops have little interest in interop, because they know it just won't work well. MS doesn't do interop. And the non-MS shops know that too, plus they know that they'd better not get tied to MS products anyway. Java apps interop with other apps from all vendors but MS. That's plenty.

"Microsoft doesn't do interop." Customers "know it just won't work well." Wow. Three short years ago. Also the statement "Java apps interop with other apps from all vendors but MS" - (by which I think he meant "Java apps don't interop with apps built on MS technology." All of this is just nutty.

Here's another excerpt from that thread, where my counterpart in the dialogue attempts to make a distinction between "good interop", which is supported just for interop's sake, and "bad interop", which is supported in order for a company to make money. Put aside for a moment whether that distinction is a valid one.

dubious: I'm singularly unconvinced that [Microsoft] really give a flying fark about true "interoperability," but want to use "interoperability" as a bludgeon to try and increase their market share.

Dino: My real question is, what is the practical difference between "true interoperability" and interoperability pursued for the sake of gaining market share, or revenue, or profit?

dubious: The practical difference is that "true interoperability" really does make things interoperate. To say that Word now lets you save documents in XML, but it's just a proprietary format wrapped in XML tags, that's not true interoperability.

Dino: I'd like to understand this. XML is extensible, right? That means, anyone can define a schema, based on the extensibility rules for XML. Anyone can name their schema, publish it, and then invite others to read and use it. this is what Microsoft did with WordProcessingML, effectively. Or am I wrong on this?
The WordProcessingML that MS-Word can save to or load from - it is a schema defined and licensed by MS. It is RAND today, and also free, but not guaranteed to be free forever. It is undeniably "proprietary" in the sense that MS owns the IP. It is not an OASIS or W3C standard. But it is available for anyone to use, if they agree to the license. [side note: as of 2008, the WordProcessingML has been included in the Open Specification Promise, which as I have noted previously, goes way beyond RAND]

... Is this interop? "True interop"? or is it the other kind, the bad kind?

dubious: Again, I don't know details, so maybe it is true interop, I don't know. But I absolutely will not trust it, even if it is true interop.

This is how things really were. And this was only 3 short years ago. The guy refused to grant one inch on the "Microsoft does interoperability" issue. Even in the face of countervaling facts, he gripped his opinions ever more strongly.

Getting back to the premise, that there is a distinction between "good" and "bad" interoperability... Let me say that I ascribe to the capitalist philosophy. I believe that companies do what they do in order to make more money. A corollary of that is that "interop just for interop's sake" is an idea that no real company pursues. Another corollary is, "it's not bad to make money, by delivering interop." This is just capitalism. So I don't accept the premise that interop can be "good" or "bad".

Thinking about it now, I guess maybe using a thread from a javalobby forum isn't the best example. The forums there are the birthplace of many flamewars. It seems like the participants view it as good sport. Probably safe to assume that the participants there are not representative of the broader development community. But, I will say.. my perspective was that I saw lots more incredulity than was justified around Microsoft interop capabilities , and not just at javalobby.

There's a guy I know, a really bright guy, sharp technologist and a very successful software entrepreneur. He knows his stuff. He cannot believe that I have a Windows XP machine running IIS on the internet. (actually I have several) They have been running for maybe 5 years this way. Even today this guy cannot believe it. He laughs when I tell him. He thinks I'm an idiot. He is certain that the only reason the machines haven't been hacked (ever) is that they haven't been found yet.

But I have the IIS logs that show the machines have been sniffed. I have the urlscan logs that show they get probed regularly. I'm a little hesitant to even *say* "those machines have never been hacked", because it seems like threatening fate. I know that all software is vulnerable, and it's just a matter of time and effort for any machine, any operating system. So I'm not daring anyone, not explicitly anyway, to just go ahead and try to hack my WinXP "servers". But the point is, they have been out there for a long long time, and I haven't had a breech yet.

Some people will never change their minds. They learn something once, and it stays forever. They have write-only storage in their brains. Once they "know" something, regardless how it came to be that they "know it", things don't change. They never re-examine. Obviously this is not a blanket statement. A person can be close-minded about some things and open-minded about others. The software entrepreneur I spoke of, he's learned a ton as he built successful software companies, one after the other. He's open minded about business. But he's not about Windows security. In the same way some people are just not open-minded about interop, regardless what the facts say.

Hmmm, do I sound defensive lately? Maybe my biorhythms are in a downcycle.

The good news is that over time, the skew between the perception and reality on .NET interop capabilities, has lessened. Thanks be to Scott McNealy!

Hanselman survey of web2.0 APIs for .NET

DotNetInterop — Fri, 28 Mar 2008 12:34:00 GMT

Hanselman does a whilrwind tour of the various popular web2.0 systems that have C# or .NET APIs.

In my book, this is all interop.

What makes it all possible? First: cool, interesting, programmable services. I don't have high value scenarios for programming Picasa, or Twitter, but apparently somebody does. And ... Second, .NET is interoperable. It works with XML , with JSON, with HTTP and so on. For those of you who have been using .NET for a while, this is no surprise. In fact it sounds inane to you, that I keep saying ".NET is interoperable" ; But listen, it wasn't that long ago....

All the connections we're seeing these days are beautiful.

A Look back at the History of .NET Interop

DotNetInterop — Thu, 27 Mar 2008 20:49:00 GMT

Check out the last few weeks worth of blog posts here. One on .NET and Google's Social Graph API. Another on .NET connecting to OpenID. Another on JSON, another on JMS.

When I started this blog, there were people out there who knew, they were certain, that .NET apps could not connect to systems built with non .NET technology, or could not connect to systems built with non-Microsoft technology. This was accepted as fact. I spoke with customers daily who accepted this view as the truth. It was looney. I spoke with these people, explained that .NET could connect to the system they had running in their data centers right then, and they did not believe me. The only way I could convince them of what I was saying, was to build the prototypes and proof-of-concept systems. Even then, people were incredulous. When I connected systems together, people looked at me like I had done something mystical. I remember telling people that the XML libraries in .NET supported XML namespaces, and they flatly did not believe me.

How did it get that way? I think mostly because of the dear Scott McNealy and his stagecraft. Remember him? Founder of Sun Microsystems and longtime industry blowhard. He blasted .NET, repeatedly. Every chance he got. There was a brief period when he claimed that the XML that was produced by .NET apps was "proprietary." And the tech press ate this stuff up. It sold magazines. The kind of claims he made - they were so kooky to me, but the press accepted it. This was a billionaire CEO, someone with a ton of charisma, and when he said .NET produced "proprietary XML", nobody bothered to ask "what they hell does that mean?" They just printed it. And then people read it, and believed it. That was reality. So, off to work I went - building prototypes and proving interop was real, and that XML was just XML.

Scott is now out of the picture, I don't know what he is doing now, I'm sure it's something beautiful - do I recall that he wanted to just enjoy his kids? Well, he's earned it. But the fact is, he is not talking, and he is certainly not talking about .NET as a dead-end lock-in technology for Windows-only shops. With McNealy's mouth no longer a factor in the industry, all the little mini-me's also evaporated. All the people that made a living just repeating McNealy's bon mots disappeared, I guess they are now making honest livings somewhere. The demagoguery in general has waned, and now customers believe what they see, rather than what they hear or read. Now when I say that .NET does JSON, nobody stands up and expresses disbelief. It's years now that people have been building .NET systems that connect to everything under the sun. Interop happens. People know it works now.

It's this kind of thing that makes me start to think that a blog dedicated to .NET-Interop, ...ah...maybe it has lived past its usefulness? I mean, come on now. Does anyone doubt interop these days?

Still, though, I find the novel combinations of systems to be intriguing and thought-provoking, so I'm going to continue writing about interop, exploring different angles, building proofs of concept, and so on.

Cheers!

Google Social Graph API via C#

DotNetInterop — Wed, 26 Mar 2008 19:40:00 GMT

Here's something different for a blog that generally focuses on enterprisey technologies. A .NET guy in Denmark built a C# wrapper on Google's Social Graph API. The Social Graph API exposes its data in JSON only; I guess it is designed to be consumed by web pages. This dev put a C# wrapper together that can be used in any .NET app, including in code-behind in ASP.NET pages.

Check it out.

http://blog.madskristensen.dk/post/Build-your-online-social-graph.aspx

How to Build a REST app in .NET (with WCF)

DotNetInterop — Thu, 20 Mar 2008 21:46:00 GMT

My prior post talked about how NOT to write a REST app in .NET. I mentioned WCF as the preferred option. In this post, I'll describe the steps for how you should do it.

Some background

First up, you should use WCF to build your REST app. WCF is the Windows Communication Foundation. (Microsoft has such a strong penchant for creating acronyms, that there are web sites dedicated solely to cataloging them. ) WCF is part of the .NET Framework, first added in .NET 3.0. WCF is used by applications developers when building apps that communicate, whether using REST, SOAP, or something else. These days, most applications need to communicate.

The basic metaphor in WCF is that services receive and respond to incoming communication, and clients initiate those communications. The communication is modeled as an interface in code, and the service is a class or type that implements that interface. Services run within a host on any Windows computer - a desktop, laptop or a big server machine. You can also run services on Windows Mobile devices like smart phones!

Therefore for any WCF app, you need a service interface, a service implementation, and a host.

We'll be building a REST service - an application that receives and understands HTTP GET Requests according to the REST pattern.

No Visual Studio required

Contrary to what you may believe, you do not need to have Visual Studio in order to build .NET applications, including WCF applications. But all of the posts I have seen on the topic assume Visual Studio. VS2008 is the commercial application developer's tool that Microsoft sells; the 2008 version includes some nice WCF design and development tools. It is by far the easiest way to build a WCF app; using VS2008 to build WCF apps also allows you to take advantage of other Visual Studio goodies like unit testing, Intellisense, debugging, profiling, and so on. I highly recommend it. If, however, you just want to get something done quickly and you don't have and don't want to pay for the commercial tool, you can also build WCF apps using a text editor (like emacs), and the command line tools included in the .NET SDK (a free download). In this post, I will show you how.

Hosting a WCF Service

WCF provides various options when it comes to hosting a service. These options are:

"Self hosted" - within a Console or Windows Forms application.
Hosted within IIS
As a Windows Service
Hosted within Windows Activation Service. This option was added with IIS7, available in Windows Vista or Windows Server 2008.

You can read more about these options, and how to choose between them, here.

My Recommendation: Do your WCF Prototype work in a self-hosted app.

If you are developing an application to prototype some ideas, then you probably want the simplest environment possible. This, for me, is often the self-hosted route - it gives me the most control and the lightweight approach I need. Hosting WCF services within IIS can also be a lightweight approach. For this post, though, I'm going to show you how to write a WCF app that is self-hosted in a console EXE. This way you can use the console output as a diagnostic tool while tweaking and tuning the app. You can start it and stop it manually. It's easy and accessible.

There is a nifty WCF Service Host that is included as part of Visual Studio 2008, called WcfSvcHost.exe. This is a Windows Forms app that hosts any WCF service you create. It collapses into the system tray, it's got some nice usability features. On the other hand, (1) I'm presuming no Visual Studio, so you don't have WcfSvcHost.exe, dear reader. And (2), this hosting app doesn't give me the control I want. [In particular, it does not give me control over how to handle errors in the service layer, which is something I really want.]

Rolling your own host for a WCF service is a pretty simple affair. Here's my code to do it.

    1 namespace ionic.samples.WcfRest
    2 {
    3 
    4     // console-based app to Host the WCF / REST service 
    5     public class ConsoleServiceHost
    6     {
    7         public static void Main()
    8         {
    9             string addressRoot = "http://localhost:8080/";
   10 
   11             // get the type we are hosting 
   12             System.Type t1 = typeof(ionic.samples.WcfRest.NorthwindDataService);
   13 
   14             // Create a new ServiceHost to start and stop the service 
   15             // (The URI specified here is used for MEX inquiries)
   16             System.ServiceModel.ServiceHost serviceHost1 =
   17                 new System.ServiceModel.ServiceHost(t1, new System.Uri(addressRoot)); 
   18 
   19             // Create the REST binding
   20             System.ServiceModel.WebHttpBinding restBinding = new System.ServiceModel.WebHttpBinding();
   21 
   22             // Create the REST endpoint.  We need to do this explicitly in order to add a custom behavior to it. 
   23             var restEndPoint =
   24                 new System.ServiceModel.Description.ServiceEndpoint
   25                     (System.ServiceModel.Description.ContractDescription.GetContract(typeof(ionic.samples.WcfRest.IDataService)),
   26                     restBinding,
   27                     new System.ServiceModel.EndpointAddress(addressRoot + "rest"));
   28 
   29             // Add a customm behavior to the REST endpoint
   30             restEndPoint.Behaviors.Add(new ionic.samples.WcfRest.FaultingWebHttpBehavior());
   31 
   32             // Add the endpoint to the service
   33             serviceHost1.Description.Endpoints.Add(restEndPoint);
   34 
   35             // Open the ServiceHost to create listeners and start listening for messages
   36             serviceHost1.Open();
   37             System.Console.WriteLine("Service implementation: " + t1.ToString());
   38             System.Console.WriteLine("The service is ready.");
   39             System.Console.WriteLine("Service Address: " + addressRoot + "rest");
   40             System.Console.WriteLine();
   41             System.Console.WriteLine("Press <ENTER> to terminate the service.");
   42             System.Console.WriteLine();
   43             System.Console.ReadLine();
   44 
   45             // Close to shutdown the service
   46             serviceHost1.Close();
   47         }
   48     }
   49 }

I will call your attention to some highlights there: First, you will see that things like base addresses, service interfaces, and service implementation classes are all specified in code (line 12, 17, 25, etc). This stuff could be specified in config files, and commonly is. But in this case, I am specifying all of it in code. There is no config file required here.

Second, is the use of WebHttpBinding, on line 20. This is the binding in WCF, new for .NET 3.5, that supports REST.

Finally, a subtle bit - notice the custom behavior I added to the endpoint. FaultingWebHttpBehavior on line 30. That behavior gives me the error handling control I mentioned earlier. More about that later.

Ok, that's the host. Now I need the service interface and the service implementation.

The Interface

The database I am using is the Northwind sample database which has been shipped with Microsoft database products for years. My service will simply return information for orders in the database - order date, customer, order contents, shipping address, and so on.

This is a simplistic interface, with just one method. It takes a single parameter as input - the order ID - and returns order information in an XML document. Here's the final product:

    1     [ServiceContract(Namespace = "urn:ionic.samples.2008.03.wcfrest")]
    2     public interface IDataService
    3     {
    4         [OperationContract]
    5         [WebGet(
    6             BodyStyle = WebMessageBodyStyle.Bare,
    7           RequestFormat = WebMessageFormat.Xml,
    8           ResponseFormat = WebMessageFormat.Xml,
    9           UriTemplate = "Northwind/Order/{orderId}")]
   10         OrderInfoMsg GetOrderInfo(string orderId);
   11     }

Things to notice:

Standard WCF-isms like OperationContract and ServiceContract.
The WebGet attribute is new for .NET 3.5, and is the one you want to use for a method that handles REST requests.
The UriTemplate specifies the form of the URI requests this method will be tickled for. Also it does automagic URI-to-method-parameter mapping.

The interface for a service in WCF is exhibited at multiple levels - in code (C# in this case), and on the wire (XML in this case). When doign web services design, a best practice for interoperability is to define the WSDL first, and then implement the services and clients from that WSDL. But REST has no WSDL, and the development style is more rapid iteration. In keeping with that tradition, in my case, I defined the interface in C#, and then iterated on it until I got XML in a shape I liked.

The OrderInfoMsg type, which is the response type I finally arrived at here, looks like this:

    1     [DataContract(Namespace = "urn:ionic.samples.2008.03.Rest")]
    2     public class OrderInfoMsg
    3     {
    4         [DataMember]
    5         public OrderT Order;
    6         [DataMember]
    7         public ApplicationFaultT Fault;
    8 
    9         [DataMember]
   10         public MessageInfoT MessageInfo;
   11 
   12 
   13         public OrderInfoMsg()
   14         {
   15             MessageInfo = new MessageInfoT();
   16         }
   17     }

There are 3 parts to the class - one part contains information about the order, one part to contain information about any fault that occurred on the server side, and a final part to contain generic message information. The fault information is key, because REST doesn't formally specify a way to handle faults, or what they look like. So your REST application has to consider that itself. My approach is to include a way to pass fault information back to the caller explicitly. The MessageInfo part gets filled implicitly, with a timestamp and other information. Think of that as a basic message "dog tags".

I won't show all the code for the other classes. They are just basic Data Transfer Objects.

The Service Implementation

The service implementation is obviously going to be pretty basic. All we need to do is query SQL Server for the order information, and then form an XML document in reply.

Here's where there is some fun involved. We can use LINQ-to-SQL to do the queries and fill the Data Transfer Object. Check the code:

    1   public OrderInfoMsg GetOrderInfo(string orderId)
    2   {
    3       int n = 0;
    4       try
    5       {
    6           n = System.Int32.Parse(orderId);
    7       }
    8       catch
    9       {
   10           return new OrderInfoMsg
   11           {
   12               Fault = new ApplicationFaultT
   13               {
   14                   message = "Bad input, please pass a valid order number",
   15                   code = 11
   16               }
   17           };
   18       }
   19 
   20       OrderInfoMsg oim = null;
   21       try
   22       {
   23           oim =
   24           (from o in db.Orders
   25             where o.OrderID == n
   26             select new OrderInfoMsg
   27               {
   28                   Order = new OrderT
   29                   {
   30                       OrderID = o.OrderID,
   31                       Customer = (from c in db.Customers
   32                                   where o.CustomerID == c.CustomerID
   33                                   select new CustomerT
   34                                   {
   35                                       CompanyName = c.CompanyName,
   36                                       ContactName = c.ContactName,
   37                                       ContactTitle = c.ContactTitle,
   38                                       Phone = c.Phone
   39                                   }).Single(),
   40                       OrderDate = o.OrderDate,
   41                       ShipInfo = new ShipInfoT
   42                       {
   43                           ShipName = o.ShipName,
   44                           ShipAddress = o.ShipAddress,
   45                           ShipCity = o.ShipCity,
   46                           ShipPostalCode = o.ShipPostalCode,
   47                           ShipCountry = o.ShipCountry,
   48                       },
   49                       Items =
   50                       (from od in db.Order_Details
   51                         where od.OrderID == o.OrderID
   52                         select new ItemT { 
   53                             ProductName = od.Product.ProductName, 
   54                             Quantity = od.Quantity, 
   55                             UnitPrice = od.UnitPrice }).ToArray()
   56                   }
   57               }).Single();
   58 
   59       }
   60       catch (System.Exception exc1)
   61       {
   62           oim = new OrderInfoMsg
   63           {
   64               Fault = new ApplicationFaultT
   65               {
   66                   message = "Could not retrieve Order Information. Maybe you passed bad input?",
   67                   innerMessage = "Exception: " + exc1.Message,
   68                   code = 12
   69               }
   70           };
   71       }
   72 
   73       return oim;
   74 
   75   }

Lines 4 through 18 are just validation of the input. The LINQ stuff starts on line 21. Line 26 is where I create the new OrderInfoMsg and the following lines fill that data structure based on information retrieved from the SQL database.

At first that LINQ stuff may look novel and confusing, but it is really a simple way to do database queries. Keep in mind though, that the REST stuff in WCF is not dependent on LINQ in any way. You could create and fill the OrderInfoMsg any old way, including using an old-fashioned DataReader if you like.

But I find LINQ a nice upgrade. At line 49, you can see I fill an array of line items for the order. That's nice, concise, readable code.

In line 62 you can see some error handling, and the use of the object initializers that are new for C# 3.0. Again, nice, clean code.

Where does this LINQ stuff come from?

The LINQ mappings for the Northwind database are defined in a generated C# file, which is not shown here, and which, I confess, I produced using Visual Studio. I know, I know. I promised that VS wasn't required. But I figured that digression was allowed, seeing as how the main point of this post is not LINQ but how to use WCF to build a REST app. You don't need LINQ to retrieve data. It's just a little extra BAM! for you in this sample.

The FaultingWebHttpBehavior

I found that when there was an error in the service, it would return an HTML page to the caller. This has been noticed by others. A fellow by the name of Andre posted code for an endpoint behavior that would prevent the generation of HTML messages. I liked it and used it here. This is the custom behavior I added to the endpoint, in the service host code, shown above.

    1 namespace ionic.samples.WcfRest
    2 {
    3     /// <summary>
    4     /// A <see cref="WebHttpBehavior"/> that returns error messages to the caller 
    5     /// when an exception occurs on the server/service. 
    6     /// </summary>
    7 
    8     public class FaultingWebHttpBehavior : System.ServiceModel.Description.WebHttpBehavior
    9     {
   10 
   11 
   12         protected override void AddServerErrorHandlers(System.ServiceModel.Description.ServiceEndpoint endpoint,
   13                                System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
   14         {
   15             endpointDispatcher.ChannelDispatcher.ErrorHandlers.Clear();
   16             endpointDispatcher.ChannelDispatcher.ErrorHandlers.Add(new ErrorHandler());
   17         }
   18 
   19         public class ErrorHandler : System.ServiceModel.Dispatcher.IErrorHandler
   20         {
   21             #region IErrorHandler Members
   22 
   23             public bool HandleError(System.Exception error)
   24             {
   25                 return true;
   26             }
   27 
   28             public void ProvideFault(System.Exception error,
   29                         System.ServiceModel.Channels.MessageVersion version,
   30                         ref System.ServiceModel.Channels.Message fault)
   31             {
   32                 System.ServiceModel.FaultCode faultCode =
   33                   System.ServiceModel.FaultCode.CreateSenderFaultCode(error.GetType().Name,
   34                                               "urn:ionic.samples.serviceexception");
   35                 fault = System.ServiceModel.Channels.Message.CreateMessage(version, faultCode, error.Message, null);
   36             }
   37 
   38             #endregion
   39         }
   40     }
   41 }

The REST messages

The request looks something like this:

    1 GET /rest/Northwind/Order/11049 HTTP/1.1
    2 Accept: */*
    3 Accept-Language: en-us
    4 UA-CPU: x86
    5 Accept-Encoding: gzip, deflate
    6 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;)
    7 Host: dinoch-2:8080
    8 Proxy-Connection: Keep-Alive

Obviously, any application on any computer can generate that sort of request. I used an IE browser, but it could be anything, and in a real REST app it won't be just a browser.

And the response looks like this:

    1 HTTP/1.1 200 OK
    2 Content-Length: 1189
    3 Content-Type: application/xml; charset=utf-8
    4 Server: Microsoft-HTTPAPI/2.0
    5 Date: Thu, 20 Mar 2008 20:34:59 GMT
    6 
    7 <OrderInfoMsg ...>

The prettified XML looks like this:

    1 <OrderInfoMsg xmlns="urn:ionic.samples.2008.03.Rest" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
    2   <Fault i:nil="true"/>
    3   <MessageInfo>
    4     <ApplicationId>319a80e4-3e64-4328-a5d1-468b354c370a</ApplicationId>
    5     <ApplicationName>WcfRestService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null</ApplicationName>
    6     <OkToStore>true</OkToStore>
    7     <generated>2008-03-20T13:34:59.3459363-07:00</generated>
    8     <originatingHost>dinoch-2</originatingHost>
    9   </MessageInfo>
   10   <Order>
   11     <Customer>
   12       <CompanyName>Gourmet Lanchonetes</CompanyName>
   13       <ContactName>André Fonseca</ContactName>
   14       <ContactTitle>Sales Associate</ContactTitle>
   15       <Phone>(11) 555-9482</Phone>
   16     </Customer>
   17     <Items>
   18       <Item>
   19         <ProductName>Chang</ProductName>
   20         <Quantity>10</Quantity>
   21         <UnitPrice>19.0000</UnitPrice>
   22       </Item>
   23       <Item>
   24         <ProductName>Queso Manchego La Pastora</ProductName>
   25         <Quantity>4</Quantity>
   26         <UnitPrice>38.0000</UnitPrice>
   27       </Item>
   28     </Items>
   29     <OrderDate>1996-05-24T00:00:00</OrderDate>
   30     <OrderID>11049</OrderID>
   31     <ShipInfo>
   32       <ShipAddress>Av. Brasil, 442</ShipAddress>
   33       <ShipCity>Campinas</ShipCity>
   34       <ShipCountry>Brazil</ShipCountry>
   35       <ShipName>Gourmet Lanchonetes</ShipName>
   36       <ShipPostalCode>04876-786</ShipPostalCode>
   37       <ShipRegion i:nil="true"/>
   38     </ShipInfo>
   39   </Order>
   40 </OrderInfoMsg>

Clean, simple, easy.

But wait! There's more! What if you don't want XML but want that data in JSON? A simple flip of an attribute in the Service definition gives us this as a response:

    1 {
    2   "Fault":null,
    3   "MessageInfo":{
    4     "ApplicationId":"319a80e4-3e64-4328-a5d1-468b354c370a",
    5     "ApplicationName":"WcfRestService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null",
    6     "OkToStore":true,
    7     "generated":"\/Date(1206047182582-0700)\/",
    8     "originatingHost":"dinoch-2"
    9     },
   10   "Order":{
   11     "Customer":{
   12       "CompanyName":"La maison d'Asie",
   13       "ContactName":"Annette Roulet",
   14       "ContactTitle":"Sales Manager",
   15       "Phone":"61.77.61.10"
   16       },
   17     "Items":[
   18       {"ProductName":"Guaraná Fantástica","Quantity":10,"UnitPrice":4.5000}
   19     ],
   20     "OrderDate":"\/Date(833180400000-0700)\/",
   21     "OrderID":11051,
   22     "ShipInfo":{
   23       "ShipAddress":"1 rue Alsace-Lorraine",
   24       "ShipCity":"Toulouse",
   25       "ShipCountry":"France",
   26       "ShipName":"La maison d'Asie",
   27       "ShipPostalCode":"31000",
   28       "ShipRegion":null
   29       }
   30     }
   31 }

Pretty nifty, eh?

That's how to write a REST app in .NET.

Where are we?

Well, I hope I've shown you a couple things here. First, it's easy to use WCF to build REST apps, using the .NET Framework 3.5. Second, you can build WCF apps with free command line tools. Finally, LINQ is cool, and is a nice complement to REST approaches.

Grab the source code attached here and try it yourself.

How to build a REST app in .NET (not)

DotNetInterop — Tue, 18 Mar 2008 16:23:00 GMT

This post by Jack Altiere describes how to build a REST API in .NET. This spurred a respose...

Firstly, I think really he is talking about a REST interface, not an API. REST is all about the interface. Maybe I am splitting hairs here, but I think it is important to be careful about terminology.

My main respoinse is this - use .NET 3.5 and the REST capabilities included as part of Windows Communication Foundation. I respect the enthusiasm in the blog post, but the thing is, most devs don't want just a REST interface. They want a service, and they want it to be accessible in various ways. REST is one of those ways. They want it to be easy to handle parameters. They want auditing and logging. They want an easy way to map URIs to methods. The .NET Framework v3.5, released in November 2007, gives developers those capabilities. Sure, you can roll your own REST Framework for .NET, but why would you?

-D

Get Smart on WCF

DotNetInterop — Mon, 17 Mar 2008 20:20:00 GMT

Joe Stagner posted a good list o links for learning WCF. A good first stop on your journey.

http://www.joeon.net/post/2008/03/windows-communication-foundation---65-links-to-make-you-an-expert!.aspx

SAP Enterprise Services Explorer for .NET (Visual Studio) does WCF

DotNetInterop — Mon, 17 Mar 2008 17:07:00 GMT

via http://dedjo.blogspot.com/2008/03/localization-fix-for-sap-esa-explorer.html

SAP just released a sneak preview of an add-in for Visual Studio 2005 that they call "SAP Enterprise Services Explorer for Microsoft .NET ". It feels like a misnomer to me, because it's not for .NET, which is the name of the programming framework. It's for Visual Studio, which is the name of the tool. But lots of people use those names interchangeably, I take it. So there you have it.

Based on my read, the tool allows a developer to query the SAP Service Registry, and then generate, for .NET applications, web services proxy classes, that enable .NET apps to connect to the services. There are some nifty query capabilities for accessing the service registry. And, the generated proxy is a WCF client. That's what I like to see.

Not sure if this also works in VS2008.

here's the link: https://www.sdn.sap.com/irj/sdn/dotnet

Worth checking out!

Sudoku Generator and Solver in C#

DotNetInterop — Sat, 15 Mar 2008 01:41:00 GMT

Seems like building a Sudoku application is almost a compulsory thing for programmers these days.

I've written about my prior efforts. Here's an update. Rather than force you all to use the XBAP I published last year, here's a standalone WPF app. C# Source and EXE include.

It uses the DLX (Dancing Links) algorithm from Donald Knuth.

Pretty speedy. It is a WPF app, but there are no fancy WPF graphics. It just generates a table, and that's about it. This one is handy if you like to do Sudoku on paper. I've uses this app to generate and print out puzzles that I can do with my kids.

Source: http://cid-842434ebe9688900.skydrive.live.com/self.aspx/Games/Sudoku-1.0-source.zip
EXE: http://cid-842434ebe9688900.skydrive.live.com/self.aspx/Games/Sudoku.exe

Cheers!

JNBridge Interview on Channel9

DotNetInterop — Wed, 05 Mar 2008 02:39:00 GMT

Kirk Evans of Microsoft interviewed Wayne Citrin of JNBridge, the Interop company.

Check it out on Channel9.