Tomcat的对象化处理和apache的统一式处理 --

tomcat是一个很优秀的轻量级的web引擎和java容器，它本身用java开发，而java是一个面向对象的语言，因此面向对象的语言开发出来的tomcat当然也就继承了面向对象的特征，tomcat还说明，OO真的使得开发变得简单，而且开发出来的产品天生就带着OO的特点，不光开发和维护本身，就连产品也OO了。反过来看apache，标准c语言开发，纯粹过程式的处理，十分符合http的处理流程，单个http请求本身的处理就是串行的过程化的，其实那个年代的东西都是这样，比如c语言，比如unix，当然还包括Tcp/ip协议族，虽然c开发的apache很稳定，性能也不错，但是它的最大的用武之地在于它对静态页面的推送，这也是http协议最基本的初衷，随着web应用日趋复杂，静态页面已经不能解决所有的问题，于是大量的动态页面出来了，像asp，php，jsp等，此时，apache本身解析并推送处理这些动态页面就有些力不从心了，毕竟这不是它的强项，即使设计了相应的模块，那么由于apache设计上的因素，对于动态页面它还是不适合的，不过由于apache性能以及稳定性的优势，它很适合做web服务器的前端，将请求定向给后端复杂的应用服务器或者动态页面容器，然后从后端接收处理后的静态元素，最终推送给客户端web浏览器。从过滤器这个web服务器的一个模块最能看出该web服务器的架构。 
     apache以往的过滤器都是连成一条链，分为输入过滤链和输出过滤链，前者可以将请求过滤而后者可以将推送给客户的内容过滤。所有的请求无一遗漏的要通过事先安好的所有的过滤钩子，这种方式虽然工作得很不错，但是由于页面都是静态的，所以缺点当然无法暴露，试想动态页面的处理结果，有些钩子只在特定的动态解析结果下起作用，对于大多数不起作用，如果将这个过滤钩子安装的话，很多处理都要在它里面白跑一趟，这很损失性能，或者说这很丑陋。apache新版本的做法是，实现了一个过滤器的动态安装，对于输出过滤器，在内容处理器处理完以后，也就是动态元素已经解析完毕，这个时候就可以根据解析的结果裁定要不要安装输出过滤器了，如果要的话，那么此时才安装，如果不要，就不安装了，而且，新的apache还可以为一个过滤器注册多个策略，在内容处理器的任务完毕之后根据结果裁决最终哪个策略作为过滤器被使用，如此一来就可以在某种意义上实现“每请求”的钩子过滤了，而不是以前的对所有的请求安装相同的过滤钩子，然后在钩子函数内部裁定对这个请求是否起作用。这可以说是apache从静态向动态发展的一项创举，但是apache天生的设计问题决定了它也只能走到这里，下面的主角该是tomcat了，它就是由于要解析动态jsp要求而生的。 
既然如此，tomcat的优势就不言自明了，它具有OO的特性，里面的模块设计得特别人性化，特别的OO，它虽然比不上apache的强大与灵活，但是它的设计我感觉比apache的要好得多，毕竟儿子终归要超越父亲的。在tomcat中实现了“每网站”配置，就是每个网站在遵循tomcat总体的大的配置之后还可以拥有自己个性的配置，总体的配置在tomcat安装目录\conf目录下，而每网站的配置在网站\WEB_INF目录下的web.xml文件，之所以如此就是因为tomcat是以动态jsp页面解析为主的，既然是动态的，那么当然需要很多的配置策略才可以进行，最起码你要告诉解析引擎在哪里可以找到一些servlet类，而每个网站使用的类很大程度上是不同的，因此每网站配置就成了必须，如此的解决方案就是，将所有网站的共性配置放到tomcat安装目录\conf\web.xml中，将个性配置放到每网站的配置中。对于过滤，tomcat也使用了不同于apache的方式，在tomcat中，解析引擎根据每网站的配置文件为每一个网站的每一个过滤器生成了一个唯一的实例，之后针对这个网站的所有的请求都使用这一个实例，如果你想设计一个过滤器针对于所有的网站，那么很好办，只需要将过滤器的代码放到所有网站共享的shared\classes目录下即可，然后再在公共的配置文件里配置过滤器，这样的好处在于可以方便的进行不同请求间的通信和同一请求的不同过滤器之间的通信，执行引擎只需要简单得将这些通信转化为类的对象之间的通信，而类的对象之间的通信在java的OO规范中有明确的定义。tomcat之所以可以如此灵活，全在于它的OO特性，在传统的apache中，一切都是以函数调用为基础的，因此很难在执行过程的层面上形象地表达真实世界，而tomcat的执行是以对象为基础的，对象的设计如果设计的好的话必然是现实世界的写照，因此执行过程才显得如此简单而易懂。 
因此可以说，apache并没有过时，它是针对http协议的，而tomcat是针对应用的，它和http协议没有冲突，如果你用tomcat作web服务器亲自处理http，那么我感觉不如用apache，如果你将tomcat作为一个serlet容器，这才是它的职责，apache和tomcat的分工是不同，apache使http协议实现的一个例子，而tomcat某种意义上是http上面的东西，为了使http更灵活，使http承载的内容更丰富，http为繁多的应用铺就了一条道路而已。简单的说，apache就是接受http请求，热后解析，最后将结果推送给客户端浏览器，这里的解析就是一个机制，具体怎么解析，http不管，而apache很多时候也是交给了可加载模块，让模块找到合适的解析者，比如tomcat，比如websphere，比如weblogic等等，这些已经不是apache本身的事情了，如果它们能如此分工的话，运行于它们之上的web网站一定很强大。