Java应用框架总览 1. 综述 阿里巴巴的Java应用程序是由一套自己开发的框架来构建的。它的总体模块结构如下图所示： 这是一个标准的3-tiers框架。从横向看，分成三个层次，每一个层次都有一个框架作为基础。 1. 表现层（Presentation Tier） —— 负责和WEB用户交互、或通过Web Service和外界应用交互。这一层是外界和内部商业逻辑交流的纽带。 2. 商业逻辑层（Business Tier） —— 实现了核心的商业逻辑。通过数据访问层存取数据源中数据。 3. 数据访问层（Data Access Tier） —— 和底层数据源交互，存取数据。也可以和公司内部的其它系统之间通信。 从纵向看，可以看到还有一些跨层模块来支持各层次的运作。这些模块也是框架的一部分。应用开发者只需要开发上图中“加阴影”的部分。 2. 跨层模块 2.1. Common Tools 2.1.1. 功能 Common Tools的主要目的是扩展JDK的功能。它提供一组最基本的工具包，主要实现了下列功能： 1. 字符串操作、数组操作、字符串编码和解码、取系统信息、Class和ClassLoader操作等。 2. 扩展Java的collection类库。 3. 枚举类型的实现。 4. Java数据类型转换。 5. 基于XML的ResourceBundle。 2.1.2. 项目组成 Common Tools主要包括下列子项目（将来还要不断扩展和添加）： 1. toolkit/common/lang。 2. toolkit/common/collection。 3. toolkit/common/configuration。 4. toolkit/common/convert。 5. toolkit/common/expression。 6. toolkit/common/regexp。 7. toolkit/common/resourcebundle。 2.2. Common Logging 2.2.1. 功能 Common Logging是对日志系统的一个封装，应用程序通过Common Logging工具包，可以用统一的方式访问多种不同的日志系统，例如：jakarta/log4j或JDK自带的日志系统。 Common Logging扩展了jakarta/commons/logging系统的接口，在此基础上，额外提供了ResourceBundle和MDC、NDC的支持。 2.2.2. 项目组成 Common Logging包括下列内容： 1. toolkit/common/logging。 2. 诸如jakarta/log4j之类的日志系统。 2.3. Service Framework 2.3.1. 功能 Service Framework在系统中处于极为重要的地位。 在JavaEE应用的开发中，常常碰到这样的问题： 1. Singleton的问题 —— 我们希望某个对象或服务是随手可得的，而不需要通过参数传递的方式来取得。例如，我们希望能在任何地方调用mail服务来发送e-mail。 2. Configuration的问题 —— 不止一个地方需要读取配置文件。最好有一种方法可以统一地管理配置文件。 3. Lifecycle的问题 —— 一个功能模块需要在适当的时候被初始化和销毁。 Service Framework正是为了解决上面三个问题而设计的。Service Framework管理着一系统被称作Service的功能模块。Service是一个可重用、可扩展的独立模块。整个系统正是搭建在这一个个相对独立的Service的基础之上。 2.3.2. 项目组成 Service Framework包括下列内容： 1. toolkit/service/framework。 2.4. Resource Loader Service 2.4.1. 功能 Resource Loader Service是一种特别的Service。它在所有的应用程序和系统之间建立了一个抽象层，通过该抽象层，应用程序可以使用统一的路径来访问所有类型的资源。 通过resource loader来装载资源有如下好处： 1. 应用程序不需要知道资源的物理位置 —— 无论资源是在文件系统中，还是在classpath中，或是在别的什么地方，应用程序都不需要关心这些细节。只需要配置Resource Loader Service，就可以找到所有资源。你甚至可以改变资源的物理位置，而不用担心影响任何应用程序代码。 2. 应用程序也不需要知道装载资源的具体方法 —— 无论是从jar文件中读取资源、从classpath中查找资源、或是从文件系统中打开资源文件，对应用程序来说，取得所有资源的方法都是一样的，而Resource Loader Service会以正确的方法装载不同的资源。 3. 很容易扩展新的资源类型 —— 通过扩展Resource Loader，我们可以很方便地增加新的资源类型，例如：JNDI resource等。 4. 配置方便 —— 可以通过配置文件来指定不同资源的位置和装载的方法。这一切对应用程序是透明的。 2.4.2. 项目组成 Resource Loader Service包括下列内容： 1. toolkit/service/resource。 2.5. 其它services 2.5.1. 功能 除了前述的Resource Loader Service，在toolkit系统中，还存在很多其它的services。这些services都是相对独立的，各自完成一定的功能。 1. Form Service —— 提供基于HTML form的表单验证功能。 2. Template Service —— 提供基于文本的模板渲染的功能。 3. JSP Service —— 基于JSP的模板引擎，和Template Service配合，渲染JSP格式的模板文件。 4. Velocity Service —— 基于Velocity的模板引擎，和Template Service配合，渲染Velocity格式的模板文件。 5. Pipeline Service —— 读取配置，创建pipeline。Pipeline是一种可配置的程序流程控制技术，被webx用来控制HTTP请求的流程。 6. Mail Service —— 通过配置和编程的方法，方便地创建、发送、接收符合RFC标准的e-mail。 7. Pull Service —— 实现Pull-MVC的设计模式。 8. RunData Service —— 将HTTP请求中的诸多对象包装成一个更易于使用的接口，并且对HTTP response实现了buffer机制，是页面cache技术和页面layout技术的基础。 9. Upload Service —— 处理multipart/form-data类型的HTTP request。 10. URIBroker Service —— 动态生成任意类型的URL和URI。 2.5.2. 项目组成 Services主要包括下列子项目（将来还要不断扩展和添加）： 1. toolkit/service/form。 2. toolkit/service/template。 3. toolkit/service/jsp。 4. toolkit/service/velocity。 5. toolkit/service/pipeline。 6. toolkit/service/mail。 7. toolkit/service/pull。 8. toolkit/service/rundata。 9. toolkit/service/upload。 10. toolkit/service/uribroker。 3. 表现层 表现层（Presentation Tier）负责和WEB用户交互、或通过Web Service和外界应用交互。在框架系统中，表现层又被划分成三个层次： 1. Webx Framework。 2. Turbine Scheme。 3. Webx Components。 3.1. Webx Framework 3.1.1. Webx Scheme和Pipeline Webx Framework提供了一个非常轻量和通用的WEB应用的平台。Webx Framework并没有定义一个HTTP请求是如何被执行的。相反，我们可以通过“定制（Customize）”Webx Framework来实现特定的功能。类似Windows系统中的主题（scheme），我们只需更换Windows主题，就可以更换整个Windows操作系统的外观 —— 我们也可以更换Webx scheme，来改变整个Webx Framework的处理过程。 Webx Framework的核心是管道（Pipeline）。一个pipeline是由一个或多个阀门（Valve）组成的。通常，pipeline会顺序触发所有的valves，但也可以让pipeline循环或选择地执行valves。当一个HTTP请求到达的时候，Webx Framework取得特定pipeline并开始执行。可见，我们只需要定制pipeline中的valves，就可以实现各种各样的处理过程。 目前流行的WEB框架包括：Webwork、Turbine、Struts、Tapestry等。每种框架都有各自的优缺点。而在Webx Framework的基础上，我们可以比较轻松地定制出任何一种框架的风格。 目前我们已经实现了Turbine风格的处理过程。想必实现其它风格也不会很困难。 3.1.2. Webx组件 JavaEE平台支持多组件的开发模式。 每一个JavaEE应用都可以由多个WEB应用、EJB应用及JCA连接器等独立组件构成。 1. 在开发阶段，这些组件可以单独开发，独立调试。 2. 在布署阶段，这些组件被组装成一个或多个大应用（EAR），然后被发布到服务器上运行。 将一个大的应用划分成多个组件，这种模式有如下好处： 1. 层次清晰。 2. 代码耦合度低，便于扩展和测试。 3. 开发和维护的代价低。 然而JavaEE的WEB应用组件有一个严重的问题，问题来源于JavaEE平台的class loading的模式： 每个WEB应用组件都独占一个classloader，这两个classloader所装载的类是无法共享的。换句话说，同一个类在两个WEB应用中可能有两个副本，各不相干。这将导致下列问题： 1. 导致了大量内存的浪费。特别是当EAR中包含许多个WAR文件的时候。 2. 导致另人费解的ClassCastException异常。这是因为不同classloader所装载的类的实例是不能互换的。而不同的WAR文件却是共享同一个EAR class loader。因此在某些情况下（例如cache），一个WAR下的对象可能会跑到另一个WAR的程序中，从而导致错误。 3. 导致类的初始化问题。如果有一个被两个WAR所共享的类（位于EAR class loader），需要初始化。那么首先执行的WAR会抢先初始化该类，并用当前WAR的参数来初始化它。当第二个WAR被启动时，这个类的初始化状态有可能会发生错误。例如，在同一个EAR中同时运行两个使用Jakarta Turbine框架的WEB应用，就会发生这样的问题。org.apache.turbine.Turbine类会被第一个WEB应用初始化，而第二个WEB应用将失败。 Webx Framework通过引进了一种新的组件：Webx Component（文件名后缀为CAR），很好地解决了这个问题。事实上，CAR文件的内部结构和WAR差不多，只是少了下列文件或目录： 1. WEB-INF/web.xml描述文件。 2. WEB-INF/lib目录。 和WAR组件一样，CAR可以单独开发和调试，但在布署阶段，多个CAR被合并成一个WAR文件： 由于Webx Components（CAR）最终是运行在同一个WAR空间中的，所以还带来另一个价值：一个CAR可以引用另一个CAR中的模块。 3.1.3. 项目组成 Webx Framework包括下列内容： 1. toolkit/webx/framework。 3.2. Turbine Scheme 前文讲到：Webx Framework并未定义如何处理一个HTTP请求。Webx Framework所做的，只不过是激活了一个pipeline。而pipeline的设置决定了系统是怎样处理请求的。 我们的框架使用了Turbine风格的处理方式。用过Turbine的人使用Webx Framework + Turbine Scheme将感觉到熟悉。 注意，我们的框架只沿用了Turbine的风格，但并未直接使用Turbine的代码。 3.2.1. 项目组成 Turbine Scheme包括下列内容： 1. toolkit/webx/turbine。 3.3. Webx Components 在Webx Framework + Turbine Scheme的基础之上，摆放着一系列和具体应用直接相关的Webx Components。以淘宝网为例： 1. Auction - 拍卖组件。 2. Member - 会员管理组件。 3. 更多... 当然，这是因不同的应用而异的。 4. 商业逻辑层 4.1. Business Tier Framework 4.1.1. 功能 Business Tier Framework是一套基于Spring Framework ，以Use Case为中心的一套框架。它糅合了几种经典的JavaEE设计模式，使应用开发者在实现Use Case时，能够更专注于商业逻辑本身。 通过CommandDispatcher，你可以将不同的Command指派给不同的ApplicationObject来处理。通常一个Command就代表一个Use Case的请求。 框架还提供了好几种类型的CommandDispatcher的实现，以满足不同的需要。 简单解释如下： 序号 CommandDispatcher的实现 说明 1. Stateless Session Bean 使用Stateless Session Bean来分发Command。该实现允许进行分布式的商业逻辑调用。 2. Message-driven Bean 通过Message-driven Bean来分发Command，通过JMS来发送Command请求。该实现允许进行异步的商业逻辑调用。 3. Plain Javabean 通过普通的Javabean来分发Command。这个实现非常适合在非EJB的环境下调用商业逻辑。 4. NOOP 不做任何事情的分发器。这个实现非常适合在程序的开发阶段，用来调试程序。或者当商业逻辑还未开发完成时，调用者可以利用该分发器来“调用”商业逻辑，以便调用者的代码可以被顺利地开发。 5. Selector 该分发器可根据Command的内容来自动先择合适的其它CommandDispatcher。这样，我们就可以更方便地控制CommandDispatcher的行为。例如，在调用者完全不知情的情况下，将某个Command的处理转变为利用Message-driven bean来异步处理。 4.1.2. 项目组成 Business Tier Framework包括下列内容： 1. toolkit/biz/command。 4.2. 商业逻辑组件 在Business Tier Framework的基础上，摆放着一系列和具体应用直接相关的Business Components。以淘宝网为例： 1. Auction - 拍卖组件。 2. Member - 会员管理组件。 3. 更多... 当然，这是因具体应用而异的。 5. 数据访问层 5.1. Persistence Framework 5.1.1. 功能 Persistence Framework是基于Spring Framework的： 1. 支持多种O/R Mapping工具，例如iBatis SQL Map和Hibernate。 2. 支持分库。在某些系统中（如Taobao）由于对数据库的性能要求非常高，不得不采用多个数据库服务器来分担访问压力。 3. 支持global和local的事务。 4. 创建和维护数据访问对象DAO。 5.2. Data Access Layer 5.2.1. 功能 Data Access Layer包括下列内容： 1. 数据访问对象DAO的定义及实现。 2. Hibernate或iBatis的配置文件。 3. 定义Data Object对象。 6. 总结 我们的框架至力于提供一整套的JavaEE应用开发方案。整个方案设及到传统的三层架构的每一层，也应用了多种Design Patterns。这使得这套框架成为一个可以提升生产效率，保障生产质量的工具。