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产品将取得更辉煌的成功。