为什么选择SICS 5/6

8)其它的服务和工具集:MiniHttp,OpenUser,Toolkits

MiniHttp也是SICS的原生服务之一。从功能上来说，它完全可以取代我们通常所使用的一些WEB容器.但是,它的一个特点(如果你愿意,认为这个 特点是一个缺点也未尝不可)是:紧密集成SICS,并贯彻SICS的编程思想,而这也直接导致了它和标准的SERVLET/JSP规范不兼容。但是我的确 为MiniHttp建立了自己的Servlet、Jsp、Jsp-Tag、Filter等规范，甚至从功能上，它对比标准的SERVLET规范来得更加简 洁方便，尤其是：内置支持文件上传的处理过程，并且留下了充分的扩展空间！

也有一些朋友问我：为什么要抛弃SERVLET规范，而要自己重新搞一套呢？

是的，这个问题我自己也考虑过，要知道，在之前的版本中，SICS带的HTTP服务的确是支持SERVLET规范的。但是，因为几个原因，让我最终决定抛弃SERVLET规范：

1）第一个重要原因是规范中过于冗长的结构关系，甚至有些自相矛盾的体系设计。因为敏感性的原因，我这里不好直接列举这些问题,胆小:) 但是，如果大家有兴趣研究一下一些开源的服务器的源程序（包括一些广受赞誉的），很容易就会发现这些问题。

2）SERVLET规范中所倡导的是这样的一个结构：servlet + ejb，但是，实际上工程实践中ejb的失败已经是不争的事实，于是大家所实际使用的常常是jsp + javabean，然而servlet规范并没有为这样的应用结构做好充分的准备。（我想，这个应该也是spring、hibernate得以生存发展的原因吧！）

3）servlet的规范的地位，导致了它总是处在一个高高在上的角度，很少考虑为程序员多做些实际的工作，而很多工作又的确的必要的，却又是比较复杂或 者繁琐的。于是WEB容器的提供者开始玩花样了，给大家各种各样的新式武器，可是通常大家又不敢用，结果导致规范中的不规范比比皆是！

类似这些原因,我最终选择抛开规范!同时,作为SICS的原生服务之一,MiniHttp获得了系统核心级的大力支持,从而获得了无与伦比的效率和方便性,从这个角度来说,我认为自己的选择是正确的!

还有其它的一些服务或者引擎,包括XMessage(消息队列)、ProxyDts(数据传输)等等，因为实践应用不多或者系统本身存在一些问题，这里先不作介绍了，但是后面的文章中我会一一描述的。

值得一提的是OpenUser，它是一个基于SICS/AOP开发的公用用户管理和权限控制系统。OpenUser采用引擎模式设计，比起基于服务的模式，在使用中多了一些限制，但是却的的确的以一种非常优雅的方式解决了分组会话中最复杂的权限控制问题。

还有一个工具集，名字就叫ToolKits，它着力解决应用系统中一些常见需求，包括：安全日志、系统配置、对象分组、容器事务、数据存储、对象缓存，等等。