service框架指南..doc

Service框架指南 1.前言 目前阿里巴巴的Java框架，全部是基于Service框架的。本文主要从使用者的角度来介绍我们的Service框架。 不过在开始介绍之前，我想先介绍一下Service框架的历史。 1.1.历史简介 Service框架是用来创建可重用“组件”的通用框架。用现在的眼光来看，似乎这是很平常的一种设计。现在流行的每一种Web框架，在底层几乎都会有一个通用组件框架来支持它。例如， ???????? Tapestry是建立在HiveMind通用框架之上的； ???????? Webwork是建立在Xwork通用框架之上的； ???????? Spring MVC是建立在Spring通用框架基础之上的。 HiveMind、Xwork、Spring都是功能类似于我们的Service框架的通用组件框架。除了这些常见的以外，还有很多。但有一些项目由于用的人少，或者是不够好，就慢慢淡出我们的视线了，例如Avalon。这很正常 —— 技术总是在进步的。 我们的Service框架的设计，来源于几年前流行的Jakarta Turbine框架（/turbine/）。和Turbine同时流行的，还有Struts框架（/struts/）。虽然Struts的知名度比较高，但是从设计的角度而言，Turbine在当时是非常领先的。虽然Turbine项目最后没有成功，但它的思想却被现在的许多框架借用了。Turbine有很多重要的创举，例如： ???????? Turbine开创了在Web应用中的Convention over Configuration的先河。在Turbine中，被称为driven。相对于当时Struts的Configuration-driven，方便了许多。 ???????? Turbine的screen/navigation/layout的页面布局模型，今天用起来还是够方便。 ???????? Turbine的很多子项目都获得了局部或全部的成功，例如：Maven、Torque。 ???????? Turbine鼓励使用轻量级的模板，例如Velocity代替JSP，打破了JSP一统天下的局面。而且Turbine建立了良好的Template框架，允许插入任意类型的模板引擎。 ???????? Turbine的Pull Model，非常像现在常说的“注入”机制，只不过是注入到页面。 ???????? Turbine 3.0（一直没有完成）第一次引入了开创性的pipeline机制。 ???????? Turbine上述所有的功能，全部建立于一套Service框架基础之上。Turbine创建了很多很有用的Service。 正由于Turbine建立在Service的基础之上，才使得Turbine框架具有极大的弹性。Turbine正如它的名字所示（涡轮），它可以把很多系统整合到它里面来。相对而言，在当时，想在Struts中加点什么新功能就没这么容易。也许是Turbine的雄心太大，什么都想做，什么都想整合进来，导致它看起来异常庞大。就像现在的Spring，整合了很多内容。人们普遍认为Turbine是一个很Heavy的系统，因而害怕去接近它。此外，Turbine框架中也包含了很多不好的设计（如过度使用Singleton，分层不够清晰，框架的侵入性太大等），影响了它的扩展性和易用性，最终导致整个项目的失败。 但不管怎么说，Turbine的Service框架是整个Turbine的精髓。阿里巴巴最初直接使用Turbine和它的Service框架。后来有感于Turbine中很多的设计缺陷，却等不及Turbine极为缓慢的发展速度，因而取其所长、克其所短地自建了一套框架。这就是我们将要介绍的Service框架。我们在这套Service框架之上建立了Webx框架及业务层框架。 随后，Turbine也将它的Service框架分离了出来，改名叫Fulcrum。再后来，Turbine将其合并到Avalon框架中。Avalon框架是最早使用“依赖注入”的框架之一。很可惜，先行者成了后来人的垫脚石，Avalon被历史无情地淘汰了 —— 真的很可惜。 1.2.怎样看待Service框架 任何技术都是一步一步前进的。先进的东西很快会变成落后的。Service框架也不例外。 从设计理念上，Service框架继承了Turbine Service框架所声称的IoC（Inversion of Control）的观念。然而，从今天的眼光来看Service框架不算是IoC的，因为现在的IoC往往意味着DI（Dependency Injection，参见Martin Fowler著名文章）。但Service框架很好地符合了DIP的原则，即Dependency Invers