I wanted to post my experiences with WebInvoke using generic DataContract's as parameters, because I found so little information on the subject via MSDN and throughout the interweb. Specifically, on how to properly formulate a non WCF client XML POST request in this scenario. I will not be focusing on how to host and configure the service (creating REST based services and endpoints in WCF), since I found plenty of information available in that area via blogs and msdn documentation.

Lets start with the following service contract and corresponding data contract types:

See code at http://chriskirby.net/archive/2008/01/18/building-a-raw-xml-request-for-a-restful-wcf-service-operation-which-accepts-a-generic-datacontract-type.aspx

As you can see above, the operation CreateBlogPost on the service contract IBlogService returns a boolean and accepts the type BlogCreateRequest<BlogPost> as its input. To the outside world via wsld or IMetadataExchange, the operation CreateBlogPost accepts schema type BlogCreateRequestOfBlogPost with a default namespace of http://chriskirby.net/examples/blog, however, the Data property is of schema type BlogPost with a namespace of http://chriskirby.net/examples/blog/data. To formulate the request properly, you need to make sure each node in the xml request is of the correct namespace, otherwise the DataContractSerializer will not recognize you request on deserialization, and WCF will return a 400 error (Bad Request). I've also used several notable DataContract and DataMember properties in order to control how the type looks to the outside world (serialized). On the BlogCreateRequest generic class I specified the name of BlogCreateRequestOf{0}, which in this case translates to BlogCreateRequestOfBlogPost. If I chose not so specify the name using the placeholder, the DataContractSerializer would serialize the type with a name like BlogCreateRequestOfBlogPost4sdop, where the suffix is comprised of a series of random characters to ensure that the type has a unique name. However, I know that my service will not use any other types by that name, so I can safely specify it for ease of used to the client. I also used the Order property, which is pretty self explanatory, it simply ensures that the serializer will use the same order I specified in my class definition. Finally, I decorated the Tags property on BlogPost with the CollectionDataContract attribute which allows me to specify how I want the collection formatted by serializer, e.g. <Tags><Tag/><Tag/></Tags>.

Formulating the request:

See code at http://chriskirby.net/archive/2008/01/18/building-a-raw-xml-request-for-a-restful-wcf-service-operation-which-accepts-a-generic-datacontract-type.aspx

The tricky part here is really just understanding how the DataContractSerializer works... which now, after hours of debugging, I now have a much better understanding of. The key points of understanding for me were discovering how to assign the correct namespace to the corresponding node as well as figuring out how the serializer organized generic types, specifically my generic type CreateBlogRequest<>. During your first glace at the service and data contract code block, you may have thought as id did in that the Data property/element would be in the http://chriskirby.net/examples/blog/data namespace, since it is in fact of type BlogPost...however, the Data property is first an foremost a part of the BlogCreateRequest type, so it must be a part of the class namespace and not the namespace of its generically assigned type. My second, and ultimately incorrect thought, was that the structure would look like <Data><BlogPost><Title/>....</>. But after careful thought, that would mean Data would be of a type which had BlogPost as a member, which is not the case here. Its also worth noting there are several other ways of formatting the xml request to get the same result. The most common would be to declare both namespaces in the root element and assign them prefixes, you would then use those prefixes to denote the namespace in each element in the document.

So there you have it...The simple and sometimes complicated power of WCF. I look forward to many more headaches adventures in the near future.

The wait is over, and I still can't wait! The only issue I'm going have with the upgrade at this point is that Fortress is not going to support 2008 integration until version 1.1/4.1, which unfortunately is still several weeks out according to their support site. At least the folks at Jetbrains were on the ball...resharper already has experimental support for us immediate adopters.

To comment, visit my site chriskirby.net

Visit my main blog at dotNetWookie.com

Evidently, when MySpace isn't taking away the privacy if its users its busy building some serious .net web apps. According to Scott's post, their running asp.net 2.0 and IIS 6 to process their ridiculous amount of traffic. He also mentions that they will be implementing some Atlas stuff down the road, so i will be really interested to see how that preforms on a site on a site that gets more traffic than Google and MSN combined.