从整体上来说，webx框架是一个可定制可扩展的javaEE框架。为什么说它是可定制可扩展的，其根本原因在于webx框架的层次性和继承性的，webx分为3大层次，SpringExt，Webx Framework和Webx Turbine。从SpringExt到Webx Framework再到Webx Turbine，一层一层的扩展，在原来的层次基础上添加功能。从上层到下层整体来说和继承机制像类似，Webx Framework继承了SpringExt，而Webx Turbine又继承了Webx Framework。在继承的过程中通过使用OCP原则使得子层次的结构完全兼容父层次的结构，只是在原来的结构上添加了一些额外的功能。正是这种层次化，继承化的框架结构使得webx框架可定制和可扩展。
因为其可定制可扩展的特点，在使用框架的时候可以只使用SpringExt框架，或者使用Webx Framework框架，或者使用全部的WebxTurbine框架。或者，可以在Webx Framework结构上不使用Webx Turbine的那一套网页渲染方式，而是用另外的一套网页渲染方式。灵活性很强。
因为所有层析结构的原始结构都是Spring，所以不管哪个层次的结构，其框架的启动方式和服务方式是统一的。在应用启动的时候，会加载一个Spring容器到内存中，并且默认的在容器中添加一些用于服务的Service Bean，这些Service Bean会通常在整个生命周期中存在并提供各项服务。对于不同的层次，其Service会有各种不同的扩展，比如在SpringExt层次中有用于加载资源的ResourceLoaderService，在Webx Framwork层次中扩展了用于控制整个应用流程的Pipeline Service，在Webx Turbine层次中又扩展了用于加载模块的ModuleLoaderService。这些service都会有与其对应的Service Bean在Spring容器加载的时候被添加到Spring容器中，有时候这些Service Bean也会被注入到应用中具体的Bean中去，为其提供服务。
我们现在的项目中通常都是使用整个Webx 框架来进行项目开发，所以对于之前提到的三层结构，我们用的是最外层，即Webx Turbine结构。对于每一层的service都可以进行使用，这样形成一个比较庞大的框架体系。用到的service如下：
- Form Service —— 提供基于HTML form的表单验证功能。
- Template Service —— 提供基于文本的模板渲染的功能。
- JSP Service —— 基于JSP的模板引擎，和Template Service配合，渲染JSP格式的模板文件。
- Velocity Service —— 基于Velocity的模板引擎，和Template Service配合，渲染Velocity格式的模板文件。
- Pipeline Service —— 读取配置，创建pipeline。Pipeline是一种可配置的程序流程控制技术，被webx用来控制HTTP请求的流程。
- Mail Service —— 通过配置和编程的方法，方便地创建、发送、接收符合RFC标准的e-mail。
- Pull Service —— 实现Pull-MVC的设计模式。
- RunData Service —— 将HTTP请求中的诸多对象包装成一个更易于使用的接口，并且对HTTP response实现了buffer机制，是页面cache技术和页面layout技术的基础。
- Upload Service —— 处理multipart/form-data类型的HTTP request。
- URIBroker Service —— 动态生成任意类型的URL和URI。
这些service各司其职，为我们提供有效的服务。我们在应用中要使用这些service的时候需要在webx.xml中对其进行配置，这样在Spring容器加载的时候才能加载这些service，后面才可以对该service进行使用。下面对几个比较重要的service进行描述。
资源表现形式的多样性，给应用程序的接口设计带来一点麻烦，为了统一资源的获取，Spring框架中提供这方面的服务，即Resource Loader，但是Resource Loader还存在一些不合理的地方，于是webx中提供了Resource Loading Service对资源进行统一管理，在Resource Loading Service中可以包含多个不同的Resource Loader进行资源的加载，使得加载资源具有多样性，同时也很好的完成了资源加载的大部分功能。
并且在ResourceLoading的服务中添加了XML Shema及其解释器，使得对于资源的装配的配置文件写起来更加清晰易读，而且修改和维护性增强。
RequestContexts Service是对servlet中的Filter的扩展，作用是对请求进行预处理。该服务负责访问和修改request和response，但是不负责改变应用执行的流程，改变应用执行的流程则是另一个对Filter扩展的Service: Pipeline Service来完成。
Request ContextsService的核心是Request Contexts，Request Context是对HttpServletRequest和HttpServletResponse这两个对象的封装，将有多个Request Context嵌套，就好像一个filter chain一样，从内到外一步一步执行，直到最后形成一个较大的Request Context用来处理，在处理结束以后，再从外到内一步一步执行，将Response返回。
Pipeline service通过Value的控制，提供应用执行的流程，但不关心request和response。Request和Response的处理交给 Request Contexts Service来做。
Pipeline service控制着整个应用的运行流程，Pipeline和Action一起在MVC结构中起到了一个Controller的作用，对整个应用的走向进行控制。
Form Service是对表单的验证的服务，这是webx中一个极其重要的服务，将验证逻辑和表现逻辑分离。
在form.xml中详细的定义了表单验证的要求，并定义了相应验证模块Group。
将form.xml中定义的group在页面模板中创建出其实例。
在用户填写完表单进行提交操作的时候需要在Action中注入FromService的实例，并通过fromService对表单进行验证。
以上是一个简单的form service的使用场景，对于form service还有一些更加深层次的应用。比如国际化之类的使用。form service很好的解决了表单验证的代码冗杂问题，在表单的验证方面是一个很好的服务。
URIBroker Service的作用是对于应用中的URI进行统一的管理，比如由AnalyzeURLValve来分析请求URL，还可以动态的生成URI，而拥有以下的好处：
• 集中管理 —— 全网站的URL均可在同一个配置文件中管理
• 可靠 —— 动态生成，不容易出错
• 规范 —— 例如在生成query string时，会自动URL encoding
• 透明 —— 应用程序、模板不需要知道最终生成的URL的样子，修改URL就变得很简单
URI的用法如下：
- 取得URIBrokerService：
URIBrokerServiceuriBrokerService = (URIBrokerService)
getWebxComponent()
getService(URIBrokerService.SERVICE_NAME);
- 取得指定名称的URIBroker：
URIBrokeruriBroker = uriBrokerService.getURIBroker(
"petstoreLoginLink", rundata);
- 渲染URL：
Stringurl = uriBroker.render();
对于前台的显示，使用了Velocity渲染技术，将页面静态设计和页面的动态数据呈现分离，通过模板技术和pull技术使得界面可以先于程序优先设计，并且将这两个方面脱离使得维护的成本降低。
模板方面如下：由layout，control和screen组成。而相应的Java代码中由screen，control和action组成。
对于页面的渲染过程如下：
从上面这个数据流来看，用户首先通过对于view的操作将http request发送到服务器，在服务器端首先要进行一系列的处理，比如Request Context Service对http request的处理，Pipeline service对流程的处理等等，以上这些处理都可以放在WebxController层里。
经过webxController的这些处理以后调用两个方面，一个是screen进行渲染，另一个是调用action进行请求的处理。如果是screen进行渲染，则使用Template Service将页面渲染呈现出来。如果是调用action进行请求处理，则需要在action中继续调用AO来进行后台的处理，在调用AO的时候使用Command模式。AO继续调用Biz层，将处理交给业务逻辑，业务逻辑在调用数据持久化层，即DAO进行数据访问。
整个流程如上图所示，从最前面到最后面，再依次返回。Webx最具特点的是其WebxController层，其中包含了上面所讲的众多service，通过这些service对应用进行整体的控制，而到后面的业务逻辑层以后，就和大多数J2EE框架类似了。
说一下对于整个webx框架学习后的感受吧。
首先，webx框架是一个比较重量级的企业级JavaEE应用框架。说其重量级，是指使用webx的整体功能。当然如果像一开始说的那样，仅使用其SpringEx层次的部分，则没有这么庞大。当然在淘宝和阿里巴巴里，大多数web项目使用的是就是整个webx的框架。对于这样一个重量级的框架，有人说它臃肿，对，确实是臃肿，但这却是必须的。
我觉得，一个企业级的应用和一个简单应用相比，最大的差别是对于代码的维护方式是不同的。企业级应用中，对于一个项目往往需要好多人来共同维护，或者说在项目重构的时候的开发人员和上一版本的开发人员很有可能没有交集。这样，如何去读懂前人的代码，如何去修改其他人的代码则成了一个比较严重的问题。
而从另一方面来看，一个重量级框架和轻量级框架相比，最大的差别是在于功能实现以及层次划分和模块独立方面是不同的。一个重量级框架拥有着各种服务代码(即service)，很多东西都不需要进行编写，直接在配置文件中加载服务即可实现功能。另一方面来说，一个重量级框架是层次清晰的，各个层次的耦合度比较低，模块和模块之间相对比较独立。
这样，对于一个企业级的应用来说，是需要一个重量级框架的。虽然对于重量级框架的学习成本比较高，但是一旦新人深入学习了框架的内容，则可以在很多情况下方便的使用框架来组织自己的应用。通过对已有的Service的调用，使得所有开发人员在该Service的功能的实现方面不需要自己进行代码编写，从而保持代码的标准化和统一性。这样，一是提高了开发人员在阅读已有代码时的效率。二是提高了开发人员编写代码，组织应用的效率。三则是通过减少新开发代码的代码量，降低了Debug发生的概率，使得稳定性上升。
总的来说，一个重量级的框架虽然看上去臃肿，却很合适这种开发人员众多的企业级应用。
WebX相比于很多其他的JavaEE框架，比较明显的特点在于其的定制和扩展特性。WebX的核心是Spring容器，其他几乎所有的功能都是通过Service的方式来完成的。而每个Service实际上就是在Spring容器中的一个个Service Bean。这些Service是多可少的，全凭在配置文件中配置。这样，每一个应用就可以选取与自身相关的Service进行使用，对于不需要的Service完全可以不予加载。这就使得应用可以根据需要定制自身的Service群。另一方面，随着技术的日益发展，很多旧的功能都需要淘汰，而很多新的功能需要加入。通过WebX的Service机制，可以很好的做到这一点。所有的Service就好象插件一样，对于不需要的旧的Service可以进行去除，而对于新的好的Service可以给予加入。这样就很好的扩展了现有的结构，使得webx框架不断进步。
