Create effective,scalable solutions with Microsoft BizTalk Server 2010
According to Gartner , it falls in the leaders quadrant and has the highest ability to execute.
BizTalk Server 在组织中可以被看作为信息传递的一个中介物或者是一个管道。它的关注点是连接各种系统和提供服务。但是它远比中间件类产品强。
BizTalk不是企业的灵丹妙药。BizTalk is not a panacea for the enterprise.
BizTalk 基本上是一个中间件，用来连接各种独立的系统，消除紧耦合，端到端的集成。
1.4 Exploring the architecture of BizTalk Server
从核心来说，BizTalk就是一个建立在SQL Server上的.NET应用程序，提供稳定可扩展的特性。
要了解它关键是要了理解发布订阅模式。这个是BizTalk的核心模式。
1.5 Design patterns within the BizTalk architecture
消息发送（Messaging）
发布订阅（Publish/Subscribe）
流程如下：
1.订阅者加入订阅
2.订阅管理者跟踪这些订阅
The sending system (Publisher) Sends a message ,and the Subscription manager matched the subscription list ,forwarding each subscriber its own immutable copy of message.
Publish，发布者是不知道谁对发布的消息感兴趣的。
订阅管理者抽取消息的接收人，也抽取这些目标系统的状态。
Publish Subscribe的主要目的是把端到端的同步架构改变成松耦合的异步步交互。
通过BizTalk实现的服务和端点虽然呈现为同步方式，但是其实他们是异步的。
Adapter
Streaming
Streaming也是BizTalk另外一个重要的架构设计原则需要考虑的东西。大部分BizTalk组件都是基于流的组件。
Pipelines、maps通过流也处理消息。This means that stream classes are chained together in the framework so as to avoid large memory buffers.
BizTalk只加载正常报文中的一些字节，不会加载全部报文数据到内存。Then , each class in the chain of classes involved in mapping and pipeline processing calls the Read operation on the next in the chain, passing this small buffer between them, making their requisite changes along the way. This ultimate motivation behind this is to keep a flat memory footprint for the process.
对于必需要操作的非常大的需要很大的中间缓存的消息，BizTalk will even stream to disk as needed, to save memory.
1.6 Understanding BizTalk message flow
消息接收流程中的各种角色：
1.Adapter
2.Pipeline:chain of Pipeline Components
3.Map
4.Message Box
1.6.1 The Message Box
Message Box 是BizTalk的核心组件。
The Message Box is the place where everything in BizTalk happens.
Message Box是基于队列的概念的。BizTalk的队列比MSMQ更具有扩展性。
每个队列由下面几个表组成：
- Queue
- Suspended queue
- Scheduled queue
- Message Ref Count Log
- Dequeued batched
当一个消息达到Message Bos的时候（插入实际数据库中），订阅管理器检查订阅列表——哪些是这个消息的订阅者。每一个订阅者的队列中会得到一个“工作项”，虽然“工作项”可能会很多，但是消息本身实际上不会被复制。它们只是对原始消息的引用。
消息在BizTalk中是不可改变的。（immutable）也就是说当接收一个消息后，消息是不能被改变的，即使你感觉你在对消息做改变，其实你只是创建了一个新的消息。
然后每个订阅者检索队列中的工作顶，处理它们。当处理结束，被标记成完成，引用数（reference counts）可以反映这一情况。其它维护任务开始执行必要的清理。
如果没有找到订阅者，消息仍然会被插入到Message Box，但是作为一个失败的消息。
1.6.2 Other BizTalk Databses
除了消息数据库，BizTalk还有其它一些数据库：
- BizTalkMgmtDB：这个是管理数据库，Ports,Maps,Schemas,Orchestrations都包含在此数据库里面，还有BizTalk需要知道的某些从GAC中加载的东西。提供Biztalk运行时信息、自我调整和控制。
- BizTalkRuleEngineDb：为业务规则引擎提供存储策略，包括词汇。
- BizTalkDTADb：跟踪数据库，记录所有BizTalk发生的事件。
- BAMPrimaryImport：存储初始的业务活动监控数据。
- BAMArchive：
- BAMStarSchema:
- SSODB：单点登录的信息存储。
- BAMAlertsNSMain：通知正文。存储订阅参数。
这些数据库可以迁移到不同的数据库服务器的不同实例上。或者说如果你的应用跟踪压力很大，你可以把BAM数据库移到别的地方，这样就不会影响到正常的事务。
1.7 呈现BizTalk的运行时环境
1.7.1 服务器和服务（Servers and Services）
1.7.1.1 应用程序服务器
BizTalk是一个应用程序服务器，但是他被设计成一个分布是系统。在一个BizTalk环境中，可以有多个特定的服务器，每个服务器可以运行特定的服务。首先是BizTalk应用程序服务器，BizTalk是一个Windows服务，跟IIS和SQLServer一样在服务器的后台运行。每个Biztalk服务器可以运行多个实例，每个实例相互独立。
1.7.1.2 数据库服务器
是BizTalk数据库的宿主，也是BAM通知服务的宿主。
执行SQL Jobs, 是BizTalk必不可少的构件。
BAM的分析服务。
1.7.1.3 Web服务器
作为HTTP/Web Services/WCF的终结点和BAM门户，它们都是基于IIS。
BAM门户可以被安装在一个非BizTalk的服务器上。
1.7.1.4 企业单点登录服务器
为BizTalk提供企业级完全凭证存储。
这个服务是运行时必需的。
存储非AD认证系统的凭证，比如FTP，DB2,ORALCE等适配器。
这个凭据提供Group内的应用程序的共享。
每个BizTalk服务器都有一个自己的SSO 服务实例，但是只有一个是主密钥服务器。It is used to prime the pump, so to speak, for the other SSO servers, by hosting the encryption key used to make the SSO store secure. 其它组中的服务器安全地从主密钥服务器请求主密钥，并缓存备份，周期性地检查密钥是否变更。
这些服务器都可以被安装在一台物理机器上。
1.7.2 理解角色和关系
这一节介绍基本的逻辑组件和运行时的组织结构。
1.7.2.1 BizTalk组
BizTalk组是BizTalk的最高层抽象。它是一个逻辑的容器。组是于BizTalk管理数据库关联的，当你通过管事控制台连接到一个组时，你实际上连接的是它的管理数据库，它提供整个组可用的命令和控件。
一个典型的企业中，一般会有好几个BizTalk组，一般来说有一个用来整合/开发测试，一个用来URAT或者用户测试，和一个正式生产环境。
1.7.2.2 宿主（Hosts）
一个BizTalk宿主定义了一个运行时组件，它把多台独立的物理服务器呈现为单一的组织单元。
宿主更像是一个虚拟机。
1.7.2.3 宿主实例
一个宿主实例通过一个指定的Windows用户运行在指定的服务器的BizTalk组中。
宿主实例被创建时会自动创建为一个windows服务，可以在服务管理控制台中看到。
流程和内存的瓶颈可以在宿主实例中被设置。
下图描绘了组、宿主、服务器和宿主实例之间的关系：
1.7.2.4 Isolated 和in-process hosts对比
In-process宿主运行在BizTalk运行时中，它包含我们上述的内容。它是一个Windows服务运行在指定的服务器的BizTalk组中。
Isolated 宿主独立运行于其它进程中，比如IIS。
1.8 总结