引言
过去十年间，商务市场在信息技术领域投入了空前巨额的资金。其中，两种不同的开发方式为这些投资提供了需求驱动：企业框架应用的引入以及国际互联网、电子邮件和Internet应用程序的出现。
企业框架应用旨在对各种核心商务运作方式进行重构，其组成元素包括包含供应链管理（SCM）系统在内的广泛应用程序、企业资源规划（ERP）系统以及客户关系管理（CRM）系统。这些精密复杂的应用需要雄厚的资金基础、特殊的技术资源以及强大的运行架构方可予以实现。对于那些成功部署此类企业框架的公司而言，其核心业务运行效率将得到显著增强，进而转化为强大的市场竞争实力。
Web应用和电子邮件通常用于实现消息通信与信息交换，这些技术大多基于开放标准并且相对易于实现。此类开发工作能够为信息通信提供新增功能并使其工作效率得到增强，所有这些最终将改善办公场所的响应速度与工作效率。
对于遍布各地的各类公司而言，企业应用数量与规模的增长总是伴随着旨在提供信息交换渠道的计算与网络基础架构的不断扩建。由于多种技术不断涌现所产生的系统复杂性不仅导致系统本身的多样化，同时也造成了用以使应用程序库中所存放的信息便于为其它平台、企业员工及合作伙伴与客户予以访问的各类编程资源和IT预算的紧缺。
由于当今企业内部已建立起广泛的信息处理与通信机制，因此，针对信息的需求也变得日趋迫切。每一名配备具有Internet上网能力计算机的信息工作者均能够访问无限的信息与计算功能，尽管其中某些信息或功能并非与他们的日常商务工作关系最为密切。用户期望提供的信息技术与他们实际获取的技术之间相互差距的不断增大，已成为企业应用集成（EAI）与业务流程自动化（BPA）项目成为大多数组织机构内部首要IT任务的主要原因。
目前的问题在于，企业框架应用由数以千计的程序模块、数据库、带有运行过程的数据文件、控制单元以及可扩展的严格访问机制所组成。由于相关工作涉及大量连续的低级别程序开发任务，因此，开发扩展程序化功能或尝试通过原先系统中未予定义的方式访问各类信息需要消耗大量资源、时间与资金。
手工实现端到端系统集成是目前在信息交换过程中所采用的流行方式。那些在接口应用程序API方面具有丰富经验的程序员将负责开发用以访问来源应用程序数据的定制化应用（通常采用二进制格式）；将其映射、转换为特定的数据结构；根据要求对这些数据进行操作，并将其提交至目标应用程序。正如应用程序本身那样，这种方式所生成的是一套以程序代码形式存在并执行、且具有高度针对性与紧密耦合的功能集合。 此类开发工作具有高度线性化特征；其中每个步骤均依赖于上一步骤的完成，并且无法被轻松打断或被分割为多个可以利用分布式资源分散完成的独立任务。由此可见，满足集成项目所产生的不断增长的工作负载就意味着需要增添更多的编程资源。
集成项目所需消耗的资源范围可以用N的平方形式予以表示：N* (N-1)/2，其中，N为接口端点数量。如果某一组织机构具有由20个内部交互端点相连接的全面啮合系统（这是一个很小的数目），那么，就必须为其开发190个程序化内部交互接口。由于每个集成化接口均为专用模式，并且采用不具重用性的非模块化编码结构，因此，整体编程效率不会随着编程资源的增加而得到相应提高。随着集成需求的增加，IT力量不断被占用，进而导致相关资源及预算不断被耗尽。有鉴于此，在多数组织机构中，那些本应由自动化解决方案来实现的功能仍旧通过手工方式来执行的现象就完全不足为奇了。
一种替代集成方式是部署中间件集成枢纽或队列平台。此类产品的用途在于利用预先提供的适配器来捕获企业框架应用的专用数据格式，并通过中间件平台所提供的映射、转换与传输机制在应用程序端点之间实现数据交换。中间件平台同时还能提供针对事务交换、事件监控、错误捕捉及安全特性的支持机制。尽管此类平台避免了大量程序编码工作，并将对端点工作方式的了解程度降至最低限度，然而，它却并非适用于所有情况——其造价昂贵、结构复杂且缺乏通用性。与端到端的集成方式相类似，这种平台需要凭借高度专用化资源方可发挥出其所具备的潜在效率，此外，其所创建的集成接口同样具有紧密相关性，它是将信息与内部工作机制绑定在一起、从而传递相互依赖性的封闭系统体系结构的另一种表现形式。
软件开发团队及终端用户均已认识到，阻止信息技术在企业内部发挥更高效能的主要障碍在于将信息提供给多种应用程序或业务流程的处理过程所存在的线性化特征与昂贵的资金消耗。这种障碍使企业无法创建以处理过程为中心商务环境，因而无法对其自身进行组织、监控与调整，进而无法对商务环境内部的细微及显著变化做出合理的均衡响应。
所幸的是，一种能够缓解EAI与BPA开发过程中效率低下现象的新型计算范式正在兴起，同时，相关软件标准体系也在快速编纂之中。这种新型范式在概念定义上将集成过程从程序层提升到信息（文档）与传输（通信）层。通过将信息从使用它的应用程序中分离出来，以清晰的文本形式对其进行展现，并采用自描述XML元数据方式为其赋予含义及结构，相关信息得以通过任意一种具备XML元数据解析能力的应用程序进行处理。甚至应用程序自身的运行功能和调用方法也可通过XML形式进行描述与展现，这使其能够在不考虑所处位置、最初开发方式以及具体运行平台的情况下自由执行。以上这些便是Web Service协议、简单对象访问协议（SOAP）以及Web Service定义语言（WSDL）所需具备的基本前提。
以业务处理过程为中心的计算方式
这种消息通信范式最为重要的作用之一便是提供面向各种以处理过程为中心的需求提供一种易于访问的可行解决方案。置于管理状态下的工作流、应用集成接口或传统合作伙伴交互方式能够通过由结构化XML文档与消息所编制的流程加以描述、组合及实现。之后，这些消息将根据各自的内容、格式要求和业务规则进行传输、转换与处理。凭借基于这种模型的集成开发平台，用户不再需要自行编写用以访问、映射及转换数据格式的程序代码。同时，也不再需要理解多种不同应用程序所使用的API。在这种范式中，不再包含那种需要通过编程方式创建且具有紧密关联性的硬编码接口，相反，信息从信息源分离并且可以在任何内部应用程序中交换
XML和Web Service将对企业创建并集成的那些用以控制自身业务运作效率的应用程序及处理过程所采用的方式产生深远影响。与此同时，电子邮件和互联网的出现也使得随时随地交换并访问信息成为可能，XML和Web Service能够在应用程序和业务流程之间实现顺畅的自动化信息交换机制，而不必考虑这些信息最初是由何种应用或平台提供的。尽管如此，单就技术而言，XML和Web Service只是一种具备有限功能的技术。他们无法通过某种简单方式嵌入到组织机构的现有基础架构当中，提供预期的功能效率，或实现IT企业所习以为常的运行性能标准。只有在那些由为其在嵌入式基础架构中提供应用途径的补充技术和支持技术所构成的框架结构中予以实现，XML和Web Service的价值才能够真正得以发挥。
要使XML和Web Service能够在创建以处理过程为中心的灵活业务环境过程中真正发挥作用，它们所具备的功能就必须嵌入到便于终端用户和开发人员轻松使用的托管宿主应用程序中。除利用XML标准与异种系统实现连接的集成化平台外，软件开发工具必须能够直接生成Web Service，数据库必须具备内建XML元数据存储能力，人员生产力工具必须能够以透明的方式解析、处理并生成XML文档，SOAP必须充当允许这些组件实现交互的底层消息通信机制。这也正是以处理过程为中心的基础架构能够增强企业灵活性的原因所在。
商务灵活性是指根据业务变化及时调整并改造企业资源与处理过程，并通过有序且不具破坏性的方式对其进行扩大或分解的能力。以下属性定义了以处理过程为中心的灵活基础架构所应具备的特征：
· 端到端处理活动在创建与执行过程中的可见性
· 具备展现及自描述特征的处理过程组件与功能
· 将处在不同位置上的各种信息来源与应用功能集成到单一处理过程中的能力
· 在整个处理过程中具备自动化功能的信息流及事件通知
· 能够提供工作流服务
· 能够针对处理过程中的各项活动加以指定、监控及强制的服务等级协议
· 能够在不干扰处理过程中其它活动的情况下在处理过程中添加、删除或重新配置各项活动的能力
· 能够以实时或接近实时的方式进行监控的活动
· 能够满足各种异常处理需求的处理过程设计方案
· 能够轻松复制、扩展并伸缩的处理过程
· 以高效且高性价比的方式部署所有属性的能力
XML Web Services的角色
Microsoft®公司一直在XML与Web Service开发领域中处于前沿地位。Microsoft公司是提交至互联网协会的Web Services协议的最初发起人。同时，作为最早基于XML消息通信模式所开发的EAI / B2B和BPA工具之一，Microsoft公司还引入了BizTalk® Server作为企业应用集成服务平台。比其它软件开发商更进一步的是，Microsoft公司承诺在各类产品中应用这些技术，与其他公司相比，Microsoft公司在集成、开发与生产力技术领域中对XML和Web Service技术的应用要更为显而易见且更加广泛。
新版BizTalk Server、Visual Studio® .NET和Microsoft Office 2003中所包含的XML与Web Services功能再次印证了Microsoft所提出的分布式EAI和BPA开发与部署活动构想。
这份白皮书探讨了如何在此类应用中实现XML与Web Service技术，并且描述了作为Microsoft企业集成活动基础架构的这三种平台如何通过交互通信的方式创建以处理过程为中心的计算基础架构。同时，这份白皮书还介绍了那些能够为BizTalk Server提供连接能力、监控机制、性能管理功能、伸缩特性以及容错支持能力、并使得这种基于XML的集成与处理过程管理体系结构能够遵循IT企业所惯用的设计与运行性能标准的Microsoft技术。
Microsoft公司面向企业集成与BPM所提供的产品
为了实现Microsoft公司所构想的企业集成（EI）、业务处理过程管理（BPM）和商贸伙伴交互（TPI）的开发与实时平台，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中所包含的BizTalk Server开发组件：
· 用以定义文档语义（XML架构）的XML编辑工具
· 用以将文档动态转换为不同格式且基于XSLT的映射工具
· 提供文档交换过程中确认、验证、加密、转换及路由功能所需逻辑处理机制的发布与订阅消息通信基础架构。这种基础架构同时还应支持消息间的相互关联及持久性。
· 用以创建能够支持拖放装配方式的复杂处理过程的图形化业务流程工具
BizTalk Server环境中所包含的组件：
· 使用基于XML的XLANG并且允许对业务处理过程执行语言（BPEL）文档执行导入、导出操作的处理过程执行引擎
· 用以创建能够按照高度模块化方式加以应用和修改的复杂业务规则集合的业务规则组合引擎
· 用以对有关活动消息和处理过程活动状态及历史数据的实时信息进行监控和查看的健康状态与活动（HAT）管理工具
· 用以生成并分析业务处理过程实时性能指标的业务活动管理（BAM）模块。这些指标可以是业务处理过程或业务处理过程组件所产生的结果。BAM是针对商务智能（BI）所提供的一种补充技术。
XML与BizTalk Server
新版BizTalk Server所具备的最重要特性之一便是采用XML Schema标准来规范内部BizTalk Server文档定义。XML Schema是一套旨在定义XML文档结构、内容及语义的规范集合。
BizTalk Server使用XML Schema来为那些将会从外部应用或处理步骤收到或发出的专有信息格式创建内部结构化语义模型（文档定义）。BizTalk Server将这些内部文档定义存放并发布到一个共享存储库中。映射工具将负责把与一种应用信息格式（基于其内部BizTalk Server文档定义）相对应的转换机制映射到另一种格式（同样基于其内部文档定义），以便创建相应的映射。这种转换图同样存放并发布到一个存储库中。当收到来自另一应用且标明为输入的信息时，BizTalk Server将进行数据交换，并通过预先存储的映射机制对其执行格式转换。此后，BizTalk Server将以要求的格式将这些信息提交至接收应用程序或处理过程步骤。
当应用于某种一对多或多对多集成需求时，这种信息枢纽模型的灵活性与高效性是显而易见的。举例来说，某种应用可以生成一份文档，并在其中包含能够被大量其它应用以不同方式有选择加以使用的信息。这份文档可以通过BizTalk Server的“发布与订阅”功能分发至多种转换管道。借助这些管道，每种文档实例所需要的信息将依据映射在相应的频道内进行提取与转换。随后，这些信息将被发送到不同的应用程序或处理过程。
为这些转换操作提供执行支持的技术同样基于XML协议标准——XML Schema、SOAP、XSLT和XPATH。特别需要说明的是，这些转换的实现方式不涉及任何程序开发。BizTalk Server应用组件对XSLT、XPATH和XML Schema的底层复杂性进行了抽象。这种方式有效的将集成开发过程从一项高度专业化的晦涩程序开发工作转变为一种易于理解的透明装配活动。
与信息工作者融为一体
XML技术同样被广泛应用到了Microsoft Office 2003的工作流管理功能当中，这也正是Microsoft为企业提供用以建立以处理过程为中心的基础架构所需工具这一策略所依赖的另一块基石。工作流管理是对那些依赖人员与系统之间信息交流的业务运行方式进行优化的一项专门学科。由于人力资源在所有组织机构中均代表着最大一块费用开支，因此，劳动者生产力的任何提高都会对组织机构的经济效益与竞争实力带来显著增长。工作流效率低下通常是由以下因素所造成的：
· 存在处理过程二重性的纸张文档生成、操作与处理机制
· 为获取完成某项任务所需的必要信息而造成的延误
· 由于瓶颈或优先级冲突所造成的延误
· 造成处理过程瘫痪的不完整或不正确信息
· 处理过程中各步骤间无法保证的连续依赖性
与其它技术相比，通过允许参与者直接访问那些原先需要借助中介资源访问的功能和信息，Web技术大大降低了成本，并且显著提高了工作流任务的执行效率。然而，基于Web的业务功能与信息访问方式最适用于那些存在分散性且生命周期短暂的业务活动——即处理过程中的所有或多数步骤均可在发起者的控制下一次完成。此类活动的典型示例包括采购商品或检查订单状态。尽管如此，基于Web的交互方式仍然无法适应许多需要满足特定文档需求和复杂处理过程动态性要求的工作流场景。
复杂工作流的文档动态性通常具备以下特征：
· 文档属于某种由多个步骤组成且需要长时间执行的处理过程，在此类处理过程中，信息由多个参与者共同生成，需要在不同参阅者之间来回传递，并且会定期进行修改或扩展。
· 文档可能需要在处理过程中任意步骤内的初始上下文中加以引用。
· 文档传递与处理需求取决于文档中所包含信息
· 来自于其它信息中的信息将被归入文档本身（自动文档记录）
· 文档和参与者标识将在处理过程中的某个环节上进行验证。
此类复杂工作流的典型示例包括费用报表处理、保险单申请、财务报表生成、商业银行信用证发放、捐税收入处理、贷款申请以及催询单处理等。在这些工作流中，通常存在多份需要在整个处理过程生命周期中予以保留文档及附件，对它们的访问会在很长一段时间内存在，并且将会涉及多个参与方及应用程序。
相比之下，尽管基于纸张的文档方式会大大降低处理过程的执行效率，然而它却能够通过多种方式满足包含多个步骤、需要多方参与且长时间运行的工作流所存在的基本文档需求：
· 以最初形式及上下文关系保存信息
· 在不影响原始文档完整性的前提下合并汇总不同文档或文档中所包含的特定信息。
· 对文档本身以及创建或修改该文档的各方进行验证
· 提供易于理解的信息，此类信息易于通过文档中的元数据（定义、说明、引用）关联性进行处理与传递
· 确保提供独立于软件应用程序的内容访问能力
为简化具备全数字特征的工作流处理过程，必须通过一种参与者可以接受且易于访问的方式对这些文档特征及工作流动态特性进行模拟。此外，只有当信息能够通过自动化、透明方式在不同应用之间进行交换与处理时，数字化信息所具备的真正优势与效率才能体现出来。利用文字处理或电子表格程序创建的表单可以非常轻松的进行填写，然而，其中所输入的信息却并不易于理解，换言之，在缺少程序或人为干预的情况下，这些信息很难被相同应用程序或其它应用程序所处理。这正是另一种常见计算问题的具体表现，即如何确保数字化信息便于理解、具备可用功能、且独立于任何托管应用程序。与模拟复杂工作流中基于纸张文档管理方式所具备的特征一样，这种问题也被纳入到了XML解决方案的涉及范畴之内。
更加明确的说，这种问题通过XML Schema和XSLT所提供的功能得到了解决，这与BizTalk Server在应用程序数据交换过程中利用它们将一种文档格式的结构与内容转换为另一种结构与内容所采用的方式完全相同。如果应用程序本身可以利用其所特有的架构定义和处理指令来生成并解析XML文档，那么，它们亦可根据在文档中所发现的信息和元数据（例如，在文档收条中检查根节点并按照可识别节点的脚本指令进行处理）来实现事件级交互。此种情况下，应用程序应当能够通过协商方式在应用程序以及应用程序与参与者之间执行自动化信息处理功能。
这是Web Services背后的基本概念。事件级交互基于文档本身所包含的嵌入式处理指令。由于这些处理指令可以由对其进行交换的应用程序来执行，因此，不但基于纸张的文档管理方式所具备的特征得到了保持，同时，文书处理工作（一项通常需要按照更为复杂的格式要求来进行内容分析与现有信息重构的任务）的繁重负担也得到了避免。借助面向XML处理的内建应用支持能力，多数分析任务以及所有信息重构工作均可在限制用户只能与单一任务进行交互的前提下交由应用程序来完成：执行他们需要在工作流中负责完成的决定性操作。
一旦应用程序具备全面XML支持能力，其处理过程执行效率将得到显著提升。这种执行效率的提升具有重要意义，在即将发布的Microsoft Office 2003中，Word和Excel将采用通过架构定义文件实现的XML作为内建文档格式。由于从本质上重新定义了功能概念以及这些应用程序所具备的功能，因此，XML允许Word和Excel像网络客户端那样（类似于Web浏览器或电子邮件客户端的方式）进行工作，并且允许它们与包括自身在内具有各种来源的XML信息进行复杂的自动交互操作。显然，由于这些应用程序中本身部署了XML，生成于组织机构内部的信息质量与可用性也将立即得到提高。
利用Microsoft InfoPath实现基于工作流服务
在Office 2003中，Microsoft引入了InfoPath™，这是一种基于XML的表单应用程序，其用途在于满足复杂的工作流文档需求。一个InfoPath表单模板由一个或多个底层架构和XSLT样式表，以及业务逻辑和控制脚本组成。这种模板将通过以下方式对在其基础上创建的表单运行方式加以控制：
· 分配数据类型，限制并验证允许在表单中输入的数据取值
· 控制数据记录间的相互依赖性，并激活表单中的特定区域
· 生成自动获得、来自其它数据源或通过计算得出的取值
· 调用事件、提示及指令
· 提供针对远程信息源的访问机制
· 支持使用数字签名
当InfoPath表单被填写时，它将生成一个由输入信息、获取信息、可选数字签名以及由表单模板根据有关事件、提示与指令生成的相关数据所组成的XML文档。同时，这个文档还将包含针对相关架构的引用，以便允许其他应用程序（包括BizTalk Server）通过各自的架构对该文档进行验证。这个由InfoPath创建的XML文档通过以下方式模拟了传统工作流中的纸张特征：
· 一份最初经过数字签名的文档将始终保存在其创建者手中
· 该文档可以同其签名一道分发给所有相关人员，并确保其不会遭到未经授权的修改
· 文档内容具备自描述特征，它可以基于自身所包含的信息进行处理和传递
· 该文档能够在维持初始完整性的情况下与其它XML文档相互结合
除解决前面所介绍的许多围绕工作流效率低下的常见问题外，InfoPath还具备了创建能够满足几乎所有组织机构性能与运行需求的协同工作流的能力。当InfoPath生成的XML文档与BizTalk Server所提供的编排消息通信方式和活动机制相结合时，它们的交互功能将通过相互利用的方式实现前所未有的工作流执行效率。
与Visual Studio.Net实现集成
在BizTalk Server 2004中，业务流程设计器模块与Visual Studio .NET实现了全面集成。凭借其所具备的扩展功能，业务流程设计程序模块提供了一种全新的集成或处理过程装配工作区，这种工作区能够通过图形方式展现与实现对象（如消息管道、端口和架构）相绑定的设计逻辑。
尽管Visual Studio .NET属于一种编程环境，然而，实现集成需求或处理过程设计的方法却与常规程序开发技术不尽相同。作为一种替代产品，业务流程设计程序能够绘制逻辑流程图以及实现消息通信范式（一种用以发送、接收、检查、转换XML消息与文档的模型）所需的装配组件。此外，针对高度复杂功能（例如需要两步提交的事务以及组件相关性等）的实现机制可以由平台自身提供——从而避免了手工编写实现此类功能的复杂程序代码。
通过这种方式创建的集成接口和业务处理过程相互独立且采用松耦合方式。每条消息事件及其实现绑定在功能上与其它消息事件和实现绑定都是相互独立的。针对特定耦合机制所进行的修改不会对整体处理逻辑或其它绑定的完整性造成影响。这样一来，对于在BizTalk Server环境中所开发的集成接口或处理过程进行修改或完全重用就变成了一项非常简单直接的工作。在以往的处理过程开发过程中，复杂的集成方式与处理过程将被包含在晦涩难懂的程序代码中。此类代码结合了端点对象结构、处理过程流程逻辑、数据格式转换机制、业务规则以及传输架构绑定。如果需要对该代码的某一方面进行修改，整个代码模块的完整性就会遭到破坏。修改代码可能导致错误的风险一直是软件开发的缺陷之一，同时也是导致用户在根据业务需求变化进行处理过程后续修改时犹豫不决的主要原因。当整个开发环境以及通过这种开发环境所创建的应用程序变为透明方式且采用松耦合方式后，这种情况将不复存在。
通过引入BizTalk Server 2004业务规则编辑器（Business Rules Composer）模块所包含的新增功能组件，这种暴露式模块化开发环境所具备的功能得到了进一步增强。业务规则编辑器由用以通过转发链接口模型创建并处理复杂规则集合的业务规则编辑器和引擎构成。用以驱动特定活动或功能的规则集合（或“策略”）由业务规则组合程序创建，并将成为能够在BizTalk Server编排程序中加以引用的资源对象。业务规则的创建与实施过程中贯穿着透明和松耦合原则。一套结合到BizTalk Server业务流程程序中的规则集合可以在设计和运行过程中进行查看、修改或替换，并且不会对处理过程的其它方面造成任何影响，不会中断相关处理过程的任何运行实例。
由暴露式模块化规则引擎针对业务处理过程修改所提供的灵活性具有非常重要的意义。在以往的应用开发过程中，业务规则逻辑被嵌入到程序代码当中，并且几乎无法在不改变代码本身的情况下进行修改，这种开发方式消耗了大量时间与资源，并且可能导致无法预见的程序执行方式。由于针对业务处理过程生命周期的绝大多数修改均属于业务规则的修改（区别于技术方面的修改），因此，将业务规则完全独立于程序代码以外的能力，或者任何一种处理过程实现机制都将显著提高业务处理过程在其整个生命周期内管理与运行效率。
业务活动监控
一旦集成接口或业务处理过程被创建，集成应用程序或处理过程的运行版本便会由Visual Studio .NET生成，同时由BizTalk Server执行引擎负责将其实例化并进行管理。借助BizTalk Server运行时环境，数以千计的短期与长期业务、文档交换及处理过程实例便可在任意指定时刻发生。跟踪、监控并确保这些活动的持续性是处理过程执行引擎所必备的功能——同是也是BizTalk Server 2004超越其它产品的独特之处。
健康状况与活动跟踪（HAT）和业务活动监控（BAM）是两种旨在提供审计与分析机制的全新模块。健康状况与活动跟踪（HAT）模块通过健壮的查询机制来提供历史活动与实时活动视图，从而展现有关被查询处理过程和交换活动步骤的全面信息。
业务活动管理模块是一种OLAP分析工具，它能够定义并生成有关BizTalk Server活动任意方面的定性及定量历史或实时性能指标。通过结合使用，这两种模块将提供能够应用于BizTalk Server对象及其属性的无限跟踪与分析配置功能，从而对运行性能进行管理并实现具有价值商务智能特性。
小结
与其它信息技术提供商相比，Microsoft公司更加清楚的认识到XML在造就具备高度集成化特征与高效工作流的组织机构方面所蕴含的巨大潜力。同时，为实现创建具备灵活运行机制的企业这一构想，Microsoft公司在围绕XML技术对整条产品线进行重构方面也走在了其它信息技术企业的前面。在一家具备灵活运行机制的企业当中，分布式资源与资产（人员、信息、技术及合作伙伴）可以在最短时间内通过最佳方式对业务需求或机遇做出快速响应。通过为广大知识工作者提供建立并部署基于XML工作流和集成化应用所需的简便易用工具，灵活的企业运行机制将真正走入各种类型的组织机构。