今天下载了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="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在系统架构上比较成熟是一个优势，但框架还比较简单，虽然已经满足了目前的开发需求，但仍需要完善整个框架。
本文地址：http://com.8s8s.com/it/it18113.htm