SOA编程模型介绍

目前比较流行的SOA编程模型有3种:Indigo,JBI和SCA.

一.Indigo

Indigo是Windows通信基础，它试图为所有服务元件创建统一的OO模型来简化服务编程。

Indigo将服务定义为暴露一组端点(endpoint)的程序，每个端点是3个主要元素的组合5：

　　端点的地址(address)——它是一个网络地址，通过它，端点可以被寻址。

　　端点的绑定(Binding)——它指明了与端点进行通信的额外细节，包括传输协议(如TCP、HTTP)和编码策略(如文本、二进制)，安全需求(如SSL、SOAP消息安全)等。

　　端点的契约(Contract)——它指明由该端点暴露的操作，被这些操作使用的消息，以及消息交换模式(Message Exchange Patterns，MEP)，如单向、双向和请求/答复。

　　通过允许使用包含不同绑定和端点契约(QoS)的复合端点(multiple endpoints)来暴露相同的功能(服务)，这些定义有效地扩展了基于WSDL的服务定义。

　　Indigo编程模型的基础之一是使用OO实现SOA编程的所有方面。

SO实体	OO实体	标注
服务契约	接口	使用[ServiceContract]]标注接口
服务操作	方法	使用[OperationContract]标注接口方法
实现类	类	使用[ServiceBehavior]标注类，它由服务契约接口派生。
实现方法	方法	使用[OperationBehavior]
数据契约	类	使用[DataContract]标注类，[DataMember]标注成员

表1 Indigo中的SO实体和OO实体的关系。
　　表1显示了SO实体与OO概念之间的映射(由Indigo编程模型定义)，以及将它们关联起来的标注6。SO与OO的融合既是Indigo的主要优点，也是它的缺点：

　　OO是被大多数开发者所熟悉的行之有效的范式。这意味着可以使用一种熟悉的技术开始开发新的面向服务架构解决方案。这种情况下，Indigo运行时会在幕后将OO风格的调用转变成用来通信的可互操作的SOAP消息。

　　SO与OO有很大的不同。使用OO作为定义和实现服务的一种机制会创建出一个高度不匹配的实现(粒度、耦合等等)，这可能导致非最优甚至苍白的面向服务架构实现。

　　Indigo支持2种主要的服务调用方式：

　　携带一组类型参数(最初的Web服务版本)的RPC风格调用(同步和异步)。这种类型的服务调用非常类似传统的方法调用，使用在分布式对象和RPC实现中。

　　消息传递风格调用(同步和异步)。这种类型的服务调用类似传统的消息系统(类似本书前面介绍的语义消息传递)。

　　根据服务提供的访问类型(RPC vs. 消息传递)，它的契约被定义成接口(RPC)或消息(消息传递)契约形式(参见表1)。

Indigo的另一个基本特性是：引入连接器(提供安全可靠的通信的托管框架)用于访问服务端点。通过将“管道部分”分离进入单独的类(类层次)，并在大多数情况下提供“标准”实现，连接器减少了用于构建互操作服务所必须的“管道代码(plumbing code)”，从而简化了“被连接系统”网络的创建。

　　Indigo连接器使用很少的概念(端口、消息和信道)，使得服务调用独立于传输协议或目标平台。它们中最重要的是信道(channel)，它抽象了给(从)端口发送(接收)消息的处理过程。Indigo中定义了2类信道：

　　传输信道(Transport channels)用于支持特定的传输协议，如HTTP、TCP、UDP或MSMQ和拓扑结构，如点对点、使用中介(intermediaries)的端到端、对等、发布/订阅。

　　协议信道(Protocol channels)用于支持特定的QoS特性，如安全信道加密消息和增加安全头。Indigo使用 WS-*c规范来实现协议信道。坚持标准使得Indigo的实现可以与其他基于WS-*兼容性实现的系统互操作。

　　Indigo同样支持组合信道概念——将一个信道置于其他信道之上。如，可以使用将安全协议信道置于HTTP传输信道之上来提供安全的HTTP传输通信。

　　Indigo连接器提供了一个构建(Build)为中介提供支持，包括防火墙、代理和应用程序级网关。这些中介是成功实现SOA所必须的很多模式的实现基础，包括消息验证、安全性加强、传输层交换、监视和管理、负载均衡和基于上下文的路由。

　　除了支持业务服务创建，Indigo还提供几个系统服务，它们可以被任何业务服务实现使用。这些服务的例子如下：

　　联邦认证。这个服务基于WS-Federation，支持企业内部和来自外部边界的身份管理和验证。它的实现在服务和相应的可信凭证之间代理认证。

　　事务支持。这个服务基于WS-AtomicTransaction规范，简化了基于服务的事务编程

二.JBI

JBI 是Java Community Process管理的JSR中的一种，它通过创建专用(服务)容器形式的抽象层，解决服务编程的复杂度和可变性。

Java Community Process利用应用服务器托管应用程序的成功，将它的JBI实现建立在服务容器概念之上。

　　就像Java业务集成(IEEE互联网计算)中定义的那样——“JBI是由容器和插件(Plug-in)组成的可插入式架构。这个容器托管使用消息路由进行通信的插件组件。架构上，组件通过一个抽象的服务模型(一个消息传递模型，位于任何特殊协议或消息编码之上的抽象层中)进行交互。"

　　在基于JBI的实现中，服务之间并不直接交互。取而代之的是，采用类似EAI实现中广泛应用的消息代理架构，JBI容器扮演在服务之间路由消息的通用中介，(见图1)。



图1 通过JBI协调消息交换
　　分离交换的参与者(JBI架构的基础)在服务提供者和消费者之间提供了解耦，以及一个用于协调(mediating)服务通信量(或插入所有额外需要的功能)的明确位置。

　　此时，协调器(Mediation)可以支持广泛的功能，从消息传送和安全加强，到基于内容的路由和服务标本标定。

JBI容器托管了2类不同的插件组件：

　　服务引擎(Service Engine，SE)。SE本质上是用来托管JBI环境内部服务提供者和消费者的标准容器f。例如，在JBI环境中经常出现的SE包括数据转换器、业务规则容器和BPEL引擎。

　　绑定组件(Binding Component，BC)。BC为JBI环境外部的服务消费者和提供者提供互联性。BC允许集成不提供Java API的组件/应用程序，并使用远程存取技术访问它们。

　　组件间的交互利用了基于WSDL 2.0的标准化服务定义。WSDL 2.0定义在服务消费者和提供者之间提供了共享的协议，并作为JBI实现互操作能力的基础。

　　除了标准化的服务定义，JBI使用“通用化(normalized)”消息的概念支持全局组件互操作能力。消息通用化将协议与业务特定的上下文映射成一个通用的、可传输风格，这与EAI实现中经常使用的“规范(canonical)”消息表示概念非常类似。

　　每个JBI容器存在于一个单独的虚拟机中，并容纳所有的BC和SE，容器提供了一组服务，为SE和BC实现提供操作性支持。

　　JBI也定义了基于JMX的标准控制集合，允许外部管理工具执行不同的系统管理任务，也可以管理组件本身。管理支持为以下情形提供了标准机制：

　　安装plug-in组件。

　　管理plug-in组件的生命周期(启动/停止等。)。

　　部署服务器件给组件。

三.SCA

SCA由IBM、BEA、IONA、Oracle、SAP、Siebel、Sybase等公司共同制定，它基于的前提是：以结构良好的组件为基础，兼具清晰的接口和明确的组件责任，这样的体系结构有充分的理由被视为SOA。

尽管服务组件架构(SCA)被作为规范定义(该规范定义了使用面向服务架构构建系统的模型)，但它是一个有效的模型(该模型用来将组件组合成服务)，并为服务组合成解决方案提供了额外支持。

　　SCA基于2个主要的元模型：

　　类型元模型。

　　组合元模型。

　　类型元模型

　　这个元模型(见图2)描述组件类型、接口和数据结构。




图2 描述组件、接口和它们依赖的元模型
　　一个组件实现由以下的4组规范定义：

　　被提供的接口——组件定义的接口集。这些接口通常定义为WSDL端口类型或语言接口，如Java或C++。一个组件可以暴露0或多个接口。每个接口包含几个方法。

　　被要求的规范(引用)——组件实现使用的接口集。这些接口通常定义为WSDL端口类型或语言接口，如Java或C++。一个组件可以有0或多个接口。

　　用来裁剪或自定义组件行为的属性。每个属性定义为一个属性元素。一个组件可以包含0或多个属性元素。

定义组件实现的实现元件。SCA允许很多不同的实现技术，如Java、BPEL、C++、SQL等。SCA为引入新的实现类型定义了扩展机制。

组合元模型

　　这个元模型(见图3)定义了组件实例，以及它们是如何连接的。




图3 组件实例和它们在组合元模型中的连接
　　这个元模型中实例的概念有别于在OO中使用的实例概念。此处的组件实例是指一个带有被完整解析的属性集，为解决特殊问题而修改组件行为的组件实现。

　　一个组合定义了很多组件实例，它们彼此交互，这里的交互使用连线(wire)来定义。

　　在SCA中，连线使得绝大多数的底层代码被抽出(与Indigo中的信道类似)。如，连线可以被定义同步的或异步的，支持组件调用的事务行为等。SCA在幕后处理这些底层细节。连线同样可以在任意方向上连接2个不同的接口语言(如Java接口和WSDL 端口类型/接口)，只要这2个接口定义的操作是等价的就行了。

　　除了连线，SCA也支持通过特殊的组件类型，如导入(imports)和导出(exports)，进行模块间通信。连线、导入和导出组件的结合使得组件可以引用外部服务。

　　组合元模型定义的组件组合，与服务组合既类似又不同，尽管两者都定义了使组件/服务一起工作的方式。通过被组合本身引入的功能，服务组合增强了参与服务的功能;而这个元模型只定义组件(更接近于服务实现)间的连接。

　　SCA实现依赖于服务数据对象(Service Data Objects，SDO)，它提供了表示数据的通用模型的技术。SDO是组件的数据交换基础。SDO架构中的基本概念是数据对象——包含基本类型数据和(或)其它数据对象的容器。元数据提供了被包含数据的信息，它被数据对象显式引用。在SDO中数据对象的组合由数据图表示。除了对象本身，图中还包含变更概要，用来记录图中数据对象和属性在处理过程中变化的信息(类似微软环境中的ADO)。除了SDO，SCA还引入了服务消息对象(Service message objects，SMO)，它提供了服务间处理和交换消息的抽象层(类似JBI中的标准化消息)。

　　SCA目前尚显稚嫩(本文写作时版本为0.9)，并且还不支持SOA实现要求的大多数?模式。作为替代，目前IBM的Websphere ESB/WPS 6.0的SCA实现引入了协调器框架，它基于SCA并为协调器实现和定位提供了定义良好的机制。(类似Indigo中的中介)。

　　如果GUI支持，SCA实现会非常强大，可以在面板上实现图形化组件的连接，这种方式正是IBM的WebSphere Integration developer(WID)中所实现的。

在SCA的模型中用户一般看到的都是Service。只有在这个粒度上，SCA服务才具体到实现层面，通过<implementation>元素跟具体的实现绑定起来。

可以看到，一个Component可以有Java（通过JDK1.5的Annotation进行实现绑定），BPEL、Composite等各种实现，这也是与SOA本身保持技术中立的立场是一致的。

从下图可以看到，除了实现，还有若干关键概念：

首先是Properties。它用来设定一个Component的配置项，这确保了一个Component的外部可配置性，可复用性。

然后是该Component所实现的Service，即提供的服务。当然，一个Component也可以不提供任何服务。

最后是Reference，即Component所引用的东西。有点类似java里的import或c#中的using概念。Component虽然是粒度最小的单元，但是并不意味着它是孤立的。它可以指定所依赖的其他部件。

Component作为最小粒度的构件，通过组合（即wire）可以上升一个层次，形成更大粒度的构件，即Composite。

Component可以选择把它的Property上升成为Composite的Property，把它的Service和Reference上升为Composite的Service和Reference。即，把它们的可见性暴露出来。

那些不暴露出来的Service和Reference则可以通过wire将服务的引用和服务的实现串联起来。所以服务可以是外部的，也可以是内部的。

Composite本身的名字容易使人联想到Composite设计模式。的确，Composite是可以自聚合的。若干个小的Composite可以通过和Component类似的wire聚合成更大粒度的Composite。

此外，可以看到，Composite比Component多了interface和bingding的概念。

interface描述了服务是用什么样接口格式来描述的，如java interface或wsdl文件。从这里也可以看出，Composite是发布服务的构件单元。

bingding则描述了服务的获取方式。一个Service的实现可以走WebService、可以通过JMS消息或者无状态EJB来提供服务。

以上两类描述让Service的形式更灵活，可以适应大部分既有的系统接口。

通过Composite这样的不断组装、聚合，一个subsystem就可以逐渐成型。

从下图中可以看到一个SOA的subsystem内部与出传统的module的构造有什么不同。

基于SOA的系统是装配(assemble)起来的，而不是搭建(build)起来的。这也是SOA跟传统方法在构建系统上最大的不同。

此外，还可以看到，在构件之间传递有很多SDO对象夹杂在服务之间。他们的作用是负责服务数据的传递。

一个统一、中立的数据载体是异构服务之间有效通讯的必要条件。很难想象互不兼容的数据结构之间如何进行服务的调用。

http://webservices.ctocio.com.cn/tips/182/7495182.shtml

http://gocom.primeton.com/blog1232_101.htm?referer=techtargetwsprimeton