谈谈各大框架/产品的流程应用 框架应用服务器SeamJBPMJSP
程序员文章站
2022-07-16 20:29:35
...
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 方法，内部可以调用服务/运算逻辑和另外一个逻辑流。
不要把这些个事情弄混了！逻辑流/页面流/业务流 它们运行在非常不同的层面或粒度中。逻辑流来自于一次与单一用户的单一交互； 页面流来自于与单一用户的多次同一上下文的交互；而业务流则横跨许多用户和交互。从另外一个角度看，他们三个是完全正交的，可以在一起使用或是分开单独使用，或者都不用。
业务流程了解得比较多，这里就不废话了。举几个例子用做广告：) 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 方法，内部可以调用服务/运算逻辑和另外一个逻辑流。
不要把这些个事情弄混了！逻辑流/页面流/业务流 它们运行在非常不同的层面或粒度中。逻辑流来自于一次与单一用户的单一交互； 页面流来自于与单一用户的多次同一上下文的交互；而业务流则横跨许多用户和交互。从另外一个角度看，他们三个是完全正交的，可以在一起使用或是分开单独使用，或者都不用。