为什么需要一个企业服务总线（Enterprise Service Bus，ESB）

从IT管理的角度看，随着企业内信息化系统的不断建立，企业已经充满了各种各样的业务系统（line-of-business, LOB），以及各种异构技术。公司经常会购买软件产品，用于非商业性的关键业务活动（例如财务系统，人力资源系统），然后搭建公司日常活动中使用的关键业务系统。通常，每一个系统都采用独立的方式进行搭建，随着时间的推移，这些相互独立的闭环系统在其内部积攒了大量数据。如果对这些数据进行有效的整合，那么这些数据可以为公司提供一个更高层次的商业功能。这就是为什么，由统计分析发现，在企业级软件内部，有超过百人之七十的代码用来实现将数据从一个系统搬运至另一个系统的整合解决方案。

一般来说，解决整合问题的最简单方法，就是独立的系统之间建立点对点的数据连接。有些数据整合可以建立在开箱即用的解决方案基础上，其他的则需要定制的代码开发（或者在开箱即用的解决方案基础上进行二次开发）。虽然这些解决方案都成功上线了，但是随着时间推移，这些定制的点对点导致系统的负责性明显增加，每一个业务系统都需要维护大量的数据连接，导致系统管理和维护的成本增加。点对点连接中，不论修改任意一方的业务系统，都有可能导致整合连接的中断。对于整合系统的升级也需要对点对点整合的双方同时进行系统升级。随着时间推移，点对点的定制整合系统策略必须不断改进，以保证业务逻辑随市场情况改变而改变，最终系统连接的增长量，将会让IT不堪重负。随着组织的不断完善以及业务系统的不断增加，系统监控及系统错误响应的需求将会变得越来越重要。系统可控性及敏捷性的不足会导致软件供应商及开发人员寻找不同于点对点整合的，更好的解决方案。

在解决上述问题的过程中，经常使用一种叫做企业应用整合（Enterprise Application Integration, EAI）的技术。企业应用整合（EAI）允许在业务中使用开箱即用的中间件产品，将企业中的整合集中化组织在一起。尽管企业应用整合（EAI）提供了比点对点定制整合方案更有优势的特性，但是最终实现企业应用整合（EAI）后，依然产生的相同的问题。由于企业应用整合（EAI）解决方案倾向于允许系统接入端点位置使用硬编码，这样每一个服务都与其后端系统之间紧密耦合在一起，这样接入端的修改，将导致企业应用整合（EAI）解决方案的部分甚至全体进行相应修改。

另一个解决问题的方式是考虑以面向服务的架构搭建系统。从面向组件构架向面向服务构架的转变过程，由多个原因驱动着。其中最主要的驱动力是，从单一供应商提供的应用系统，迁移至由多语言多平台组成的应用系统运行环境。这将允许独立的业务系统之间进行并行的开发和部署，这将大大加快开发和部署的速度，并且业务系统可以被包装为黑盒模块，供其他业务系统使用。这样大量的服务都可以以功能为单位进行更高层次的整合。

一个驱动力是，希望暴露当前系统，遗留系统，和行业业务系统（LOB）接口，使新开发的应用系统可以使用它们。这将导致已有系统进入整合空间，并变为面向服务的一部分。这使得行业业务系统（LOB）可以被看作服务，以新的方式与现有系统进行整合。

在大多数情况下，面向服务的应用程序的最终部署方式也和点对点的解决方案相同。随着时间向前，它们也会紧紧耦合在一起，像一个应用程序一样。如果一个地址发生改变，或者一个消息格式发生改变，同样会导致连接的另一端必须做出相应的改变。那么在这种情况下，整个系统将不再拥有面向服务架构所带来的任何优势，而在许多时候甚至更糟。

如图1所示，服务提供及服务使用者的集合会很快进入一种想意大利面一样错综复杂的混乱结构，难于管理和维护。点对点的设计很难进行扩展，因为每一个节点都直接连接到另一个节点。当服务试图避免被额外的调用时，功能将不再独一无二，而变得冗余。这样导致很难描述清楚一个系统或者系统的一个部分在做什么，因为每一个连接都是直接连接的，无可替代的，这样很难找到一个简单的方式去监控整个系统。

或许最大的限制在于，当连接中的一个端点进行修改的时候，另一个端点将受到毁灭性打击，这样使得整个架构变为一种不可控的服务架构。每一个服务的修改都可能影响到多个调用了它的服务或应用程序，因为这些服务或应用程序已经对它形成了依赖关系。

图1: 点对点的连接纷繁复杂

企业服务总线（ESB）可以很好的应对在面向服务应用程序中产生的一些问题。从这个意义上讲，企业服务总线（ESB）扮演了关键角色。在企业服务总线（ESB）模式（这种模式已经嵌入了许多供应商的产品与工具）背后的首要驱动力是，搭建一个面向服务的框架，以解决早期系统整合解决方案中产生的各种问题。达到这个目的的方法是，将业务逻辑从参与应用程序连接的每个独立端点转移至一个集中化的业务逻辑层。虽然企业应用整合（EAI）也是基于集中化业务逻辑层实现的，但是企业服务总线（ESB）模式与之不同的是提供了动态的执行方式。

可扩展性是非常重要的，因为业务的改变时时存在，软件必须随业务的变化，甚至提前于业务的变化而不断进行更新。企业服务总线（ESB）模式的理念就是：通过提供集中化的，松耦合的，动态中间层对整合进行管理，以简化应用系统随业务变化而更新的过程。

如果软件可以更易于维护，那么业务将从降低操作成本，减少系统停机时间中获得价值。

企业服务总线（ESB）模式

企业服务总线（ESB）的主要目的就是在服务的提供者与调用者之前搭建一个中间层。如果所有服务都连接到该中间层（系统总线），那么在点对点连接过程中产生的许多问题都可以迎刃而解。

图2: 在服务组件化的过程中体现出的敏捷性

企业服务总线（ESB）可以提供通用的可重用服务，比如数据转换，协议转换，动态路由，以及错误处理，同时需要提供数据透视功能，对于正在交互的应用程序数据内容进行监视。

由于使用企业服务总线的（ESB）的应用程序以一种松耦合的方式进行交互，在应用程序与由企业服务总线（ESB）提供的服务之间进行修改，变得容易许多，这大大加强了商业敏捷性。如果一个服务改变了，应用程序甚至不用做出任何修改，因为企业服务总线（ESB）层可以修改配置达到借口直接的适配。如果一个消息需要转换到一个新的格式，一个额外的数据转换可以在企业服务总线（ESB）中进行配置，同样不需要对数据服务的提供者或使用者进行任何修改。

BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit ）概览

BizTalk 企业服务总线工具包（BizTalk ESB Toolkit）提供了一系列的加强服务，使有的BizTalk架构允许服务的提供者和消费者采用一种松耦合的方式接入中间层环境。

图 3: BizTalk ESB Toolkit 2.0的基础架构

由BizTalk企业服务总线工具包（BizTalk ESB Toolkit）提供的框架由以线路为格式的元数据驱动。线路信息的本质是一个XML格式的文档，它描述了企业服务总线工具包（BizTalk ESB Toolkit）处理消息的步骤集合。线路信息可以附着于一个进入总线的消息中。然而，更多的情况下线路信息会由消息本身的内容动态决定。例如我们可以使用输入消息内的客户ID来决定消息应该使用何种线路来进行处理。

在企业服务总线工具包（ESB Toolkit）决定了线路后，一系列的处理将被执行。这些处理步骤可以包含消息的转换，终端节点的解析，或者业务流程处理。另一个关键的特性是，企业服务总线工具包（ESB Toolkit）的所有协调服务都是可扩展的，可以提供最大的灵活性。相比到企业服务总线（ESB）外部获取新的功能，将新功能集成入企业服务总线（ESB）内部更有优势，因为这样可以不干扰到已有的服务提供者和服务使用者。

消息进入总线的方式采用了名为入口（OnRamp）的概念，在BizTalk企业服务总线工具包（BizTalk ESB Toolkit）中，它由BizTalk输入端口实现。消息通过出口（OffRamp）离开消息总线，而出口则绑定于BizTalk输出端口。

BizTalk企业服务总线工具包（BizTalk ESB Toolkit）可以为消息提供服务，帮助它们流过总线。大多数的服务也可以暴露在总线之外，这样它们可以被其他消费者使用。这些服务包括消息转换，端点解析以及业务流程和管道处理。

从技术层面上讲，BizTalk企业服务总线工具包（BizTalk ESB Toolkit）更多的复用BizTalk Server 已有的功能组件，是最合适的选择。在BizTalk 应用程序中，接收端口接收到消息后，会将消息路由至发送端口或业务流程。通常，BizTalk应用程序会在程序的设计阶段，或部署阶段，将接收端口，发送端口等元素的物理位置信息绑定起来。但是这样做会降低敏捷性，使物理位置信息的动态修改变得困难。

图4: 企业服务总线工具包（ESB Toolkit）及相关的BizTalk组件

BizTalk企业服务总线工具包（BizTalk ESB Toolkit）使用了动态的方式，实现这些元素信息的绑定。在只处理消息的应用程序中企业服务总线工具包（ESB Toolkit）使用动态端口。BizTalk企业服务总线工具包（BizTalk ESB Toolkit）在BizTalk Server已有的强大特性（通常没有发挥完全）的上层建立了一个新的包装层。这样产生的新架构使得BizTalk应用程序有了更高的价值，使得BizTalk Server变为了一个可以协调 任何服务的中间协调层。

BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）核心组件

线路（Itineraries）

处在BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）最核心位置的是一个名为线路（Itineraries）的概念。线路（Itineraries）指的是一个元数据片段，它描述了总线应该以何种流程处理消息。它也可以包含一系列的服务信息，消息会按顺序流过这些服务。它可以被看成域描述语言（Domain-Specific Language, DSL）一样的轻量级服务编排模型。这个模型可以被用来决定消息在BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）运行时环境中流转的方式

BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）包含了一个DSL设计器，使开发人员都能轻松的进行设计，并且使用可视化的方式编辑服务的消费者和提供着是如何被关联到一起的。

图5: 使用BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）设计简单的线路（Itineraries）

每一个消息都需要加载一个线路（Itineraries）。消息可以在进入总线的时候已经加载入了一个线路。（BizTalk 企业服务总线工具包支持将一个线路信息附着在一个SOAP头中。）由于把线路（Itineraries）信息硬编码到消息内容中，并不是一个最好的选择。所以更多的时候线路（Itineraries）信息并不附着在消息中，而是在用一种叫做解析器（resolver）的企业服务总线（ESB）组件来动态决定进入总线的消息使用哪种线路（Itineraries）处理。（开箱机用的解析器将在后文中详细介绍。）

当一个消息携带线路（Itineraries）信息进入总线 ，BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）组件将使用线路（Itineraries）中的信息指导消息在总线中的行进路线。可以是 这样，但并不强制使用这种方式来决定正确的出口（OffRamp），应用服务（例如数据格式转换），或者路有消息至将要进行的处理（由一个业务流程处理）。

实现线路（Itinerary）处理的机制是采用了BizTalk管道（pipeline）组件。在管道组件中，系统读取存储于SOAP头中的企业服务总线（ESB）线路（Itinerary）信息，获取了连接字符串。并且提供了端点物理位置解析，数据格式转换执行的能力，这些能力基于解析器（Resolver）和适配器（Provider）框架实现。线路（Itinerary）管道（Pipeline）组件可以实现动态的端点物理位置解析，以及动态的数据格式转换执行，而如何确定物理位置以及数据格式转换方式，则由线路（Itinerary）信息中的内容决定。这些组件负责在复杂的处理和服务调用之间管理，更新，保存线路（Itinerary）信息。

因为BizTalk企业服务总线工具包（BizTalk ESB Toolkit）是建立在已有的BizTalk基础构建之上的抽象层，你可以把基于线路的路由功能想象为在现有BizTalk动态发送端口（Dynamic Send Port）之上建立的抽象。这种抽象可以简化动态端口操作，降低路由错误发生的几率。

输入/输出通路（On/Off Ramps）

在BizTalk企业服务总线工具包（BizTalk ESB Toolkit）中，入口（OnRamps）和出口（OffRamps）指的是所接入应用程序的端点位置。

入口（OnRamps）指向携带消息进入总线的端点。入口（OnRamps）是一个真正意义上的建立在BizTalk接收端口之上的抽象层，所以每一个入口（OnRamps）都对应着一个配置了BizTalk企业服务总线工具包（BizTalk ESB Toolkit）管道组件的BizTalk接收端口。尽管从通常意义上讲，进入总线的消息都应该来自于入口（OnRamp），但是BizTalk企业服务总线工具包（BizTalk ESB Toolkit）是建立在已有的BizTalk基础构件之上的，所以依然消息依然有可能通过其他方式进入总线。比如有的消息可能会通过业务流程或者接收端口，这些没有配置企业服务总线工具包（ESB Toolkit）管道的组件，在消息数据库（MessageBox）中进行发布，并通过正确的提升属性从而进入消息总线。

出口（OffRamps）指的是将消息从总线发送出去的端点。出口建立在BizTalk发送端口，以及BizTalk出站机制基础之上；每一个出口（OffRamp）都对应了一个BizTalk的动态端口。事实上，出口（OffRamps）使用动态端口的原因，就是希望消息从总线向外发送的时候可以路由至多个不同的物理位置（包括使用不同的传输协议和安全方式），这些变化都动态实现，不需要在程序上做出任何改变。

这些抽象后的组件组成了一个建立在BizTalk基础架构之上的顶层视图。然后更多的是，它们提供了一种概念，这种概念帮助BizTalk的开发人员以及非BizTalk的开发人员更多的采用原子的方式看待系统中的服务，这是区别于一直以来的物理架构的。

适配器提供者框架（Adapter Provider Framework）

适配器提供者（Adapter Providers），被用来设置从BizTalk企业服务总线工具包（BizTalk ESB Toolkit）离站的适配器的属性。它们提供了从BizTalk企业服务总线工具包（BizTalk ESB Toolkit）配置属性到发送适配器（Send Adapter）上下文属性的映射方式。BizTalk企业服务总线工具包（BizTalk ESB Toolkit）通过适配器提供者（Adapter Provider）设计期的元数据描述来建立这种也映射。元数据被用来映射线路（Itinerary）的配置信息（可以静态编写，也可以动态生成）至BizTalk的某一确定发送适配器（Send Adapter）的上下文属性（ContextProperty）值。

下面列出了BizTalk企业服务总线工具包（BizTalk ESB Toolkit）中包含的适配器提供者（Adapter Providers）：

· WCF-BasicHttp

· WCF-Custom

· WCF-WSHttp

· FTP

· File

· SMTP

· WebSphere MQ

适配器提供者框架（Adapter Provider framework）提供了非常简单的扩展方式，以应用于更多的适配器，并有能力实现动态的配置。这些适配器继承了一个叫“IAdapterProvider”的 .NET框架组件接口。继承后，适配器会在BizTalk Server中注册自己的转换类型，这个转换类型设置了在这个BizTalk适配器上的解析器（Resolver）提供的端点信息。

企业服务总线解析框架（ESB Resolver Framework）

解析器框架（Resolver Framework）提供了一个功能全面，可插拔的架构，它实现了对服务元数据的动态解析。它用来提供端点信息的动态解析，它可以解析外部服务端点的信息，也可以解析企业服务总线（ESB）服务（内部服务）的参数与返回数据，例如路由服务，数据格式转换服务或者您向企业服务总线工具包（ESB Toolkit）中添加的任意自定义服务。例如，你可以在消息进行数据格式转换的时候动态解析BizTalk Server的映射（Map）类型。解析器框架（Resolver Framework）允许开发人员创建自定义的解析器（Resolver），在其中编写动态的解析方式以及路由方法。

下面列出了解析器框架提供的开箱即用的组件，这些组件各自对应不同的技术：

· 通用描述，发现，集成服务（Universal Description, Discovery, and Integration, UDDI）

· 商业规则引擎（Business Rule Engine, BRE）

· XML路径语言（XML Path Language, XPath）

解析器框架（Resolver Framework）也为开发人员提供了开发接口“IResolveProvider”，这个接口允许开发人员创建自定义的解析器（Resolvers）。自定义的解析器（Resolvers）在运行期加载并缓存在内存中，支持使用决策类型和连接字符串。

线路解析（Resolving Itineraries）

一个BizTalk企业服务总线工具包（BizTalk ESB Toolkit）的核心问题就是线路信息的动态决策和执行。

一个消息被入口（OnRamp）处理，它可以有一个线路（Itinerary）信息嵌在消息本身中（保存在消息的SOAP头中），或者可以在入口（OnRamp）中解析应该使用哪个线路（Itinerary）。

图6展示了动态决策解析线路的几种方式：

图 6: 线路（Itinerary）解析

在上图展示的情况中，解析器（Resolver）解析的过程中，都只获取线路（Itinerary）信息的名称，获取名称后BizTalk企业服务总线工具包（BizTalk ESB Toolkit）将从数据库中根据线路名称取出线路（Itinerary）的实体内容（在某些时候线路信息的全文也可以附着于消息本身之上）。

异常管理框架（Exception Management Framework）

企业服务总线（ESB）异常管理框架（Exception Management Framework）提供了统一的，面向消息的错误产生机制，通过它可以管理在微软BizTalk Server运行环境中产生的所有异常信息。企业服务总线（ESB）异常管理框架（Exception Management Framework）可以获取所有通过异常发布服务发布的异常信息，同时，也可以获取BizTalk服务器失败消息路由（Failed Message Routing）机制下抛出的错误消息。

框架提供了发现错误是创建错误消息，发布错误消息，管理错误消息的API，这些API由业务流程处理，它的实现利用了BizTalk服务器的失败消息路由特性。额外的，框架也提供了方式来规范所有异常，扩充异常信息，应用商业活动监视（Business Activity Monitoring, BAM）跟踪，并且最终将异常发布至异常管理数据库（Exception Management Database），并且展现在企业服务总线（ESB）异常管理门户中（Exception Management Portal），并提供报表。

BizTalk企业服务总线工具包（BizTalk ESB Toolkit）囊括了一些管道组件，这些管道组件帮助实现企业服务总线（ESB）异常管理框架（Exception Management Framework）：

• 异常错误处理管道组件（Exception Fault processor pipeline component）。
• 商业活动件事跟踪管道组件（BAM Tracking pipeline component）。

路由功能示例

在大多数情况下，BizTalk企业服务总线工具包（BizTalk ESB Toolkit）的一个重要目标就是把收到的消息按照与其关联的线路（Itinerary）信息转交给正确的服务（这既可能是另一个处理程序，也可能是一个出口）。虽然可能在这个线路中需要经过多个服务（例如，数据转换），但是从入口（OnRamp）获取一个消息并且把这个消息发送给一个配置好的出口（OffRamp），这个过程是所有线路处理都必须包涵的。

对于BizTalk来说，这就意味着线路（Itinerary）中的信息必须对应到BizTalk消息的上下文属性（Context Properties），而上下文属性是BizTalk发布/订阅系统的基础。想知道它是如何工作的，请看下面的例子。

示例1: 第一个BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）应用程序

在这个例子中，我们将使用最常见的BizTalk示例：消息根据动态的网络地址（URI）进行路由。想象我们的消息总线需要接收一些消息，并且需要根据这些消息中动态变化的目标网络地址把这些消息路由到不同的物理位置去。（这可能是基于消息的路由，如果我们想要把路由的目标网络地址写在消息内容中，当然也可以写在其他别的地方。）

通常BizTalk解决这种问题德的方法是，创建一个接收端口静态绑定到一个业务流程的接受形状上。在业务流程内部，我们使用表达式形状来修改消息的上下文，来描述传输类型（TransportType）与传输位置（TransportLocation）（就是这里，网络位置，URI）属性。（这也可以通过自定义管道组件完成）然后，在业务流程中使用一个发送形状，这个发送形状将被绑定到一个动态发送端口（Dynamic Send Port）。

如果我们改用BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit），我们首先需要创建一个线路。（事实上，只要是使用BizTalk 企业服务总线工具包，那么这永远是第一个步骤，不论是否能解决问题。）设计这个线路的方式可以参照图5的方式来完成。使用BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）来实现和图5相同的模式有不止一种做法，但是图5中展示的是最直接最方便的。

在这个线路（Itinerary）图中有三个形状：

· 一个入口OnRamp

· 一个线路服务Itinerary Service

· 一个出口OffRamp

当消息被入口（OnRamp）接收，首先要确定处理这个消息所使用的线路（Itinerary）（在我们这个例子中，我们起名为“SimpleItinerary”），根据线路的名字，我们将这个线路与消息关联在一起，BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）调度组件（Dispatcher）会完成这件事，并且开始处理这个消息。

如同前面所介绍的，线路（Itinerary）信息可以直接附着在一个消息中，或者由入口（OnRamp）决定应该应用哪一个。不论哪种方式，每一个入口（OnRamp）都必须关联到一个BizTalk中的接收端口（ReceivePort），在我们这个示例中，我们的接收端口（ReceivePort）叫做“ESBON”。

在这个例子中，我们使用BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）提供的管道来配置接收位置（Receive Location）。在BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）中提供了几个不同的自定义管道来帮助我们实现不同的场景。在这个例子中我们使用管道“ItinerarySelectReceivePassthrough”，这个组件可以帮助我们根据填入的名字搜索正确的线路（Itinerary）信息，并且使用最简单的方式将消息发布到消息数据库（MessageBox）。

“ItinerarySelectReceivePassthrough”管道是使用由BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）提供的名为“ESB Itinerary Selector”的管道组件配置生成的。从管道的角度，BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）提供了不止一个管道组件，这些管道组件适用于不同的线路服务（Itinerary Services）。

如果一个消息没有附加线路（Itinerary）信息，BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）可以使用名为解析器（Resolver）的组件来决定线路（Itinerary）。解析器（Resolver）是一个可以用来动态解析信息的组件（一个继承了“IResolverProvider”接口的类），它的特点是在BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）运行期实现动态解析。在这种情况下，解析器（Resolver）用来决定线路（Itinerary）。在其他情况下，解析器（Resolver）可以用来解析端点信息，使用哪个业务流程，或者应该使用哪个映射（Map）来进行消息转换。解析器（Resolver）是BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）的关键组件，它实现了运行期的动态解析，在整个系统中扮演了关键角色。

“ItinerarySelectReceivePassthrough”管道包含了名为“ESB Itinerary Selector”的管道组件，该组件位于管道处理的第一阶段，解码（Decode）阶段。“ESB Itinerary Selector”管道组件的主要作用就是正确配置线路解析器（Itinerary Resolver）。解析器（Resolver）在BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）中注册了一个全局的字符串前缀“ITINERARY”（类似于网络架构，比如http，ftp等等）。在图7中，可以这样配置解析器（Resolver）“ITINERARY:\\name=SimpleItinerary”，这表示了解析器（Resolver）将在解析器存储中搜索名为“SimpleItinerary”的线路（Itinerary）并进行应用（这些线路存储在SQL Server数据库中）。

 

图 7: 企业服务总线线路选择器（Itinerary Selector）配置

这也意味着我们必须在执行程序之前就把名叫“Simple Itinerary”的线路（Itinerary）存储在系统中（使用Visual Studio的线路设计器就可以完成，也可使用命令行工具）。虽然把使用哪个线路（Itinerary）处理消息硬编码在入口（OnRamp）中这样看起来降低了灵活性，但是由于线路（Itinerary）信息是存储在数据库中的，所以线路（Itinerary）信息可以随时进行修改，BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）在运行期会动态响应这些修改。当然也有解析器（Resolver）可以负责动态解析使用哪个线路（Itinerary），例如商业规则引擎（Business Rules Engine, BRE）解析器，或者UDDI3解析器（UDDI解析器需要有UDDI服务配合）。但是在我们目前的示例中，我们选择采用预配置线路（Itinerary）的方式。

提示： 我们必须把线路关联至接收端口，然后再关联至接收端口（ReceivePort）中的每一个接收位置（ReceiveLocation），使用BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）提供的管道组件。这看起来有些多余。但是从BizTalk架构的角度看，这也是合理的。因为能够附加自定义功能到接收端口（ReceivePort）的，只有适配器和管道组件。为了ESB能够使用而重新编写适配器，这样做需要太多的精力，并不值得，所是通过管道组件来完成这件事还是很合理的。 

总的来说，到现在为止我们已经建立了BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）的入口（OnRamp），使用简单的物理地址（例如，接收位置），这样所有进入这个接收位置的消息都会经过企业服务总线（ESB）提供的管道和管道组件的处理，在处理的过程中，消息会和我们指定的线路（Itinerary）信息进行关联（这依赖于我们在接收位置中对于管道进行的配置）。在被接收端口处理后，消息会进入消息数据库（MessageBox）。之后，下一个步骤中，我们需要一个动态的发送端口（SendPort），订阅这个消息。

在BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）的词典中，我们需要出口（OffRamp）与入口（OnRamp）进行关联。在线路设计器中，我们把入口（OnRamp）和出口（OffRamp）进行关键，就可以实现。和入口（OnRamp）一样，每一个出口（OffRamp）都关联到一个物流发送端口（SendPort）。这个发送端口将需要一个订阅表达式，来订阅由接收端口发布的消息。如图8所示，根据线路情况编写订阅信息。

图 8: 发送端口（SendPort）出口（OffRamp）过滤器（Filter）

在我们的例子中，先跳过线路（Itinerary）“SimpleItinerary”设计的过程，是为了更方便的介绍线路的使用方式。发送端口的过滤器已经实现了入口与出口的关联，所以在我们的例子中，这样线路服务是不需要将消息属性提升至消息上下文（MessageContext）的。代替它的是另一个解析器（Resolver），商业规则引擎（BRE）解析器（Resolver）。

商业规则引擎（BRE）解析器（Resolver）并没有在这里用来解析线路（Itinerary）（因为它已经在它执行的时候被设置了，在进入入口的时候），它用来解析通过出口（OffRamp）发送消息的必须的属性。它负责了端点网络地址（URI）的解析工作，端点的解析在BizTalk中分别由两个不同的上下文属性（MessageContext）组成，传输类型（TransportType）和传输位置（TransportLocation）。

根据图9（请忽略在本例中出现的非真实判断条件1=1，除非你也希望结果永远为真），我们可以看到这个策略（由BizTalk 企业服务总线工具包的字典提供）解析了传输类型（TransportType）和传输位置（TransportLocation）这两个属性

图 9: 通过业务规则引擎（BRE）策略解析数据传输类型（TransportType）与传输位置（TransportLocation）

再次强调，BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）是建立在BizTalk已有的基础构建之上的。在我们这里例子里使用商业规则引擎（BRE），并且可以使用在BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）应用程序中，提供另一个动态层。我们可以设置策略，配置发送端口使用文件适配器（因为两个规则中的操作的属性将会被提升），并且设置文件物理位置为“C:\Labs\InvoiceDrop\%MessageID%.xml”。当一个新版本的策略被部署了，使用商业规则引擎（BRE）解析器（Resolver）的线路服务（Itinerary Service）会自动获取新版本的策略，这样可以简化对于商业规则的改变，不需要重新编译或者部署BizTalk部件。

这是我们可以在BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）中使用解析器的另一种方式，虽然线路可以串起多个服务，但是我们依然可以保证系统能够的灵活性，保证系统在需要根据商业需求改变的时候动态变化。图10为我们再一次展现了“SimpleItinerary”，这一次包括了个步骤的文字解释。

图 10: 简单的线路（Itinerary），及其解释

如果我们从BizTalk的角度审视我们的程序，开发一个业务流程也可以完成相同的功能，但是我们使用了BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit），我们保证了一下特性：

a) 我们搭建了一个具有扩展性的应用程序，服务的提供者和消费者松耦合（比一个典型的BizTalk程序的耦合程度低很多）。

b) 我们使用了标准的BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）技术，并且整个系统更具有客观理性，同时也更直观，整个程序更容易被其他团队所理解。

c) 线路可以动态变化（例如一个新的服务被插入到整个处理过程之中），这个过程不需要任何代码修改，也不需要编译。

如果我们从非BizTalk的角度审视示例程序，可以很快发现BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）提供了标准的方式，描述了服务，使这些服务可以轻松的修改，这些都得益于工具包提供的协调层。

对于一下这个问题：“把入口（OnRamp）与出口（OffRamp）一对一的关联在一起，难道不是点对点的整合吗？”我们的回答是：不。因为我们可以为入口绑定多个接收位置，新的服务消费者可以消费这个服务通过多种不同的方式（例如，不同的端点）而不需要改变原有的消费者。由于使用了商业规则引擎（BRE）解析器（Resolver），出口可以进行动态的修改，除非部署了新版本的商业规则引擎（BRE）策略（策略本身的修改也是全局性的，不需要改变任何BizTalk配置或者是线路信息）。同时线路（Itinerary）本身也可以变化，这不需要任何BizTalk配置进行修改。这意味着线路可以被扩展至多个出口（OffRamps），加入新的消息格式转换，甚至混合进一个业务流程，如果有必要的话。

由BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）应用程序（即使是我们现在这里看到的一个最简单的示例）提供的这些功能保证了我们在进行整合的时候，可以获取比点对点整合方式更高的灵活性。

示例2: 添加一个额外的企业服务总线工具包（ESB Toolkit）功能

BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）为我们提供了诸多的强大功能，其中最强有力的一个，就是可以在不改变任何端点的情况下修改整合应用程序。（尤其是在我们希望进行应用和的同时保持敏捷性的时候，不改变端点更显得尤为重要）。

在这个示例中，我们将会对第一个示例做出两处修改。

1) 线路（Itinerary）信息将从原来的静态硬编码，改变成在入口中动态解析（OnRamp）。

2) 会有一个额外的线路（Itinerary）信息被加入我们的例子，并且会有一个单独的解析器（Resolver）来解析它，最终决定出口（OffRamp）的属性，同时也会添加一个动态的传输在整个消息处理过程中。

我们需要做的第一个修改，就是修改在出口（OnRamp）中的接收管道设置，如图11所示。

图11: 新修改后的入口（OnRamp）管道设置

按照图中所示进行修改后，我们将原有的静态解析，改为了通过商业规则引擎（BRE）进行的动态解析（在线路解析中使用“BRI”前缀）。现在，我们可以在示例程序中，对通过入口（OnRamp）进入的消息应用多个线路（Itineraries）了。在图12中，我们可以看到简单的业务规则策略，它根据消息的SOAP头信息来修改线路（Itinerary）。如果我们想修改，可以随时在策略中修改我们想要指定的线路（Itinerary）。

图 12: 通过业务规则策略进行简单的线路（Itinerary）解析

下面我们来看一下在本实例中新加入的线路（Itinerary）, 如图13所示。

图 13: 稍稍复杂一些的线路（Itinerary）

可以能看到我们添加了一个使用了用来扩展消息（Messaging Extender）的形状。它可以设置为一个或多个解析器。在这种情况下，我们可以再次使用商业规则引擎（BRE）解析器（Resolver），只有在图中所示的这种情况（“SimpleMapResolve”，我们选择了“BREMapResolver”的属性），商业规则引擎（BRE）才被用来解析使用何种映射（Map）来处理消息。

图14为我们展现了上图中所选择的商业规则引擎策略的一部分设置。需要注意的是我们使用了企业服务总线提供的事实（Fact，在规则引擎中类似于属性的概念），来设置转换（BizTalk映射）的方式。

图14: 在商业规则引擎（BRE）中，为解析映射（Map）配置简单的规则

总结一下到现在为止我们使用的企业服务总线工具包（ESB Toolkit）应用程序：

1) 在入口（OnRamp）中动态解析处理消息时所使用的线路（Itinerary），解析过程通过商业规则引擎（BRE）策略完成。

2) 有两个配置好的线路（Itinerary）可以被使用（在不修改现有应用程序的基础上，动态添加更多的线路）。

3) 基于商业规则引擎（BRE），至少有一个线路（Itinerary）可以实现动态解析使用那种映射（Map）来处理消息。

4) 一个商业规则引擎（BRE）策略可以用来决定出口中使用的适配器以及消息发送的目标网络地址（URI）。

在我们的例子中我们使用商业规则引擎（BRE）解析器（Resolver），但是需要记住还有许多其他解析器（Resolver）可以供我们使用（当然我们也可以开发自己的解析器）。这样做的主要目的是使用BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）提供的动态能力，每一个整合都保证是动态的，可扩展，易于维护，复出很小代价就可以修改。

企业服务总线管理门户（ESB Management Portal）

BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）的另一个有价值的功能是它提供了基于ASP.NET技术的门户代码示例。这个门户示例向我们展示了通过门户管理BizTalk 企业服务总线工具包（ BizTalk ESB Toolkit）应用程序的功能。

它包括以下功能：

图15: 企业服务总线（ESB）门户功能

例如，门户可以为开发人员或管理员设置在某种情况下出发的报警（默认是邮件形式）。报警可以为开发人员创建，当出现某种特殊错误时，或者当在某一个指定应用程序发生错误的时候进行提示。

如果安装配置成功，没有错误产生，用户在门户中可以看到所有的消息信息，可以对消息进行编辑并重新提交（如果出现错误的时候，可以对消息进行适当修改来更正错误）。

我们在下图中可以看到门户的截屏图片，图片中展示了门户为用户提供的功能。

 

图16: 企业服务总线（ESB）门户 – 异常报告及图表

图 17: 企业服务总线（ESB）门户 – 错误信息过滤

图18: 企业服务总线（ESB）门户 –显示异常的详细信息

图19: 企业服务总线（ESB）门户 – 管理异常报警和订阅

门户示例也可以由用户根据特定的组织进行扩充和强化，所有在门户中使用的源代码都在企业服务总线工具包（ESB Toolkit）中提供。

值得一提的是，尽管企业服务总线门户作为一个示例程序提供给用户，但是仍然有许多方法可以与企业服务总线的组件进行交互。例如，假设我们有一个订单处理过程，使用SharePoint门户将订单处理进度指标公布给订单处理团队；这样可以在自动化流程处理中可以加入人工处理。凭借企业服务总线工具包（ESB Toolkit）的异常管理框架（Exception Management Framework），你可以创建“监听器”，对订单处理进行监视，抓取异常信息（可以监视技术上发生的异常，也可以监视业务上发生的异常），并且可以把异常信息发布到SharePoint的订单处理门户。

将企业服务总线（ESB）看作一个服务

还有一个使用BizTalk企业服务总线工具包（BizTalk ESB Toolkit）的方式（这种方式可以与本文之前讲到的使用方式结合使用，也可以完全分离单独使用），是直接把工具包中提供的组件作为服务使用。

到目前为止，我们讨论了大多数的企业服务总线（ESB）服务，并把它们当作标准的网络服务（Web Service）。例如，如果我们想要使用一个数据格式转换，而不想在业务流程中硬编码一个映射（Map），或者在.NET代码中硬编码一个映射（Map），那么我们就可以考虑直接调用企业服务总线提供的转换服务。

线路（Itinerary）解析也是以服务方式暴露给用户的，所以我们可以查询这个服务，并且动态获取一个线路（Itinerary）信息，在把消息发送给企业服务总线（ESB）入口（OnRamp）之前，把线路（Itinerary）信息附着在消息上。

事实上BizTalk企业服务总线工具包（BizTalk ESB Toolkit）的功能都是被包装为网络服务（Web Service）提供给用户的，这意味着我们有许多种不同的方式可以使用，配置这些功能。

总结

BizTalk企业服务总线工具包（BizTalk ESB Toolkit）是一个对BizTalk Server强大有力的补充。它建立在BizTalk Server基础之上，提供了强大的功能。我们使用它可以作为基础架构，建立松耦合的协调服务，使整个系统可以根据市场环境的变化，快速实施业务的变更，为我们带来更深入的技术和商业价值。

线路（Itinerary）和线路路由（Itinerary routing）建立在已有的BizTalk特性之上，提供了动态的，易于管理的，有用版本控制的功能层，提供例如路由，消息，协议转换，和处理（业务流程）功能。

线路设计器（Itinerary Designer）使用开发人员易懂的界面与工具集，它集成与Visual Studio之中，可以更好的发挥开发人员的技巧。同时，实现BizTalk企业服务总系工具包（BizTalk ESB Toolkit）线路（Itinerary）处理的组件，建立在BizTalk功能至上，这意味着已经掌握的BizTalk技能可以直接使用。每一个组件不仅具有很高的灵活性，而且可以扩展，可以在必要的时候进行自定义开发。

企业服务总线（ESB）管理门户（Management Portal）可以直接透视企业服务总线的消息处理，同时也添加了强有力的功能，例如有，修改消息后再次提交。企业服务总线把这些关键的功能包装为服务，这样我们可以通过其他BizTalk之外的应用程序对BizTalk企业服务总线工具包进行控制。

BizTalk企业服务总系工具包（BizTalk ESB Toolkit）为服务提供了强大稳定的平台，使服务可以在业务需求发生变更的时候，快速的做出相应。

最后是原文信息：

发布时间 : 2010年2月

作者 : Jon Flanders, MCW Technologies

参与编写的技术专家 :

· Ofer Ashkenazi, Microsoft

· Vinay Balasubramaniam, Microsoft

· Jim Bowyer, Microsoft

· Peter Kelcey, Microsoft

· Brian Loesgen, Microsoft

· Dmitri Ossipov, Microsoft

· Robert Hogg, Black Marble

适用范围 : Microsoft® BizTalk® ESB Toolkit 2.0 and Microsoft BizTalk Server 2009

概览 : BizTalk企业服务总线工具包2.0（ BizTalk ESB Toolkit 2.0）对于BizTalk Server来说是一个非常有意义的补充。它建立在BizTalk Server基础之上，搭建了一个功能强大的平台，为客户带来技术和商业价值，帮助客户搭建新一代的松耦合整合平台。

BizTalk企业服务总线工具包2.0（ BizTalk ESB Toolkit 2.0）为企业中纷繁复杂的服务提供了一个强大稳定的平台，在这个平台之上，服务可以按客户的动态变化。企业服务总线(Enterprise Service Bus, ESB)的首要目标是在各种服务间提供一个通用的协调层，把服务连接在一起。这样，不但可以解决在点对点连接中发生的一系列问题，而且可以将系统的敏捷性整体提升到一个新的档次。想要了解更多的BizTalk企业服务总线工具包2.0（ BizTalk ESB Toolkit 2.0）信息，您可以浏览企业服务总线工具包（ESB Toolkit）的页面 (http://go.microsoft.com/fwlink/?LinkId=154169) ，由Microsoft BizTalk Server 2009 网站提供，也可以参考页面 (http://go.microsoft.com/fwlink/?LinkId=154069) ，由BizTalk Server 开发中心提供。