Integrating to the max...BizTalk Style

For my project I needed to expose an Endpoint, which accepts an HTTP Post with Xml as input/output. As I like to start small I’ve tried to start with a small test project. In this project, I wanted to learn how to expose an endpoint, how to set everything up and what options are there. This, because there are a lot of resources on all sort of specific issues, but the ones I faced were scattered in several blogposts. So for my project I developed a WCF Service, which was created using a WCF Webrole so that I can also publish it in Azure. ·          Create a new WCF Webrole o    Create a new Cloud service o    Create a new web role o    Which should result in a similar structure ·          Configure the endpoint to use WCF-WebHTTP and allow a help page At this point, you have a WCF Service, which is not yet exposed a WCF-WebHTTP endpoint. We can do this by: o  ...

  The WCF-WebHTTP is designed to support REST , with support for the verbs GET, POST, PUT, and DELETE. We can use the POST verb to replace the HTTP adapter functionality, and use WCF custom behaviors to tailor the adapter to our needs. This post explains how I migrated the HTTP adapter and why I decided to look at this approach. This should give a summary of how to do this. Problem with the HTTP Adapter 1) Error handling The BizTalk HTTP adapter hides away the logic of HTTP status codes, thus an error is handled in the adapter. Returning a custom error in a request response call, which calls a solicit-response HTTP port is therefore quite challenging, and at this moment I have not found a way to do this, except abandoning the Messaging only approach. 2) Flexibility The HTTP adapter is somewhat limited in functionality, yes you can use a custom pipeline, client/server certificate authentication and stuff, but adding custom behavior is limited; HTTP vs WCF-WebHTTP Adap...