《SOA入门教程.doc》由会员分享，可在线阅读，更多相关《SOA入门教程.doc（70页珍藏版）》请在三一办公上搜索。
1、SOA入门教程目 录1 SOA概览61.1 什么是SOA?61.2 SOA的基本特征71.2.1 可从企业外部访问81.2.2 随时可用81.2.3 粗粒度服务接口91.2.4 分级91.2.5 松散耦合101.2.6 可重用的服务及服务接口设计管理101.2.7 标准化的接口111.2.8 支持各种消息模式111.2.9 精确定义的服务接口121.3 SOA的优点121.3.1 编码灵活性121.3.2 明确开发人员角色131.3.3 支持多种客户类型131.3.4 更易维护131.3.5 更好的伸缩性131.3.6 更高的可用性132 SOA进化历程142.1 SOA进化之SOA时间轴14
2、2.1.1 XML简史142.1.2 Web服务简史152.1.3 SOA简史162.1.4 SOA如何改造XML与Web服务172.1.5 要点总结182.2 SOA进化之标准组织与贡献厂商192.2.1 比较“标准”、“规范”与“扩展”192.2.2 标准组织对SOA的贡献192.2.2.1 万维网联盟(W3C)202.2.2.2 结构化信息标准进步组织(OASIS)202.2.2.3 Web服务协同组织(WS-I)212.2.2.4 它们如何比较222.2.3 主流厂商对SOA的贡献222.2.3.1 为何要开发标准支持SOA232.2.3.2 厂商影响232.2.3.3 厂商联盟232
3、.2.3.4 选择一个标准组织242.2.3.5 为什么你应当关心252.2.4 要点总结252.3 SOA的根源 (SOA与过去架构的比较)262.3.1 什么是架构262.3.1.1 应用架构262.3.1.2 企业架构272.3.1.3 面向服务架构272.3.2 比较SOA与客户-服务器架构282.3.2.1 客户-服务器架构简史282.3.2.2 应用逻辑282.3.2.3 应用处理292.3.2.4 技术302.3.2.5 安全302.3.2.6 管理312.3.3 比较SOA与分布式互联网架构312.3.3.1 分布式互联网架构简史312.3.3.2 应用逻辑332.3.3.3
4、应用处理342.3.3.4 技术352.3.3.5 安全352.3.3.6 管理362.3.4 比较SOA与混合Web服务架构372.3.4.1 Web服务作为构件包装器372.3.4.2 SOA内部的Web服务383 BPM与SOA之间的区别及联系384 SOA 的生命周期404.1 建模414.2 组装414.3 部署414.4 管理424.5 控制425 如何构建SOA系统435.1 SOA生命周期模型435.2 SOA的难点445.2.1 服务定义445.2.1.1 工业标准455.2.1.2 缺乏方法论455.2.2 理解语义465.2.3 SOA过程471 SOA概览最近半年以来，
5、在企业级应用开发领域，谈论最多的一个词，恐怕非SOA（Service-Oriented Architecture，面向服务架构）莫属。那么SOA究竟拥有什么样的魔力，能够让众多的软件厂商对他趋之若骛，掀起新的一轮企业架构浪潮。让我们在本文中一探SOA的究竟。那么什么是SOA，让我们先从基本概念开始讲起。1.1 什么是SOA?SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者
6、交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。Service-将SOA定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”L将SOA定义为：“按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。”Gartner则将SOA描述为：“客户端/服务器的软件设计方法，一项应
7、用由软件服务和软件服务使用者组成SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”Gartner相信BPM和SOA的结合对所有类型的应用集成都大有助益，“SOA极大的得益于BPM技术和方法论，但是SOA面临的真正问题是确立正确的企业意识，即：强化战略化的SOA计划（针对供应和使用）并鼓励重用。”虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。需着重注意的是，SOA并不是新生事物。大型IT组织
8、成功构建和部署SOA应用已有多年的历史这要比现有的XML和Web服务长很多。IBM CICS和BEA TUXEDO就是过去被用于构建SOA应用的两种技术范例。重点说明的是SOA并不是一种现成的技术，而是一种架构和组织IT基础结构及业务功能的方法。SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）的模型。这一定义阐明了SOA的范围。SOA要求开发人员将应用设计为服务的集合。SOA要求开发人员跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服
9、务，由此来实现重用。但是，SOA并不仅仅是一种开发方法，它还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的方式。通过分析服务间的交互，SOA可以帮助企业了解何时以及为什么业务逻辑被切实执行了，这使管理员或分析师能够有针对性的优化业务流程。1.2 SOA的基本特征SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化重用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：可从企业外部访问随时可用粗粒度的服务接口分级松散耦合可重用的服务服务接口设计管理标准化的服务接口支持各种消息模式精确定义的服务契约我们现在开始依次
10、讨论以上概念。 1.2.1 可从企业外部访问通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。业务伙伴采用先进的B2B协议（ebXML或RosettaNet）相互合作。当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多条业务信息的交换。会话类型（会话复杂或简单、长或短等）取决于业务目的。除了B2B协议外，外部用户还可以访问以Web服务方式提供的企业服务。1.2.2 随时可用当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有
11、很强的依赖性。许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台，用户通常不会觉察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应用资源中时，可能会出现队列溢出甚至服务死锁。服务使用者要求提供同步服务时，通常是
12、基于其自身理解或使用习惯。在多数情况下，采用异步模型可以达到同样的效果，但更能够体现SOA的最佳特性。当然，并不是所有情况下都应当采用异步设计模式。但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。1.2.3 粗粒度服务接口粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。举个例说明最为清楚向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。Inter
13、net环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。1.2.4 分级一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度
14、较粗、重用性较差的服务。在服务分级方面，须注意服务层的公开服务通常由后台系统（BESs）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。1.2.5 松散耦合SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。大多数松散耦合方法都依靠基于服
15、务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现，Web服务对于SOA服务接口来讲是一个重要的标准。当使用者调用一个Web服务时，被调用的对象可以是CICS事务、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。底层实现并不重要。消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购订单），而非一组离散的参数。Web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。由于客户和
16、Web服务间不存在紧密耦合请求响应，消息类Web服务在客户和服务器间提供了更为松散的耦合。1.2.6 可重用的服务及服务接口设计管理如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。设计可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键因此，因此SOA实施者应当寻找一种适当的方法进行服务设计过程管理。服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷走捷径的项目战术与企业构建可重用通用服务的长期目标。超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要
17、一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。简言之，不按规则编写服务将无法保证可提供重用性的SOA的成功实施。在执行规则的过程中会产生财务费用，需要在制定SOA实施计划时加以考虑。1.2.7 标准化的接口近年来出现的两个重要标准XML和Web服务增加了全新的重要功能，将SOA推向更高的层面，并大大提升了SOA的价值。尽管以往的SOA产品都是专有的、并且要求IT部门在其特定环境中开发所有应用，但X
18、ML和Web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用SOA。这具有巨大的意义！Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。例如，开发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用ERP系统和定制化J2EE应用中的现有服务，而完全无须了解这些应用的内部工作原理。采用XML，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。你也可以不采用Web服务或XML来创建SOA应用，但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前只有几种服务使用者
19、支持该标准，但未来大多数的服务使用者都会将其作为企业的服务访问方法。1.2.8 支持各种消息模式SOA中可能存在以下消息模式。在一个SOA实现中，常会出现混合采用不同消息模式的服务。无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活，但由于服务提供者必须存储每个使用者的共享环境信息，因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提高了交换服务提供
20、者的服务难度。等幂消息。向软件代理发送多次重复消息的效果和发送单条消息相同。这一限定使提供者和消费者能够在出现故障时简单的复制消息，从而改进服务可靠性。1.2.9 精确定义的服务接口服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。META将SOA定义为：“一种以通用为目的、可扩展、具有联合协作性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。1.
21、3 SOA的优点了解了SOA的定义和基本特征，最后我们再来看看SOA潜在的优点：1.3.1 编码灵活性可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，这些都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这种服务实现方式本身也可以灵活使用。1.3.2 明确开发人员角色例如，熟悉BES的开发人员可以集中精力在重用访问层，协调层开发人员则无须特别了解BES的实现，而将精力放在解决高价值的业务问题上。1.3.3 支持多种客户类型借助精确定义的服务接口和对XML、Web服务标准的支持，可以支持多种客户类型，包括PDA、手机等新型访问渠道。1.3.4 更易维护服务提供者
22、和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。1.3.5 更好的伸缩性依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整，以满足服务需求。1.3.6 更高的可用性该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提供者的实现细节，这样服务提供者就可以在WebLogic集群环境中灵活部署，使用者可以被转接到可用的例程上。SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。SOA将能够帮助我们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整
23、个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。2 SOA进化历程本文审视XML、Web服务及SOA间的关系，并解释厂商和标准组织如何从那些持续浮现的Web服务规范中形成奇妙的竞争与协同竞技场。然后我们从应用架构简短历史的叙述着手来对过去的二十年作一个总结。 2.1 SOA进化之SOA时间轴我们从讲述形成当前SOA平台的关键工业开发入手来建立时间轴。然后我们看一看SOA在它的权限范围内，如何作为当代架构的平台而改变了XML与Web服务技术的角色。2.1.1 XML简史如同HTML，扩展标记语言（XML）系W3C所创建，源自流行的标准通用标记语言（SGML），它在60年
24、代后期就已存在。这是广泛使用的元语言，允许组织增加原始文档数据。XML在90年代后期的电子商务运动中声名鹊起，服务器端脚本语言可以经由互联网而处理业务。通过XML的使用，开发者能够给任何片段附加上意义和上下文，再跨越互联网协议传输。XML不仅被用于以标准化的方式来表达数据，其语言自身还被用作一系列的附加规范的基础。XML Schema定义语言（XSD）与XSL转换语言（XSLT）都以XML表达。这些规范，事实上已成为关键核心XML技术集的关键部分。XML表达架构代表了SOA的基础层。在其内部，XML建立了在服务各处流动的消息格式与结构。XSD schemas保持消息数据的完整与有效性，而且XS
25、LT使得不同的数据表达间通过schema映射而能够互相通信。换句话说，没有XML你在SOA内寸步难行。2.1.2 Web服务简史在2000年，W3C接受了一项关于简单对象访问协议（SOAP）规范的提案。这个规范本来设计用于（并在一些案例替代）专有RPC通信。想法是对于在构件间传输参数数据可以序列化成XML传送，然后支序列化成其原生格式。很快，公司及软件厂商开始看到，对于推进通过构建于专有-免费的互联网通信框架之上的电子商务技术，存在日益巨大的潜力。这最后导致了创建一个纯粹的、基于Web的分布式技术能充分利用概念标准化的通信框架，来桥接组织之间和组织内部所存在的巨大差异。这个概念被称为Web服务
26、。Web服务最重要的部分是其公共接口。它是分配服务识别并使其激活的核心信息块。因此，首先支持Web服务的是Web服务描述（WSDL）。W3C第一份WSDL评议提案是在2001年，此后还在不断地修订这一规范。为了进一步的开放协同性的愿景，Web服务需要一个互联网友好的、XML兼容的通信格式，以便能够建立一个标准化的通讯框架。尽管有别的选择，譬如可以考虑XML-RPC，但SOAP因为工业界的偏好而胜出，并且保留了最初的通讯标准用于Web服务。为支持SOAP的新角色，W3C随之发布了更新版本的规范，同时考虑了RPC风格的与文档风格的消息类型。而后者在SOA里面更为常用。最终，“SOAP”一词不再代表
27、“简单对象访问协议”的首字母缩写。到了规范的1.2版，它变成了一个独立的术语。完成第一代Web服务标准家族的是UDDI规范，它原本由UDDI.org所开发，被递交到OASIS之后，它继续与UDDI.org一起合作开发。这个规范考虑在组织内部及组织边界之外来创建标准化的服务描述的注册。UDDI提供了潜在的对Web服务在一个集中的位置注册，在此处能够被服务请求者所发现。WSDL与SOAP不同，UDDI尚未被工业界所普遍接受，并且保留了一个可选的SOA扩展。开发定制的Web服务可适应变化的业务需求，并且第三方市场出现了促进各种实用服务的销售或租赁。现存的通讯平台，譬如面向消息的中间件（MOM）产品，
28、结合Web服务可支持SOAP之外的其他消息协议。一些组织可迅速合并Web服务，以促进B2B数据交换经常要转变为EDI（电子数据交换）替代品的需求。2.1.3 SOA简史不久前组织才开始意识到只需要缓和地替代现存的分布式应用，Web服务可成为独立的架构平台-可使用Web服务技术集的效益来实现企业中服务概念的平台。这样，面向服务架构开始进入IT的主流。在这一点SOA频繁地以不同的方式被分类，经常依赖于构建服务所用的实现技术。早期的模型，主要从Web服务标准初始系列中得到灵感，将SOA定义为一个围绕三个基本的构件的架构模型：服务请求者，服务服务提供者与服务注册（图1）。图1. SOA的早期形态第一代
29、Web服务标准实现此模型的以下方面:o WSDL描述服务。 o SOAP提供了用于服务及其请求者的通讯格式。 o UDDI提供了标准化的服务注册格式。从物理架构的角度，基于Web服务的SOA第一次变异实际上超越了原始SOA模型。你或许能回忆起原始SOA不需要使用服务注册。作为替代，发现被归类为当代SOA的一个特征，通过面向服务原则在服务层面被提倡。我们的原始SOA模型在今天可轻易获得，因为它已被所有主要厂商的开发及运行平台所支持。这些相同厂商都有关于SOA的远大计划，其中许多现在已经能够自我证明。当代SOA的诸多特征，大都是过分主动的开发与协作的结果，已经产生了一系列第一代Web服务平台的扩展
30、。知名的“第二代”或“WS-*”规范，这些扩展处理特殊的功能区域，Web服务技术平台全面提升至企业水平。补充WS-*领域对于将面向服务概念引入业务分析的世界也很重要。通过面向服务，业务逻辑能够清晰地被封装，并从根本的自动化技术中抽象。这个愿景藉由业务流程定义语言的提升而得到进一步支持，最知名的是WS-BPEL。这不仅考虑到将传统的业务流程管理（BPM）模型解决成一系列的服务，更进一步提供具体的和可执行的格式充分表达业务逻辑的语言能力，填补了分析与实现间的空隙。这些及其他工业影响已经扩大了SOA的潜在范围。如同更多的当代特征被增加，也很可能今天我们所归类的当代SOA，会形成未来原始SOA的基础。
31、SOA是一个真正的进化。今天的结果明显是被不同的相关标准组织和软件厂商主动驱动的结果。通过受协作与竞争的混合刺激的不稳定环境，扩展被作为战略定位，每个都定义了我们称为当代SOA技术平台一个特定部分。在第2节，我们近距离看看标准的开发过程。2.1.4 SOA如何改造XML与Web服务如同任何架构，SOA引入了边界和规则。尽管当代SOA可能由XML及Web服务技术平台所构成，但这些平台需要经历大量的变化，以便其各自的技术被适当定位并在面向服务架构范围内加以利用。使用XML或Web服务的传统分布式应用环境因此肯定有一些重新实现，面向服务的设计原则需要在技术与心态方面都进行改变。以下是当你必须对现存实
32、现翻工时，你可能面对的一些潜在问题示例。o SOA现在需要数据表达与服务建模标准表达保持一致。这个相当含糊的需求有许多含意，并主要促进内在协同性。o SOA依赖于负责所有服务间通信的SOAP通讯。结果，所有需要XML的地方，一般也会有SOAP消息，以照顾传输、临时处理与路由及最终交付。XML文档与关联的XSD schema现在经常需要有意地与SOAP通讯一起建模。o SOA使用标准化的文档风格的通讯。从RPC风格迁移到文档风格的消息给服务描述的设计强加了变化。特别地，接口特征需要以更普通的术语表示，并全面增加操作粒度。o 由于强调文档风格的SOAP消息，SOA促进内容及高智能模型。这个支持服务
33、的无状态及自治，并使消息传输的频度最小化。然而先前的RPC风格的方法支持带有目标数据的小颗粒XML文档传输，在SOA内的XML文档经常需要代表不止一个数据语境的绑定数据。o 直到WS-*扩展的高阶信息能力普遍流行，许多应用都将需要配备SOAP报头来实现临时解决方案以管理复杂的消息交换。一些更急迫需求包括管理与关联。这些临时的设计有效地建立了转变模型，需要时可轻易地迁移到工业标准的实现。2.1.5 要点总结核心XML技术集已成为分布式互联网架构的通用部分。现在也提供基础数据表达及SOA数据管理层。o 第一代Web服务架构来自关键标准开发：WSDL、SOAP与UDDI。然而UDDI对于多数据环境而
34、言仍旧是一个可选的发现机制，WSDL与SOAP已经成为构建在XML层之上定义SOA基本通信框架的核心技术。o SOA充分利用XML与Web服务率先铺设的道路。它将久经考验的概念与先进技术的结合，已经被IT社团所充分接受。o 尽管当代SOA已经形成并有了对XML与Web服务的工业级接受度，SOA的到来对于已有XML及Web服务的传统应用还是带来了改变。2.2 SOA进化之标准组织与贡献厂商本文审视XML、Web服务及SOA间的关系，并解释厂商和标准组织如何从那些持续浮现的Web服务规范中形成奇妙的竞争与协同竞技场。然后我们从应用架构简短历史的叙述着手来对过去的二十年作一个总结。 XML作为一种语
35、言，被定义为一个规范，但实际上也被用作表达所有的XML及Web服务规范。这个普遍思路褒扬了这样的事实:不管规范的规模会有多大的增长，都分享了一个公共的根基。无论你是否需要在这些扩展上直接工作，它们的存在与进化将对你所构建的面向服务解决方案有持续影响。有关规范与标准形成的过程及原因的知识，也因此关系到你对于SOA世界的理解。2.2.1 比较“标准”、“规范”与“扩展”这些术语常可交替使用，但是许多特别是与标准组织相关还是有明显的区别。规范是标准的建议文档。直到规范被提交到一个公认的标准组织，并被接受、公布，它都不是正式的工业标准。尽管如此，规范还可被厂商发布（特别是合作厂商），并随之被这些厂商平
36、台实现，通常会进一步成为非正式的工业标准，只是由于它们变得非常普遍。为避免混淆，本书将这些术语作如下定义:o 标准：公认的工业标准。所有的第一代Web服务规范可认作标准，许多XML规范同样如此。o 规范：被提议的或公认的标准，以规范来描述。XML标准，第一代Web服务标准，以及WS-*扩展都以规范的方式存在。o 扩展：扩展典型地代表WS-*规范以及WS-*规范所提供的特性。2.2.2 标准组织对SOA的贡献众所周知，SOA由标准驱动。早先的平台在厂商特定的边界内实现;环境内的标准实际上是专有的。允诺厂商中立的通信框架常伴有不可谈判的需求，就是要定义此框架的标准是同样也厂商中立的。可是，如何确切
37、地制定这些标准，并非总是很清晰。互联网标准组织现在已经存在很长时间，但是它们各自的议程总不大清楚，有时甚至有所重叠。更复杂的问题是这些主要的厂商中立标准的贡献者是厂商自身。微软、IBM、Sun微系统以及众多其他公司已经扮演了日益重要的角色，不仅是制定Web服务规范，还促进了实现这些规范作为工业标准的实现。厂商如何贡献并影响了标准的开发过程将在后续章节解释。让我们首先来熟悉三个最主要的标准组织。它们共同负责完成XML与Web服务架构的进化。2.2.2.1 万维网联盟(W3C)最初由提姆伯尼尔斯李于1994创立，W3C对于万维网作为全球信息分享的语义媒介负有极大责任。它开始于HTML的发布，这是I
38、T行业所产生的最流行的一种语言。当互联网用于包括由电子商务开端的更广范围时，W3C开始制定关键基于XML的基础标准，象XML Schema及XSLT。四个独立工作组对W3C的Web服务活动工程作出了重要贡献，导致了重要的Web服务基本标准开发。首要的是SOAP与WSDL标准，现在已成为Web服务相关的标志性规范。更近一些，W3C已提出了Web服务编舞描述语言(WS-CDL)，一个控制标准化的服务间交换模式的规范。值得关注的还有Web服务架构文档本身。尽管这个文档不断经历变化，它还是保留了一个参考点，且是少数可用的平台中立的Web服务架构文档之一。W3C以正式和严格的标准开发方法而闻名。其过程需
39、要规范受制于诸多的评审与修订阶段，每一个新的版本都会发布在其公开网站上。这样完全的过程要以时间为代价，完成一个标准要用两到三年。2.2.2.2 结构化信息标准进步组织(OASIS)原本于1993年作为SGML开放组织而成立，OASIS五年之后改变了其名称，代表其关注点从SGML转为XML相关的标准。OASIS拥有来自超过600家组织的数千个成员，是一个公认的互联网标准制定组织。OASIS假定拥有著名的WS-BPEL规范的所有权，并且还以其ebXML的开发（一个旨在建立标准化的B2B数据交换方法的规范）和对于UDDI规范的贡献而闻名，后者是第一代Web服务平台的核心标准。OASIS组已经有力地推
40、进了XML与Web服务安全扩展的开发。安全声明标记语言（SAML）用扩展访问控制标记语言（XACML）提供了单点登录与授权领域的重要特性。然而，最重要的安全相关项目由Web服务安全（WSS）技术委员会完成。这个小组被委托进一步开发并实现重要的WS-安全框架。不同于W3C集中于建立核心的、工业未知标准，OASIS组的主要兴趣在于利用这些标准去制定附加规范以支持不同的垂直行业。而且，OASIS所用的标准开发过程要明显短一些。2.2.2.3 Web服务协同组织(WS-I)WS-I的主要目标不是创建新标准，而是确保最终实现开放的协同性目标。这个联盟建立于2002年，已经迅速成长并获得了近200家组织的
41、支持，包括所有的SOA主流厂商。WS-I最为人所知的是发布基本配置文件，用于建立可用标准的基础推荐文档，这些文档共同用于形成最想要的协同性架构。藉由正式地定位WSDL、SOAP、UDDI、XML与XML Schema规范的版本，基本配置文件已成为IT社团内的重要文档。这些组织想要确保它们开发的SOA与其他系统充分协同，并能够保证对于遵从基本配置文件的高层次赞同。最近，WS-I开发了基本安全配置文件。本质是与基本配置文件属于同一概念，这个文档建立了最重要的Web服务与XML安全技术集合。WS-I已宣布了持续发布针对每一Web服务主要方面的相关协同性配置文件计划，包括可靠通讯、Web服务管理与编曲
42、。除了建立基本的协同性架构之外，配置文件还补充了示例实现及最佳实践，以便指导如何与标准一起使用从而达到协同性品质。而且，WS-I还提供了一系列测试工具可用来确保符合配置文件。许多厂商还提供了这些工具的变种，例如:将基本配置文件作为一致的有效性标准的一部分进行有效性检查。WS-I努力提供一个场所，能在同一水准上接受其成员的贡献。当其成员包括重要的SOA厂商之时，没有哪个公司可以比另一个更有权力，不管其规模和市场分额有多大。尽管W3C近期拒绝了加入WS-I联合成员的邀请，但来自WS-I的工作组成员不断主动地直接参与W3C及OASIS的各个工作组工作。这些WS-I代表的角色持续对协同性相关问题进行反
43、馈。2.2.2.4 它们如何比较 表2.1在概要地提供了我们本节所讨论的三个组织间的相互比较。表2.1. 标准组织的比较2.2.3 主流厂商对SOA的贡献尽管标准组织关于标准应当如何开发有其自已的文化与哲学，它们都要受到来自商业市场的深深影响，因此也应当受到支持。即使这些组织作为独立实体存在，它们的成员也包括了相当多的所有主要的软件厂商。而且，这些厂商同样也是这些标准的主要贡献者和最终开发者。一些已经参与标准开发过程的公司包括:微软、IBM、BEA系统、Sun微系统、Oracle、Tibco、惠普、佳能、Commerce One、富士通，Software AG、北电、Verisign与WebM
44、ethods。这种由厂商间的交互、联盟，及与标准组织动态合作而产生现象相当有趣，值得进一步讨论。2.2.3.1 为何要开发标准支持SOA没有人或组织拥有或控制SOA。从专有平台发展而来的架构促进并支持开放的标准与厂商中立的协议，只要主流软件厂商选择支持，SOA将可能为此保留一个重要的架构。那是因为，只要SOA能够在全球范围内象现在这样被继续接受，它的效益就能实现。如果只有一部分的解决方案技术跨应用通信所支持，那么构建协同应用的关键是什么呢?不管如何，SOA今天在所有主流软件组织优先级列表上是首要的。与SOA的不兼容甚至不予考虑，因为这意味着你自己切断了通向正蓬勃成长的市场之路。对于现在和可预测
45、的将来，SOA确实如此。2.2.3.2 厂商影响即使没人单独控制SOA，人人都有关于应当如何形成底层技术平台的观点。为了这一目的，厂商在标准开发过程中的影响已经将SOA的进化转变成一场战争议程。每个厂商在关于计划如何提升自己产品线方面都有自己的愿景。IBM已经展示了一个技术路径支持在其WebSphere平台内逐渐增加对于SOA的支持。微软不仅在.NET技术框架内逐渐增加SOA特性，而且还构建直接将Web服务技术植入Windows操作系统。尽管Web服务标准必须保持非专有化，能够帮助形成标准的厂商却有动机考虑使用专有技术。这不是必经的歧途或甚至有意的操纵。任何人可以主张这些标准由通用产品的有意支
46、持来实现，他们应当通过代表更大市场份额的产品线厂商需求所影响。然而，挑战在于要争取所有厂商来决定应该如何设计一个标准。2.2.3.3 厂商联盟过去厂商间的争斗已经导致厂商间的很多不信任。现在，当想要与规范合作有意去鼓励厂商平台间的协同性时，这些猜疑会表面化并变成障碍。这个问题，与如何紧密联合厂商需求一起是一个特别的规范内容，这已经导致了一些公司形成松散联盟。形成联盟使得厂商为了共同目标而通力合作。通常，联盟的寿命开发止于开发一个特定规范的过程。然而，多数著名的长期合作者(IBM、微软与BEA)已经保持其工作关系而推动了一系列的WS-*扩展。一个更常谈论的示例是在创建了WS-可靠通讯规范的标准开
47、发中，联盟所扮演的重要角色。本来，需要的可靠通讯机制由一个OASIS技术委员会所处理。其贡献者包括Sun微系统与Oracle，且规范被命名为WS-可靠性。然而，它发布之后只有数周的时间，微软、IBM及其他厂商宣布它们拥有自己的规范，称为WS-可靠通讯。规范与处理相同的全部需求非常类似。然而，即使它被发布之后与还不能通过(或甚至提案)一个标准组织所开发，WS-可靠通讯扩展成为直接的竞争者。这只是由于这样的事实:厂商通过共同开发它而占据了一块巨大的Web服务技术平台市场份额。类似这样的事件，不仅反映了Web服务行业的不稳定状态，也揭示了缺乏权威标准组织的把控。2.2.3.4 选择一个标准组织可是，通常来说，通过标准组织而获得正式规范对厂商有益。正式建立规范的目标在于支持一个开放的标准，并受制于开放给公众的一般过程。然而，在时标准组织的选择是有含意的。另一个在标准开发竞技场中的动力是与市场需求直接的。厂商具有市场驱动的目标，发布的产品必须满足客户的要求并匹配或胜过竞争对手所提供的(或计划提供的)。假定W3C
