在工作流管理系统中，通常是先给业务流程建模，利用流程设计器，将业务的办理过程用流程支持的节点方式表示出来。
业务建模之后，再确定每个节点上办理的业务，办理业务的过程，通常是以填写完业务表单的方式来完成的。所以需要分析每个节点上填写的表单内容，根据 表单内容建立业务表，表字段等。再将字段绑定到表单中录入控件上，将表单录入的数据保存到数据库中，这样业务表单模块就完成了。
业务表单完成之后，再挂接到流程节点上。
另外可能需要再次完善一下流程节点的一些属性，如增加每个节点的指定办理人。
设置取业务表中的一些关键值用于流程中，如取报销单中的报销金额，请假单的请假天数，用于流程上下文中做条件使用。
最后，在业务表中，需要增加一个流程实例id字段，用于和业务流程关联。在启动业务流程的时候，需要将获得的流程实例id写入这个字段中，使得业务记录能和流程实例关联上。
通过上面这些步骤，就建立好了业务流程了，可以启动流程实例，办理业务了。业务的流转就按照流程建模中定义好的顺序办理，不需要再在业务表 中增加状态字段来控制业务的流转了。业务的办理过程变得有迹可循了，每个流程实例均可以列出运行的轨迹图，或者列表出运行的轨迹。每个节点上办理的业务也 能通过查询业务表单再次展现。
上面我们说过，业务表是存储办理业务数据的数据库表，一般来说，一个业务表只用于一种业务流程中，存储同一类型的业务数据。当流程运行结束的时候， 这些业务数据就被封存，不能在流程的节点中再次被编辑和修改。(除非直接开库修改数据，或者另外做一些模块，直接修改业务数据)
但是，这些封存的业务数据，有可能会被再次启用投入到另外一个业务流程中去使用，这种需求可能是需求肯定是有应用场景的，不管是分段的处理过程还是后期又做的一些业务补充等，都有可能发生。
如果一个业务表，需要再次用于另外一个业务流程当中，则我们只需要给业务表，再增加一个流程实例id字段，就可以了，再次新启动的业务流程获得的流 程实例id就写入这个新的流程实例id字段。和以前的那个流程实例id不相关了。只是如果是编辑同一条业务记录的话，就可能把上次的数据给修改了。这样理 论上是可以支持n个业务流程。
总结一下，一个业务表用于一个业务流程中，用一个流程实例id字段和流程关联，用于另外一个业务流程中，则再建一个流程实例id字段和流程实例关联。
一个业务流程可能会涉及到多张业务表，一张业务表也可能涉及到多个业务流程。
现在各种MVC框架很多，各框架的优缺点网络上也有很多的参考文章，但介绍各框架性能方面差别的文章却不多，本人在项目开发中，感觉到采用了struts2框架的项目访问速度，明显不如原来采用了struts1框架的项目快，带着这些疑惑，我对各类MVC框架的做了一个简单的性能分析比较，其结果应该说是基本符合预期的，可供大家参考。
测试环境：
CPU：酷睿2 T5750，
内存：DDR2-667 2G，
Web容器：Tomcat6.0，最大线程数设置为1000，
操作系统：WinXP-sp3
测试步骤：
搭建6个Web工程，如下：
1.纯JSP:不包含任何MVC框架，只有一个测试用的JSP页面。
2.struts1：包含一个Action，不做任何逻辑处理，直接转发到一个JSP页面
3.struts2 JSP：不包含Action，只包含测试JSP页面，直接访问该页面。
4.struts2 单例Action：采用Spring来管理Struts2的Action实例，并配置成单例模式。
5.struts2 多例Action：采用Spring来管理Struts2的Action实例，并配置成单例模式。
6.SpringMVC3：采用Spring来管理Controller实例，包含一个Controller，不做逻辑处理，收到请求后，直接返回到一个JSP页面。
测试结果：
|
测试工程
|
请求数
|
并发数
|
总时间(s)
|
总时间(s)
|
总时间(s)
|
平均值(s)
|
Requests Per Second(每秒处理请求数)
|
|
JSP
|
2000
|
200
|
5.55
|
3.59
|
4.11
|
4.42
|
452.83
|
|
struts1
|
2000
|
200
|
6.77
|
3.83
|
7.00
|
5.86
|
341.03
|
|
struts2 JSP
|
2000
|
200
|
25.20
|
26.30
|
24.11
|
25.20
|
79.35
|
|
struts2 单例Action
|
2000
|
200
|
28.36
|
27.59
|
27.69
|
27.88
|
71.74
|
|
struts2 多例Action
|
2000
|
200
|
31.31
|
31.97
|
39.56
|
34.28
|
58.34
|
|
SpringMVC3
|
2000
|
200
|
7.16
|
7.50
|
4.27
|
6.31
|
317.09
|
说明：
以上测试虽不是非常的精确，但基本能说明一定的问题。每个JSP页面和Action都不包含任何的业务逻辑代码，只是请求转发。每轮测试取三次总时间的平均值。所有工程的测试均全部完成并正常处理请求，没有请求拒绝情况发生。
结论：
-
纯JSP的性能应该最高，这不难理解，JSP被编译成Servlet后，没有任何多余的功能，收到请求后直接处理。（这也验证一句经典的话：越原始效率就越高。）
-
struts1的性能是仅次于纯JSP的，由于struts1采用单例Action模式，且本身的封装相比struts2应该说简单很多，虽然开发效率不如struts2，但已经过多年的实践考验，性能稳定高效。
-
相比来说struts2的性能就比较差了，这不难理解，struts2之所以开发方便，是由于采用值栈、OGNL表达式、拦截器等技术对请求参数的映射和返回结果进行了处理，另外还采用大量的标签库等，这些都无疑增加了处理的时间。因此降低了效率。在我们实际的项目中，我测试本地工程访问每秒处理请求数只能达到35左右，应该说还有不少可优化的空间。
-
很多人认为struts2性能差是因为它的多例Action模式导致的，但我们采用spring管理struts2的Action，并设置按单例方式生成Action实例后，发现其性能有所提高，但并不是很明显。由此可见，多例Action模式并不是struts2性能瓶颈所在。另外，我们在struts2中采用JSP方式访问，发现其性能依旧和没有采用任何MVC框架的纯JSP之间存在好几倍的差距，这又从另一个侧面证实了我们刚才得出结论，struts2性能的瓶颈不在于它的多例Action模式。
-
SpringMVC3的性能略逊于struts1，但基本是同级别的，这让人眼前一亮，springMVC有着不比struts2差的开发效率和解耦度，但性能却是struts2的好几倍，这让我们灰常振奋，SpringMVC无疑又是项目开发的一个好的选择。
Hadoop最近很火，到处都能看到，查了一下资料大概先了解一下其运行原理。
google在05年公开了Map/Reduce论文，MapReduce在处理巨量数据方面有明显优势。
google公司一个技术大牛jefffery Dean提出的这个算法，随后很多小牛纷纷实现了Mapreduce,Hadoop是它的java实现，MapReduce概念直接推动了云计算概念的火爆。
没有优秀算法云是没法搞的。
这篇文章对Map/Reduce原理讲的很清楚。
http://www.chinacloud.cn/download/Tech/MapReduceOverview.pdf
这个是Apache关系Hadoop的文档，安装、开发示例都有。
http://hadoop.apache.org/common/docs/r0.19.2/cn/mapred_tutorial.html
官方WIKI
http://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_%28Single-Node_Cluster%29
最近看Jboss in action，里面提到Jboss的hot deploy功能，今天动手试了一下了一下，发现确实很好用。
首先使用eclipse的Automaticlly publish when resources change 功能 ，设置一个较短的时间，比如一秒，那么在编辑保存之后，eclipse会自动发布更新到jboss部署目录。
在jboss中，可以使用Jmx Console，deploy，undeploy和redeploy。
例如：C:\Jboss\bin\twiddle invoke "jboss.system:service=MainDeployer" redeploy file://C:\Jboss\server\default\deploy\jbosstest.ear 。即完成对jbosstest.ear的重新部署。
在eclipse中可以把jmx命令行客户端twiddle配置为外部工具。
这样，每次修改后，点击
即可重新部署应用程序。
所谓的热部署（热发布）（下面称为“热部署”），就是说，在web工程发布之后，不可避免的，会遇到修改BUG的问题。现在的热部署就是为了解决这个问题，其功能就是说：在不停止web服务的同时，对jsp和java类进行修改，修改后的效果同时还能够在页面上显示出来。节省了调试时间，提高了效率。不过，修改配置文件是个例外，如果对配置文件做修改，一定要重启web服务。
常用的web服务器一般为tomcat和jboss，现一一做介绍。
1.tomcat热部署
在tomcat中支持热部署有两种方式（在原理上来说，这两种方式是一致的，只是放的位置不同）
a)在catalina_base\conf\catalina\localhost\中依照manager.xml定义一个xml文件，比如我的项目称作sodoperation，我们就可以写一个sodoperation.xml，内容如下：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
其中，path指的是你在tomcat中的项目名称，就像manager一样，docBase是指你的项目所在的web目录。一直到欢迎页面为止（也就是web-inf的前一个目录）。但是一般来说，这个目录中最好不要有中文，如果有的话，可以在文件开始加入
<?xml version='1.0" encoding='utf-8' ?>来试一下，即整个文件变为：
<?xml version='1.0" encoding='utf-8' ?>
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
这样就可以了，如果用这种广告，同时使用myeclipse的部署的话，轻易不要remove，这样会使文件都会被删掉，不能持久。所以，建议使用第二种方法。
b)第二种方法和第一种方法在原理上是一致的，其区别就是位置的不同，这次在catalina_base\conf下的server.xml，在文件末加入：
<context path="/sodoperation" docBase="d:\myportal\sodoperation\src\webapp"/>
解释和上面一样，这种方法在启动tomcat后，会在catalina_base\conf\catalina\localhost\中加入一个与第一种方法的文件。这样保证，只要对server.xml不做修改，你可以随便对新生成的文件删除，对热部署没有任何问题
2.jboss热部署
在jboss中做热部署也有两种方法，因为jobss集成了tomcat，也可以说这两种方法是在jobss上的一个修改。
a)修改
/opt/jboss4.3/jboss-as/server/node1/deploy/jboss-web.deployer/context.xml
<Context cookies="true" crossContext="true" antiResourceLocking="true" antiJARLocking="true">
<Manager pathname=""/>
<InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
</Context>
加上
antiResourceLocking="true" antiJARLocking="true",重启jboss,再用myeclipse Redeploy project的时候就不需要重启,部署完了直接开浏览器预览啦