http,soap或者最底层的socket之类IO请求的处理过程的复杂性, 其实都表现在对其In信息的加工和Out信息的组装过程上,
我们完全可以抽象出如下的结构:
  装入(In), 组装(Out), 将这些In/Out通过一定的方式组合起来,就构成了一个完整的IO请求处理过程,
问题的关键就是组合方式.
组合方式的问题本质上就是执行流程的问题, 而执行流程在IO的处理过程中,实质上是由每个动作能够执行的数据基础决定的,
这就是数据依赖, 因此处理过程可以描述为在一定条件下的处理,类似于规则处理,
现在常用的处理方式是建立一个处理堆栈,然后在各个处理中自行判断是否需要处理,
这种方式无法精炼处理的核心,也使得整个处理过程无法调整,更要命的是无法进行模块化的开发与测试,
只有将触发条件从处理的核心逻辑中独立出来,将调用与否的判断交给handler来执行,则各个处理相互可以完全独立,
并可以做到处理多线程并发.
这就是将调用的条件外置, Callee Condition Outside, 以实现处理过程的完全可配置化与模块化, 且不依赖于任何特定的结构,
POJO就可以完成,如此则处理逻辑可以在任何地方复用,附带的是处理逻辑可以以最轻量的方式完成单元测试,
将单个逻辑从整个系统中解脱出来,也将整个系统从处理逻辑的细节中解脱出来.

例子如下:
@On({
 "in.url:/user",
 "out.type:stream"
 })
@Before(Test3.class)
@After(Test1.class)
public class Test {
 @In String name;
 @In(name="links") String[] linkarray;
 @In(from="com.test.Administrator", name="current") User otheruser;
 
 @In int maxlen = 1000;
 
 @In(name="myfile.File") File uploadfile;
 @In(name="myfile.name") String filename;
 @In(from="client") InStream myfile;
 
 @Out(to="session") User user;
 @Out @Need Freemarker response;
 @Need(name="user") Holder<User> holder;
 
 /**
  * 缺省执行此方法,在其他带有@On的方法都不能满足的情况下
  * 或在如下例中定义的条件满足的情况下执行
  */
 @On("default")
 public void execute(){
  response.execute("/WEB-INF/page/default.ftl");
 }
 
 @On("!in.name.match(/mirror/g)")
 public void test(){
  
 }
}