SOA规范综述

SOA规范的来龙去脉

前言：SOA的概念早已从多年前的朦胧步入了逐渐清晰和具体化，当SOA开始真正地进入企业应用和实施的时候，这些飘在空中的SOA概念必须要落实到实际的白纸黑字规范和标准上，只有这样，才能实现各个不同SOA系统和实现之间的无缝连接。

随着SOA概念的不断成熟以及各大IT巨头逐渐在SOA的具体细节上不断达成共识，于是成立了一个SOA的标准化组织OSOA（www.osoa.org）专门负责制定各大SOA厂商共同遵循的SOA规范，约定SOA的具体实现的细节。

一) OSOA规范发展历史

SOA规范从2004年依始，随着不断地讨论（通过邮件组和每周的国际电话会议等）和修订，慢慢地从一些想法逐渐成型，现在已经初步确定了一套完整的规范框架。普元作为OSOA组织中的唯一中国公司，有幸参与和见证了整个规范的诞生

以下是OSOA规范演进过程的一个简单的时间表：

可以看到，在2004年末，OSOA规范还仅局限于IBM, BEA等几个IT巨头之间的内部磋商，直到2005年11月，规范才正式启动。

到了2006年7月，OSOA的合作商正式敲定为包括普元在内的18家IT厂商。

就在本月，SCA和SDO规范正式发布release版本（SCA 1.0, SDO 2.1版本）并提交标准化组织。这并不意味着规范的发展就此打住，release的意义在于所有ISV厂商都可以在此标准之上实现各自的SOA服务并确保可以互连互通。实际上，早在规范正式发布之前，参与OSOA规范的各大厂商就已经有了动作，各自SOA容器的开发在紧锣密鼓地进行着，并不断地随着规范的发展而修订，相信大家在规范发布后不久就可以很快看到各种SOA的实现

这些规范都可以在OSOA的官方网站下载到最新的版本（普元网站上有中文版，非最新版）。

另外，可以看到，比起SCA，SDO的规范启动得更早，发展得也更快一些，其中的一个原因恐怕是因为SCA涉及的技术面更广，牵涉的因素更多吧。

二） OSOA规范的构成

OSOA规范的概念主要就是SCA和SDO，其中大大小小的子规范在之下的图中大家可以有一个比较清晰的认识（其中红色虚线部分为暂未发布规范）：

SCA规范包括了Assemble Model和Client Model两部分。前者约定了如何将异种组件（Java类，BPEL, WebService）组装并发布成SOA服务，是SCA最大的特点和最核心的概念；后者则约定了如何在异种语言环境中调用SOA服务。那么，通过这两部分的规范，就可以完全解决了服务从服务端到客户端的跨语言、跨语言的问题。

SCA目前包括了Java，C++，BPEL和Spring的子规范，解释了在具体的语言环境下服务的调用和绑定方式。当然，这只是规范解释了的部分语言，不排除在某些SOA容器实现中可以提供其他语言的支持（例如PHP）。

从Spring这个开源框架出现在规范中可以看到，OSOA的规范的制定也是抱着务实的态度，认真考虑了实际应用中的现状。

SCA的服务运行于QoS容器中。所谓QoS容器指的是SOA容器不仅把SOA发布完就了事了，也要负责服务的质量、调度、调控、检测等涵盖服务整个生命周期的管理。而这些都是目前轻量级容器（如Spring，PicoContainer）所不能提供的。这就是了一套包括Security、Policy、Messaging、Transaction的Policy Framework。

所以为什么说是面向服务呢。如果只是把类的方法发布成WebService了就不闻不问了，还是OOA/OOD的思想，那么SOA的价值就大打折扣了。因为SOA本身是要做减法的，而不是在OO上做加法。

SDO规范则负责解决如何在异种服务间交换数据。它定义了一套中立的数据结构，目前有Java和C++的具体语言规范 ，Java规范解决了Java Bean和SDO的映射，C++规范解决了C++类、结构体和SDO的映射。

DAS规范则定义了SDO对象如何持久化到异构的数据结构，目前刚刚启动。

那么，在整个规范之上，承载的是SOA的思想和方法论，它更强调服务的组装而不是服务的开发。

在方法论上面，就是服务的组装、可视化和管理，即规范的应用层，比如SOA的IDE，这也是SOA容器之外各个ISV厂商可以提供附加价值的地方。

三） SOA应用架构

面向服务不光是规范和概念，也包括了架构上的创新。

实施SOA不意味着要推翻既有的架构，比如MVC，而是要在现有架构上做更大的架构。

传统的MVC对于单个应用来说非常成熟，这是实践中证明的。对于大多数独立的应用和系统来说MVC很胜任。然而，当企业中的应用规模不断扩大，从几个到几十个甚至上百个的时候，靠若干MVC架构的不断叠加能够构造出一个适合企业级的架构么？所以才出现了Portal这样的新技术来迎接这样的挑战，但是Portal的关注点更靠近与展现端，在底端通讯方面不能给出更好的答案。所谓架构是要一套整体解决方案，这样的架构所要解决的问题简而言之就是两个特点：数目或规模大、异构应用交互。

那么我们就来看看SOA概念下的多层结构是怎样的：

基本层：提供了基本的原子操作，例如‘获取用户信息’，‘获得目前利率’。在实际应用中，可能就是一个Java方法，一个存储过程。

中介层：可以理解为技术屏蔽层。它提供了各种协议（J2EE, WebService）的桥接将基本层的操作抽象为统一描述的服务接口。

流程层：提供业务层面的‘服务’。服务跟函数和操作的差别在于服务可以是多个服务的组合。比如，银行的一个开户流程可能包括了信息录入、开卡、关联银行卡一系列的动作和逻辑，但是，对于业务人员看来，这只是一个单个服务而不是3个服务。所以，有必要在这一层将服务和服务的流程屏蔽。

企业层：具体业务上下文中的定制化服务。

四） SOA应用开发方法

一套概念的提出必然要有相应的开发论配套提出，面向服务也不例外。

SOA的分析方法是典型的金字塔结构，是一个从抽象到具体、从业务到代码的分析方法。

最开始是确认业务范围，它解决的问题是做什么、不做什么。它的直接产物是业务上下文定义。

接下来是业务概念的确立。业务概念是用来解释业务范围，是业务范围的具体化，它定义了所涉及业务的流程和数据结构，并为各种业务给出了明确的、无二义性的语义。它的直接产物是业务流程和语义模型。

然后就是把业务分解为各个单独的业务功能，并明确定义了他们的接口和交互规范，可以说是业务概念的量化或数学定义。这一步的直接产物是各种服务的明确接口。

下面一步就是到了研发部门。他们负责进行对服务的实现进行技术选型，即如何更高效、更方便地实现各种服务。在这一步，服务才更具体的语言和技术绑定，比如服务是Java来实现还是C#。

最后就是技术实现，用编码实现具体的计算和操作。这一步才产生了真正的有形的东西。其实可以看到，代码本身之上承载的这么多无形的东西才是软件的价值所在，越往上走对于客户的价值越大。

五）SCA的Assemble模型

在SCA的Assemble模型中，Component是最小的实现单元。

在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对象夹杂在服务之间。他们的作用是负责服务数据的传递。

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

SDO特性概要

基于XML的数据交换是最初的中立数据雏形。而SDO作为一种比XML更有语义、与普通DTO对象结合更紧密、使用更方便的数据载体，提供了更好的数据交互能力。

下面是最基本的SDO接口关系图。
DataObject：最主要的接口，用于各种数据访问；

Type：DataObject的元信息。类似于Class和Object的关系；

Property：Type中属性的元信息。类似于Class和Field的关系；

Sequence：DataObject中数据的序列；

DataGraph：DataObject的信封。是与持久化和其他服务交互的单位；

ChangeSummary：DataObject中数据的变更历史；

DataAccessService（不属于SDO规范，没有对应的API）：为SDO对象提供持久化服务；

那么SDO究竟用来干什么呢，简单说来，它的本质可以归纳为：

• 增强型DTO对象

按照设计模式，各层之间（现在应该说各个服务之间）的数据传递应该用中立的轻量级的纯数据对象作为载体。关于具体的DTO如何设计，则众说纷纭，什么充血模型、贫血模型等等。SDO本身可以看成是一个DTO模式，而且更是融入了许多DTO的Best Practic，如弱类型、格式中立。

• 语言中立的API
  不论是Java也好，C++还是PHP也好，SDO 的API在各个语言子规范上都是一致的。这得益于OO的发展。由于现有数据结构在概念上基本可以统一，如属性、集合、父子关系等都可以在各自的语言中找到对应的概念，使得同一套API基本可以操作各种类型的数据对象。
• 统一、简洁的异构数据访问架构
  SDO的基本接口只有15个，常用方法不到百个，很精简。但包含了数据的ACID、复制、比较。回滚等各种操作。
• 数据层无关
  SDO功能非常明确，本身不关心承载数据的是JavaBean，XML文件还是数据库表格。仅负责对数据的操作，不仅屏蔽了语言层，也屏蔽掉了物理层。

下面罗列一下SDO的一些关键特性：

• 离线数据

SDO跟数据层是松耦合，它不像ResultSet那样必须持久连接才能获取数据。但同时，在需要的时候，SDO可以重新连接到数据层。

• 天然支持XML(Schema)

XML仍是常用的数据格式，在很多地方成为惯用格式，如配置信息、WebService参数等。SDO对象可以很方便进行XML格式的序列化和反序列化。SDO跟XML一样是格式中立的，它包含了XML的优点、同时也解决了XML的不足，可以说是XML的外延。

• XPath导航
  在SDO对象中进行设值、取值操作时，可以直接传递XPath（XPath 1.0 语法子集）在SDO树中进行寻址。这非常有利于程序的自动化
• 丰富的数据操作方式 除了基本的ACID操作，还可以空置一个属性。有效地把null值和空值区分开了。
• 静态/动态数据结构相结合

从下面SDO跟各种数据载体的比较可以看出。SDO几乎集成了各种结构的优点、甚至可以同时实现两套机制来进行操作：

• 静态/动态数据访问方式相结合
  除了使用DataObject接口进行操作外，还可以直接将一个DataObject造型成跟它绑定的Java接口进行操作，如：

DataObject sdo = ...;

int age = ((User)sdo).getAge();

• 反射、元信息
  跟XML不同，SDO对象是可以有元信息和各种反射操作的。这同样也有利于各种自动化工具。
• 变更历史
  SDO对象本身是有状态的，可以记录数据的变更历史，并进行数据的提交或回退。这解决了以往事务只能局限在数据层，而无法包含业务的数据的问题。
• 约束、验证属性本身可以定义约束，SDO对象的数据可以进行验证。实际上，这是作为属性元信息的元信息存在。这样SDO就不仅仅是作为一个DTO，它也保障了数据的有效性。
• 对象间的关系
  对象之间可以定义引用和包含关系。

除此之外，SDO的克隆、序列化、比较等都在规范中一一列明，这里不再赘述。

SCA和SDO的关系

首先两者不是互相依赖的，SDO是SCA的优先但非必要的数据载体。SCA的实现可以支持其他数据形式，如JAXB等。但是SCA搭配SDO是最优组合，因为这样可以彻底排除系统实现的相关性。

并且，SDO设计本身就是为了松散耦合而优化的。例如，它的变更历史采用的是乐观锁的实现。在大多数情况下，这些SDO对象更加适合在异构系统间传递。

DAS子规范

上面也说了，SDO本身是不关心数据的物理层规范的。这一点是由DAS（DataAccessService）子规范来规定的。

它规范了数据的持久化技术，目的是统一数据的持久化操作介面。跟SCA和SDO一样，也是跟语言和技术无关的。

该规范尚未启动，目前仍处于讨论阶段。

******************************************************************************

作者简介：黄凯，上海普元软件公司资深架构师。应用数学系学士，软件工程学硕士，获得系统分析员认证。曾参与EOS构件中间件的Studio和Server的核心架构设计。在Eclipse插件开发、SOA设计实现、Struts/Spring/Webwork/Hibernate等框架技术以及ANTLR, LUCENE等方面有很多经验和深入研究。