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頁面上的目錄和變量的同樣設定，估計可以大幅度降低開發和維護的成本，以及降低相應的技術要求。