这个架构实际上又是如何工作的呢？初始请求先发送到服务器小程序容器（譬如Tomcat），然后通过一系列过滤器传送。如果与Site Mesh插件等其他技术集成，可选的ActionContextCleanUp过滤器就很有用，要是用到这个过滤器，请求先通过它传送。
接着，调用请求的FilterDispatcher，它使用ActionMapper来确定要不要为这个请求调用动作。如果ActionMapper确定应当调用Action，FilterDispatcher就把控制权委托给ActionProxy。
ActionProxy使用了框架配置文件管理器，该管理器通过struts.xml文件来初始化。然 后，ActionProxy创建ActionInvocation，它负责实现命令模式。ActionInvocation进程调用所需的拦截器，然后调 用Action。一旦该Action执行，ActionInvocation就负责查寻与struts.xml中映射的Action结果代码相关的合理结 果。
然后结果被执行，大多数时候，这会显示用FreeMarker或者Velocity编写的JSP或者模板。按照相 反顺序完成Action之后，拦截器再次得到执行。最后，响应通过web.xml中配置的过滤器返回。如果ActionContextCleanUp过滤 器经过配置，FilterDispatcher就不会清理ThreadLocal ActionContext（ActionContext拥有运行时请求和响应的全部细节，该框架使用ThreadLocal以及 ActionContext类来提供配置及其他运行时细节）。如果ActionContextCleanUp过滤器未经配 置，FilterDispatcher就会清理所有的当前ThreadLocal。图1描述了Struts 2框架的架构。
这一切似乎都有点抽象。为了帮读者有更深入的了解，下面提供一个典型的架构请求流程，图2显示了这个顺序。
1．用户请求对Web应用执行某个动作后，Web浏览器将要求某些资源的请求发送到Web服务器。
2．服务器小程序过滤器调度程序接到请求后，分析请求，然后确定调用相应的动作，提供资源。
3．在Action被执行之前，经配置后把一些常见功能（如验证、工作流或者文件上传）作用到请求上的一组拦截器上，可自动作用到该请求上。
4．Action类的一个新实例被创建，然后执行动作方法，用于把信息存储到数据库，或从数据库获取信息。
5．结果显示输出——无论输出的是HTML、图像、PDF还是其他某种格式。
6．然后，请求按照相反顺序通过拦截器传送。返回的请求允许执行其他的处理或者清理操作。
7．最后，容器把输出发送到浏览器。
