SOA技术白皮书.doc

SOA技术白皮书涂航武汉大学计算机学院2008年11月目 录1、SOA的概念和意义11.1 SOA的概念11.2 SOA的革命性意义21.3 SOA的基本特征21.3.1 可从企业外部访问31.3.2 随时可用31.3.3 粗粒度服务接口31.3.4 分级41.3.5 松散耦合41.3.6 可重用的服务及服务接口设计管理41.3.7 标准化的接口51.3.8 支持各种消息模式51.3.9 精确定义的服务接口51.4 SOA的优点62、SOA的来源62.1从XML到Web服务再到SOA62.1.1 XML简史62.1.2 Web服务简史72.1.3 BPEL82.1.4 Windows DNA102.1.4 EAI112.1.5 SOI与ESB142.1.6 SOA简史222.1.7 小结232.2 SOA相关的标准组织与贡献厂商242.2.1 W3C242.2.2 OASIS252.2.3 Web服务协同组织（WS-I）252.2.4 开放SOA合作组织（Open SOA Collaboration，OSOA）262.2.5 主流厂商对SOA的贡献262.2.6 小结273、SOA与过去架构的比较273.1 什么是架构273.1.1 应用架构283.1.2 企业架构283.1.3 面向服务架构283.2 SOA与客户-服务器架构的比较293.2.1 客户-服务器架构293.2.2 应用逻辑的比较293.2.3 应用处理的比较293.2.4 技术的比较303.2.5 安全的比较303.2.6 管理的比较313.3 SOA与分布式互联网架构的比较313.3.1 分布式互联网架构313.3.2 应用逻辑比较323.3.3 应用处理的比较323.3.4 技术的比较333.3.5 安全的比较333.4 比较SOA与混合Web服务架构344、SOA的实现354.1 SCA和SDO354.1.1 SCA的历史354.1.2 SCA的目标364.1.3 SCA的内容384.1.4 SCA集成的特点394.1.5 SCA与其他集成框架的比较404.1.6 SCA和SDO的产业化414.2 服务数据对象（SDO）424.2.1 SDO的概念424.2.2 数据集成对SOA的挑战434.2.3 服务数据对象概述434.2.4 SDO与其他技术比较444.3 WCF454.3.1 WCF的前世今生454.3.2 WF简介454.3.3 什么是WCF474.3.4 什么是WCF服务474.3.5 服务合同494.3.6 宿主504.3.7 绑定534.4 SCA/SDO与WCF的比较575、SOA的发展585.1 REST585.1.1 REST架构的来源585.1.2 REST的设计准则595.1.3 使用REST架构605.1.4 REST开发框架615.2 ROA625.3 SOA和EDA、CEP625.4 SOA 2.0625.5 WOA636、SOA成熟度模型63ii1、SOA的概念和意义1.1 SOA的概念很多初涉.NET或JAVA或者SOA的初学者都希望能够从一本书中得知这些东西到底是什么？往往是看了许多介绍之后也是一头雾水。这和当今最流行的宣传方式有关。如果你看过IBM电子商务的广告就会理解这一点。从广告中你并不能得出电子商务是什么，也不知道IBM到底提供一些什么东西，只知道有事要找IBM。这种行为术语称为：FUD（FUD 是 Fear， Uncertainty， Doubt（惧、惑、疑）的缩写。其含义是在顾客的头脑中注入疑惑与惧怕，然后，你说什么他们就可能信什么。SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。S将SOA定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”L将SOA定义为：“按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。”Gartner则将SOA描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”Gartner相信BPM和SOA的结合对所有类型的应用集成都大有助益。“SOA极大的得益于BPM（业务流程管理）技术和方法论，但是SOA面临的真正问题是确立正确的企业意识，即：强化战略化的SOA计划（针对供应和使用）并鼓励重用。”虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。需着重注意的是，SOA并不是新生事物。大型IT组织成功构建和部署SOA应用已有多年的历史，这要比现有的XML和Web服务长很多。IBM CICS和BEA TUXEDO就是过去被用于构建SOA应用的两种技术范例。重点说明的是SOA并不是一种现成的技术，而是一种架构和组织IT基础结构及业务功能的方法。SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）的模型。这一定义阐明了SOA的范围。SOA要求开发人员将应用设计为服务的集合。SOA要求开发人员跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服务，由此来实现重用。但是，SOA并不仅仅是一种开发方法。它还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的方式。通过分析服务间的交互，SOA可以帮助企业了解何时以及为什么业务逻辑被切实执行了，这使管理员或分析师能够有针对性的优化业务流程。1.2 SOA的革命性意义SOA可以说是解决软件系统构件化过程中长期存在的复杂度和相关度问题的最新方法。今天的SOA建立在Web服务的基础之上，主要以SOAP/XML接口和Web服务描述语言分发。和对象以及软件构件相同，“服务”是在分布式网络上构建复杂系统的最基本的建筑材料。简而言之，SOA就是对等（P2P）计算的真正的商业化。总而言之，SOA提供了这样一种框架：一个系统上的软件可以安全而且可靠地提出请求并获得其他系统上的计算资源，而不再需要一台中央服务器来管理和控制整个端到端的网络。我们可以做一个更清晰的类比：即回忆一下网络架构从SNA（和OSI 模型相对，系统网络架构SNA由IBM 提出，也是最为流行的网络架构模型之一， 虽然SNA 模型现在已经过时，但它仍然得到了广泛的应用，SNA 的设计基于IBM 大型机）到IP的演化过程。在SNA环境下，网络的架构基本上是“主/从”式的，即由一个网关控制着远程终端和主机之间的联系，所有的控制都在主机一端。而在IP环境下，则由分布式的路由器网络提供连接，控制不再是集中的了。然而，软件架构始终未能与IP的演进步伐保持一致。在所谓的客户机/服务器计算环境中，基本的架构依然是主/从式的：应用服务器控制着与远程客户机的通信。在过去的几年中，我们已逐渐地将客户机/服务器模式推向了边缘。客户机与服务器之间的各种通信协议越来越多地基于Web而不再是专有协议了，因此应用之间的通信也成了多路径的而不是单路径的了。而SOA则从根本上突破了客户机/服务器模式。现在，服务器与客户机之间的主/从通信方式已经转变成了分布式的P2P方式，与IP网络中路由器之间的通信方式相似。于是，像IBM、Oracle、SAP和微软等软件与系统厂商就很自然地对SOA的兴起和部署给予了密切关注。当然，对SOA给予关注的绝不仅仅只有他们。SOA对于电信网络的影响也是十分巨大的。任何一位网络管理人员都很清楚，P2P通信与客户机/服务器应用有着非常显著的不同。SOA系统中的通信流量越来越多地发生在任意的端到端之间，而客户机/服务器应用的流量则主要是星型发散的。因此，像MPLS这样可提供安全、可靠的端到端通信架构的好处就日益显著了。有趣的是，这又是一个“先发后至”的例子。因为有一个应用，其流量模式一直都是端到端的。是什么应用？就是语音通信。越向前走，我们就越会发现，数据业务与昔日的话音业务有很多的相似之处。1.3 SOA的基本特征SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化重用。要实现这一目标，就要在实施SOA的过程中牢记以下九个特征： 可从企业外部访问； 随时可用； 粗粒度的服务接口； 分级； 松散耦合； 可重用的服务和服务接口设计管理； 标准化的服务接口； 支持各种消息模式； 精确定义的服务契约。1.3.1 可从企业外部访问通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。业务伙伴采用先进的B2B协议（ebXML或RosettaNet）相互合作。当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多条业务信息的交换。会话类型（会话复杂或简单、长或短等）取决于业务目的。除了B2B协议外，外部用户还可以访问以Web服务方式提供的企业服务。1.3.2 随时可用当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。当相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台，用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死锁。服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯。在多数情况下，采用异步模型可以达到同样的效果，但更能够体现SOA的最佳特性。当然，并不是所有情况下都应当采用异步设计模式。但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。1.3.3 粗粒度服务接口粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。举个例说明最为清楚。向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。1.3.4 分级一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。在服务分级方面，须注意服务层的公开服务通常由后台系统（BESs）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。1.3.5 松散耦合SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现，Web服务对于SOA服务接口来讲是一个重要的标准。当使用者调用一个Web服务时，被调用的对象可以是CICS事务（客户信息控制系统）、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。底层实现并不重要。消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。Web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。由于客户和Web服务间不存在紧密耦合请求响应，消息类Web服务在客户和服务器间提供了更为松散的耦合。1.3.6 可重用的服务及服务接口设计管理如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键因此，因此SOA实施者应当寻找一种适当的方法进行服务设计过程管理。服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷。走捷径的项目战术与企业构建可重用通用服务的长期目标。超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。简言之，不按规则编写服务将无法保证可提供重用性的SOA的成功实施。在执行规则的过程中会产生财务费用，需要在制定SOA实施计划时加以考虑。1.3.7 标准化的接口近年来出现的两个重要标准XML和Web服务增加了全新的重要功能，将SOA推向更高的层面，并大大提升了SOA的价值。尽管以往的SOA产品都是专有的、并且要求IT部门在其特定环境中开发所有应用，但XML和Web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用SOA。这具有巨大的意义！Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。例如，开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用ERP系统和定制化J2EE应用中的现有服务，而完全无须了解这些应用的内部工作原理。采用XML，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。你也可以不采用Web服务或XML来创建SOA应用，但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前只有几种服务使用者支持该标准，但未来大多数的服务使用者都会将其作为企业的服务访问方法。1.3.8 支持各种消息模式SOA中可能存在以下消息模式。在一个SOA实现中，常会出现混合采用不同消息模式的服务。 无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。 有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活，但由于服务提供者必须存储每个使用者的共享环境信息，因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提高了交换服务提供者的服务难度。 等幂消息。向软件代理发送多次重复消息的效果和发送单条消息相同。这一限定使提供者和消费者能够在出现故障时简单的复制消息，从而改进服务可靠性。1.3.9 精确定义的服务接口服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。META将SOA定义为：“一种以通用为目的、可扩展、具有联合协作性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。1.4 SOA的优点了解了SOA的定义和基本特征，最后我们再来看看SOA潜在的优点： 编码灵活性可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，这些都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这种服务实现方式本身也可以灵活使用。 明确开发人员角色例如，熟悉BES的开发人员可以集中精力在重用访问层，协调层开发人员则无须特别了解BES的实现，而将精力放在解决高价值的业务问题上。 支持多种客户类型借助精确定义的服务接口和对XML、Web服务标准的支持，可以支持多种客户类型，包括PDA、手机等新型访问渠道。 更易维护服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。 更好的伸缩性依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整，以满足服务需求。 更高的可用性该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提供者的实现细节，这样服务提供者就可以在WebLogic集群环境中灵活部署，使用者可以被转接到可用的例程上。SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。SOA将能够帮助我们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。2、SOA的来源2.1从XML到Web服务再到SOA2.1.1 XML简史如同HTML，扩展标记语言（XML）系W3C所创建，源自流行的标准通用标记语言（SGML），它在60年代后期就已存在。这是广泛使用的元语言，允许组织增加原始文档数据。XML在90年代后期的电子商务运动中声名鹊起，服务器端脚本语言可以经由互联网而处理业务。通过XML的使用，开发者能够给任何片段附加上意义和上下文，再跨越互联网协议传输。XML不仅被用于以标准化的方式来表达数据，其语言自身还被用作一系列的附加规范的基础。XML Schema定义语言（XSD）与XSL转换语言（XSLT）都以XML表达。这些规范，事实上已成为关键核心XML技术集的关键部分。XML表达架构代表了SOA的基础层。在其内部，XML建立了在服务各处流动的消息格式与结构。XSD schemas保持消息数据的完整与有效性，而且XSLT使得不同的数据表达间通过schema映射而能够互相通信。换句话说，没有XML你在SOA内寸步难行。2.1.2 Web服务简史在2000年，W3C接受了一项关于简单对象访问协议（SOAP）规范的提案。这个规范本来设计用于专有RPC通信，想法是对于在构件间传输参数数据可以序列化成XML传送，然后再序列化成其原生格式。SOAP以XML形式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。SOAP本身并没有定义任何应用程序语义，如编程模型或特定语义的实现；实际上，它通过提供一个有标准组件的包模型和在模块中进行数据编码的机制，定义了一个简单的表示应用程序语义的机制，这使SOAP能够用于从消息传递到RPC的各种系统。SOAP包括三个部分： SOAP封装结构：定义了一个整体框架，以表示消息中包含什么内容，谁来处理这些内容以及这些内容是可选的或是必需的。 SOAP编码规则：定义了一系列机制，用以交换应用程序定义的数据类型的实例。 SOAP RPC表示：定义了一个协定，用来表示远程过程调用和应答。很快，公司及软件厂商开始看到，对于推进通过构建于专有-免费的互联网通信框架之上的电子商务技术，存在日益巨大的潜力。这最后导致了创建一个纯粹的、基于Web的分布式技术能充分利用概念标准化的通信框架，来桥接组织之间和组织内部所存在的巨大差异，这个概念被称为Web服务。Web服务最重要的部分是其公共接口。它是分配服务识别并使其激活的核心信息块。因此，首先支持Web服务的是Web服务描述（WSDL）。W3C第一份WSDL评议提案是在2001年，此后还在不断地修订这一规范。为了进一步的开放协同性的愿景，Web服务需要一个互联网友好的、XML兼容的通信格式，以便能够建立一个标准化的通讯框架。尽管有别的选择，譬如可以考虑XML-RPC，但SOAP因为工业界的偏好而胜出，并且保留了最初的通讯标准用于Web服务。为支持SOAP的新角色，W3C随之发布了更新版本的规范，同时考虑了RPC风格的与文档风格的消息类型。而后者在SOA里面更为常用。最终，“SOAP”一词不再代表“简单对象访问协议”的首字母缩写。到了规范的1.2版，它变成了一个独立的术语。完成第一代Web服务标准家族的是UDDI规范，它原本由UDDI.org所开发，被递交到OASIS之后，它继续与UDDI.org一起合作开发。这个规范考虑在组织内部及组织边界之外来创建标准化的服务描述的注册。UDDI提供了潜在的对Web服务在一个集中的位置注册，在此处能够被服务请求者所发现。WSDL与SOAP不同，UDDI尚未被工业界所普遍接受，并且保留了一个可选的SOA扩展。开发定制的Web服务可适应变化的业务需求，并且第三方市场出现了促进各种实用服务的销售或租赁。现存的通讯平台，譬如面向消息的中间件（MOM）产品，结合Web服务可支持SOAP之外的其他消息协议。一些组织可迅速合并Web服务，以促进B2B数据交换经常要转变为EDI（电子数据交换）替代品的需求。由于Webservice的出现，微软立即发展了基于Webservice的架构体系：WCF。Web服务作为一种技术标准，只定义了如何构建单个服务，而没有提出对服务进行组装，服务的组合（service composition）问题是SOA的一个基础又很重要的主题。Web服务并不等同于SOA，它只是SOA的一种实现方式，基于SOA方法的应用集成不应受到Web服务技术标准的限制，每个单位的应用系统不一定适合全部都采用Web服务进行整合，例如对于操作之间数据交互频繁就不适宜采用Web服务。虽然BPEL能对Web服务进行编排和组合，但BPEL对服务的编排与组合也是局限于Web服务，并且BPEL是面向高层次的业务流程，不适合应用于SOA基础设施中低层次的服务组合，运用BPEL对服务组合指定的行为也往往非常复杂。同时，SOA对于应用集成来说，确实是一种很好的架构模型和设计方法，基于SOA的应用集成也是未来发展的必然趋势，因此，如何以SOA对应用集成进行架构，又不仅仅限制于Web服务技术，是工业界和学术组织当前和未来一个很重要的主题。2.1.3 BPELBPEL（Business Process Execution Language for Web Service，也称作WS-BPEL或BPEL4WS）可用于组合这些Web服务，是SOA的一种实现方式。面向业务过程的SOA需要使用相对简单的方式来描述如何把Web服务组合成业务过程，并且描述的方式最好能够执行，这样我们不但可以定义一个抽象的业务过程，而且完成了一个可执行的业务过程规范。BPEL正是这样的语言，它拥有以下特征： 允许同时定义抽象的业务过程和可执行的业务过程； 受到大多数公司的支持； 存在可执行这些业务过程语言的软件（BPEL服务器）和开发工具（BPEL设计工具）。组合Web服务有两种基本的方式：Orchestration（安排控制）；Choreography（舞蹈编排）。使用Orchestration，需要一个总控过程来控制涉及到的Web服务，并协调Web服务不同操作的执行。所涉及到的Web服务并不知道也不必知道它们是组合过程的一部分，只有中央的总控过程知道它们如何组合和协调。相比之下，Choreography并不依赖中央的总控协调过程。相反，每个涉及其中的Web服务都知道何时执行自己的操作，和谁交互。Choreography方式集中在消息的交换，所有的Choreography参与者都需要知道：业务流程；要执行的操作；要交互的消息；交换消息的时机。从组合Web服务来执行业务流程的角度来看，Orchestration比Choreography更灵活： 我们知道谁负责执行整个业务流程。 即使Web服务并不知道它们是业务流程的一部分，我们仍然可以把它们组合起来。 当错误发生时，我们可以提供一个备选的Scenario。BPEL遵循Orchestration方式。其他的标准则使用Choreography方式，如 WSCI（Web Services Choreography Interface）和WS-CDL（Web Services Choreography Description Language）。和BPEL相比，Choreography没有获得业界的支持。2002年8月，BEA、IBM和微软公司开发出BPEL的第一个版本。2003年4月，BPEL提交给OASIS标准化。BPEL既可以在企业内部使用，也可以在企业之间使用。在企业内部，BPEL用于标准化企业应用集成，并集成遗留的孤立系统。在公司之间，BPEL使业务伙伴之间的集成更加容易和高效。BPEL定义的业务流程并不会影响已有的系统。在功能已经存在或要发布成Web服务的环境，BPEL是关键的技术。BPEL支持两种不同类型的业务流程： 可执行的流程：允许我们定义一个业务流程的确切细节。它可以在Choreography引擎种执行。多数情况下，BPEL都用于可执行的流程。 抽象的业务协议：允许我们定义参与方之间的公开消息交换协议。它不包括业务流程的内部细节，也不能执行。BPEL构建在XML和Web服务的基础上。BPEL支持Web服务技术的协议群：SOAP，WSDL，UDDI，WS-Reliable Message，WS-Addressing，WS-Coordination和WS-Transaction。BPEL是早期两个工作流语言（WSFL和XLANG）的综合：WSFL由IBM设计，基于有向图的概念。XLANG由微软设计，是一种块结构语言。BPEL流程定义了参与流程的Web服务执行的确切次序。它可以按顺序执行，也可以并行执行。使用BPEL，我们可以表达条件行为，例如，是否执行一个Web服务取决于前一个执行结果；也可以创建循环，声明变量，复制和为变量赋值，定义错误处理Handler等等。综合使用这些结构，我们可以用算法的方式定义复杂的业务流程。BPEL可以和通用的编程语言如Java相比较，但它没有Java强大。另一方面，它更简单，更适合业务流程的定义。因此，BPEL并不是现代语言（如Java）的替代，而是它们的补充。典型的BPEL流程如下。BPEL业务流程收到一个请求。BPEL执行相关的Web服务；BPEL响应请求者。因为BPEL流程需要和其他的Web服务协作，它依赖于被调用的Web服务的WSDL描述。BPEL流程包含几个步骤，每个步骤称为活动。BPEL支持两种活动：简单的活动和结构化的活动。简单的活动代表基本的结构，用于普通的任务，例如：1、调用其他Web服务；2、等待客户端通过发送一个消息调用业务过程；3、为同步操作创建一个响应；4、为一个数据变量赋值；5、指出错误和例外发生；6、等待若干时间；7、终止整个流程等等。我们可以组合这些基本的简单活动来定义复杂的算法，用于定义业务流程的执行步骤。为组合这些基本活动，BPEL支持几个结构化的活动，最重要的是：1、用于定义按次序执行的一系列活动；2、用于定义并行执行活动的集合；3、用于创建条件分支；4、用于定义循环；5、用于从多个可选的路径中选择其一。BPEL流程可以是同步也可以是异步的。同步的BPEL流程阻塞客户端（使用该流程的客户端）直到流程结束并返回结果。异步的BPEL流程并不阻塞客户端。它使用一个回调来返回结果（如果有）。通常，我们在耗时较长的流程使用异步流程，把同步流程用于处理在短时间内返回结果的流程。假如一个BPEL流程使用异步的Web服务，通常情况下它自己也是异步的（虽然不是必要的）。对于客户端而言，一个BPEL流程看起来就像其他的Web服务。当我们定义一个BPEL流程时，我们实际上定义了一个组合现存Web服务的新Web服务。这个新的BPEL Web服务使用一系列port Type，通过这些port Type，它提供了类似于其他Web服务的操作。为调用一个在BPEL定义的业务流程，我们必须调用这些Web服务的组合。下图是一个BPEL流程的示意图。2.1.4 Windows DNA到DOTNET微软提出的Windows DNA是Windows Distributed Internet Application Architecture的缩写，可以翻译为Windows分布式网络应用程序体系结构。DNA概念是借助生命科学中脱氧核糖核酸（DNA，Deoxyribonucleic Acid）的寓意来诠释现代企业信息结构的真谛。比尔盖茨称之为数字神经系统，寓示信息系统可以灵活适应外界环境因素的变化，做出相应的反应。Windows DNA是在.NET平台出现之前在微软平台上进行技术开发的大环境，要利用微软的组件技术OLE、COM、DCOM、MTS、COM+进行开发，就不能不了解这个Windows环境下的软件体系结构。Windows DNA是第一个将互联网、客户/服务器和用于计算的PC模型结合并集成在一起的为新一代分布式计算方案而设计的应用软件体系结构。下图展示了微软创建的Windows DNA的系统架构。由图可见，Windows DNA使用了一系列的服务来完成它的架构。使用Windows DNA模型，用户可建造一个能在任何网络上实现的、可伸缩的多层应用软件。Windows DNA是基于COM和开放的Internet标准的，所以发展商可以使用任何语言或工具来生成可兼容的应用程序。COM提供了一个现代的、独立于语言的对象模型，它为应用程序提供了与结构的所有层进行交互操作的标准方式。通过COM，发展商通过可插入的软件单元能够扩展应用程序的任何部分，这些软件单元可由C+，Visual Basic，Java或者其它语言写成。总之，Windows DNA实际上是微软的.NET框架出现以前基于组件的分布式应用程序战略框架结构。与.NET的区别：.net并不是Windows DNA 的一个新名字，在很多的地方.NET更为先进，并且包括一个完整的软件开发和运行库框架。而Windows DNA 仅仅是指使用现有技术的一种途径（即所谓的三阶式途径）的市场术语。NET是一个“革命性的新平台，建立在开放的 Internet 协议和标准之上，通过工具和服务将计算和通讯以崭新的方式融合到一起。2.1.4 EAIEAI（企业应用集成）是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构，来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的 ERP、CRM、SCM、数据库、数据仓库，以及其他重要的内部系统之间无缝地共享和交换数据的需要。企业可以通过EAI将企业核心应用和新的Internet解决方案结合在一起。EAI将进程、软件、标准和硬件联合起来，在两个或更多的企业系统之间实现无缝集成，使它们就像一个整体一样。尽管EAI常常表现为对一个商业实体（例如一家公司）的信息系统进行业务应用集成，但当在多个企业系统之间进行商务交易的时候，EAI也表现为不同公司实体之间的企业系统集成，例如B2B的电子商务。在当前激烈竞争的环境下，一个成功的企业或系统在IT构建上需要解决下列问题：（1）如何实现应用系统的快速构建，迁移和伸缩；（2）如何能够让已有的多种应用系统无缝的集成起来；（3）如何设计现代IT架构，使系统不仅功能强大和可靠，而且还有强大的灵活性和可扩展性，以满足不断增长的新需求。集成时将面临的难题如下：1、协调由不同系统实现的、不兼容的业务流程2、协调不同系统所使用的数据的差别3、协调用以实现不同系统的、不兼容的技术4、协调不同系统所采用的时间刻度5、协调不同系统所使用的交互模式集成的过程中除了克服上述难题外，理想的集成方案还必须满足下列要求：1、低成本，具有较快的投资回报2、易于掌握和管理3、不会影响现有系统4、具有可伸缩性、可靠性、高可用率、容错性及安全性等等EAI的重点是流程的整合和内容的整合。一个企业或部门的EAI可以从四个方向入手：内容整合、开发整合、企业流程整合和界面的集成。从技术角度，EAI的本质是解决异质型数据源的整合，包括： 信息协作系统（如电子邮件系统、文件管理、审核系统和流程管理系统等） 材料管理系统（如ERP和数据仓库） 财务系统 客户关系管理系统 旧型主机系统EAI技术本身在发展，涉及的技术又十分广泛，不同的技术实现的集成功能不同。对要实施EAI的企业而言，EAI是分层次的，也就是说，同样是企业应用集成，其内容和层次并不一定相同。EAI涉及到结构、硬件、软件以及流程等企业系统的各个层面。由于各个公司的策略不同，具体层面的划分也有所不同。一般来说，EAI从易到难可以分为以下四个层次：表示集成；数据集成；功能集成；业务集成。表示集成是集成中最简单的方式：统一的界面。在这种情况中，一般使用软件用户界面来实现对多种软件的集成。典型情况下，集成的结果是形成一个新的、统一的显示界面。新的界面看起来好像是单一应用程序，但实际上却可能调用几个遗留应用程序。集成逻辑将现有的显示界面作为集成点来指导用户进行互动操作，并在用户操作与相应软件之间进行通信，然后再把不同的软件部件产生的结果综合起来。数据集成的基本思想是对各种软件组件的数据进行集成。用户在存取数据时就可以绕过相应的应用软件，而直接获取该软件所创建并存储的相应信息。例如：我们可以利用数据库网关来访问使用IBM DB2数据库的客户订单系统和使用Oracle数据库的客户帐单系统。网关负责将信息从各个数据库中取出，存放到一个用来评估客户购物习惯的数据挖掘应用程序中。在使用网关时，我们就可以绕过订单处理软件和账单软件而直接获取数据。数据集成模型跳过显示界面与业务逻辑模块，直接进入应用软件的数据结构或数据库来创建新的集成。这样的集成可能只需简单访问软件所使用的数据库管理系统，也可能需要与应用程序所管理的文件或用户数据库进行更加复杂的集成。功能集成在代码级别上实现软件集成，这可能在对象或过程级别上实现。如果软件使用应用编程接口，那么也可以用API来实现集成。例如，我们可以通过访问订单和账单软件来更新从第三方软件传来的用户地址信息。如果提供给订单或账单软件的地址信息需要遗留软件的相应操作，而这种操作在数据被读出或存储之前，那么在这种情况下我们将使用应用集成而不是数据集成。比起在新应用程序中创建新逻辑来说，重用现有的逻辑则更加有效，也不容易产生错误。而且对每个应用软件的访问是定制的，其中包括应用软件的语义和行为特性。另一种进行功能集成的方法是使用连接器（connector）来屏蔽软件的内部机制，而直接响应获取用户信息或改变用户地址的请求。功能集成模型是在业务逻辑层上完成集成，而不是在显示界面或数据层。功能集成要求集成点存在于应用程序代码之内。集成处可能只需简单得使用公开的API就可以访问，也可能复杂得需要用附加代码段来创建新的访问点。流程集成可使用WSI，即WEB服务集成，可将之理解为API的扩展。如果项目团队只追求立即见效与短期投资回报、而不考虑长期成本的话，用Web服务集成WSI开展战术性的集成项目是比较奏效的。通常，一个WSI项目要涉及许多需要彼此交换数据的系统。项目团队将根据下列信息来定义SOAP消息：1、要在各系统间交换的数据。2、各系统已经能够理解的各种传统消息格式。3、可用于访问各系统的传统APIs或方法。然后，项目团队将定义WSDL契约（包括接口、操作、消息交换模式）。企业级服务质量（比如安全性、可靠的消息传递、事务管理、故障转移等）是根据实际需要实现的，可以用相应的策略信息定义它。WSI具有以下优点：1、更快的产品上市速度，尤其是对于最初几个WSI项目，或者当所涉及系统的数目不多时。2、更低的集成成本，尤其是对于最初几个WSI项目，或者当所涉及系统的数目不多时候。当然WSI也存在一些局限：1、在创建数据、服务和流程模型时考虑不多，而它们是要被广泛重用于当前服务领域或不同服务领域的。例如，客户类型可能会在不同的WSI项目中有不同的含义。2、应用是通过传输层或中间妙Is直接发送SOAP消息的，这为更换传输协议或中间件增添了困难。3、安全性是用战术的、专门的方法处理的，一般无法在多个不同的WSI项目中使用同一种安全架构。这为将来实现单点登陆等设施增加了复杂性。4、未考虑在各个项目中，以一致的方式应用Web服务平台比如，一个项目采用UDDI作为服务注册库，另一个项目允许服务请求者通过简单的HTTP GET消息获取WSDL文档，还有一个项目可以用WS-MetadataExchange来获取WSDL文档。5、不支持在各个项目中，以一致的方式进行Web服务版本化。这样，机构最终将有多种版本化方案，不利于长期的服务重用。EAI在工程实现时，需要同时考虑结构、硬件、软件以及流程等企业系统的各个层面。 业务过程集成当对业务过程进行集成的时候，企业必须在各种业务系统中定义、授权和管理各种业务信息的交换，以便改进操作、减少成本、提高响应速度。业务过程集成包括业务管理、进程模拟以及综合任务、流程、组织和进出信息的工作流，还包括业务处理中每一步都需要的工具。 应用集成为两个应用中的数据和函数提供接近实时的集成。在一些B2B 集成中用来实现CRM系统与企业后端应用和Web的集成，构建能够充分利用多个业务系统资源的电子商务网站。 数据集成为了完成应用集成和业务过程集成，必须首先解决数据和数据库的集成问题。在集成之前，必须首先对数据进行标识并编成目录，另外还要确定元数据模型。这三步完成以后，数据才能在数据库系统中分布和共享。 集成的标准要实现完全的数据集成，必须首先选择数据的标准格式。集成的标准化促成了信息和业务数据的共享和分布，构成了企业应用集成的核心，包括COM+/DCOM、CORBA、EDI、JavaRMI和XML。 平台集成要实现系统的集成，底层的结构、软件、硬件以及异构网络的特殊需求都必须得到集成。平台集成处理一些过程和工具，以保证这些系统进行快速安全的通信。 硬编码最早期的系统应用集成，用户只着眼于解决眼前的一个系统和另外一个系统的互连互通，并不考虑这个系统的合理性和可扩展性。这种集成并不采用什么专门的 EAI技术，只是使用硬编码来实现系统之间的点对点连接。这种方式，在有些特定情况下（比如很小规模的集成系统）可能会得到相对较高的性能，因为一切都是为特定情况定制开发的。但集成规模稍一复杂，这种方式代码量大，不可靠，无法维护等缺点就会显露无疑。 基于基础中间件（MOM，AP Server）的集成随着商业基础中间件（MOM，AP Server等）的广泛应用，EAI系统的构造开始转向构造基于这些基础中间件的系统。虽然基础中间件的使用在一定程度上简化了开发代码量，而且大大提高了EAI系统的运行时可靠性和效率，但其本质上仍是零散的定制开发，其缺少完整的适合企业应用集成特点的集成框架和设施，各个模块之间往往仍然是紧偶合的并绑定特有基础中间件的，而且，有些时候基础中间件的使用反而会增加系统的技术复杂性。 EAI套件商业产品级的应用集成套件的出现很好的解决了上述早期系统的缺点。其具有专用的EAI平台、完整的集成框架和设施，用户开发维护部署简单，对原有系统不改动或改动小。因此，应用集成套件成为EAI趋势。目前的先进的应用集成套件提