Interview Series: Four Questions With … Alan Smith

Last month I started a new blog series where I interview a different “connected systems” thought leader each month and get some insight into their experiences and thinking in our space.  Our first victim/subject was Tomas Restrepo. We continue the series by chatting with everyone’s favorite Swedish BizTalker, Alan Smith.

Q: You spend a healthy amount of time facilitating the MSDN BizTalk R2 forums. What are some common assumptions or misunderstandings about BizTalk Server that you frequently see questions about?

A: There are quite a few people asking about using BizTalk for heavy database integration, taking flat files, inserting the data in databases and processing it. SQL Server Integration Services (SSIS) does a much better job than BizTalk at this, and is worth looking at in those scenarios. BizTalk still has its uses for that type of work, but is limited be performance. The worst case I saw was a client who had a daily batch that took 36 hours to process using BizTalk, and about 15 minutes using SSIS. On another project I worked on they had used BizTalk for all the message based integration, and SSIS for the data batching, and it worked really well.

Another common one is with mapping, there’s a lot of scenarios where replacing the map with custom XSLT is the easiest solution to solve the problem. People can spend days torturing themselves with functoids without getting the problem solved. A lot of questions appear on the forums where custom XSLT is the best solution. This picture says it all. With some scenarios the mapper is great, but with others custom XSLT can be easier to write and debug, and results in much more efficient code. The XSLT IntelliSense and debugging features in Visual Studio 2005 make it very easy to code and test. I really should get a webcast on custom XSLT published, it’s been on my to-do list for a while.

Lastly, there seem to be a lot of people who are using BizTalk Server 2006 R2, and use the SOAP adapter for consuming and publishing web services. If you can, try using the WCFBasicHttpAdpater for this, as it has so much more options for configuration, and it seems to work much better.

Q: You’re probably most famous for producing the invaluable “Bloggers Guide to BizTalk” that many of us used in those early BizTalk 2004 days as we harvested knowledge from everywhere possible. What’s the status of this resource?

A: Back in the day, when BizTalk 2004 was in beta, the blogs and the forums were where you leant about how stuff worked. The early BizTalk documentation was not that great, there were no books available, and I had several people tell me they used the guide more than the documentation. Now things have changed and we have pretty good documentation, good courses, and some great books, so the guide is not as relevant as it once was. I have just released a Version 2.0 of the guide, and will make updates if people are downloading it a lot.

I’ve already started work on “The Bloggers Guide to Oslo”, there’s not that much content yet, as anyone who knows anything is sworn to secrecy though an NDA, but after PDC in November this should change. I think after the details of Oslo have been announced publicly at PDC it will be similar to the early days of BizTalk 2004. There should be some great contributions from the development community and this will probably be the best source of information for those learning the technology. I’m looking forward to it already…

I’ll be hosting both of these guides, at http://bloggersguides.net/. I recently launched this site to provide a permanent location for the guides along with webcasts and samples related to those technologies.

Q: As you’ve grown in your understanding of connected systems, are there common patterns that you frequently reuse, and conversely, patterns (or anti-patterns) that you purposely avoid?

A: Most of the patterns and practices I use tend to be related to the development process. Automated deployment, automated testing, and a good project structure and naming conventions should be used in every project. As for messaging patterns, the “Enterprise Integration Patterns” book is the best resource, BizTalk Server provides quite a few of those patterns out of the box, and makes it very easy to implement other patterns.

One thing I would avoid would be passing every message through an orchestration. Some projects I have seen use this as a pattern, and it adds complexity to the solution, and an overhead in processing. Another one to avoid is publishing services using BizTalk that will be consumed by user interfaces. In some scenarios it can work, but you have to be aware of the latency issues and how to tune BizTalk for low latency.

Q: Nearly everyone has that silly or embarrassing song that they sing along with in their car with the windows rolled up. I will freely admit that when Bon Jovi’s “Living on a Prayer” comes on, I get stuck on stupid. Expose your dark secrets by telling us which song or musician inexplicably gets your juices flowing.

A: Right now it’s probably the James Zabiela Essential Mix from Glastonbury. In my misspent youth I used to attend the Glastonbury festival, can’t remember too much except it was muddy and there were flashing lights, but this mix helps to bring back the vibe.

Technorati Tags: ,

Author: Richard Seroter

Richard Seroter is currently the Chief Evangelist at Google Cloud and leads the Developer Relations program. He’s also an instructor at Pluralsight, a frequent public speaker, the author of multiple books on software design and development, and a former InfoQ.com editor plus former 12-time Microsoft MVP for cloud. As Chief Evangelist at Google Cloud, Richard leads the team of developer advocates, developer engineers, outbound product managers, and technical writers who ensure that people find, use, and enjoy Google Cloud. Richard maintains a regularly updated blog on topics of architecture and solution design and can be found on Twitter as @rseroter.

One thought

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.