Santosh Benjamin's Weblog

Adventures with AppFabric, BizTalk & Clouds

Contract First BizTalk – What’s Missing?

with 5 comments


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.

Advertisements

Written by santoshbenjamin

May 3, 2010 at 10:22 PM

5 Responses

Subscribe to comments with RSS.

  1. Couple of things on my side :
    – consuming REST is still a pain (especially verbs other than GET)
    – I’ve given up being WSDL first with Biztalk, too much plumbing to do. One thing that would be great would be if we could author a service using WCF and have a simple api (one way, and two way) to submit messages into Biztalk easily (like a simple, limited in-process adapter). I guess you could do it today but not sure how easily.

    Christian Dubé

    May 4, 2010 at 1:44 PM

  2. Thanks Christian. A REST adapter would be cool. I think that’s going to come up more often now especially if we want to integrate with Azure Access Control Service and so on. For the service bus, the custom WCF bindings are usable via the WCF Custom Adapter so maybe there’s not much work to be done in that area. Re: in-Proc adapter, In v2004, there was a ‘Submit Adapter’ sample that submitted messages into the message box. I haven’t paid attention to the latest samples so not sure if that’s still around, but yes, I agree, it would help to have something like that so we could write our own WCF services and just leverage the in-proc adapter to do the rest.

    santoshbenjamin

    May 4, 2010 at 6:12 PM

  3. I agree and furthermore believe that contract-first with BizTalk is not practical. I’ve written about it a while ago (http://geekswithblogs.net/paulp/archive/2006/04/18/75536.aspx) in response to Richard’s post. And I still think not much has changed since then. Some might think wrapping adapters in new shiny WCF coat is a big deal. It is but not for this problem. For example, in the SQL communication the table definition or stored procedure is the contract that will dictate message and service schema. Although generated schemas became more consistent they are still cubersome to manually edit and wizards are pain to deal with when doing small iterative changes to contracts.

    Paul

    May 17, 2010 at 9:37 PM

  4. I agree on the pain points mentioned earlier.

    Would be nice if we could leverage the new release of the service factory( http://servicefactory.codeplex.com/ ) for doing Contract First development with Biztalk.

    Mark

    May 31, 2010 at 11:16 AM

  5. +1 on the Service Factory idea Mark. I’ve thought about that for a while. If a community project is the way to go with this, then perhaps thats worth looking into. Also, In WSCF Blue we’ve worked out some WSDL parsing code that can handle multipart WSDLs and give the consumer a flat container of metadata to work with so perhaps that can be leveraged to generate BizTalk projects, orch stubs and so on.

    santoshbenjamin

    May 31, 2010 at 3:19 PM


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: