[翻译转载] BizTalk Server 介绍

[翻译转载] BizTalk Server介绍

写在前面：

原文地址：Explaining the BizTalk Architecture to your Grandma，所有版权归原作者所有。
转载意图：Microsoft BizTalk Server 是微软非常重要的中间件产品，它依赖与大部分微软自己的服务器产品，提供了非常强大和灵活的功能。笔者发现在中国，有企业应用集成需求的公司很多，不过他们之间选择BizTalk的却鲜有人在，也许是因为微软的销售策略，购买BizTalk需要一整套微软的其他产品，何况BizTalk本身并不便宜。然而BizTalk的竞争对手（如IBM的WebSphere）一整套的解决方案也不便宜，售后服务更贵；所以更多的可能是大家对BizTalk不很了解。（当然有些公司愿意通过自己开发去解决这类需求，量身订做更适合自己。）笔者觉得 Abhilash 的这篇文章写的很好，把实际的业务需求和BizTalk的架构和功能做了对应性的解释，能让大家对什么时候可以考虑BizTalk，如何从业务需求中抽象出BizTalk解决方案有大概的理解，所以翻译过来，希望对大家有所帮助。笔者的工作也和BizTalk相关，希望能认识很多对BizTalk，对企业应用继承解决方案（EAI）感兴趣的同道，一起交流提高。
注：笔者结合自己对BizTalk的理解对原文中的一些描述做了调整，使翻译过来的中文更容易理解，受笔者水平所限，如果大家在阅读过程中有问题，可先参看原文链接，也可回复您的观点，大家一起讨论。

正文内容：

BizTalk服务器是微软提供的内置支持XML和SOAP的企业应用集成解决方案。它通过集成Visual Studio .Net，提供对基于标准的企业应用集成的快速开发和部署、可靠性和灵活性。大家常说：“Similarity in some respects between things that are otherwise dissimilar” （不同的事物在某些方面存在相似性，个人理解）。所以对我来说，为了介绍BizTalk，我想通过比较BizTalk服务器和企业实际业务部署来阐述。

企业实际业务部署

上图所示是一个企业实际的业务部署。我们可以从中看到：大量货物通过不同传输方式（飞机，轮船，大卡，驳船等）由 “进入终端”进入业务系统，经过一套标准的检查程序（包括识别货物，拆箱以及识别供应商等步骤）；然后被存入一个中央仓库。在那里，企业可以对不同类型的货物进行不同的进一步检查和处理。而且我们注意到图中有一块叫“Customs Inspection Rules ” （客户检查规则），它详细定义了检查核对过程的细节，而且在实际应用过程中，可以不时进行更新。每一个货物在通过这些检查和处理流程后，又被存回中央仓库，最后被打包并发往正确的目的地。

BizTalk消息架构

上图描述了BizTalk服务器消息子系统的架构。从中我们可以注意到：除了模块的名称，这幅图和上面那张描述企业实际业务部署的图基本是一样的。在这张图里，我们用XML消息代替了货物来进行整个的流程。大量消息由各个“接收端口”进入，通过“接收管道”被存入“MessageBox”（笔者注：存入SQL Server数据库）；然后这些消息被定义好的“BizTalk 业务流程”处理，“商业规则”也可以在这个阶段被加载和执行；最后这些消息通过”发送管道“由“发送端口”传输到正确的目的地。

 

接收端口

接收端口定义消息如何进入BizTalk。就像货物可以通过飞机、轮船、卡车等运输工具到达仓库一样，消息可以通过任何类型的传输协议，如HTTP, SOAP, SQL, FILE, EDI 等等进入BizTalk。如何传输消息不会改变之后对消息的处理流程。这是一个非常强大的功能特性，它使得我们可以在应用（对消息处理流程的设计实现）部署以后仍然可以对传输协议的类型（如由FTP变为SOAP）和消息源进行改变，而且不用对应该实现的应用做任何修改。举个例子来说，今天销售相关的数据来源于通过WAN连接的位于欧洲的共享目录里的文件，明天我们可以把这个数据来源配置为通过FTP协议传输的位于印度的远程服务器，或者可能是接收一个从任何浏览器来的HTTP请求。

 

适配器

适配器是BizTalk 用来处理不同传输协议的方式。就像可以选择用私人飞机运输我们的货物，我们可以开发适用于自己传输协议的自定义适配器，比如POP3.（BizTalk本身自带了一个通用的POP3适配器）所以有时候我们需要购买或者开发我们自己的适配器去集成其他可用的传输协议，比如DB2 适配器和SAP 适配器。

 

接收管道

接收管道一般包含这些机制：解码（如果消息是经过编码的）、整合（如果消息很大，被分成小消息传输）和“Party Resolution”（实在不知道如何翻译），这类似于上面例子中货物的拆箱和识别供应商。就像我们对一些特定的货物有快速通道，BizTalk中也有一个把消息简单快速存入“Message Box” 的 “Pass Through” 管道；而且就像对特殊的货物有特殊的处理需求，我们可以基于BizTalk提供的框架开发自定义的管道组件。

 

Message Box 和 订阅者

BizTalk Message Box 在自己的消息子系统中处于核心地位（类似于例子中的中央仓库）。Message Box实际上是一个SQL Server数据库，这样BizTalk就能在消息的肯定传输方面确保可靠性。在多机或者高可用性部署环境中，如果一个BizTalk Runtime 结点宕机了，消息可以被同一个组（Group）内的其他冗余的BizTalk结点处理。BizTalk同样可以确保在消息没有被正确存入数据库之前，不会删除消息的原本（比如使用File适配器时某个文件夹下的文件）。当然，这需要我们对BizTalk所部署的SQL Server进行了容错性的设计和架构。就像在现实中我们在对货物进行拆箱的时候需要记录一些重要信息一样，在接收管道和发送管道中，消息中的特定属性可以被提升为上下文属性，比如传输信息，其中最重要的就是消息类型，一般为“XMLSchema#RootNode”。BizTalk的发布-订阅机制明确了基于提升后的属性，一个业务流程订阅、处理并路由哪种消息。

 

业务流程

BizTalk 业务流程是基于商业流程执行语言（BPEL）定义的流程。在处理时，如果消息数量比设定的阈值大，停止消息进入业务流程并排队，否则正常处理。在这个阶段，我们可以使用消息转换映射（Transformation Maps）来改变消息的格式，也可以调用其它Web Service来做一些操作（比如验证信用卡）。

 

商业规则引擎（Business Rule Engine）

BizTalk使用商业规则引擎加载当前已有的策略（Policies），这些策略就是来自于业务流程中一些规则的集合。这些规则被分别维护着因为它们会不时地被更新。就比如奥林匹克比赛中，有一些裁判标准的例外和一些效果的额外加分。这些改变被分别存储，不时更新。

 

发送管道

发送管道基本上做着和接收管道相反的事情，比如对消息进行编码，装箱或者签名，类似于我们在发货之前进行打包和密封。而且就像我们有不同的打包方式，这个阶段也可以有不同的管道组件来加工消息。

 

发送端口

发送端口像接收端口一样基于不同的传输协议传输信息，只是方向相反。在这里，消息传输的方向是从Message Box传输到目的地去。发送端口可以不经过业务流程直接从Message Box里面订阅消息，这就像实际中有些货物伴随着特定的优先许可。这种场景被称为CBR（Content Based Routing）。

 

总结

上面我们讨论的企业实际业务部署如果仔细推敲的话是不准确的，BizTalk Server能处理比这个场景复杂的多的实际业务需求。不过对于BizTalk的初学者，这可以是一个理解BizTalk的不错的开始，希望这篇文章做到了客观的描述，吸引了大家对BizTalk的兴趣，而且对得起这篇文章的标题。

 

写在后面

这是笔者在园子里的第一篇blog，欢迎大家讨论文章，也欢迎大家的任何指导和建议。

谢谢！