出处:北京东方通科技公司首席架构师 文: 朱律玮
随着近几年 SOA概念的推广及相关技术标准的发展， SOA逐渐为众多的用户所接受，并在电子政务及企业应用的建设中逐步得到应用。但是，面对众多纷繁复杂的 SOA相关技术标准，IT企业在开发 SOA相关软件产品及用户实施 SOA进行选择时，往往分不清楚哪些技术标准是他们所需要的，而且相当部分的 SOA技术标准的定位，有一定的重合。因此，选择适合的 SOA相关技术标准，成为IT企业和实施 SOA用户的面临的难题。下面，简单介绍一下部分 SOA相关技术标准，并作简单分析。
1. SOA相关技术标准分类
标准与规范基本相似，但略微不同，规范是标准的建议文档。标准一般是由业界公认的标准化组织制定和发布，而规范多为厂商或非标准化组织发布。本文不对它们进行区分，统一称为标准。
SOA相关技术标准的一种分类方式，是根据技术标准在 SOA 中的角色功能，将其分为三大类：服务层次上的信息交互规范、基础通信标准规范、元数据标准规范。根据各种标准规范在 SOA 体系中的角色功能，可以将 SOA 协议栈分为 7 层，如图1所示。从底向上，包括传输层、消息层、描述层、管理层、服务组合层、表示层及服务发现注册层，其中除了ebXML和 电子商务相关的技术标准（如资源注册的ebRS、消息表示ebMS、外部服务资源编排的WS-CDL等）外，大多数在国内已经得到了相当的应用，如东方通科技的应用集成产品TongIntegrator和 应用服务器TongWeb，都支持部分Web服务的相关技术标准，如传输层的 SOAP、RMI、SMTP，消息层的 SOAP、JMS以及描述层的WSDL协议等。
1. SOA相关技术标准分类
标准与规范基本相似，但略微不同，规范是标准的建议文档。标准一般是由业界公认的标准化组织制定和发布，而规范多为厂商或非标准化组织发布。本文不对它们进行区分，统一称为标准。
SOA相关技术标准的一种分类方式，是根据技术标准在 SOA 中的角色功能，将其分为三大类：服务层次上的信息交互规范、基础通信标准规范、元数据标准规范。根据各种标准规范在 SOA 体系中的角色功能，可以将 SOA 协议栈分为 7 层，如图1所示。从底向上，包括传输层、消息层、描述层、管理层、服务组合层、表示层及服务发现注册层，其中除了ebXML和 电子商务相关的技术标准（如资源注册的ebRS、消息表示ebMS、外部服务资源编排的WS-CDL等）外，大多数在国内已经得到了相当的应用，如东方通科技的应用集成产品TongIntegrator和 应用服务器TongWeb，都支持部分Web服务的相关技术标准，如传输层的 SOAP、RMI、SMTP，消息层的 SOAP、JMS以及描述层的WSDL协议等。
图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与JBI
SCA（Service Component Architecture），即服务组件架构，提供了一种编程模型，可以支持基于 SOA的应用程序实现。SCA是一种模型，可以支持实现服务组件的各种技术，连接服务组件的各种存取方法。对于组件，不仅包括不同的编程语言，也包括这些语言使用的框架和环境。对于存取方法SCA合成操作支持各种通讯、服务存取技术，如：WS、MQ、RPC。SCA规范包括了Assemble Model和Client Model两部分。前者约定了如何将异种组件（Java类，BPEL，Web Service）组装并发布成 SOA服务，是SCA最大的特点和最核心的概念；后者则约定了如何在异种语言环境中调用 SOA服务。通过这两部分的规范，就可以完全解决了服务从服务端到客户端的跨语言、跨环境的问题。图4为SCA的服务组件组装模型。
JBI 是Java商业集成（Java Business Integration）的简称。JBI的制订者们认为传统的EAI和B2B解决方案使用非标准的技术，这使得用户往往被锁定到特定的方案和产品提供商上，与此同时，没有任何一个单独的提供商可以覆盖EAI和B2B领域的所有问题。因此他们提出这个标准以期解决这个问题。这个标准定义了一个标准的体系结构允许第三方的组件插入到标准的基础设施上，并且即使这些组件是有不同提供商提供的，它们也可以以一种可预见的和可靠的方式互操作。从高层次上看，JBI 定义了可以从可插入组件构建集成系统的体系结构，这一结构中组件的交互使用一种经过中介的消息交换机制，而这一消息交换模式是基于WSDL 2.0或WSDL 1.1的。图5为JBI环境组成及结构。
图4.SCA服务组件组装模型
SCA（Service Component Architecture），即服务组件架构，提供了一种编程模型，可以支持基于 SOA的应用程序实现。SCA是一种模型，可以支持实现服务组件的各种技术，连接服务组件的各种存取方法。对于组件，不仅包括不同的编程语言，也包括这些语言使用的框架和环境。对于存取方法SCA合成操作支持各种通讯、服务存取技术，如：WS、MQ、RPC。SCA规范包括了Assemble Model和Client Model两部分。前者约定了如何将异种组件（Java类，BPEL，Web Service）组装并发布成 SOA服务，是SCA最大的特点和最核心的概念；后者则约定了如何在异种语言环境中调用 SOA服务。通过这两部分的规范，就可以完全解决了服务从服务端到客户端的跨语言、跨环境的问题。图4为SCA的服务组件组装模型。
JBI 是Java商业集成（Java Business Integration）的简称。JBI的制订者们认为传统的EAI和B2B解决方案使用非标准的技术，这使得用户往往被锁定到特定的方案和产品提供商上，与此同时，没有任何一个单独的提供商可以覆盖EAI和B2B领域的所有问题。因此他们提出这个标准以期解决这个问题。这个标准定义了一个标准的体系结构允许第三方的组件插入到标准的基础设施上，并且即使这些组件是有不同提供商提供的，它们也可以以一种可预见的和可靠的方式互操作。从高层次上看，JBI 定义了可以从可插入组件构建集成系统的体系结构，这一结构中组件的交互使用一种经过中介的消息交换机制，而这一消息交换模式是基于WSDL 2.0或WSDL 1.1的。图5为JBI环境组成及结构。
图4.SCA服务组件组装模型
图5.JBI环境组成与结构
从上面的分析来看，SCA定义了与具体技术无关的服务组件组装模型，SCA的定位，主要在于细粒度的组件和服务组装方式。SCA由于技术无关性及众多厂商的参与，他们得到了大多数厂商的支持。而JBI，它们都是基于Java的技术，JBI更多的像服务总线的 Java标准定义，其粒度比SCA要大，且更多的是服务间的通讯和组装模式，当前支持的主流厂家也不多，但是开源的实现相对还是比较多的。
2.4. WS4BPEL与WS-CDL
WS4BPEL，即Web服务业务流程执行语言，它是一种可执行语言，能够与各种促使业务流程自动化的软件系统相兼容。Web服务编制，通过说明性的方式（而不是编程的方式）表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，目前越来越多的BPM产品基于此规范实现。
WS-CDL，即Web Services Choreography Definition Language，Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点（endpoints）都有Web服务基础设施。此规范更多地用于组织之外的服务与流程编排，目前在国内还不常用。
另外，XPDL也可以用于服务的编排和组合，但它主要用于传统的工作流定义，目前它也是BPM产品实现的重要技术标准。
2.5. JSR168与WSRP
JSR168 是java 规范要求，它为创建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相关技术标准及面临技术标准选择困惑的开发人员、软件厂商及用户等提供一些参考，以此达到抛砖引玉的作用。
WS4BPEL，即Web服务业务流程执行语言，它是一种可执行语言，能够与各种促使业务流程自动化的软件系统相兼容。Web服务编制，通过说明性的方式（而不是编程的方式）表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，目前越来越多的BPM产品基于此规范实现。
WS-CDL，即Web Services Choreography Definition Language，Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点（endpoints）都有Web服务基础设施。此规范更多地用于组织之外的服务与流程编排，目前在国内还不常用。
另外，XPDL也可以用于服务的编排和组合，但它主要用于传统的工作流定义，目前它也是BPM产品实现的重要技术标准。
2.5. JSR168与WSRP
JSR168 是java 规范要求，它为创建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相关技术标准及面临技术标准选择困惑的开发人员、软件厂商及用户等提供一些参考，以此达到抛砖引玉的作用。