BizTalk2010简介

绝大多数现代业务流程都或多或少地依赖于其它软件。尽管其中部分流程仅由单个应用程序支持，但其他许多业务流程都依赖于不同的软件系统。在许多情况下，已使用不同的技术在不同时间、不同平台上创建了此软件。若要使这些业务程序实现自动化，则需要连接不同系统。BizTalk 可以将不同的系统组合到有效的业务流程中，有效的解决企业应用集成的问题。

         BizTalk支持如下两种方式的应用程序集成，即企业应用程序集成 (EAI)和企业对企业 (B2B) 集成；

         企业应用程序集成(EAI)用于连接单个组织内的应用程序。

图-1 企业应用程序集成 (EAI)

       企业对企业 (B2B) 集成，用于连接不同组织中的应用程序。

图-2 企业对企业 (B2B) 集成

       应用程序集成历史及集成模型

       为了更好的理解biztalk server 和它带来的益处，我们来简单的了解一下应用程序集成的发展过程，这样可以更好的了解biztalk的设计模型。在很早以前，每个单位组织使用的都是单独的软件。这些软件产生的相互隔离的信息用来满足特殊的需求，比如财务管理和资源管理。它们彼此是自包含的无需进行交互。这个时候的集成包括冗余数据条目(redundant data entry)（转椅集成(swivel-chair)）和文件转储(file dumps)等，简单的将信息从一个系统转移到另外一个系统。应用程序之间的壁垒森严，真正的无缝集成很少，同时也很难实现。

         随着时间的推进，不同的组织单位使用的应用程序通过点对点的集成方式联系越来越紧密。数据可以更方便的在不同的应用程序之间流动。然而，要实现这种集成方案需要耗费大量的时间和精力。不同的软件开发人员需要通力合作建立技术约定、共享数据模型、交互的方案和协议等。

图-3 点对点应用程序集成模型

         尽管实现实现成本比较高，但点对点集成模型仍然流行起来了。然而，这种模型有一些劣势和固有的脆弱性。如果一个系统的约定改变了，那么其他每个连接的系统也必须进行改变。随着集成节点的增多，点对点集成将变得很难管理（如图-4），这样强迫相关的组织单位将更多的IT资源用于集成的维护工作而不是解决新的和紧急的业务需求。随着单点连接数目的增多，该节点的版本管理意味着随客户端数目增加而不断更新。版本管理和最终遗弃一些系统，这些在最初的设计时往往并没有考虑到，从而导致了成本和风险的增加。

图-4 复杂的点对点集成

         随着时间的推进，点对点集成中引入了hub-and-spoke模型(如-5)。在这个模型中，消息需要先发布到中心的hub服务，然后由hub服务将消息发送给其他的接收者。现在消息的发送者和接收者的关系可以通过配置或者发布订阅规则进行定义。这个模型使发布消息的应用程序无需关注接收者，消息接收者也无需关注发送者。

图-5 hub-spoke模型

         假如一个在线的订单处理系统接收到了订单并向hub服务发送消息。一个数据仓库执行系统可以订阅这些消息并在接受到消息的时候进行处理。现在这两个应用程序的操作时相互独立的。他们之间是松耦合的、它们彼此之间没有进行直接的交互。所有的消息交互都是通过中心的hub，而且它们也不需要知道对方是否存在。现在考虑一个销售跟踪的商业智能应用程序。它也可以订阅相同的订单消息并独立的进行处理，并不需要知道其他两个程序的存在。

         在这个模型中，共享的约定信息还是需要的。如果在线的订单处理系统更改了订单的结构化定义，必须要有相关的策略保证任何订阅者的正常运行。这可以通过一个合理的版本控制策略进行控制。依赖于具体的实现方案，约定信息可以发布到一个中心部署库或者hub，这样可以更方便的进行维护。    

图-6 hub-bus集成模型

         Biztalk server 2004引入订阅发布模型作为混合中心总线架构的一部分，该架构利用消息总线拓扑连接不同的中心辐射模型。在这个中心总线模型中，功能可以分布在多个机器上。每台机器都是一个物理的集线器，它们共享同样的中心消息总线而不会有单点故障。分布系统的配置都是集中地，如捕获操作和业务度量等功能。从概念上说，你可以认为一个biztalk server 主机就是一个逻辑中心集线器。单独的biztalk server 机器运行一个本地实例。这些实例使用消息总线进行协作。总线连接了biztalk的Message Box 和管理配置数据库以及管理操作的功能和工具。

         从功能分层的角度看，biztalk server可以跨越多台机器组合众多的主机实例提供接受、处理、发送消息的功能。当来自外部源的消息被某个主机实例接收，这些消息会保存在中心的Message Box中。其他的主机实例可以订阅这些消息并对它们进行处理。一些主机实例可能共享同一个订阅。在这种情况下，运行在每个机器上的消息代理通过执行协作算法，会自动的选中某个特定的主机实例。完成这些工作后，如果愿意，主机实例可以发布经过处理的消息到Message Box以作进一步的路由。另外，主机实例也有可能会给外部目标发送恢复消息。

         中心总线架构解决了早先的方式的很多局限性。例如，高度的可伸缩性。你可以通过增加机器增强处理能力，你也可以通过移除机器进行缩减。你可以通过定义新的主机实例并把主机实例放入指定的主机，就可以为不通的功能建立不通的主机。Message Box 、配置数据库、BAM跟踪基础设施都是使用sql server实现的。

         这种架构当然也有某些局限性。例如，将集线器进行地理分布往往是不可行的，因为他们共享同一个后端的数据库同时需要较低的网络延迟。此外，尽管biztalk server 2004提供的最初的模型支持动态消息路由，但是缺乏对服务总线设计模式的运行时支持。这些模式只能通过在biztalk server 的上层创建额外的自定义功能模块来实现。Biztalk后续版本会引入ESB Toolkit，以一种统一的方式解决这种需求，并提供一种通用的架构作为动态ESB平台。

BizTalk提供的功能

1. 适配器

         不同的系统使用不同的方式发送和接受信息。biztalk通过使用单独的适配器层分离中心总线模型对此的关注。为了使适配器可以与biztalk server进行交互，biztalk提供了一个管理适配器实例的主机环境，同时也提供了一种编程框架来创建或者扩展现存适配器的功能。除此之外，biztalk为不同的协议、数据库系统、第三方ERP和CRM等提供了一个开箱即用的扩展类库。

2. 消息中介

         biztalk server使用的模型的一个优势是为消息中介提供了一个合理的位置。消息中介可以编码、解码、校验和润色消息。除此之外，消息中介的功能还包括转换消息的格式、拆分消息、组合消息的能力。biztalk使用管道提供了一种通用的可扩展的框架来扩展消息通道。

         消息中介的一个主要的方面就是将消息和有用的元数据进行关联。这些被称为消息上下文的元数据被用来路由。消息上下文会随消息一起穿过消息总线。为了实现彻底的解耦合和更高的性能，订阅引擎评估消息上下文而不是消息内容。通常的做法是在管道里处理消息，并将相关的值从消息内容中拷贝到上下文中来实现基于内容的路由。

3. 异常处理

         Biztalk server提供了很多不同方面的异常处理。例如，当消息不能向外部系统回复时，biztalk内置支持自动重试。消息传递期间，失败的消息可以暂停、发送给一个次级传输或者路由到一个异常处理程序。当一个批处理中的一个单独的消息失败了，biztalk既可以配置为使整个批处理失败或者单独的处理这个失败的消息。

         处在同一个事务中的所有的消息都持久化到Message Box数据库。这提供了基本的机制实现暂停失败的消息，以便稍后可以重新提交。使用biztalk的编排特性可以实现更多异常处理的高级模式和错误恢复。编排特性基于BPEL标准中支持的Saga模型进行扩展，提供了一种可以实现自定义错误处理的逻辑和补偿方案的机制。

 

4. 编排和编制

         编排经常被用来实现自动化的处理流程。其可能展现为特定的业务流程或者简单的自动化信息交换的某些方面。为了更好的分离关注点和重用、促进某些高级形式的消息交换，一个父编排可以分解成不同的子编排。不同的编排可以在单独的消息总线上通力合作。编排是使用图形模型驱动开发技术创建的。编排展现了BPEL标准的超集，并且对BPEL进行了增强。

         服务编制给编排提供了一种互补的模型。它是之中参与服务之间定义交互协议的非中心化的方法。biztalk通过使用ESB工具管理和创建的路线图来实现编制。每个路线都代表一个可以扩展和通过中心存储进行管理的路由策略。路线图往往与消息关联，并在管道和编排中使用。它们也可以被非biztalk服务（例如web服务）创建、查询、消费，从而实现更广阔的企业级合作模型。

5. 性能和可伸缩性

         很多组织单位经常需要处理以便的工作负载，但是又不希望招致大量的额外的话费和扩展重构已存的系统。可以使用很多的技术来实现可伸缩性和提供更好的性能。这些技术包括负载均衡、数据处理分区、分布处理过程等技术。biztalk在内部使用这些技术，同时也支持在外部使用这些技术。

6. 安全性

         鉴于业务的需要和客户的需求，系统常常必须交换敏感的信息。解决方案可能使用传输级别或者消息级别的安全机制保护消息或者特定的数据值。它们需要确保敏感数据只能在需要的地方进行解密。

         Biztalk提供的开箱即用的适配器提供了传输级别的安全。消息级别的安全是通过wcf适配器提供的.WCF适配器也可以用来支持统一身份验证，一个组织单位的用户验证可以通过访问跨组织托管提供的服务实现，而不是使用集中地用户账户验证。

         解决方案架构通过定义信任边界来简化安全模型和减少风险。Biztalk使用不同的逻辑主机实现信息边界的建模。外部系统可能实现了他们自己的身份验证和授权机制。即使它们与信心边界发生冲突，biztalk也必须遵守这些安全模型。鉴于这个原因，biztalk提供了一个单点登录服务器来将安全主题映射为目标系统需要的凭证。

7.洞察力

         集成的环境可以很复杂并且难以理解和管理。技术的细节可以使我们难以检验整个解决方案是否满足业务需求。组织需要洞察了解他们解决方案的状态、形势、行为。他们需要监视系统的性能和健康，维护分布式业务活动的审计，确保商业和法规的遵从性。

         追踪和监控提供了基本的分析和洞察的能力。Biztalk提供了工具跟踪消息流、钻取每次交互的细节、重启失败的交互。BAM框架支持业务管理和通过收集、聚集分布式业务活动中的事件数据的态势感知。业务规则引擎将决策逻辑从流程和消息流中分离出来单独管理和修改。规则展现的方式允许它们直接追踪到业务策略。

8.电子数据交换

         集成常常涉及到不通组织间数据的电子交换。Biztalk为使用最广泛的EDI（电子数据交换）标准提供了扩展支持。它对标准的EDI架构、批处理、确认和其他问题提供了可扩展的、可定制的支持。这些特征连同更新、改进贸易合作伙伴管理的特性使biztalk server 2010拥有捕获和建模有关贸易伙伴、业务档案、B2B社区广泛使用的协议的信息的能力。

9.RFID（无线射频识别）事件处理

         Biztalk提供一个无线射频识别设备的管理和事件处理平台。这是一个单独的边缘的服务器，跟用于消息交换和编排的中心总线架构是不同的。除了支持各种RFID的工业标准，biztalk还提供了一种用来支持部署、管理、监控不通种类的设备的基础架构和高效灵活的事件过滤和探测的事件处理框架。它同时也提供了像业务规则引擎和BAM等其他的biztalk的特性。Biztalk 2010还支持在RFID手持设备和移动设备上进行传感应用程序开发。