jsp可以令菜鸟直接写简朴的网页程序（网友言），而servlet却有jsp所不及的集成程度和易维护性。两者在JAVA/BS系统中无法简朴取代，但同时并存却令开发者陷入近两年来最常见的陷阱中：必须在一个即使是相对简朴的项目中维持多套程序模式的方案，显然，这是高成本的。本文考虑并初步实验了使用标签组件连续完成类似servlet的处理效果，从而达到鱼和熊掌兼得的目的，看来有一定的效果。

    在完全使用servlet的环境中，可以使用servlet的继续获得上级servlet的设定属性；还可以使用servlet-chains达到分类处理的目的，整个WEB程序与实际应用系统异常相似，高效而简洁；在servlet-jsp的环境中servlet起到集中处理哀求的作用，而jsp负责显示各种形式采摘的数据。后者最麻烦的就是在servlet/jsp中的数径和变量处理方法不一致，平添大量的原始的工作量。strutsr actionmapping一定程度上解决这个问题，不过解决得不算太彻底。因此在大型的java BS应用中采用servlet/jsp形式所带来的方便，一定程度上将会被这种变量的不一致性所抵消，究竟，维持两种处理方案本身就是高成本的。

    因为这个原因，过去本人干脆完全采用servlet形式，而通过另外写程序解释由网页人员编写的嵌套式的html来达到与JSP类似的目的。这套方案在三四年前是有效的，但在今天由于SUN选择了JSP作为发展的主体，包括JTL，TAG技术，甚至于jsdk1。5中的cacheResutlSet都是为了这种（我认为是落后的）JSP随机编码而开发，因此，独自坚持走servlet道路是不明智的,(参看本人《选择JSP作为BS发展方向很可能是致命的战略失误》一文)；但是，同样的疑问并不会因为SUN选择了JSP而消失：假如完全采用JSP，那么在数据提交处理上还是必须使用SERVLET以简化处理逻辑，但同时也必须承受上述的负面作用。

    作为SUN赞助支持的JAVA/BS主体项目方案之一的struts框架充分体现了这一矛盾带来的困惑和折衷：struts- action/actionmapping本身就是为了达到克服上述的JSP不足，希望鱼和熊掌兼得，通过ActionServlet令使用者减少 servelt程序的编写量；不过，在不能完全解决问题的同时，也令开发者为了这不是主体需求的需求，而必须多采用一个框架；一定程度上实际上是得不尝失。

    假如上述逻辑成立，那么犹如几年前本人完全选择servlet相同，既然选择了jsp作为主体方案，那么就应该考虑完全抛弃servelt，以便以一套方案处理项目，避免维护两套系统带来的附加性成本。但是犹如所有人在若干年前指出的相同，JSP缺乏有效的代码治理手段；也不便于形成象servlet那样的基本框架体系，这样它与简朴的网页程序如ASP/PHP没有什么不相同。引入javabean(组件，不是简朴的数据对象化载体），可以一定程度上改善这种处境，但javabean缺乏统一的调用规范，却令这样的JSP比纯粹的servelt开发显得更为麻烦。

    我在使用tag时，觉得可以吸取servelt-chains的概念，使用象SimpleTabSupport这样最简朴的标签方法，生成一个个的命令形式的标签，参数可以直接作为标签参数输入，这样在某个jsp中次第引入这种标签命令，就可以达到类似于servlet-chains的效果，而从易于配置使用上看，超过了servelt。为简便起见，我以struts的ActionServlet为蓝本，写成一个ActionTag的基本类，同样使用 ActionErrors/ActionForm作为数据和消息的载体；然后所有的Command标签全部继续这个ActionTag，这样编写一个命令标签的工作量不会比编写一个struts-action bean的工作量更大。另一方面，由于标签直接可以接受参数设定，所以无需任何如Actionmappin这样的预设置，实际上简化了维护。我认为仅此而言，它至少比struts的ActionMapping要简洁有效。

    类似这样的在一个平面上以标签形式执行多个命令的处理方式并不鲜见，大名昭昭的Apache的httpd.conf就是使用这样的方法完成设置的。

    通过这样的方式，可以统一以JSP的方法来处理几乎所有BS的网页哀求，接受在JSP页面上的目录和变量的同样设定，估计可以大幅度降低开发和维护的成本，以及降低相应的技术要求。