SOA携手开源软件 IT行业的未来趋势

目前最为前沿的IT行业趋势，第一是面向服务的体系结构(SOA)，第二就是开源软件。而把SOA与开源软件的优点相结合，不仅可以降低客户的IT成本，同时还能敏捷地应对不断变化的业务需求。

在现有的软件开发项目里面，一直存在一个没有办法解决的问题:业务功能的理解和技术功能的理解是由同一个人负责的，也就是让同一个人或同一些人完成业务与技术领域的衔接。实际环境中想要找到一个这样的人是非常不容易的，而如果没有这个人，软件开发项目基本就离失败不远了，这是IT领域的老问题，也是面向服务的体系结构SOA(Service-Oriented Architecture)要解决的主要问题之一。

SOA限制IT部门考虑采用最佳的组织与能力的组合，从而获得Web服务、SOA以及BPM技术的全部优势。就好象一个汽车公司一样，它不一定有能力发明制造轮胎、发动机、音响等全套的汽车零件。它的音响可能是从A公司批量购买的，它的刹车系统可能是B公司提供的，汽车公司利用了其他零件供应商的服务，来为最终的汽车用户服务。

在SOA架构中也是这样，技术人员必须能够适应从做全部工作到做部分工作，并与他人共同完成整个工作的转变。与对象或者过程相比，服务的开发应面向一个更为宽广的环境，因为它被重用的机会更大。实际上，定义可重用的服务也许是SOA中最重要的方面，也是SOA现在如此流行的重要原因。

OSOA规范三架马车

为了响应客户需求，IBM、BEA、Oracle、SAP、Primeton等公司正在合作制定用于构建SOA系统的规范，为开发人员提供构造基于SOA应用程序的更简单更强大方法。目前，制定规范的工作交由这些公司组成的OSOA(Open Service Oriented Architecture)协作组织负责，另外OSOA还负责在Apache推出开源的SCA/SDO实现，用来更快的催化市场的发展。

OSOA目前正在起草一系列的规范，并以免版税的许可方式提供给业界使用。OSOA的业界伙伴们现在主要在两个项目上协同工作，分别是SCA(Service Component Architecture，服务构件架构)和SDO(Service Data Objects，服务数据对象)，这两个项目就象OSOA的两架马车一样，为SOA架构立下了汗马功劳。根据笔者掌握的最新情报，OSOA正在准备启动第三架马车:DAS(Service Data Objects，服务数据对象)。

1.SCA

早在2005年11月，OSOA就发布了SCA 0.9规范草稿。SCA是一种全新的、跟语言无关的编程模型，这种面向服务构件的编程模型可以大大简化客户的编程，提高应用的灵活性，将会对现有软件开发方式产生颠覆性的影响。

2.SDO

SDO致力于为应用系统中处理数据提供统一的方式，而不论数据的来源、格式是什么样的。SCA和SDO都可以独自使用，没有规定说在同一个应用程序中必须同时使用两种技术。然而SCA和SDO可以结合起来一起使用，从而为采用面向服务的架构搭建应用系统提供一种强有力的、灵活的方式。

3.DAS

DAS是与SDO密切相关的。DAS提供了一种对数据库和对服务来说统一的数据处理方式，它也提供了相应的机制，用来实现当数据同其来源分离时的处理。DAS设计用于简化和统一应用程序处理数据的方式。通过使用DAS，应用程序编程人员可以采用统一的方式访问和操作来自异类数据源的数据，包括关系数据库、XML数据源、Web服务以及企业信息系统。

开源SOA四将军

SOA作为新生事物，它的开源实现并不多。就笔者在行业内的了解，目前共有下面四个开源SOA项目，就如同战场上的将军一样，为SOA阵营攻城略地，开拓了不少疆土。

1.大将军Tuscany

Tuscany是Apache软件基金会的孵化项目，由在Apache软件基金会占有重要份量的IBM和BEA主导。Tuscany原本是意大利行政区名，一般中文翻译为托斯卡纳区，这里被借用作为项目名称。Tuscany的主要目标是为用户提供一组SOA基础设施，其中包括Java和C++实现的SCA/SDO/DAS标准。

2.骠骑将军STP

STP(SOA Tools Platform)项目是Eclipse基金会的重要项目。STP的目标是为技术人员提供一个灵活可扩展的框架，技术人员能够在这个框架的基础之上围绕SOA方便地进行设计、配置、组装、布署、监控和管理等工作。STP提供相关工具来支持开发人员使用面向服务的体系结构进行解决方案构建，而面向服务的体系结构则使用服务组件体系结构作为其核心模型。

3.左车骑将军SOA PHP

PECL(PHP Extension Community Library)库在PHP社区是无人不知无人不晓，不过知道PECL库新纳入的SOA PHP项目的人却并不多见。SOA PHP项目的主要目标是用PHP来实现SOA中的SCA/SDO标准，这对PHP社区的同志们真是个莫大的福音。

4.右车骑将军牛顿(Newton)

Newton是一个分布式的运行时框架，用来对企业级环境下复杂的SOA系统做动态的实例化和可持续管理。Newton利用SCA系统描述，对OSGi的组件做动态的布署，由此实现对分布式的异构数据源的监控和管理。

Tuscany开源架构分析

从以上可以看出，世界上两大开源软件基金会(Apache软件基金会和Eclipse基金会)还有其他的不同社区都已经开始了SOA开源软件的研发进程。下面将主要讨论Tuscany开源项目架构和它在SOA标准化进程中的影响。

1.Tuscany的问题域

问题域是一个软件产品解决方案的首要目标。BEA Systems CTO办公室的Jim Marino告诉我们，Tuscany的问题域用一句话概括，就是解决怎么样来构造和组装服务的问题。

服务是表示一个业务功能的代码单元，它可以被客户端在本地或者远程定位并构造。服务可以布署在不同的运行环境中，比如可以是J2EE Server，也可以是J2SE客户端、可以是Servlet容器，也可以是OSGi容器等。

服务可以用不同的程序语言来编写，然后在异构环境中被组装。这里的服务和Web Service中的服务有很大区别。Web Service中的服务是用低层级的协议来约束系统间的互操作，而Tuscany中的服务是从高层级的业务组合来屏蔽Web Service中的服务所考虑的问题。Tuscany可以使用Web Service中的技术，但并不限制于它，应该说Tuscany对外封装了WS-*和RMI等服务调用细节。

用一句话概括就是Web Service描述了服务间的协议，但并没有描述服务间的关系，而后者正是Tuscany所要做的主要工作之一。

2.Tuscany的Service Network架构

以上面确定的问题域为中心，Tuscany为我们解决了很多现有的技术架构问题。我们用现有的技术架构，在平常的开发中总会碰到如下一些问题:

◆大规模软件系统的开发和配置的复杂性。

◆缺乏动态性，比如对目标功能服务点的动态切换，这一直是软件业的一大核心问题。

◆异构环境下的模块功能不能复制。

◆很难构建一个可平滑地对用户规模伸缩的系统。比如1999年，Ebay网络在用户数急增的情况下，曾经宕机20小时，导致股价下跌9%，损失惨重。

在这样的情况下，Tuscany在SOA基础上设计为Service NetWork架构。SCA用来组装一个服务网络，而SDO表达了服务网络内流动的数据，DAS则对这些流动的数据进行统一格式的存储。

Tuscany的异构Service NetWork架构如图1所示。从图中可以看出，在Service NetWork中，业务逻辑是包含在Component(组件)中。Component对外提供服务，一个Component可以引用其他Component提供的服务，还可以依赖于其他Component提供的服务。Component之间的引用或者依赖关系，可以用一定的Policy(策略)表达，比如事务策略、可靠性策略等。

Tuscany的Service NetWork就好比一桌满汉全席，而Service NetWork中的Component就好比满汉全席中的108道菜。我们要自己去做一个好吃的菜是很难的，而如果有不同的厨师掌握了不同的菜的手艺，我们就可以自己来从108道菜中挑选我们自己爱吃的菜了。在SOA的软件开发环境下，显然“由一个厨师来决定消费者口味”的时代将很快结束。

Tuscany的Service NetWork中的Component是可大可小的，服务可以在本地也可以在远端。对Java而言，服务实现可以在单个JVM中也可以在多JVM中。还有非常重要的一点，Component是自包含的，Component中还可以包括另外的Component，甚至可以包括本Component。实际上，Service NetWor本身也作为一个Component对待。

3.Tuscany的业务调用流程

在上面的架构下，Tuscany的服务可以用各种各样的语言来实现，并分布在各种各样的环境中。它的业务调用流程如下，我们用114拨号进行比对分析:

◆客户向Tuscany服务发起调用。就好象我们拨打“号码百事通”一样，使用的是中国电信的统一服务。

◆Tuscany的绑定功能模块负责把调用分发到不同的传输功能实现。比如“号码百事通”的座席或者后台程序会根据您的选择，把您要问的问题转发到不同的业务后端去。

◆对应的传输功能实现把调用进行传输，传输方式可能是SOAP/HTTP、JMS、RMI或者AMQP等。比如“号码百事通”和“携程网”的通信方式，还有和“蚂蚁搬家”的通信方式可能是不同的。

◆Tuscany绑定功能服务模块收到调用请求，把它转发给对应的目标服务。“携程网”收到请求后，把客户想订什么酒店转发到不同的酒店集团。

◆目标服务执行服务功能。不同的酒店集团确认是否还有空房等。

看起来好象和Web Service等差别不大。不过要注意，这里的第五步不需要判断是否需要返回信息。是否需要返回信息是不同的服务功能已经确定好的，由Tuscany已经实现。

4.Tuscany的内核分析

Tuscany采用微内核加扩展插件的结构。它的工程本身加上全部依赖工程只有4M代码，而它的可扩展插件都是一个独立的SCA Component。实际上，它的内核中的bootstrap就是由一系列的Component组成的。 Tuscany对外提供一个非侵入的编程模型，具有自动化配置功能，并且这些配置都是有缺省值的。就如同富捷软件集团总裁周强说的一样，Tuscany和射雕英雄传中的周伯通一样，已经学会了“左右手互搏”的武功，它的内核和插件就如同自己的左手和右手一样，互相竞争功能，互相弥补缺憾，恰到好处。

Tuscany的内核被控制在30K行代码之内。它提供扩展点来提供功能，而且这些功能都是在运行期动态加入的。Tuscany允许多样化的技术选择，比如它不会限制你用什么Web Service实现。

Tuscany的内核组成如图2所示，从图中可以看出，Tuscany主要由五大部分组成:

◆一个Ioc(Inversion of Control)的单JVM的织入引擎;

◆组件状态管理容器;

◆策略布署框架;

◆数据访问服务;

◆依赖管理和SPI管理容器。

5.Tuscany与其他项目的异同

从上面的内核分析可以看出，Tuscany与我们平常知道的项目是完全不同的。Tuscany是基于SCA而实现的，它通过组装的方法来表达自己的Service NetWork架构概念。它可以用各种各样的语言比如Java、C++、BPEL来构造组件，并能和已经存在的各种编程模型进行集成，它还提供了一个用来表达服务关联关系的策略模型。

Tuscany可以布署在J2EE Server上，也可以使用J2EE中的很多技术，Tuscany中的Components也可以用J2EE中的EJB或者JAX-WS实现。不过，Tuscany提供的功能和J2EE是不相同的。Tuscany可以用多种语言实现，包括C++、BPEL和PHP等。和J2EE相比，Tuscany对业务子系统间的通信做了更好的抽象，在J2EE中，必须确定系统哪里需要一个Web Service或EJB;但Tuscany可以容许你在后面才决定这里是一个Web Service或者是一个POJO。Tuscany中的服务还可以是轻量级的实现。

Tuscany所做的事情和JBI(Java Business Integration)也不相同。对于中间件供应商而言，JBI是在NMR(Normalized Message Router)的基础上，把SPI(Server Provider Interface)标准化了。Tuscany没有NMR的概念，而是使用点对点的织入模型，用来起到“服务交换机”的作用。和SPI一样，Tuscany也有一个扩展模型，但它主要是针对服务开发者和服务组装者而设置。

Tuscany目前已经发展成为了SOA的试金石，在OSOA等开放组织的带领下，它将为我们发现更多的金矿，相信随着OSOA的不断发展，Tuscany这样的开源SOA产品将取得更辉煌的成功。