SOA标准选型研究

　　旨在介绍SOA项目实施中涉及到的技术标准。重点介绍SOA的支撑技术Web Service的相关技术标准。包括各技术标准的分类介绍。技术标准之间的冲突及解决方案等。目的是为SOA项目的开发者和使用者提供对SOA技术标准的正确。直观、全面的印象。给实施SOA项目的技术人员和使用SOA项目的用户提供采用技术标准的参考依据。

　　引言

　　新技术的兴起必然伴随着一系列技术标准和规范的诞生，SOA也是如此。短短几年内，在厂商、研究人员和标准化组织的共同努力下，已经制定出一大批SOA 标准和规范，有力地推动了SOA的发展。而这些标准或规范经过实践的检验，有些已成为目前SOA项目实施中的主流，有些已不适应目前的发展趋势，渐被淘汰。所以，了解SOA领域中技术标准的现状，对于实施效果良好的SOA项目是不可缺少的。

　　在SOA解决方案各组成领域都会存在不同厂商和组织基于不同立场提出的协议和标准。并且在短时间内不可能走向统一。为避免IT建设从“信息小孤岛”演变为“信息大孤岛”，了解SOA解决方案各层次不同协议之间的关系，研究基于现状、面向未来的SOA建设方案就成为SOA架构师与和质量架构师的重要工作之一。

　　SOA的技术标准大体上可以分为XML标准集、Web服务标准集和SOA参考模型。2001年10月，W3C发布了XML信息集（XML Information Set，XML Infoset）。Infoset是一个抽象的数据模型，兼容基于文本的XMLl.0，也是所有最新XML规范（XML Schema、XML Query和XSLT2.0）的基础。Web服务标准集内容丰富，涵盖传输层、消息机制、编程模型、服务发现和描述、可靠性：事务处理、安全和管理等方面。SOA参考模型由结构化信息标准促进组织制定和发布。它统一了SOA相关术语的用法和涵义，同时还明确定义了SOA各组件之间的关系。

　　1 、SOA标准应用现状分析

　　SOA通过建立一种统一的架构，使得软件开发人员能快速开发，集成和重用。更为重要的是，基于这种软件框架，系统能在业务发生变化之后，动态响应新的需求，快速重新装配各种软件构件和服务。

　　支撑SOA架构的实施技术可以包含W e b服务、CORBA、DCOM等多种类型。其中，CORBA协议和DCOM协议都是比较成熟的，Web服务技术则是2000年以后随着电子商务的兴起而诞生的、面向Internet在网络上发布和调用程序的一种方法。Web服务技术不是一个单一的标准，它糅合包括从传输层协议（HTTP/SMTP /FTP）、数据表现层（XML）、数据模型层（XML SCHEMA）、消息层（SOAP）、消息安全层（WS-Security）、服务描述层（WSDL）、服务发布与发现层（UDDI）、服务业务流层 （BPEL）等紧密相关的多层次协议栈。图1为SOA的相关标准分类。

　　在SOA的各层协议中，不同组织或公司发布的协议既具有相容的方面，也具有冲突的地方。下面仅对SOA协议栈中的消息层协议和服务质量层协议之间互相冲突的协议进行比较研究，以此说明sOA系统中标准规范的不同，进而明确在SOA系统的实施过程中存在标准的选择问题。

　　1.1消息层

　　●协议间冲突问题

　　在可靠消息传输领域主要是WS Reliability和WS ReliableMessaging之争，两项协议在功能上有大量叠加部分，且存在较大的不兼容性。

　　●目前解决方案

　　可靠消息传输标准的争议源自两家厂商阵营在利益上的竞争，WS-ReliableMessaging以IBM、微软、BEA和Tibco等行业巨擘为首，占据重要的市场份额，虽然标准提交较WS-Reliabitiy晚，但在竞争中占较大优势，在OASIS的促进下，目前两项标准趋向统一，OASIS 标准起草委员会负责人James Bryce Clark称，已将WS ReliableMessaging审核放人快速程序，两项标准有望在不久的将来取得和解。

　　●背景资料

　　在典型的 SOA环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（once—and—only—once delivery）、“最多传送一次”（at-most-once delivery）、“重复消息过滤”（duplicate message elimination）、“保证消息传送”（guaranteed message delivery）等特性消息的发送和确认，在关键任务系统（mission-critical systems）中变得十分重要。WS-Reliability和WS-Reliable Message是两项用来解决此类问题的标准。

　　1.2服务质量层

　　1.2.1安全

　　●协议间的冲突

　　安全协议的冲突主要是围绕OASIS、Libery Alliance的SAML（Security Assertion Markup L a n gu a g e。安全断言标记语言）和微软等的W S Federation两大阵营展开的，SAML是由OASIS制定，这家非营利性组织得到了EDS、IBM和Sun等重量级IT厂商的资助，旨在推动及促进Web服务，目前的最高版本是SAML2。微软及IBM已制定了一项不同的专有规范WS-Federation。WS-Federation让客户可以使用名为微软活动目录联合服务的产品，把安装的活动目录与其他活动目录连接起来。该系统可以读取SAML令牌以及其他类型的身份信息，不过处理令牌的方式并不相同。WSFederation和SAML在不少功能项出现叠加（overlap），主要表现在帐户联邦（Account federation）、私有、安全令牌、业务和政策发布、底层技术五项叠加的功能。以底层技术为例，Liberty Alliance主要扩展SAML并以依赖于SSL和WS-Security来保障传输和消息的安全；而WS-Federation的底层技术建立在 WS-Trust.WS Policy和WS—Metadata基础之上并且以SSL和WS Security来保障传输和消息的安全。两套解决方案在对待开源这一问题上，态度也是截然相反的：SAML的做法是坚持开源，而WS- Federation不属于开源阵营。

　　●目前解决方案

　　目前，联合工具厂商正在把结合WS-Federation 和SAML／Liberty两种协议的功能加人到产品中，其中就有RSA、拥有Tivoli产品线的IBM、Ping Identity以及惠普。然后，客户要把这些产品与身份管理基础设施或者想要允许用户访问的任何应用程序集成起来。从安全角度来看，公司应当走哪条路线不但取决于操作环境，还取决于选择开放源代码方案还是选择专有方案。开源可能使得工具的获取更加容易，同时也意味着人侵系统的人也会掌握更多的系统安全信息。

　　●背景资料

　　SAML允许企业发布在整个企业范围有效的用户身份认证和授权证书。OASIS在经过近一年半的努力，批准了期待已久的SAML2.0版，它增加了账目链接、全球注销、带隐私功能的属性交换和同Shibboleth和自由联盟的互操作等功麓，SAML Assertion元素可以以原始形式插入到Security元素中。

　　WS Federation规范允许软件开发商为运行在各种安全设计上的网络服务创建一个共同方法，其目标是允许人们登录网络服务并进人多种应用软件。支持 WS-Federation规范的公司认为。采用该规范的开发商可以彼此建立“信赖关系”，理顺公司之间的电子消费交易业务。

　　1.2.2事务机制

　　●协议间的冲突

　　Web服务事务处理领域有两大标准相竞争：oASlS业务事务处理协议（Business Transactions Protoc01.BTP）和Web服务事务处理（WS-Transaction）规范。两种协议在协调构架、事务处理框架，严格的原子模型、灵活的模型、范围、服务行为、业务逻辑分离和失败恢复等方面部存在不一致之处，例如在列原子模型的要求上wS Transaction要求严格的ACID特性，特别是在与穿透事务处理进行互操作时；而BTP所谓的。原子“只是指的原子性，也就是ACID中的A，其他属性通过服务指定（而通过协议指定无效）。使用Open-top协议使得现有的事务处理系统进交互操作变得非常困难。

　　●目前解决方案

　　拥有ACID的WS-Transaction看似不适合松耦合的Web系统环境，但我们要注意到，目莉还有大量的企业现有基础设施使用强耦合的架构，混合使用也是解决该冲突问题的方法。

　　●背景资料

　　为了获得相互一致的结果，大多数工作流和企业到企业（828）协作应用程序都需要事务处理支持。事务处理支持保证输出结果在组成业务活动的应用程序中的所有任务间都能保持一致，这些任务包括了相应的业务活动。一个任务的执行结果一般在整个应用程序或活动结束勘都能保持有效。例如，航班预订系统能在一段特定时间内为一个乘客保留某航班的一个座位，但如果该乘客没有在这段时间内确认这个座位，那么该座位应该重新收回，以便下一位乘客能够预订它。

　　2、标准选型

　　上面我们探讨了SOA架构的消息层和服务质量层等现有协议存在的影响和目前业内的一些解决方案。可以看到，只要有利益驱动，冲突是无法避免的。而且各种标准本身也需要市场来证明其应有的价值。但目前协议割据的现状又势必造成在实际开发中的彷徨和无所适从，大孤岛效应也使得采用SOA架构的IT设施的优势大打折扣。为最大限度地保证SOA架构的互操作性、通观处理协议与标准冲突的经验，我们提出如下手段：

　　●为SOA架构各层提供一个凌驾于冲突各方标准之上的底线标准，使得采用不同标准开发的SOA项目的互操作有可以挽回的余地；

　　●作为标准的制定力量之一，联合大厂商强化某一开放标准当然也不失为手段之一，但更有效的手段是加强对原有标准的引导，使得为同一层次而设的标准侧重点逐渐明晰，统一的道路将更为平坦；

　　●对于采用标准SOA设施的开发商而言，明确现有标准在实际使用中的优劣，根据项目的实际需求，选择某种标准甚至是某几种标准的混合体，不失为务实的良策。