良好的信息处理方式的复杂性与迫切性日益增加

过去十年间，商务市场在信息技术领域投入了空前巨额的资金。其中，两种不同的开发方式为这些投资提供了需求驱动：企业框架应用的引入以及国际互联网、电子邮件和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）所需具备基本前提。

小结：Microsoft BizTalk Server 2004

BizTalk Server 2004与Visual Studio .NET之间实现了紧密集成，从而为Microsoft公司的企业应用集成（EAI）、业务处理过程管理（BPM）和商贸伙伴交互（TPI）系统提供了开发和运行平台。BizTalk Server 2004与Visual Studio .NET中包含利用XML和Web Services技术实现的集成与业务处理过程自动化功能。

Visual Studio .NET中增加了大量健壮的应用集成与工作流开发工具集，而BizTalk Server 2004则为那些在Visual Studio .NET中所创建的集成应用程序充当处理过程执行与活动监控引擎。此外，BizTalk Server 2004还通过广为熟知的Microsoft Office环境为桌面级业务处理过程提供了实时可视化特性。

与其它信息技术提供商相比，Microsoft公司更加清楚的认识到XML在造就具备高度集成化特征与高效工作流的组织机构方面所蕴含的巨大潜力。同时，为实现创建具备灵活运行机制的企业这一构想，Microsoft公司在围绕XML技术对整条产品线进行重构方面也走在了其它信息技术企业的前面。在一家具备灵活运行机制的企业当中，分布式资源与资产（人员、信息、技术及合作伙伴）可以在最短时间内通过最佳方式对业务需求或机遇做出快速响应。通过为广大知识工作者提供建立并部署基于XML工作流和集成化应用所需的简便易用工具，灵活的企业运行机制将真正走入各种类型的组织机构。

如需获取更多相关信息，请访问：
http://www.microsoft.com/china/biztalk

本文档所提供的信息资料仅代表Microsoft公司在信息发布当日就所讨论问题持有的临时观点。鉴于Microsoft公司必须针对瞬息万变的市场状况不断做出相应调整，故而，本文档内容不应被解释为Microsoft方面所做出的任何承诺，与此同时，Microsoft也无法在发布之日后继续保证文件所含信息的准确性。

这份白皮书仅供用于信息参考目的。Microsoft并未在本文档中提供任何形式的保证、明示或暗示。

遵守所有适用版权法律是文档使用者所应承担的义务。Microsoft公司虽未在版权保护下就与本文档相关的权利做出任何限定，但是，任何人未经Microsoft公司书面授权许可，均不得出于任何目的、以任何形式、利用任何手段（电子、机械、影印、录音等）将本文档的任何组成部分制作成拷贝、存储或引入检索系统、亦或向任何对象进行传送。

Microsoft公司可能就本文档所涉及的主题拥有专利、专利申请、商标、版权或其它形式的知识产权。除非已同Microsoft公司签订书面许可协议，并根据协议条款获得明确授权，任何出示本文档的行为均无法使您具备针对上述专利、商标、版权或其它知识产权加以利用的许可权限。

除非另有说明，本文档用来举例的公司、机构、产品、域名、电子邮件地址、徽标、人员、场所及事件均纯属虚构。请不要将它们推想或引申为任何真实的公司、机构、产品、域名、电子邮件地址、徽标、人员、场所及事件。

?2003年，Microsoft公司。版权所有，保留所有权利。

Microsoft、BizTalk、Visual Studio和InfoPath均系Microsoft公司在美国和/或其它国家所拥有的注册商标或商标。

本文档所涉及的其它公司和产品的真实名称均为其各自所有者持有的商标。