随着近几年SOA概念的推广及相关技术标准的发展，SOA逐渐为众多的用户所接受，并在电子政务及企业应用的建设中逐步得到应用。但是，面对众多纷繁复杂的SOA相关技术标准，IT企业在开发SOA相关软件产品及用户实施SOA进行选择时，往往分不清楚哪些技术标准是他们所需要的，而且相当部分的SOA技术标准的定位，有一定的重合。因此，选择适合的SOA相关技术标准，成为IT企业和实施SOA用户的面临的难题。下面，简单介绍一下部分SOA相关技术标准，并作简单分析。

　　1.SOA相关技术标准分类

　　标准与规范基本相似，但略微不同，规范是标准的建议文档。标准一般是由业界公认的标准化组织制定和发布，而规范多为厂商或非标准化组织发布。本文不对它们进行区分，统一称为标准。SOA相关技术标准有多种分类方式，本文介绍两种。

　　1.1.分类方法一

　　一种方法是将其分成三类，即XML标准集、Web服务标准集和SOA参考模型：

　　XML标准集

　　主要包括两类，一是基于纯文本的编码技术，XML信息集、XML Schema、XML Query和XSLT 2.0等。二是允许不透明的二进制数据与传统的基于文本的标记交织在一起的编码技术。如XML二进制优化封装协议（XML-binary Optimized Packaging，XOP）、SOAP 消息优化（Transmission Optimization Method，MTOM）等。

　　XML标准集是促进SOA发展的头等功臣，它们多数是由W3C组织制定，并得到了众多软件厂商及用户的支持和使用，如不管是Java阵营还是.NET阵营，乃至其他软件开发技术，大都提供XML标准集的工具包。XML标准集不但是用于SOA数据描述和处理的最佳标注，它还是其他SOA相关技术标准的基础，如Web服务标准，都是以XML来进行描述的。

　　Web服务标准集

　　Web服务标准集已经初具规模，内容涵盖传输层、消息机制、编程模型、服务发现和描述、可靠性、事务处理、安全和管理等方面。如WSDL用于Web服务的语义描述，WS-Policy用来描述Web服务的能力和策略等，WS-Security、SAML等用来描述Web服务相关安全性要求，等等。目前，多数Web服务标准集，由OASIS组织制定，有些Web服务标准尚不完善，正在发展中。

　　SOA参考模型

　　SOA发展早期，不同厂商宣扬的SOA参考模型不尽相同，随着相关技术标准的发展，各个厂商的认识逐渐统一。当前，OASIS已经制定了SOA的参考模型SOA-RM1.0规范，它提供了一个整体的抽象框架，它用来理解SOA先进技术理念的抽象框架，是在面向服务环境里的重要衔接方式，是标准逐步统一的重要发展进程，也是服务支持的详尽规范。SOA参考架构，能够在企业的SOA整体计划中提供一个很具有全局性的整体框架加以指导，但却不能在现实的SOA执行中提供太多具体可行的意见。

　　虽然已经有了SOA参考模型的推荐性标准，但标准化组织和厂家在SOA的参考架构上还没有统一。

　　1.2.分类方法二

　　SOA相关技术标准的另一种分类方式，是根据技术标准在 SOA 中的角色功能，将其分为三大类：服务层次上的信息交互规范、基础通信标准规范、元数据标准规范。根据各种标准规范在SOA 体系中的角色功能，可以将 SOA 协议栈分为 7 层，如图1所示。从底向上，包括传输层、消息层、描述层、管理层、服务组合层、表示层，其中除了ebXML和电子商务相关的技术标准（如资源注册的ebRS、消息表示ebMS、外部服务资源编排的WS-CDL等）外，大多数在国内已经得到了相当的应用，如东方通科技的应用集成产品TongIntegrator和应用服务器TongWeb，都支持部分Web服务的相关技术标准。传输层作为传统的传输协议，在SOA技术实现中，依然发挥着重要的作用；消息层SOAP已经是Web服务消费的消息传输载体的首选；Web服务描述标准WSDL，虽然在语义方面的描述还不完善，但它已经被绝大多数厂商和用户接受并使用了；在管理层的相关技术标准，目前还在发展完善，国内实际应用的还不多，但诸如常用的安全要求WS-Security、可靠传输要求WS-Reliability等，已经有用户和厂家开始考虑使用；服务组合层，已经有不少的商业及开源组织，基于BPEL标准来开发业务流程管理软件了；表示层的标准如JSR168和WSRP，主要用于Portal软件的开发。

　　图1.SOA协议栈分层结构

　　2.SOA相关技术标准比较说明

　　由于SOA相关技术标准太多，图1中，并没有完全列举出所有的SOA相关技术标准。下面，就部分相似的SOA相关标准进行比较说明，以便进行SOA开发时，能够基于了解认识进行选择。

　　2.1.WSDL与OWL-S

　　W3C组织提出的标准的Web服务描述语言WSDL，它从句法层面对Web服务的功能进行描述，包括4个不同的粒度：数据类型（Data type）、消息（Message）、方法（Operation）和访问端口（PortType）。这只是提供了Web服务的接口描述，对服务的行为约束和属性描述缺乏进一步的支持。

　　OWL-S是语义Web服务标记语言的标准，它比WSDL更能向用户提供可理解的服务资源的描述形式，提高服务选取与推荐的准确性。语义Web服务的主要方法是利用Ontology来描述Web服务，然后通过这些带有语义信息的描述实现Web服务来实现服务的自动发现，调用和组合。语义Web和Web 服务是语义Web服务的两大支撑技术。OWL-S是连接两大技术的桥梁，目前对语义Web服务标记语言研究最重要的组织就是DARPA组织，其研究组OWL Services Coalition提出了语义Web服务标记语言OWL-S（原DAML-S）。

　　语义Web服务及相关标准（OWL-S等）对于Web及Web服务应用的深化具有重要意义，同时也具有很好的发展前景。目前OWL-S等语义Web服务相关标准的应用还主要是研究性、示范性的。

　　2.2.XML Web服务与ebXML

　　SOA中的服务，当前多以Web服务技术实现和解释，传统的Web服务及其相关协议，都是以XML为基础进行扩展的，因此我们把它称为XML Web服务。其实，在XML Web服务之前，ebXML已经出现，鉴于此标准复杂而完善，因此它在传统的电子商务领域，用处较广。就具体的内容和定位而言，两者有一定的区别。

　　1)消息传输技术

　　XML Web服务和ebXML都使用SOAP作为消息传输技术，但是XML Web服务服务定义了松散耦合的协议堆栈，该堆栈由可靠传输 (WS-Reliability) 和 安全 (WS-Security) 的各个规范组成，而ebXML将所有这些功能都融入到自己的消息传递标准和ebMS中，从而使用混合技术。

　　2)服务描述和发现

　　XML Web服务分别使用WSDL和UDDI标准，UDDI注册机制是基于目录的体系结构，其注册内容包括技术模型和业务模型，本身可扩展但目前其注册的内容和描述还不够丰富和完整，图3为UDDI的数据模型及关系图。

　　而ebXML将服务描述和发现机制对应两个标准，一是注册信息模型ebRIM，二是注册服务规范ebRS。ebXML注册机制要比UDDI丰富和完善的多，它的注册机制用途广泛，可以表示范围广泛的数据对象，包括 xml 模式、业务流程描述、ebXML Core Component、UML模型、一般贸易合作伙伴信息及软件组件。为了支持如此多样的数据，使用一个定义良好的信息模型而不是目录，将ebXML注册设计得更像一个数据库，图2为ebXML的注册信息模型ebRIM的组织结构示意图。

　　3)业务流程协作
　
　　基于Web服务的业务流程协作和服务编排，有WS4BPEL、WS-CDL、基于XML的工作流XPDL等，这些基于XML和Web服务的标准都彼此相对独立，甚至是不同的组织制定。

　　ebXML标准也包含业务流程协作的标准，如ebCPPA、ebBPPS。

　　总之，ebXML是一个独立的规范集，具有内部一致性，而且不依赖于新兴标准和规范，它的用途主要定位在有特殊要求的电子商务方面，目前，ebXML已被国家确定为国标推荐，但其应用看起来还要有一段路要走。而XML Web服务由于其内容相对简单，技术实现容易，对应的一系列协议栈相对松耦合，因此其在构建SOA的应用中使用越来越广泛。

　　图2.ebXML的注册信息模型(ebRIM)

　　图3.UDDI数据模型及其关系图

　　2.3. SCA/SDO与JBI/JDO

　　SCA（Service Component Architecture），即服务组件架构，提供了一种编程模型，可以支持基于SOA的应用程序实现。SCA是一种模型，可以支持实现服务组件的各种技术，连接服务组件的各种存取方法。对于组件，不仅包括不同的编程语言，也包括这些语言使用的框架和环境。对于存取方法SCA合成操作支持各种通讯、服务存取技术，如：WS、MQ、RPC。SCA规范包括了Assemble Model和Client Model两部分。前者约定了如何将异种组件（Java类，BPEL，Web Service）组装并发布成SOA服务，是SCA最大的特点和最核心的概念；后者则约定了如何在异种语言环境中调用SOA服务。通过这两部分的规范，就可以完全解决了服务从服务端到客户端的跨语言、跨环境的问题。图4为SCA的服务组件组装模型。

　　服务数据对象(SDO)的设计初衷是为了统一和简化应用程序处理数据的方式,使用SDO,应用编程人员可以用一致的方法操作异构数据源,包括关系型数据库,XML数据源,Web services和企业信息系统 。

　　JBI是Java商业集成（Java Business Integration）的简称。JBI的制订者们认为传统的EAI和B2B解决方案使用非标准的技术，这使得用户往往被锁定到特定的方案和产品提供商上，与此同时，没有任何一个单独的提供商可以覆盖EAI和B2B领域的所有问题。因此他们提出这个标准以期解决这个问题。这个标准定义了一个标准的体系结构允许第三方的组件插入到标准的基础设施上，并且即使这些组件是有不同提供商提供的，它们也可以以一种可预见的和可靠的方式互操作。从高层次上看，JBI定义了可以从可插入组件构建集成系统的体系结构，这一结构中组件的交互使用一种经过中介的消息交换机制，而这一消息交换模式是基于WSDL 2.0或WSDL 1.1的。图5为JBI环境组成及结构。

　　图4.SCA服务组件组装模型

　　图5.JBI环境组成与结构

　　JDO，即Java Data Object，它定义了持久保存类与JDO运行时环境之间的关系。JDO的设计目的是用来广泛支持不同的数据来源，甚至包括一般不被认为是数据库的来源。因此我们用“数据存储空间”（datastore）一词泛指以JDO 访问的底层数据来源。

　　从上面的分析来看，SCA/SDO定义了与具体技术无关的服务组件组装模型及服务间访问的数据结构表示方式，SCA的定位，主要在于细粒度的组件和服务组装方式。SCA/SDO由于技术无关性及众多厂商的参与，他们得到了大多数厂商的支持。而JBI/JDO，它们都是基于Java的技术，JBI更多的像服务总线的Java标准定义，其粒度比SCA，而且更多的是服务间的通讯和组装模式，而JDO是基于Java的数据对象表示，因此它们使用的范围受到限制，当前支持的主流厂家也不多，但是开源的实现相对还是比较多的。

　　2.4.WS4BPEL与WS-CDL

　　WS4BPEL，即Web Service Business Process Execution Language的简写，Web服务业务流程执行语言，它是一种可执行语言，能够与各种促使业务流程自动化的软件系统相兼容。Web服务编制，通过说明性的方式（而不是编程的方式）表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，目前越来越多的BPM产品基于此规范实现。

　　WS-CDL，即Web Services Choreography Definition Language，Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点（endpoints）都有Web服务基础设施。此规范更多地用于组织之外的服务与流程编排，目前在国内还不常用。

　　另外，XPDL也可以用于服务的编排和组合，但它主要用于传统的工作流定义，目前它也是BPM产品实现的重要技术标准。

　　2.5.JSR168与WSRP

　　JSR168是java 规范要求（java specification request ，jsr）的缩写，它为创建portlet建立标准的api，它是为实现porltet、基于java的门户服务器和其他web应用程序之间的互操作性而设计的。JSR168的主要价值在于它被独立软件开发商（isv）所广泛采用。在采用JSR168之前，企业应用程序开发商不得不支持所有开发商门户的不同portlet集，支持多个门户开发商不同的portlet集在类似业务信息、内容管理、检索和分析这样的领域中非常令人头疼。使用JST168规范，现在开发商只需要支持一种portlet集。目前，JSR168在基于Java技术开发Portal产品上，得到了广泛的支持，但也仅限于Java技术。

　　WSRP，即Web Services for Remote Portlets的缩写，它定义了如何利用基于 SOAP 的 Web 服务在门户应用程序中生成标记片断的规范。通过定义一组公共接口，WSRP 允许门户在它们的页面中显示远程运行的 portlet，而不需要门户开发人员进行任何编程。对于最终用户，这些 porlet 就和运行在他们本地的门户上一样，但是实际上这些 portlet 来自于远程运行的 portlet 容器，并且交互是通过 SOAP 消息的交换来实现的。在面向服务的体系结构中利用 WSRP 将是一个强大的组合，从而使面向呈现的 portlet 应用程序可以被发现并重用而不用任何额外的开发和部署活动。WSRP是由OASIS组织制定，目前已得到多数厂商的支持，鉴于它基于Web服务标准，而且技术相对独立，因此随着此标准的逐渐完善，相信越来越多的Portal生产企业会支持此标准。

　　3.总结

　　前面对部分SOA相关技术标准的比较分析，不可能覆盖所有的SOA相关技术标准，如SOA的参考架构、Web服务协议栈的比较分析等。本文的目的，希望能够为希望了解SOA相关技术标准及面临技术标准选择困惑的开发人员、软件厂商及用户等提供一些参考，以此达到抛砖引玉的作用。