Contract First BizTalk – What’s Missing?
Although BizTalk is in many respects ‘contract driven’ (with the emphasis on first setting up the XSDs for the messages etc), WSDL First development has, IMO, always been a bit ‘iffy’. The purpose of this post is two-fold. One is to (re) start the discussion around Contract First development with BizTalk and the other is , through the discussion, to get a list of pain-points that I can go back to the product group with via our field channels and which would be of use to them in planning features for the next versions. I’m hoping that even if we cant get these into the core product, we could at least influence and/or help set up a CodePlex project to provide some of the missing ingedients.
In v2004 (and 2006 R1) absence of support for Contract First was a huge shortcoming because we couldnt even import a WSDL let alone round-trip it while maintaining fidelity to the original. With the advent of v2006 R2 and the WCF adapters, to some extent things are better. At least we can now consume WSDL or MEX endpoints.
However, Contract First isnt just about importing WSDL. The round-trip experience and being able to maintain fidelity to the original is critical, especially in interop scenarios. While we cannot always expect service consumption and publishing to be single-click / push button, IMO, there’s currently far too many steps involved in building a provider or consumer that adheres to a supplied WSDL (and this is assuming you manage to coax it into rendering the WSDL exactly as you want). Added to this, in the WCF world you also have to consider how you will handle strong typed SOAP Faults (when your client demands that you throw them). My esteemed colleague, Paolo Salvatori has a blog post describing how to add endpoint behaviors to a service to dynamically modify the WSDL exposed and to extend operations with fault messages. Ironically, I see this is part of the problem, namely, having to dive into so much custom code . Sure, its typical WCF, but hey, this is BizTalk, we are supposed to make the hard things easier.
The implementation of the tooling also leaves much to be desired. I don’t know of any people who still use Web Site projects as part of their automated build. Once the novelty wore off in the early days of VS2005, and once web apps came back in VS05 SP1, pretty much everyone went back to them. However, the Web Service and WCF Service publishing wizards still insist on generating website projects and there is no way to customize that to use your own template (has this changed in v2009 ?). While there is a command line tool to automate WCF service publishing, you cannot publish schemas as web services with that nor is there a command line interface (AFAIK) to automate consumption of WSDL/MEX endpoints.
Another problem I found is that Schema web services are great for one way messaging (especially when you can use direct binding so you dont have to tie an orchestration to the receive location) but if you want to expose a request/response operation, then you cant just use direct binding because the response doesnt make its way back to the required location. I read somewhere (could have been Yossi’s blog) that this is because the EPM demotes some properties. So you are forced back into an orchestration and static binding to the port. It’s not a big problem, after all the orch can be just a facade/shim, but it still feels a little dirty.
Ok, I hope that didnt come across as too much of a rant. I would like to hear your thoughts on the subject. Have I gone way off base anywhere ? Do you run up against the limitations of BTS in the Contract First (specifically WSDL First) world? What’s missing in the tooling? What should the product group (or a tool provider) be looking to supply to make things better. Do post your comments and let me know. Hopefully we can get enough consensus and ideas to provide the product group with valuable information. Let’s discuss.