、 struts2框架是基于MVC模式的，是由webwork和struts1合并的一个全新的框架。struts2的核心是webwork，采用拦截器的机制处理用户请求，这样的设计也使得业务逻辑控制器能够与servlet API完全脱离。
（1）客户端发送一个请求，当web容器接受轻请求（httpServletRequest）它将请求传递给一个标准的过滤链包括（ActionContextCleanUp，Other filters ）过滤器。
（2）接下来需要调用FliterDispatcher核心控制器，然后由它调用ActionMapper确认请求哪个Action，ActionMapper返回一个收集Action详细信息的ActionMaping对象。
（3）FilterDispatcher将控制权委派给ActionProxy,ActionProxy调用配置管理器（ConfigurationManager）从配置中文件中读取配置信息（struts.xml）,然后创建ActionInvocation对象，ActionInvocation在调用Action之前会以此调用配置拦截器，一旦执行结果返回结果字符串ActionInvocation负责查找结果字符串对应的（Result），然后执行这个Result会调用的模版（JSP）来呈现页面
（4）然后拦截其会在被执行最后相应（HttpServletResponse）被返回在web.xml中配置的那些过滤器和核心控制器（FilterDispatcher）
技术改进：
（1）在Action的实现方面：struts1要求必须统一扩张Action类，而struts2中可以是一个普通的POJO（javaBean）
(2)线程模型方面：struts1的Action是单实例的，一个Action的实例处理所有的Action请求，struts2的Action是一个请求对应一个实例（每次请求时都新new出一个对象），没有线程安全方面的考虑
（3）servlet依赖方面：struts1的Action依赖于ServletAPI，比如Action的execute方法的参数包括requet和response对象，这使程序难于测试。struts2的Action不再依赖于ServletAPI，有利于测试，并且实现TDD（测试驱动）
（4）封装参数：struts1中强制使用ActionForm对象封装请求的参数，struts2可以选择使用POJO类来封装请求的参数，或者直接使用Action的属性
（5）表达式语言方面:struts1中整合了EL，但是EL对集合和索引的支持不强，struts2整合了OGNL
（6）绑定值到视图技术：struts1使用标准的JSP，sturts2使用“ValueStack"技术
（7）struts1中的ActionForm基于使用String类型的属性。struts2中使用OGNL进行类型转换，可以更方便的使用
struts1中支持覆盖validate方法或者使用validator框架。struts2支持重写validate方法或者使用xwork的校验框架
（8）Action执行控制的对比：struts1支持每一个模块对应一个请求，但是模块中的所有Action必须共享相同的生命周期，struts2支持通过拦截器堆栈为每一个Action创建不同的生命周期