Professional BizTalk® Server 2006

2.1. Why BizTalk?

Before we start discussing how BizTalk is architected, let's take a step back and think about how you would implement your own solution without BizTalk. This is an approach I use often with my customers, to counter scenarios where developers just want to write code. Sure, you can write the code, but the devil is in the details.

It's also important to remember that BizTalk is not a universal panacea for all software problems and must be used in the right place. You should not be using it for all your applications — just where it makes sense. I always try to get customers to consider what value they are seeking from BizTalk in each use case. If they struggle with the answer, perhaps BizTalk is not the best solution.

We'll use a fictional scenario to illustrate some of the reasoning behind why BizTalk is architected the way it is.

2.1.1. Phase 1

A new software project is designed by your organization. You need to take travel itinerary bookings that arrive at this new system as individual files on the Windows filesystem (a directory). These files must be collected and the contents transformed from the third-party data structures to your internal format.

Once this has been done, you need to interface to flight, hotel, and rental car booking Web services hosted by third-party suppliers.

2.1.1.1. Custom Development

You start with a Windows service that can be executed unattended on a server. This Windows service, once started, can use the FileSystemWatcher class provided ...