昨天尝试着利用WebWork做了一个小功能[1]之后，对她有一点点的了解，但是她留给我的疑问实在太多了。于是，我决定从今天开始对WebWork来一次全方位的探索(因水平有限，这个探索的过程可能会很长)。
WebWork作为一个Web应用框架，拥有成百上千的类，想要对她有个整体了解，我该从哪里开始呢？还记得在Web.xml中定义的唯一的一个servlet吗？而这个servlet对应着的class就是ServletDispatcher，就从这里开始吧，因为这个类负责所有处理.action请求，正如WAF中的MainServlet[2]一样。于是，我迫不及待的打开了ServletDispatcher的源代码。
凭着自己对WAF的了解，我一开始便认定了ServletDispatcher实现机理与MainServlet是一样的。但是当我真正看到ServletDispatcher的代码的时候，我发现我的估计失误了。MainServlet是通过调用RequestProcessor类的processRequest方法去处理httpServletRequest的，然后在processRequest方法中则是通过反射获得了一个HtmlAction的实例，最后直接调用这个实例中的perform方法去处理httpServletRequest。然而在ServletDispatcher中，代码就简单得多了。
ActionProxy proxy = ActionProxyFactory.getFactory().createActionProxy(namespace
, actionName, extraContext);request.setAttribute("webwork.valueStack"
, proxy.getInvocation().getStack());proxy.execute();
我们可以发现ServletDispatcher调用的是ActionProxy接口定义的execute方法，而不是Action接口定义的execute方法。而在ActionProxy的默认实现类——DefaultActionProxy中，则又调用了ActionInvocation接口定义的invoke方法，直到ActionInvocation的默认实现类——DefaultActionInvocation中，我才找到了Action接口定义的execute方法的身影。
而我原本所猜测的代码应该是这样的：
Action ac =
ActionFactory.getFactory().createAction(actionName,other parameter
);ac.execute();
为什么要经过这样的辗转去调用具体的action类中的execute方法呢？现在的我真的不得而知了。面对WebWork，再加上她的基础——XWork，这样的庞然大物，我现在就象一个盲人在摸象，能告诉你的就是：咦，这不是一堵的墙吗？现在的心情只能借用那英的一句歌词来形容了：借我借我一双慧眼吧！
[1] WebWork初体验；
[2] 关于MainServlet的介绍，可以参考PetStore的文档