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

Stating the goals of BizTalk Server

BizTalk is Microsoft's premier messaging platform. It was designed with many specific scenarios in mind and has evolved to work with others as well. Whether you are involved in integration, service orientation, business process management, or enterprise service bus, BizTalk's purpose is to enable the following goals:

  • Increasing reliability
  • Decoupling systems
  • Providing reuse
  • Decreasing development time
  • Providing rich information to technical as well as business consumers
  • Improving administration
  • Providing a rich set of security options that can be controlled separately from the functionality of a solution

Used as presented in this text, it will deliver on all of these points. This is a lot to cover, so let's address each of these aspects individually and discuss how they are achieved.

Increasing reliability

The very core of BizTalk Server is a construct called the Message Box. Everything that goes in and out of BizTalk Server travels through the Message Box. We will cover this in greater depth later, but for now it is enough to know that even in a catastrophic outage, there is never a chance for messages to simply be "lost" in BizTalk. Distributed transactions while managing the input, update, and removal of messages from the Message Box are fully ACID compliant. BizTalk is designed as a distributed system and has resilience built into the product. Just as we have been able to abstract away details of processor architecture, BizTalk abstracts away details of durability and reliability. BizTalk recovers cleanly and often automatically from outages. This inherent reliability allows us to shift our focus to solving business problems rather than solving technical issues. BizTalk is also designed to work in a scaled environment; addressing both scale out and scale up scenarios in a simple manner.

Decoupling systems

BizTalk, when used correctly, provides unprecedented decoupling by allowing you to graphically map message formats to each other. This simple flexible mapping capability is critical to decreasing coupling as it enforces a barrier between chains of connected systems. Using the best practices presented in this text, changes in endpoints such as transport, encoding, timing, and format will have little or no impact on your internal solutions. Here again the Message Box achieves abstraction and helps by decoupling message senders from message receivers. As mentioned earlier, every message in BizTalk goes through the Message Box—so even a simple solution still uses the Message Box. This separation enforced by the Message Box allows us to decouple message senders (publishers) from message consumers (subscribers). For more information on loose coupling see "What is Loose Coupling" in the appendix.

Providing reuse

By using internal message formats that are known only to your BizTalk solutions, endpoints and adapters of existing solutions can be leveraged repeatedly over time. Other great candidates for reuse are infrastructure services such as logging or audit that can easily be provided by the ESB capabilities of BizTalk. Properly structured BizTalk solutions encourage reuse. By decoupling, format, transport, and time constraints solutions and their components can be readily reused to solve variations of specific processes. Some of these components, like the WCF Adapters, can even be used completely outside of BizTalk.

Decreasing development time

By leveraging the familiar Visual Studio environment, developers are quickly at home with BizTalk and can begin creating solutions almost immediately. We will see later how to make those solutions effective, scalable, and flexible. Perhaps the greatest time savers for developers are all the tools that are part of BizTalk. The Mapper, the Flat File Wizard, Business Activity Monitoring, the other wizards for various adapters, and all the robust infrastructure and service publishing tools make BizTalk a complete toolset to address the vast majority of issues facing the enterprise. Very few of the tools involved in BizTalk will be completely new or unfamiliar to developers who work on the Microsoft platform. Great care has been taken to make the transition to BizTalk as easy as possible. Further, because BizTalk does not focus on code and libraries the way most programming environments do, the amount of time taken to create a solution is greatly decreased.

Providing rich information to technical as well as business consumers

As mentioned earlier, nothing is ever "lost" in BizTalk. By default, there is a tremendous amount of technical tracking for every message and workflow (orchestration) inside of BizTalk. As useful as this is, there is another level available via Business Activity Monitoring (BAM) that allows for the creation of tracking profiles to follow business processes at the desired level of granularity and to include data from within the messages (content) as well as metadata about the messages (context). Further, this data can be used in automatically created analysis cubes (via SQL Server Analysis Services) to provide nearly self-service BI solutions. With the addition of notifications on this monitoring information, what BizTalk offers in this area is currently unrivalled by any other platform.

Improving administration

Continuing in the line of messages never being "lost", BizTalk also provides a rich set of tools for administrators to deploy, monitor, and manage solutions. Using the MSI deployment package concept, there is also no compiling or scripting necessary for the administrator (although these features are available if needed). BizTalk enables the solid line handoff between developers and administrators that is increasingly required by regulatory compliance regimes. Further, BizTalk allows administrators to reallocate and partition processing over their servers to make solutions more scalable or allow for in-place upgrades requiring little or no downtime. IT administrators have more control over the runtime of BizTalk solutions than of any other platform in the Microsoft stack. Moreover, none of these controls require code to be implemented, freeing staff to focus on their primary jobs rather than learning new scripting languages. BizTalk is also heavily instrumented and uses familiar MMC and WMI tools that IT operations staff will quickly feel comfortable with. Additionally, other administration tools like SCOM have add-on packs for BizTalk that plug into this instrumentation.

After using BizTalk for a while (in accordance with the practices outlined here), I invite you to revisit this list and determine for yourself how relevant each of the points have been.