一位优秀的商人杰克，有一天告诉他的儿子
　　杰克：我已经决定好了一个女孩子，我要你娶她
　　儿子：我自己要娶的新娘我自己会决定
　　杰克：但我说的这女孩可是比尔·盖茨的女儿喔
　　儿子：哇！那这样的话……

　　在一个聚会中，杰克走向比尔·盖茨
　　杰克：我来帮你女儿介绍个好丈夫
　　比尔：我女儿还没想嫁人呢
　　杰克：但我说的这年轻人可是世界银行的副总裁喔
　　比尔：哇！那这样的话……

　　接着，杰克去见世界银行总裁
　　杰克：我想介绍一位年轻人来当贵行的副总裁
　　总裁：我们已经有很多位副总裁，够多了
　　杰克：但我说的这年轻人可是比尔·盖茨的女婿喔
　　总裁：哇！那这样的话……

　　最后，杰克的儿子娶了比尔-盖茨的女儿，又当上世界银行的副总裁

　　知道吗，生意通常都是这样谈成的

jbpm在用户角色管理上共设计了四个类：Entity、 Membership、 Group、 User
Entity类是其他三个类的父类，它包含了两个属性：name(String)、 permissions(Set)
User类继承Entity类，包含三个属性：password(String)、 email(String)、 memberships(Set)
Group类继承Entity类，包含四个属性: type(String) 、parent(Group)、 children(Set)、 memberships(Set)
Membership类继承Entity类，包含三个属性:role(String)、 user(User)、 group(Group)
很明显，一个user对应一个用户，一个group对应一个用户组，它们之间通过membership关联，并且一个user可以属于多个不同类型（type)的group，user和 group之间是多对多的关系。
Membership类的role属性个人感觉用途不大，反倒是name属性代表了user在group里的role（角色）！         一个流程图由许多node和transition组成。每个node都有一种类型，这个类型决定了当流程执行到这个node时的不同行为。jbpm有一组node type可以供你选择，当然你可以定制自己node 。
node的作用
node有两个主要的作用：
1）执行java代码，比如说创建task instance（任务实例）、发出通知、更新数据库等等。很典型的就是在node 上挂上我们的action
2) 控制流程的执行：
  A、等待状态
     流程进入到这个node时将处于等待状态，直到一个signal 的发出
  B、流程将沿着一个leaving transition越过这个node
     这种情况特殊一点，需要有个action挂在这个node上（注意这个action不是event触发的！），action中将会调用到API里
     executionContext.leaveNode(String transitionName)，transitionName即这里的leaving transition名字。
  C、创建新的执行路径
     很典型的就是fork node。流程在这里会分叉，产生新的执行路径。这样就创建了新的token，每个新的token代表一个新的执行路径。注意的是，这些新的token和产生前的token是父子关系！
  D、结束执行路径
     一个node可以结束一条执行路径，这同样意味着相应的token的结束和流程的结束。 最近一直打算对原有的一套业务管理系统进行重构。原因很简单，原来的系统采用的是JSP+JAVABEAN+MYSQL的两层架构，在JSP中直接调用JAVABEAN，并且包含了太多的业务逻辑，在维护的时候很困难。
初步的打算是采用jstl+struts+spring+hibernate。
struts仅仅用于表现层，它的Action中不可以涉及到业务逻辑
最近看了看jbpm的源代码，但是还没有在具体的项目中实践。也决定先不在程序中包含工作流。

看过一些人的职业规划，也和同事们聊过。感觉做程序这一行的职业规划都有很多相似的地方：
程序员-->高级程序员-->项目经理-->CTO-->中层管理
规划是这样，至于能走到哪一步就完全靠自己了。感觉想做技术专家的人似乎很少，最后都是想往管理上发展。，毕竟管理拿得 money 多嘛。当然，你也可以自己开公司的。另外，人们好象都有一个观念：年龄大一点就不再适合编码。可我在一篇分析印度软件业的文章里却看到：四十多岁的妇女都可以在家写代码。真是让人流汗！