企业应用集成服务平台白皮书

1、企业应用集成服务平台白皮书 产品特性 企业应用集成服务平台白皮书 发布日期：2004年1月 适用于： BizTalk Server 2004，Visual Studio .NET 以及 Microsoft Office 2003 引言 过去十年间，商务市场在信息技术领域投入了空前巨额的资金。其中，两种不同 的开发方式为这些投资提供了需求驱动：企业框架应用的引入以及国际互联网、 电子邮件和In ternet应用程序的出现。 企业框架应用旨在对各种核心商务运作方式进行重构，其组成元素包括包含供应 链管理（SCM系统在内的广泛应用程序、企业资源规划（ERP系统以及客户关 系管理（CRIM系统。这些精

2、密复杂的应用需要雄厚的资金基础、特殊的技术资 源以及强大的运行架构方可予以实现。对于那些成功部署此类企业框架的公司而 言，其核心业务运行效率将得到显著增强，进而转化为强大的市场竞争实力。 Web应用和电子邮件通常用于实现消息通信与信息交换，这些技术大多基于开放 标准并且相对易于实现。此类开发工作能够为信息通信提供新增功能并使其工作 效率得到增强，所有这些最终将改善办公场所的响应速度与工作效率。 对于遍布各地的各类公司而言，企业应用数量与规模的增长总是伴随着旨在提供 信息交换渠道的计算与网络基础架构的不断扩建。由于多种技术不断涌现所产生 的系统复杂性不仅导致系统本身的多样化，同时也造成了用以使应

3、用程序库中所 存放的信息便于为其它平台、企业员工及合作伙伴与客户予以访问的各类编程资 源和IT预算的紧缺。 由于当今企业内部已建立起广泛的信息处理与通信机制，因此，针对信息的需求 也变得日趋迫切。每一名配备具有In ternet上网能力计算机的信息工作者均能 够访问无限的信息与计算功能，尽管其中某些信息或功能并非与他们的日常商务 工作关系最为密切。用户期望提供的信息技术与他们实际获取的技术之间相互差 距的不断增大，已成为企业应用集成（EAI）与业务流程自动化（BPA项目成为 大多数组织机构内部首要IT任务的主要原因。 目前的问题在于，企业框架应用由数以千计的程序模块、 数据库、带有运行过程 的

4、数据文件、控制单元以及可扩展的严格访问机制所组成。由于相关工作涉及大 量连续的低级别程序开发任务， 因此，开发扩展程序化功能或尝试通过原先系统 中未予定义的方式访问各类信息需要消耗大量资源、时间与资金。 手工实现端到端系统集成是目前在信息交换过程中所采用的流行方式。 那些在接 口应用程序 API 方面具有丰富经验的程序员将负责开发用以访问来源应用程序 数据的定制化应用 （通常采用二进制格式） ；将其映射、 转换为特定的数据结构； 根据要求对这些数据进行操作， 并将其提交至目标应用程序。 正如应用程序本身 那样，这种方式所生成的是一套以程序代码形式存在并执行、 且具有高度针对性 与紧密耦合的功能

5、集合。 此类开发工作具有高度线性化特征；其中每个步骤均 依赖于上一步骤的完成， 并且无法被轻松打断或被分割为多个可以利用分布式资 源分散完成的独立任务。 由此可见， 满足集成项目所产生的不断增长的工作负载 就意味着需要增添更多的编程资源。 集成项目所需消耗的资源范围可以用 N的平方形式予以表示：N*（N-1）/2，其中, N为接口端点数量。如果某一组织机构具有由 20个内部交互端点相连接的全面 啮合系统（这是一个很小的数目），那么，就必须为其开发 190 个程序化内部交 互接口。由于每个集成化接口均为专用模式， 并且采用不具重用性的非模块化编 码结构，因此， 整体编程效率不会随着编程资源的增加

6、而得到相应提高。 随着集 成需求的增加， IT 力量不断被占用，进而导致相关资源及预算不断被耗尽。有 鉴于此，在多数组织机构中， 那些本应由自动化解决方案来实现的功能仍旧通过 手工方式来执行的现象就完全不足为奇了。 一种替代集成方式是部署中间件集成枢纽或队列平台。 此类产品的用途在于利用 预先提供的适配器来捕获企业框架应用的专用数据格式， 并通过中间件平台所提 供的映射、转换与传输机制在应用程序端点之间实现数据交换。 中间件平台同时 还能提供针对事务交换、 事件监控、 错误捕捉及安全特性的支持机制。 尽管此类 平台避免了大量程序编码工作，并将对端点工作方式的了解程度降至最低限度， 然而，它却并

7、非适用于所有情况其造价昂贵、 结构复杂且缺乏通用性。 与端 到端的集成方式相类似， 这种平台需要凭借高度专用化资源方可发挥出其所具备 的潜在效率， 此外，其所创建的集成接口同样具有紧密相关性， 它是将信息与内 部工作机制绑定在一起、 从而传递相互依赖性的封闭系统体系结构的另一种表现 形式。 软件开发团队及终端用户均已认识到， 阻止信息技术在企业内部发挥更高效能的 主要障碍在于将信息提供给多种应用程序或业务流程的处理过程所存在的线性 化特征与昂贵的资金消耗。这种障碍使企业无法创建以处理过程为中心商务环 境，因而无法对其自身进行组织、 监控与调整， 进而无法对商务环境内部的细微 及显著变化做出合理

8、的均衡响应。 所幸的是，一种能够缓解EAI与BPA开发过程中效率低下现象的新型计算范式正 在兴起， 同时， 相关软件标准体系也在快速编纂之中。 这种新型范式在概念定义 上将集成过程从程序层提升到信息（文档）与传输（通信）层。通过将信息从使 用它的应用程序中分离出来，以清晰的文本形式对其进行展现，并采用自描述 XML元数据方式为其赋予含义及结构， 相关信息得以通过任意一种具备 XML元数 据解析能力的应用程序进行处理。 甚至应用程序自身的运行功能和调用方法也可 通过XML形式进行描述与展现，这使其能够在不考虑所处位置、 最初开发方式以 及具体运行平台的情况下自由执行。以上这些便是 WebServ

9、ice 协议、简单对象 访问协议（SOAP以及Web Service定义语言（WSD）所需具备的基本前提。 以业务处理过程为中心的计算方式 这种消息通信范式最为重要的作用之一便是提供面向各种以处理过程为中心的 需求提供一种易于访问的可行解决方案。 置于管理状态下的工作流、 应用集成接 口或传统合作伙伴交互方式能够通过由结构化 XML文档与消息所编制的流程加 以描述、组合及实现。之后，这些消息将根据各自的内容、格式要求和业务规则 进行传输、 转换与处理。 凭借基于这种模型的集成开发平台， 用户不再需要自行 编写用以访问、 映射及转换数据格式的程序代码。 同时，也不再需要理解多种不 同应用程序所使

10、用的API。在这种范式中，不再包含那种需要通过编程方式创建 且具有紧密关联性的硬编码接口， 相反，信息从信息源分离并且可以在任何内部 应用程序中交换 XML和WebService将对企业创建并集成的那些用以控制自身业务运作效率的应 用程序及处理过程所采用的方式产生深远影响。 与此同时，电子邮件和互联网的 出现也使得随时随地交换并访问信息成为可能，XML和WebService能够在应用 程序和业务流程之间实现顺畅的自动化信息交换机制， 而不必考虑这些信息最初 是由何种应用或平台提供的。尽管如此，单就技术而言，XML和WebService只 是一种具备有限功能的技术。 他们无法通过某种简单方式嵌入

11、到组织机构的现有 基础架构当中，提供预期的功能效率，或实现 IT 企业所习以为常的运行性能标 准。只有在那些由为其在嵌入式基础架构中提供应用途径的补充技术和支持技术 所构成的框架结构中予以实现，XML和WebService的价值才能够真正得以发挥。 要使XML和WebService能够在创建以处理过程为中心的灵活业务环境过程中真 正发挥作用，它们所具备的功能就必须嵌入到便于终端用户和开发人员轻松使用 的托管宿主应用程序中。除利用 XML标准与异种系统实现连接的集成化平台外， 软件开发工具必须能够直接生成 WebService，数据库必须具备内建XML元数据 存储能力，人员生产力工具必须能够以透

12、明的方式解析、处理并生成XML文档， SOAP必须充当允许这些组件实现交互的底层消息通信机制。这也正是以处理过 程为中心的基础架构能够增强企业灵活性的原因所在。 商务灵活性是指根据业务变化及时调整并改造企业资源与处理过程， 并通过有序 且不具破坏性的方式对其进行扩大或分解的能力。 以下属性定义了以处理过程为 中心的灵活基础架构所应具备的特征： 端到端处理活动在创建与执行过程中的可见性 具备展现及自描述特征的处理过程组件与功能 将处在不同位置上的各种信息来源与应用功能集成到单一处理过程中的能力 在整个处理过程中具备自动化功能的信息流及事件通知 能够提供工作流服务 能够针对处理过程中的各项活动加以

13、指定、监控及强制的服务等级协议 能够在不干扰处理过程中其它活动的情况下在处理过程中添加、删除或重新 配置各项活动的能力 能够以实时或接近实时的方式进行监控的活动 能够满足各种异常处理需求的处理过程设计方案 能够轻松复制、扩展并伸缩的处理过程 以高效且高性价比的方式部署所有属性的能力 XML Web Services 的角色 Microsoft?公司一直在 XML与 WebService开发领域中处于前沿地位。Microsoft 公司是提交至互联网协会的 Web Services 协议的最初发起人。同时，作为最早 基于XML消肖息通信模式所开发的EAI / B2B和BPA工具之一，Microso

14、ft公司还 引入了 BizTalk? Server 作为企业应用集成服务平台。 比其它软件开发商更进一 步的是， Microsoft 公司承诺在各类产品中应用这些技术，与其他公司相比， Microsoft公司在集成、开发与生产力技术领域中对XML和 WebService技术的 应用要更为显而易见且更加广泛。 新版 BizTalk Server 、 Visual Studio? .NET 和 Microsoft Office 2003 中所包 含的XML与 WebServices功能再次印证了 Microsoft所提出的分布式EAI和BPA 开发与部署活动构想。 这份白皮书探讨了如何在此类应用中

15、实现XML与 WebService技术，并且描述了 作为 Microsoft 企业集成活动基础架构的这三种平台如何通过交互通信的方式 创建以处理过程为中心的计算基础架构。 同时，这份白皮书还介绍了那些能够为 BizTalk Server 提供连接能力、监控机制、性能管理功能、伸缩特性以及容错 支持能力、并使得这种基于XML的集成与处理过程管理体系结构能够遵循IT企 业所惯用的设计与运行性能标准的 Microsoft 技术。 Microsoft公司面向企业集成与BPM所提供的产品 为了实现Microsoft公司所构想的企业集成（EI）、业务处理过程管理（BPM 和商贸伙伴交互（TPI）的开发与实

16、时平台，BizTalk Server与Visual Studio .NET 被紧密集成在一起。它们包含了利用XML和Web Services技术所实现的集成与 业务处理过程自动化功能。 Visual Studio .NET 中增加了大量健壮的应用集成 与工作流开发工具集，而 BizTalk Server则为那些在Visual Studio .NET中所 创建的集成应用程序充当处理过程执行与活动监控引擎。以下列表描述了由 Visual Studio .NET和BizTalk Server 2004联合构成的集成化开发环境（IDE） 中所包含的核心模块。 Visual Studio .NET 中所

17、包含的 BizTalk Server 开发组件： 用以定义文档语义（XML架构）的XML编辑工具 用以将文档动态转换为不同格式且基于XSLT的映射工具 提供文档交换过程中确认、验证、加密、转换及路由功能所需逻辑处理机制 的发布与订阅消息通信基础架构。 这种基础架构同时还应支持消息间的相互关联 及持久性。 用以创建能够支持拖放装配方式的复杂处理过程的图形化业务流程工具 BizTalk Server 环境中所包含的组件： 使用基于XML的XLAN倂且允许对业务处理过程执行语言（BPEL文档执行 导入、导出操作的处理过程执行引擎 用以创建能够按照高度模块化方式加以应用和修改的复杂业务规则集合的业 务

18、规则组合引擎 用以对有关活动消息和处理过程活动状态及历史数据的实时信息进行监控和 查看的健康状态与活动（HAT管理工具 用以生成并分析业务处理过程实时性能指标的业务活动管理 （BAM模块。这 些指标可以是业务处理过程或业务处理过程组件所产生的结果。BAM是针对商务 智能（ BI ）所提供的一种补充技术。 XML与 BizTalk Server 新版BizTalk Server所具备的最重要特性之一便是采用 XMLSchema标准来规范 内部BizTalk Server 文档定义。XML Schem是一套旨在定义 XML文档结构、内 容及语义的规范集合。 BizTalk Server使用XML

19、Schem来为那些将会从外部应用或处理步骤收到或发 出的专有信息格式创建内部结构化语义模型（文档定义）。 BizTalk Server 将 这些内部文档定义存放并发布到一个共享存储库中。 映射工具将负责把与一种应 用信息格式（基于其内部 BizTalk Server 文档定义）相对应的转换机制映射到 另一种格式（同样基于其内部文档定义），以便创建相应的映射。这种转换图同 样存放并发布到一个存储库中。当收到来自另一应用且标明为输入的信息时， BizTalk Server 将进行数据交换，并通过预先存储的映射机制对其执行格式转 换。此后， BizTalk Server 将以要求的格式将这些信息提交

20、至接收应用程序或 处理过程步骤。 当应用于某种一对多或多对多集成需求时， 这种信息枢纽模型的灵活性与高效性 是显而易见的。 举例来说， 某种应用可以生成一份文档， 并在其中包含能够被大 量其它应用以不同方式有选择加以使用的信息。这份文档可以通过 BizTalk Server 的“发布与订阅”功能分发至多种转换管道。借助这些管道，每种文档 实例所需要的信息将依据映射在相应的频道内进行提取与转换。 随后，这些信息 将被发送到不同的应用程序或处理过程。 为这些转换操作提供执行支持的技术同样基于 XML协议标准一一XML Schema SOAP XSLT和 XPATH特别需要说明的是，这些转换的实现方

21、式不涉及任何程序 开发。BizTalk Server 应用组件对XSLT XPATH和XML Schema勺底层复杂性进 行了抽象。这种方式有效的将集成开发过程从一项高度专业化的晦涩程序开发工 作转变为一种易于理解的透明装配活动。 与信息工作者融为一体 XML技术同样被广泛应用到了 Microsoft Office 2003的工作流管理功能当中， 这也正是 Microsoft 为企业提供用以建立以处理过程为中心的基础架构所需工 具这一策略所依赖的另一块基石。 工作流管理是对那些依赖人员与系统之间信息 交流的业务运行方式进行优化的一项专门学科。 由于人力资源在所有组织机构中 均代表着最大一块费用

22、开支， 因此，劳动者生产力的任何提高都会对组织机构的 经济效益与竞争实力带来显著增长。工作流效率低下通常是由以下因素所造成 的： 存在处理过程二重性的纸张文档生成、操作与处理机制 为获取完成某项任务所需的必要信息而造成的延误 由于瓶颈或优先级冲突所造成的延误 造成处理过程瘫痪的不完整或不正确信息 处理过程中各步骤间无法保证的连续依赖性 与其它技术相比， 通过允许参与者直接访问那些原先需要借助中介资源访问的功 能和信息，Web技术大大降低了成本，并且显著提高了工作流任务的执行效率。 然而，基于Web勺业务功能与信息访问方式最适用于那些存在分散性且生命周期 短暂的业务活动即处理过程中的所有或多数步

23、骤均可在发起者的控制下一 次完成。此类活动的典型示例包括采购商品或检查订单状态。尽管如此，基于 Web的交互方式仍然无法适应许多需要满足特定文档需求和复杂处理过程动态 性要求的工作流场景。 复杂工作流的文档动态性通常具备以下特征： 文档属于某种由多个步骤组成且需要长时间执行的处理过程，在此类处理过 程中，信息由多个参与者共同生成， 需要在不同参阅者之间来回传递， 并且会定 期进行修改或扩展。 文档可能需要在处理过程中任意步骤内的初始上下文中加以引用。 文档传递与处理需求取决于文档中所包含信息 来自于其它信息中的信息将被归入文档本身（自动文档记录） 文档和参与者标识将在处理过程中的某个环节上进行

24、验证。 此类复杂工作流的典型示例包括费用报表处理、 保险单申请、财务报表生成、 商 业银行信用证发放、 捐税收入处理、 贷款申请以及催询单处理等。 在这些工作流 中，通常存在多份需要在整个处理过程生命周期中予以保留文档及附件， 对它们 的访问会在很长一段时间内存在，并且将会涉及多个参与方及应用程序。 相比之下， 尽管基于纸张的文档方式会大大降低处理过程的执行效率， 然而它却 能够通过多种方式满足包含多个步骤、 需要多方参与且长时间运行的工作流所存 在的基本文档需求： 以最初形式及上下文关系保存信息 在不影响原始文档完整性的前提下合并汇总不同文档或文档中所包含的特定 信息。 对文档本身以及创建或

25、修改该文档的各方进行验证 提供易于理解的信息，此类信息易于通过文档中的元数据（定义、说明、引 用）关联性进行处理与传递 确保提供独立于软件应用程序的内容访问能力 为简化具备全数字特征的工作流处理过程， 必须通过一种参与者可以接受且易于 访问的方式对这些文档特征及工作流动态特性进行模拟。 此外，只有当信息能够 通过自动化、 透明方式在不同应用之间进行交换与处理时， 数字化信息所具备的 真正优势与效率才能体现出来。 利用文字处理或电子表格程序创建的表单可以非 常轻松的进行填写，然而，其中所输入的信息却并不易于理解，换言之，在缺少 程序或人为干预的情况下，这些信息很难被相同应用程序或其它应用程序所处

26、 理。这正是另一种常见计算问题的具体表现，即如何确保数字化信息便于理解、 具备可用功能、 且独立于任何托管应用程序。 与模拟复杂工作流中基于纸张文档 管理方式所具备的特征一样，这种问题也被纳入到了 XML解决方案的涉及范畴之 内。 更加明确的说，这种问题通过 XMLSchema和XSLT所提供的功能得到了解决，这 与 BizTalk Server 在应用程序数据交换过程中利用它们将一种文档格式的结构 与内容转换为另一种结构与内容所采用的方式完全相同。 如果应用程序本身可以 利用其所特有的架构定义和处理指令来生成并解析 XML文档，那么，它们亦可根 据在文档中所发现的信息和元数据 （例如，在文档

27、收条中检查根节点并按照可识 别节点的脚本指令进行处理） 来实现事件级交互。 此种情况下， 应用程序应当能 够通过协商方式在应用程序以及应用程序与参与者之间执行自动化信息处理功 这是 Web Services 背后的基本概念。事件级交互基于文档本身所包含的嵌入式 处理指令。 由于这些处理指令可以由对其进行交换的应用程序来执行， 因此，不 但基于纸张的文档管理方式所具备的特征得到了保持， 同时，文书处理工作 （一 项通常需要按照更为复杂的格式要求来进行内容分析与现有信息重构的任务） 的 繁重负担也得到了避免。借助面向XML处理的内建应用支持能力，多数分析任务 以及所有信息重构工作均可在限制用户只能

28、与单一任务进行交互的前提下交由 应用程序来完成：执行他们需要在工作流中负责完成的决定性操作。 一旦应用程序具备全面XML支持能力，其处理过程执行效率将得到显著提升。这 种执行效率的提升具有重要意义， 在即将发布的 Microsoft Office 2003 中， Word 和Excel将采用通过架构定义文件实现的XML作为内建文档格式。由于从本质上 重新定义了功能概念以及这些应用程序所具备的功能，因此，XML允许Word和 Excel像网络客户端那样（类似于 Web浏览器或电子邮件客户端的方式）进行工 作，并且允许它们与包括自身在内具有各种来源的 XMLW息进行复杂的自动交互 操作。显然，由于

29、这些应用程序中本身部署了XML生成于组织机构内部的信息 质量与可用性也将立即得到提高。 利用 Microsoft InfoPath 实现基于工作流服务 在Office 2003 中，Microsoft引入了 InfoPath?，这是一种基于 XML的表单应 用程序，其用途在于满足复杂的工作流文档需求。一个 InfoPath 表单模板由一 个或多个底层架构和XSLT样式表，以及业务逻辑和控制脚本组成。这种模板将 通过以下方式对在其基础上创建的表单运行方式加以控制： 分配数据类型，限制并验证允许在表单中输入的数据取值 控制数据记录间的相互依赖性，并激活表单中的特定区域 生成自动获得、来自其它数据源

30、或通过计算得出的取值 调用事件、提示及指令 提供针对远程信息源的访问机制 支持使用数字签名 当 InfoPath 表单被填写时，它将生成一个由输入信息、获取信息、可选数字签 名以及由表单模板根据有关事件、提示与指令生成的相关数据所组成的XML 文 档。同时，这个文档还将包含针对相关架构的引用，以便允许其他应用程序（包 括 BizTalk Server ）通过各自的架构对该文档进行验证。这个由 InfoPath 创建 的XML文档通过以下方式模拟了传统工作流中的纸张特征： 一份最初经过数字签名的文档将始终保存在其创建者手中 该文档可以同其签名一道分发给所有相关人员，并确保其不会遭到未经授权 的修

31、改 文档内容具备自描述特征，它可以基于自身所包含的信息进行处理和传递 该文档能够在维持初始完整性的情况下与其它XML文档相互结合 除解决前面所介绍的许多围绕工作流效率低下的常见问题外， InfoPath 还具备 了创建能够满足几乎所有组织机构性能与运行需求的协同工作流的能力。当 InfoPath生成的XML文档与BizTalk Server所提供的编排消息通信方式和活动 机制相结合时，它们的交互功能将通过相互利用的方式实现前所未有的工作流执 行效率。 与 Visual Studio.Net 实现集成 在 BizTalk Server 2004 中，业务流程设计器模块与 Visual Studi

32、o .NET 实现 了全面集成。 凭借其所具备的扩展功能， 业务流程设计程序模块提供了一种全新 的集成或处理过程装配工作区，这种工作区能够通过图形方式展现与实现对象 （如消息管道、端口和架构）相绑定的设计逻辑。 尽管 Visual Studio .NET 属于一种编程环境，然而，实现集成需求或处理过程 设计的方法却与常规程序开发技术不尽相同。 作为一种替代产品， 业务流程设计 程序能够绘制逻辑流程图以及实现消息通信范式（一种用以发送、接收、检查、 转换XML消息与文档的模型）所需的装配组件。此外，针对高度复杂功能（例如 需要两步提交的事务以及组件相关性等） 的实现机制可以由平台自身提供从 而避

33、免了手工编写实现此类功能的复杂程序代码。 通过这种方式创建的集成接口和业务处理过程相互独立且采用松耦合方式。 每条 消息事件及其实现绑定在功能上与其它消息事件和实现绑定都是相互独立的。 针 对特定耦合机制所进行的修改不会对整体处理逻辑或其它绑定的完整性造成影 响。这样一来，对于在 BizTalk Server 环境中所开发的集成接口或处理过程进 行修改或完全重用就变成了一项非常简单直接的工作。 在以往的处理过程开发过 程中，复杂的集成方式与处理过程将被包含在晦涩难懂的程序代码中。 此类代码 结合了端点对象结构、 处理过程流程逻辑、 数据格式转换机制、 业务规则以及传 输架构绑定。 如果需要对该

34、代码的某一方面进行修改， 整个代码模块的完整性就 会遭到破坏。 修改代码可能导致错误的风险一直是软件开发的缺陷之一， 同时也 是导致用户在根据业务需求变化进行处理过程后续修改时犹豫不决的主要原因。 当整个开发环境以及通过这种开发环境所创建的应用程序变为透明方式且采用 松耦合方式后，这种情况将不复存在。 通过引入 BizTalk Server 2004 业务规则编辑器（ Business Rules Composer ） 模块所包含的新增功能组件， 这种暴露式模块化开发环境所具备的功能得到了进 一步增强。业务规则编辑器由用以通过转发链接口模型创建并处理复杂规则集合 的业务规则编辑器和引擎构成。用

35、以驱动特定活动或功能的规则集合（或“策 略”）由业务规则组合程序创建，并将成为能够在 BizTalk Server 编排程序中 加以引用的资源对象。业务规则的创建与实施过程中贯穿着透明和松耦合原则。 一套结合到 BizTalk Server 业务流程程序中的规则集合可以在设计和运行过程 中进行查看、 修改或替换， 并且不会对处理过程的其它方面造成任何影响， 不会 中断相关处理过程的任何运行实例。 由暴露式模块化规则引擎针对业务处理过程修改所提供的灵活性具有非常重要 的意义。在以往的应用开发过程中， 业务规则逻辑被嵌入到程序代码当中， 并且 几乎无法在不改变代码本身的情况下进行修改， 这种开发方

36、式消耗了大量时间与 资源，并且可能导致无法预见的程序执行方式。 由于针对业务处理过程生命周期 的绝大多数修改均属于业务规则的修改（区别于技术方面的修改），因此，将业 务规则完全独立于程序代码以外的能力， 或者任何一种处理过程实现机制都将显 著提高业务处理过程在其整个生命周期内管理与运行效率。 业务活动监控 一旦集成接口或业务处理过程被创建， 集成应用程序或处理过程的运行版本便会 由 Visual Studio .NET 生成，同时由 BizTalk Server 执行引擎负责将其实例化 并进行管理。借助 BizTalk Server 运行时环境，数以千计的短期与长期业务、 文档交换及处理过程实例便可在任意指定时刻发生。 跟踪、监控并确保这些活动 的持续性是处理过程执行引擎所必备的功能同是也是 BizTalk Server 2004 超越其它产品的独特之处。 健康状况与活动跟踪（HAT和业务活动监控（BAM是两种旨在提供审计与分析 机制的全新模块。健康状况与活动跟踪（HAT模块通过健壮的查询机制来提供 历史活动与实时活动视图， 从而展现有关被查询处理过程和交换活动步骤的全面 信息。 业务活动管理模块是一种O