OMToolkit介绍(5)： 总结

[align=center][size=large][b]OMToolkit介绍(5)： 总结[/b][/size][/align]

[align=center][size=medium][b](1) OMToolkit整体结构[/b][/size][/align]
[align=center][img]http://xxing22657-yahoo-com-cn.iteye.com/upload/picture/pic/84731/393fc294-7f40-3036-91f5-b4e5830883a4.png[/img][/align]
　　OMToolkit包含了Web Server（sever包）、Web Framework（web包）和Object-Oriented Database（data包）三个部分。（图例中的箭头表示“使用”关系）
　　OMToolkit与Web应用开发者的接口是Entity，即用户需要实现一组Entities，这些Entities包含了数据以及对数据的操作。
　　server包中的类借助基于NIO的轮询接收请求，如果该Web请求需要进行动态的处理（不是resources请求），则调用web包中的类进行处理。
　　web包将提取所请求的Entity、所需要调用的方法和需要赋值的属性，借助反射调用用户实现的Entity的方法来处理请求。
　　请求处理完毕，将由data包中的类负责将更新过的数据保存到数据文件中。

[align=center][size=medium][b](2) Server包的结构[/b][/size][/align]
[align=center][img]http://dl.iteye.com/upload/picture/pic/84733/bd631bc1-4c4d-3a54-b0d4-5baffa64d4a6.png[/img][/align]
　　server包中表示守护进程的类是Server类，Server类利用NIO中的Selector进行select，获取需要处理的key，及附加的处理类。
　　key上的Channel分为代表服务器端socket的ServerSocketChannel和代表客户端socket的SocketChannel类。
　　ServerSocketChannel上附加了Acceptor，而SocketChannel上附加了Worker。
　　Acceptor的处理过程是将SocketChannel注册到Selector上，创建Worker并附加到SocketChannel对应的key上。

　　Worker的处理过程比较复杂，先用图示说明，如下：
[align=center][img]http://xxing22657-yahoo-com-cn.iteye.com/upload/picture/pic/84735/c351e4e8-6eb5-3bf3-a17f-5b570fc4c71f.png[/img][/align]
　　Worker包含了Reading、Processing、Wrting三个内部类，分表表示读取状态、处理状态和写回状态。
　　Reading和Writing的run方法会在Server轮询中被调用，每次读写一部分数据，各个Worker的run方法是单线程进行的，所以Reading和Writing的run方法的执行也是单线程的。
　　Processing的情形有所不同，会被提交到线程池中，当有空闲的线程时就执行run方法处理请求。Processing的处理过程是多线程的。
　　之所以采用不同的策略，是因为通常而言多线程的切换会有额外的开销，但是Processing的过程往往相对复杂和多样，不一定能够划分为可以轮询的时间片，因此仍采用多线程进行处理。
　　由于这是一个Web Server，所以需要等全部请求读取完毕才能进行处理，然后一起写回；如果是C/S模式或RIA中的Socket Server，则可以考虑一边读取、一边处理、一边写回。

　　Worker在处理过程中将创建Request对象，用于分析输入的报文，Requset的一些方法调用了CookieUtil和SessionUtil中的一些方法，用于解析cookie和session的信息。

[align=center][size=medium][b](3) Web包的结构[/b][/size][/align]
[align=center][img]http://xxing22657-yahoo-com-cn.iteye.com/upload/picture/pic/84737/778657b6-1cf7-30ce-be32-1ff7f7e8bb6b.png[/img][/align]
　　Controller中Request中提取所需要的信息，先调用AccessChecker对访问的合法性进行检查（用户的权限，输入的参数等），如果通过检查，则创建Entity和Tranaction，并将Tranaction附加到Entity中。PageUtil和View类分别负责分页处理和视图渲染，可以理解为在Entity中使用的工具类。
　　Entity内置的doList和toView等方法已经使用了这两个类，用户也可执行使用这两个类来产生所需的输出。另外，用户也可以通过Entity.getTransaction()方法来获取对事务的管理，进行rollback或commit。

[align=center][size=medium][b](4) Data包的结构[/b][/size][/align]
[align=center][img]http://xxing22657-yahoo-com-cn.iteye.com/upload/picture/pic/84739/1e15a3fc-bab5-37b7-8921-7d8b39f4824f.png[/img][/align]
　　data包中的DataUtil可以认为是这个数据包的对外接口，负责数据文件中的Entity信息的增删改查等。FieldUtil提供对数据的操作，而FieldVisitor提供对数据的遍历。
　　Cache是对已经获取过的Entity进行缓存，并定时清理。
　　Meta保存Entity的id，Entity信息在数据文件中的起始位置和长度，Entity的类型名称等重要信息；程序启动时将加载所有的Meta信息。
　　数据文件以文本形式保存，分为两个：data/data和data/meta。

[align=center][size=medium][b](5) 总结[/b][/size][/align]
　　OMToolkit的目标是尽可能简化Web应用的开发（尤其是业务逻辑简单的Web应用），因此把传统开发中（尤其是SSH）需要的Action、Service、DAO等多个层次合并在了一起；同时，自行开发Server和Database，以使用Web Framework的需要，而不是让Web Framework去适应Server和Database。
　　Entity的设计是将数据以及对数据的处理放在了一起，而将对方法的调用开放给Web请求（调用的Entity、方法、属性值都是从Web请求中获取的），但同时也进行严格的权限和更新参数的限制，以保证安全性。
　　后续版本中将依次对Web Framewok、Web Server和Database进行优化，0.1.0版本需要约一年的时间，希望到时的OMToolkit即使不够“好用”，但也至少是“可用”的。
　　谢谢。（附件中是最新的OMSimpleBlog和OMToolkit的源码）