My current employer recently requested some practices for exposing interfaces hosted on BizTalk Server. This advice was destined for some new BizTalkers who were looking at WCF, HTTP, and SOAP adapters for the first time. So many ways to skin a cat. My initial response was simply recommend they use the tool of best fit. i.e. in the case of SOAP as with any technology ask why am I using SOAP. Ask do I need SOAP? Who will be consuming my interfaces and more importanly from what platform? etc…
If speaking generically I would have to lean towards the native HTTP adapter, and that comes from cold hard experience in the trenches developing from both the apps and BizTalk side of the fence.
- Simplified client side code. i.e. no ugly auto generated client side proxy to contend with
- No having to regenerate the SOAP proxy web service on the BizTalk Servers each time the data contract changes
- Compatibility/Interoperability. Even though Java and .NET are meant to work together nicely I’ve had real world issues in the past with SOAP. No such problems when talking plain HTTP
- Service definition is somewhat obfuscated. This is almost a point that can be equated to why use a Restful service. Basically a HTTP receive location hides its purpose. i.e. we’re just doing a HTTP PUT and GET for a blob of data. By looking at the service endpoint its difficult to understand what the service does, which is a good thing when exposing the service externally.
So in my experience pushing messages via raw HTTP provides for a much simpler and hassle free interface. Its a bulldozer of a solution. Plain, simple, hassle free, and it works. Not a bad interview question really.