Jive3.0 Webwork和 Jute1.0 Action Mapping 之間的比較

今天下載下傳了Jive 3.0來試用，準備研究一下Jive的新特性，為Jute下一步發展做一些參考。研究過程中的發現将會收集起來與大家一起分享。

标題：Jive3.0 Webwork和 Jute1.0 Action Mapping 之間的比較

作者：Rainmanzhu

時間：2002-11-29

來自：http://www.cjsdn.com

内容：

Jive3.0中，包含了一個webwork的架構，看命名就能了解是用來處理網頁連結以完成一系列相關的任務。因為http協定是無狀态的，是以如果任務是分步執行的就必須定義協定把多個連結串（chain）起來，一般情況下任務處理會有出錯或成功的分支，比如新添話題這樣一個任務，如果文章标題過長，就需要把出錯頁面顯示給使用者；如果成功加入話題，又需要提示使用者發貼成功，在jive中，這個action是定義在actions.xml的：

<action name="PostAction" alias="post">

<view name="attach">

attach!default.jspa

</view>

<view name="cancel">doRedirect.jspa?url={last}</view>

  <view name="error">postform.jsp</view>

  <view name="input">postform.jsp</view>

  <view name="login">loginform.jsp</view>

<view name="preview">viewpreview.jsp</view>

<view name="rejected">postform.jsp</view>

<view name="spellcheck">spell!default.jspa</view>

<view name="success">postform-success.jsp</view>

</action>

可以看到這個動作有很多個分支，并且有些分支是鍊起來的（加粗的地方），如attach。當然actions.xml中也定義了attach動作：

<action name="AttachAction" alias="

attach

">

<view name="input">attachform.jsp</view>

<view name="error">attachform.jsp</view>

<view name="success">postform-success.jsp</view>

<view name="cancel">

post!default.jspa

</view>

<view name="unauth">error.jsp</view>

</action>

cancel動作就使得能傳回到發貼動作。action的name事實上是指向jive定義的一個類的，是以動作的邏輯均在該類中實作。action類的基類都是com.jivesoftware.webwork.action.Action，内有一抽象excute()方法。action的分發統一通過com.jivesoftware.webwork.dispatcher.ServletDispatcher來進行，ServletDispatcher通過url (*.jspa －jsp action？)來尋找相應的action，然後設定ActionContext（動作環境，所有參數都通過該類傳遞給action，傳遞是根據同一線程來進行的，方法非常之好！），最後執行action的excute()方法，方法傳回值為view（如attach,cancel...），而view對應的jsp在actions.xml也定義好了！ServletDispatcher再通過RequestDispatcher轉發給jsp頁面，應用伺服器再執行jsp生成html。

上面稍微分析了一下jive中的webwork是怎麼回事，其實本文最重要的是分析jive為什麼要引入webwork？從jive發展的曆史來看，1.0的jive是用javabean+jsp的模式，兩個jsp之間沒有固定聯系，而且都堆積在一個根目錄下，這樣維護是非常糟糕的，jive當時也支援skin，但可以看到每個skin都是寫了一堆這樣的jsp，幾乎沒有重用性！其實這種模式是2層的，缺乏了控制層，如判斷使用者登入狀态等，每個需要的地方都需要調用api，jsp裡出現了大量的java代碼，是以每次jive更新，都可以看到先前的jsp幾乎面目全非，這對一個快速發展的項目來說，是非常的一個阻礙因素，當時的jive重點在資料層的設計可能是一個原因。2.0以後的Jive我似乎看過，發現設計上沒什麼大改。但jive3.0帶了一個make sense的三層結構，資料層仍然不變，中間層為action，表現層為使用标簽的簡化jsp。我認為這才是真正有意義的設計。順便提一點，webwork定義了一組标簽用于jsp：

如首頁當中的：

<%-- Print info messages if they exist --%>

<ww:if test="infoMessages/hasNext == true">

<%@ include file="info-messages.jsp" %>

<br><br>

</ww:if>

通過标簽的使用，jive界面的可控性變得良好起來。

稍後我會重點分析一下webwork的性能，希望能從中學到一些好方法。

Jute 1.0也是非常成熟的三層結構，中間層采用Servlet Mapping+Action Mapping，将不同功能組通過url字首區分開來，同一功能組根據功能的複雜程度來選擇定義新的Servlet或選擇定義新的Action來分隔代碼。采用繼承和抽象方法來重用代碼，Jute所有的Servlet都從JuteServlet繼承。事實上其他Servlet都是定義Action組！每個Servlet都有perform(Context context, CGI cgi)方法，是預設的action；然後可以定義其他action來完成不同的動作，Jute的CGI類類似Jive的ActionContext，Request，Cookie，Session都通過cgi對象擷取，為了提高性能，CGI類是通過對象Pool建立的；Jive每次都建立新的ActionContext，并儲存在ThreadLocal内！這點是偶以前沒想到的，稍後研究一下。而Jute的Context類事實上是TemplateContext（hash結構），也可以用于儲存控制層狀态，但更多用于向界面層提供資料。

基類JuteServlet裡有excuteAction方法，方法執行結束後傳回界面模闆，這點和jive非常類似！！！但差別也非常大！Jive是用靜态映射action的，而Jute是運作時刻映射的，最終兩者都通過cache來加快尋找action的，但Jive可以定義action chain，及action的各種view，并能儲存上一個action，對于action執行過程中産生的錯誤也能儲存在action中，并且通過修改配置擴充功能。而Jute的Action mapping，能通過cgi類來儲存上一次狀态，類似采用ASP.Net中的ViewState。建立action chain的時候比較麻煩，要注意儲存每個過程的上一個狀态，而這樣url就變得非常長！Jive預設可以嵌套10層。

Jive可以這樣寫：

<a href="<%= path %>/<ww:property value=" target="_blank" rel="external nofollow" previousURL" />">Go Back</a>來擷取上一個url。

我覺得日後可以修改Jute來改進Http狀态的儲存。

Jute的傳回界面沒有象jive一樣采用mapping方法，而是直接寫在相應action方法中，因為界面和action關系緊密，一般不能變換，但在界面模闆裡可以通過include方法來嵌入子模闆。

綜上所述，Jive 3.0體系更加成熟，采用的設計模式更加豐富了，非常值得采用Servlet技術的網絡應用開發者學習。相當于cgi,mod-perl,php,asp,asp+等技術，servlet功能更強大，更靈活，也容易開發出好的framework，目前java世界裡的framework不計其數！而現在仍采用cgi技術開發顯得比較落後，缺乏安全性保證；php隻适合小型網站的快速開發，一但代碼到達一定量，維護和更新就是很大的問題，也不容易進行代碼的性能調節；早期的ASP技術（VBScript）也顯得比較落後，ASP+已經取而代之，但ASP+的缺點是底層代碼不公開造成自己來開發Framework比較困難，市面上缺乏成熟可靠的應用架構，我看過微軟推薦的ASP.Net開源項目，其中應用的設計模式偶覺得遠不如Java。而從Jive的發展我們可以看到采用Java技術帶來的靈活性，在Jive的資料庫層（包括Cache層）成熟後，Jive的開發者又着手優化上層的設計，雖然這一階段代碼修改量很大，但這樣做是非常值得的，将來Jive可以有更快發展的！

Jute在系統架構上比較成熟是一個優勢，但架構還比較簡單，雖然已經滿足了目前的開發需求，但仍需要完善整個架構。