谈谈各大框架/产品的流程应用

1  长子：业务流
   业务流程了解得比较多，这里就不废话了。举几个例子用做广告：) EOS工作流/jBPM/其他的BPEL产品 等，我的博客上写了不少其他的产品(blog.csdn.net/hongbo781202/)。业务流程可能横跨多个用户的多次对话，流程的状态被保存在数据库中，所以流程被认为是长时间运行的。

2   老二：无状态的页面流

   无状态的页面流早已经存在，大家也都非常熟悉。就比如webwork框架等。无状态的页面流定义了一种映射，把事件的的逻辑结果用命名规则直接映射到视图的结果页面。新近的两个无状态的页面流是JSF和Seam框架。
    JSF举例如下：
<navigation-rule>
    <from-view-id>/numberGuess.jsp</from-view-id>
       
    <navigation-case>
        <from-outcome>guess</from-outcome>
        <to-view-id>/numberGuess.jsp</to-view-id>
        <redirect/>
    </navigation-case>

    <navigation-case>
        <from-outcome>win</from-outcome>
        <to-view-id>/win.jsp</to-view-id>
        <redirect/>
    </navigation-case>
       
    <navigation-case>
        <from-outcome>lose</from-outcome>
        <to-view-id>/lose.jsp</to-view-id>
        <redirect/>
    </navigation-case>

</navigation-rule>
     Seam举例如下：
<page view-id="/numberGuess.jsp">
       
    <navigation>
        <rule if-outcome="guess">
            <redirect view-id="/numberGuess.jsp"/>
        </rule>
        <rule if-outcome="win">
            <redirect view-id="/win.jsp"/>
        </rule>
        <rule if-outcome="lose">
            <redirect view-id="/lose.jsp"/>
        </rule>
    </navigation>

</page>（说明：这两个example是从seam的userguide中抄过来的）。

3  老三：有状态的页面流
  用过业务流程和无状态的页面流的同学大都有过心痒痒的感觉，是不是这两个东西可以合起来用啊？因为我以前一直是做业务流程的，所以我在05年就做过一套“自认为创世纪的东东”，其实就是把业务流程用到页面上来。后来终于有一天，知道了这个东西的名字是“页面流”，也知道那个“自认为创世纪的东东”早就在业界有了产品了。  我最早是用BEA workshop试验的页面流，当时挺撼动的，毕竟比自己捣鼓
的那个东东强多了。现在想来也就很一般的功能。
  BEA的jpf毕竟不是标准，(应该不是吧？呵呵)为了推广市场，BEA的Beehive包含了一个jpf框架：Pollinate的NetUI。NetUI Page Flow（页面流）是一个基于Apache Sruts的Web应用程序框架，基于JSR-175元数据，它构建在模型/视图/控制器元素的核心Struts分离的基础之上。
  如果说NetUI Page Flow更偏重于无状态的页面流（使用简单），那么Spring WebFlow更偏重于业务流程（功能强大）。Spring WebFlow以有限自动机(Finite State machine)的概念为基础。Web应用内部的用户交互行为和事务被建模为一般的状态机。
  EOS的页面流更是同时吸收了BEA JPF的优点（eclipse插件方便用户开发）和Spring WebFlow的优点（功能全面），大家可以下载EOS6.0试试用用。
  页面流领域给我最大振撼的还是是jBPM。（注意，我认为seam的页面流功能是jBPM的功劳，不是Seam自己的）。因为我05年做的那套“自认为创世纪的东东”，开始是想过要用这个思路的（我当时就已经用了好久的jBPM了），可惜当时我们团队掌握jBPM的人太少，没有用这个方案。
 下面是一个使用jPDL定义页面流的例子（摘自Seam2.0 userguide)：

<pageflow-definition name="numberGuess">
   
   <start-page name="displayGuess" view-id="/numberGuess.jsp">
      <redirect/>
      <transition name="guess" to="evaluateGuess">
          <action expression="#{numberGuess.guess}" />
      </transition>
   </start-page>
  
   <decision name="evaluateGuess" expression="#{numberGuess.correctGuess}">
      <transition name="true" to="win"/>
      <transition name="false" to="evaluateRemainingGuesses"/>
   </decision>
  
   <decision name="evaluateRemainingGuesses" expression="#{numberGuess.lastGuess}">
      <transition name="true" to="lose"/>
      <transition name="false" to="displayGuess"/>
   </decision>
  
   <page name="win" view-id="/win.jsp">
      <redirect/>
      <end-conversation />
   </page>
  
   <page name="lose" view-id="/lose.jsp">
      <redirect/>
      <end-conversation />
   </page>
  
</pageflow-definition>
    用过jBPM的同学们，看到这个感觉怎么样？亲切吧？一个简单的页面流定义看起来跟业务流程定义非常相似（是同一种类型的东西），不同的是用 <page>节点替换了<task-node> 节点。

4.老四：逻辑流
   逻辑流应该是EOS首创(应该是吧?)，在EOS中他们是.bizx文件，基本上等同一个java 方法，内部可以调用服务/运算逻辑和另外一个逻辑流。

不要把这些个事情弄混了！逻辑流/页面流/业务流 它们运行在非常不同的层面或粒度中。逻辑流来自于一次与单一用户的单一交互； 页面流来自于与单一用户的多次同一上下文的交互；而业务流则横跨许多用户和交互。从另外一个角度看，他们三个是完全正交的，可以在一起使用或是分开单独使用，或者都不用。