Microsoft BizTalk Server 2010 Patterns
上QQ阅读APP看书,第一时间看更新

When to use BizTalk Server

Perhaps most strikingly, unlike a lot of other software, such as Office, Windows, and even SAP or PeopleSoft in the enterprise space, after installation BizTalk doesn't actually do anything yet. I think this really confuses people and a good analogy is in order. BizTalk Server is much like its close companion SQL Server. Once you install SQL Server, it doesn't actually do anything; you must build solutions that use a database before it does anything useful. The same is true of BizTalk. Both products are platforms on which solutions are built, not solutions in and of themselves. In fact, BizTalk is an application built on top of SQL Server and .NET. To a certain extent, the same can be said of SharePoint; SharePoint doesn't do anything, it allows you to do things with it and is also built on a similar platform.

There are two primary areas where BizTalk fits very well into an organization: integrated (or distributed) systems and high volume systems. BizTalk is ideal for solutions that involve inter-system communication. If you are building software systems that will interact with other external systems, BizTalk is a good fit. Bear in mind that external doesn't always mean outside of your enterprise. It could mean outside your department or outside your current ability to change. The more external interactions that take place the better the leverage from the investment in BizTalk Server as you replace point to point or direct connections with a hub and spoke or service bus architecture.

The other close fit is for high volume and/or mission critical systems. BizTalk provides scale up and scale out growth more easily than any other platform choice and can accommodate the loads of even the most intensive scenarios. It is also reliable enough not to lose any messages and to provide best in class disaster recovery while maintaining transactional integrity.

For all its features and the benefits it brings to an organization, BizTalk Server is not the right tool for every possible solution. The license cost is high by Microsoft standards; although it is extremely low compared to rivals in the space. Not all businesses need BizTalk Server, but many will benefit from it. If you don't need adapters to connect to the existing line of business systems, business activity monitoring to provide analytics and visibility, message format mapping, business rules, or iron clad reliability you may not need BizTalk. If your solution only does Web Services (or WCF) in a homogeneous Microsoft environment with limited need for tracking and monitoring, you may be able to simply use Workflow Services on App Fabric and build a good solution. It may even be possible to simply code services by hand.

Finally, if your solution is not meant to be real-time, but instead to handle large volumes of data on a scheduled fashion, such as ETL, there are other tools that are probably more appropriate. SQL Server Integration Services (SSIS) certainly comes to mind quickly. SSIS is a great tool, but it is meant for point to point ETL and does not offer the rich fabric of features offered by BizTalk.

It can effectively be argued that everything BizTalk Server does could be built into in-house applications and thus there would be no need for it. Although this is theoretically correct, it would prove terribly costly to do so. Imagine the amount of dollars and resources Microsoft has already invested into BizTalk to ensure that it is reliable, scalable, extensible, and easily manageable. It's probably billions of dollars at this point in the seventh version. I would consider that to be well beyond the budget of most projects, especially considering that the risk is really the infrastructure that sits below the solution, not the solution itself. The same argument can be made of database software. One could choose to write their own database, but they would have a very difficult time justifying the cost.

David Chappell addresses this very issue in his article, Introducing Windows Server AppFabric: "One of the great truths of building software is this: Application developers shouldn't spend their time creating infrastructure." BizTalk is an infrastructure layer that provides us with messaging, reliability, durability, and scalability. To this end BizTalk is a force multiplier, in that it allows fewer developers (and operations staff) to accomplish more work in less time. This is a bold statement, but once you know the product and its tools, the results are unmistakable. Unlike many other platforms, the tools in BizTalk Server allow for rapid but robust solution development. WCF services, for example, can be created, exposed, and secured without a single line of code being written. For this very reason many programmers are put off by BizTalk, but make no mistake, code is being written and it is quite advanced .NET code. For now, it is enough to say that you can get a lot out of BizTalk without ever knowing much about .NET, but a deep understanding of .NET will help you get the most out of the platform over time.