That is very funny总在思考一个问题，框架是什么？框架就是一种遵循软件工程里80/20规则的软件实现，如webwork，Struts等展现层框架，它们将所有Web应用都需要做的从http请求中获取form表单数据，然后解析之，并进行处理，最后再进行页面的跳转与展现，这一系列如果使用Servlet技术解决之将是极其复杂无味的操作都进行了封装，而各个Web应用所不同的差别仅仅在于20%的对各个页面处理不同而已，所以通过Action的概念让用户可以定制自己的业务逻辑，并将其plug in框架中，从而让框架这个半成品变成了相应领域的应用。

　　笔者在学习和研究Jbpm此开源项目时，深深体会到Jbpm团队的优秀设计理念，领略Tom baeyons（Jbpm project”s leader）的大师风范，简约而又不落俗。一般都认为，当然包括baeyons也认为，jbpm只是一个process-oriented应用的一个for java的解决方案，更多情况是将之作为一套lib来使用，这样它的地位就变成了called，被调用，集中掌管整个应用关于流程推进的逻辑。但，随着对Jbpm的使用和学习，笔者发现其实jbpm与webwork有许多类似的地方，只是webwork管理http协议的页面流，jbpm则负责工作流；webwork在页面流之间维护相应的数据（如各个页面流间表单数据的传动），而jbpm则关注流程实例的上下文变量；webwork要等待用户的输入，jbpm也通过task来收集用户输入的信息；多个类似的场景常常出现，让我开始反思两种理念的异同点。

　　做webwork开发有段时间的程序员都知道，在Action中应该只是对service层进行相应的调用，而不应该在Action的实现中放入细节的业务逻辑。从这个意义上来说，Webwork是高层的页面流调度，并传递数据流给后续页面。而更自然的思考模式是：我们开发基于工作流系统的软件，一般都是将应用的用例划分为两大类，一类是流程状态逻辑相关的，一类是应用本身业务逻辑相关的。然后在用户的按钮按下后进行两部分状态数据（一是流程状态数据、一是业务数据）的更新。这里只是完成了将流程逻辑从原本混沌的应用代码中分离出来进行集中管理而已，并没有象web应用一样，以Webwork为主体，可以说是半流程状态。我们应该将jbpm作为一个框架来使用，它成为主体，从是以流程全局化的视角来审视应用。

　　原文链接：http://gocom.primeton.com/blog12717_19935.htm