由于WebWork对request，parameter，Session和Application都进行了封装，将这些隐含的对象封装成了相应的Map，如RequestMap，ParameterMap，SessionMap和ApplicationMap，而这些Map就组成了ActionContext，因此我们通常都不再需要与request，session这些底层的对象打交道了，这也是我一开始觉得迷惑的地方，因为我找不到Session了。事实上，对于SessionMap的处理即是对Session的处理了。我们可以通过ActionContext的静态方法getContext返回一个ActionContext的实例，然后再调用其getSession方法获得SessionMap，接着就可以利用put和get方法对session进行读写的操作了。
        而在页面上，我们可以通过以下的方式对session进行操作：

<webwork:property value="#session.name" />

        #session.name表示从SessionMap中取得与"name"这个key对应的对象，实际上是调用了如下的statement：ActionContext.getContext().getSession().get("name")，并且进行了类型的转换。又如：     

<webwork:property value="#session.player.name" />

        则是在SessionMap中获得了Player对象之后，并调用类Player的getter方法：getName()获得name属性。
        简而言之，为了能够降低与部署环境的耦合程度，WebWork将Servlet的隐含对象进行了封装，这在很大程度上简化了开发的工作。而且WebWork也提供了类ServletActionContext，我们通过这个类中的getRequest方法获得原始的HttpServletRequest，然后就可以对request和session这些底层对象进行操作了。但是，一般情况下，利用ActionContext.getSession()可以完成几乎所有的工作了，我们又为什么要去碰那些底层的东西呢？因此我们应该优先考虑使用SessionMap，而不是底层的session。
        另外一个需要注意的问题，就是SessionMap和隐藏对象session的作用域是不同的。也就是说，通过 ActionContext.getContext().getSession().put("name","Fantasy Soft")，往SessionMap中写入了与"name"这个key相对应的内容，但是在页面上通过session.getAttribute("name")得到的将会是null。