When will then be now? Soon...
Dark Helmet and Colonel Sanders, Sbaceballs

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.

Dear original 360 owners, if you have a pre hdmi Xbox 360, then your console is basically a ticking time bomb that will die at any time. Fortunately for me, it lasted just over 1.5 years before it finally fried. All it took was a 6 hour session of guitar hero III for mine to experience the warning signs (consistent game freezes) and finally detonate. Nearly everyone I know with a 360 lately has had the same issue...which can probably be attributed to the latest crop of games exploiting the full horsepower of the console. The one good thing out of the whole experience is that Microsoft will still repair this particular issue free of charge, in or out of warranty; which, in my opinion, is their rightful obligation to do so. Also, on the upside, it only took a total of 2 weeks (1 week just to get the box) to receive the repaired unit back...which was considerably faster than the estimated 6 weeks. And they threw in 1 month free of Live Gold, which was a nice bonus. Though, I had already purchased a new Elite, since I am the Zen master of patience...so time was less of an issue for me. If you do have a pre hdmi 360, don't bother with the cooling units either. Most forums on the subject suggest that using a cooling unit may even have the opposite effect causing additional strain and possibly voiding the warranty.

To comment, visit my site chriskirby.net