Oracle神谕

Nodetype task-node 节点类型 任务节点
A task node represents one or more tasks that are to be performed by humans. So when execution arrives in a task node, task instances will be created in the task lists of the workflow participants. After that, the node will behave as a wait state. So when the users perform their task, the task completion will trigger the resuming of the execution. In other words, that leads to a new signal being called on the token.
　　一个任务节点表现为被人所运行的一个或多个任务。所以当执行到达一个任务节点，任务实例将被创建在工作流创建者业务列表中。毕竟，这个节点将作为一个等待状态。所以当用户运行他们的任务，这个任务完成将触发执行的恢复。换言之，那导致一个新的标记在那个toke上被呼叫。

7.3.3. Nodetype state  节点类型　状态
A state is a bare-bones wait state. The difference with a task node is that no task instances will be created in any task list. This can be usefull if the process should wait for an external system. E.g. upon entry of the node (via an action on the node-enter event), a message could be sent to the external system. After that, the process will go into a wait state. When the external system send a response message, this can lead to a token.signal(), which triggers resuming of the process execution.
　　一个状态是裸骨等待状态。这个不同一个任务节点的是没有任务实例将被创建在任务任务列表中。这可以是有用的，如果流程应当为外部系统等待。例如，在节点实体之上（依靠在节点进入事件的一个动作），一个消息将被发送到外部系统。毕竟，这个流程将进入等待状态。当外部系统发送一个返回信息，这可以导致token.signal(),这将触发一个流程执行的恢复。

7.3.4. Nodetype decision　节点类型　决定
Actually there are 2 ways to model a decision. The distinction between the two is based on *who* is making the decision. Should the decision made by the process (read: specified in the process definition). Or should an external entity provide the result of the decision.
　　实际上这里有两种方法来创建一个决定。两者的区别是基谁在做这个决定。　应该被流程来决定。（限定在流程定义中）或者应该一个外部实体支持决定的结果。

When the decision is to be taken by the process, a decision node should be used. There are basically 2 ways to specify the decision criteria. Simplest is by adding condition elements on the transitions. Conditions are beanshell script expressions that return a boolean. At runtime the decision node will loop over its leaving transitions (in the order as specified in the xml), and evaluate each condition. The first transition for which the conditions resolves to 'true' will be taken. Alternatively, an implementation of the DecisionHandler can be specified. Then the decision is calculated in a java class and the selected leaving transition is returned by the decide-method of the DecisionHandler implementation.
　　当这个决定被流程执行，一个决定节点应该被使用。这里有两个基本方法来限定决定标准。最简单是在跃迁上增加条件因素。条件是Beanshell脚本表达式返回一个boolean值。在运行时这个决定节点将循环离开跃迁（顺序和xml定义的一样）。一个DecisionHandler的实现被定义是可选择的。那么，决定被计算在java类中并且选择离开跃迁被DecisionHandler实现的决定方法返回。

When the decision is taken by an external party (meaning: not part of the process definition), you should use multiple transitions leaving a state or wait state node. Then the leaving transition can be provided in the external trigger that resumes execution after the wait state is finished. E.g. Token.signal(String transitionName) and TaskInstance.end(String transitionName).
　　当这个决定被外部执行（意味着：不是流程定义部分），你应该使用多跃迁离开一个状态或等待节点。那么这个离开跃迁在外部的除法器可以被支持恢复执行，在等待状态完成后。例如，Token.signal(String transitionName) 和TaskInstance.end(String transitionName).
7.3.5. Nodetype fork 节点类型　叉
A fork splits one path of execution into multiple concurrent paths of execution. The default fork behaviour is to create a child token for each transition that leaves the fork, creating a parent-child relation between the token that arrives in the fork.
一个叉分离一个路径执行到多个并行的执行路径。这个缺省的叉行为是为每个离开叉跃迁创建一个子token，创建一个到达叉中父－子关系。

7.3.6. Nodetype join 节点类型　合并
The default join assumes that all tokens that arrive in the join are children of the same parent. This situation is created when using the fork as mentioned above and when all tokens created by a fork arrive in the same join. A join will end every token that enters the join. Then the join will examine the parent-child relation of the token that enters the join. When all sibling tokens have arrived in the join, the parent token will be propagated over the (unique!) leaving transition. When there are still sibling tokens active, the join will behave as a wait state.
缺省的合并假设所有的token到达合并点，这些都都是相同父的子。这个情形被创建如我们以上提到的使用叉并且当所有被fork创建的所有token到达相同的join.　一个join将结束每个进入join的token.　那么这个join将检查进入join的token父－子关系。当所有的兄弟姐们tokens激活，这个离开的跃迁join将传播。当这里还有兄弟tokens激活，这个join将作为一个等待状态。

7.3.7. Nodetype node　节点类型　节点
The type node serves the situation where you want to write your own code in a node. The nodetype node expects one subelement action. The action is executed when the execution arrives in the node. The code you write in the actionhandler can do anything you want but it is also responsible for propagating the execution.
节点类型服务在你想写你自己的代码在节点中。这个节点类型节点期待一个子元素行为。这个行为被执行当所有执行到达这个节点。在actionHandler中你写的代码可以做你想做的任何事情，当时它是也是一个责任为执行传播。

This node can be used if you want to use a JavaAPI to implement some functional logic that is important for the business analyst. By using a node, the node is visible in the graphical representation of the process. For comparison, actions --covered next-- will allow you to add code that is invisible in the graphical representation of the process, in case that logic is not important for the business analyst.
这个节点可以被使用，如果你将使用JavaAPI来实现一些功能逻辑，对逻辑分析是重要的. 作为使用一个node,node 是可以视的在流程图形表现中。为对比，actions-convered next--将允许在流程图形表现中增加不可见的代码，万一对你逻辑分析是不重要的

 

三个字段：
1. List  entities
2. Map user
3. Map groups
这个类主要从一个流文件中获得
users用户列表  Map列表  name<key>,user<value>。 user : name email password
组列表   Map列表  name<key>,group<value>。 group : name type
父组列表
memberships列表

这个类主要用来解析XML流中的用户 组 父组 以及会员等等操作的。

Class Token
represents one path of execution and maintains a pointer to a node in the ProcessDefinition. Most common way to get a hold of the token objects is with ProcessInstance.getRootToken() or ProcessInstance.findToken(String).
在流程定义中表现一个执行路径和维持一个指示器给一个节点。
ProcessInstance.getRootToken()
ProcessInstance.findToken(String)

signal()
    provides a signal to the token. this method activates this token and leaves the current state over the default transition.
    准备一个信号给标记。这个方法激活这个标记并且离开当前的状态越过缺省的跃迁。
------------------------------------
Class ProcessInstance
is one execution of a ProcessDefinition. To create a new process execution of a process definition, just use the ProcessInstance(ProcessDefinition).
是一个流程定义的执行。
ProcessInstance(ProcessDefinition)
---------------------------------------
Class ProcssDefinition
创建一个ProcessDefinition
parseParResource(String parResource)
parseParZipInputStream(ZipInputStream zipInputStream)
parseXmlInputStream(InputStream inputStream)
parseXmlReader(Reader reader)
parseXmlResource(String resource)
parseXmlString(String string)
-----------------------------
Class ContextInstance
maintains all the key-variable pairs for a process instance. You can obtain a ContextInstance from a processInstance from a process instance like this :
 ProcessInstance processInstance = ...;
 ContextInstance contextInstance = processInstance.getContextInstance();
为流程实例维持所有的key-variable对。

ContextInstance  contextInstance = ProcessInstance.getContextInstance();
contextInstance.setVariable("amount",new Integer(500));
contextInstance.setVariable("reason","I met my deadline");

--------------------------
任务节点：
<task-node name="t">
  <task name="change nappy">
    <assignment  class="org.jbpm.tutorial.taskmgmt.NappyAssignmentHandler"/>
  </task>
  <transition to="end">
</task-node>

TaskInstance taskInstance = (TaskInstance)processInstance.getTaskMgmtInstance().getTaskInstances().iterator().next();

taskInstance.end(); //标志这个任务已经结束

--------------------------------------------

public interface LoginModule

LoginModule describes the interface implemented by authentication technology providers. LoginModules are plugged in under applications to provide a particular type of authentication.

While applications write to the LoginContext API, authentication technology providers implement the LoginModule interface. A Configuration specifies the LoginModule(s) to be used with a particular login application. Therefore different LoginModules can be plugged in under the application without requiring any modifications to the application itself.

The LoginContext is responsible<负责> for reading the Configuration and instantiating the appropriate<适当的> LoginModules. Each LoginModule is initialized with a Subject, a CallbackHandler, shared LoginModule state, and LoginModule-specific options. The Subject represents the Subject currently being authenticated and is updated with relevant<相关> Credentials<凭证> if authentication succeeds. LoginModules use the CallbackHandler to communicate with users. The CallbackHandler may be used to prompt for usernames and passwords, for example. Note that the CallbackHandler may be null. LoginModules which absolutely require a CallbackHandler to authenticate<认证> the Subject may throw a LoginException. LoginModules optionally use the shared state to share information or data among themselves.

NameCallback:
PasswordCallback:

The LoginModule-specific options represent the options configured for this LoginModule by an administrator or user in the login Configuration. The options are defined by the LoginModule itself and control the behavior within it. For example, a LoginModule may define options to support debugging/testing capabilities<能力>. Options are defined using a key-value syntax, such as debug=true. The LoginModule stores the options as a Map so that the values may be retrieved using the key. Note that there is no limit to the number of options a LoginModule chooses to define.

The calling application sees the authentication process as a single operation. However, the authentication process within the LoginModule proceeds in two distinct phases. In the first phase, the LoginModule's login method gets invoked by the LoginContext's login method. The login method for the LoginModule then performs the actual authentication (prompt for and verify a password for example) and saves its authentication status as private state information. Once finished, the LoginModule's login method either returns true (if it succeeded) or false (if it should be ignored), or throws a LoginException to specify a failure. In the failure case, the LoginModule must not retry the authentication or introduce delays. The responsibility of such tasks belongs to the application. If the application attempts to retry the authentication, the LoginModule's login method will be called again.

In the second phase, if the LoginContext's overall<全面> authentication succeeded (the relevant REQUIRED, REQUISITE<需求>, SUFFICIENT<足够> and OPTIONAL LoginModules succeeded), then the commit method for the LoginModule gets invoked. The commit method for a LoginModule checks its privately saved state to see if its own authentication succeeded. If the overall LoginContext authentication succeeded and the LoginModule's own authentication succeeded, then the commit method associates the relevant<相关> Principals (authenticated identities) and Credentials<凭证> (authentication data such as cryptographic keys) with the Subject located within the LoginModule.

If the LoginContext's overall authentication failed (the relevant REQUIRED, REQUISITE, SUFFICIENT and OPTIONAL LoginModules did not succeed), then the abort（异常） method for each LoginModule gets invoked. In this case, the LoginModule removes/destroys any authentication state originally saved.

Logging out a Subject involves only one phase. The LoginContext invokes the LoginModule's logout method. The logout method for the LoginModule then performs the logout procedures, such as removing Principals or Credentials from the Subject or logging session information.

A LoginModule implementation must have a constructor with no arguments<无参数构造子>. This allows classes which load the LoginModule to instantiate it.

security安全包应该是identity身份模块中很重要的组成部分，其中主要包含以下类：
一、AuthenticatedUser认证用户类：其中很简单，就是gettter和setter 方法，设置和获取authenticatedUser。
 　　其中的authenticatedUser是一个ThreadLocal。
二、IdentityLoginModule身份登陆模块类：
　　实现LoginModule接口。这个类和javax.security.auth.*等包结合非常紧密。
三、IdentityPolicy身份政策类：扩展Policy类。
四、IdentityService身份服务接口：验证用户和获取User
五、Password和Usename　JavaBean
------------------------------------------------------------

补充知识：
１.ThreadLocal
This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID).
这支持支持thread-local 变量。这些变量不同于它们常用的对应物，在那每一个线程获得一个(依靠get或set方法)拥有它自己的，独立地初始化复制这个变量。ThreadLocal实例是典型地私有静态字段，它希望联系状态使用线程(例如；一个用户ID或事务ID)。

JBpm赋值包：
一、ExpressionAssignmentException类：表达式赋值异常类 扩展了RuntimeException
二、ExpressionAssignmentHandler类： 表达式赋值处理器类 实现AssignmentHandler接口。
　　主要字段：
　　　1.String expression;
            2.ExecutionContext executionContext
 　　   3.TermTokenizer tokenizer
            4.Entity entity
 　　语法：syntax : first-term --> next-term --> next-term --> ... --> next-term
　　　first-term ::= previous |
 *                swimlane(swimlane-name) |
 *                variable(variable-name) |
 *                user(user-name) |
 *                group(group-name)

* next-term ::= group(group-type) |
 *               member(role-name)

三、ExpressionSession接口
四、TermTokenizer类："-->"

PermissionUserType类是一个Hibernate组合用户自定义数据类型：
实现了抽象接口CompositeUserType：
其中实现的是一个String[] 数据类型，其中将Java的Permission对象和这个数据类型绑定在一起。

hbm.xml影射文件中
<set name="permissions" cascade="all" table="JBPM_ID_PERMISSIONS">
      <key column="ENTITY_" foreign-key="none" />
      <element type="org.jbpm.identity.hibernate.PermissionUserType">
        <column name="CLASS_"/>
        <column name="NAME_"/>
        <column name="ACTION_"/>
      </element>
    </set>   
一些特殊的组合，使用Hibernate的组合用户自定义类型，在使用上还是很方便的。目前的开发中似乎这个用的比较少，可是在特定场合下可能用的比较多的。

IdentitySessionFactory类基本上类似于Hibernate 的SessionFactory，Jbpm中很多采用了类似于SessionFactory的机制。其中有获取IndentitySession的几个方法。其中还有一个evictCachedIdentities()也不知道有什么用法，可能是将缓存中的数据进行清空的操作。

一、这个类实现了IndentityService接口和ExpressionSession接口：
1.IndentityService接口：
校验用户方法：Object verify(String userName, String pwd);
根据用户id获得User：User getUserById(Object userId);
2.ExpressionSession接口：
 Group getGroupByName(String groupName);
User getUserByName(String userName);
二、包含字段：
　　Session session
        Transaction transaction
三、方法：
１.其中的verify(String userName,String pwd)的处理是通过传递用户名和密码获得一个User列表，如果为空或者size()为０，返回异常，否则get(0)获得对象（User）。
２.采用了Session的get方法获取一个User
３.其中实现事务的开始、确认、回滚方法
４.实现了用户、组、实体的保存加载等方法
５.还有一堆的获得List的方法：

　　IdentitySchema 类主要用来生成SQL脚本<删除、创建、清除>建立数据表以及其他相关的数据库表的操作：
　　delimiter 定界符
Fields：
  private static final String IDENTITY_TABLE_PREFIX = "JBPM_ID_";
  Configuration configuration = null;
  Properties properties = null;
  Dialect dialect = null;
  Mapping mapping = null; 
  String[] createSql = null;　//创建SQL脚本
  String[] dropSql = null; //删除SQL脚本
  String[] cleanSql = null; //清除SQL脚本

　　通过这个类可以创建数据库表结构，通过Hibernate的configuration.generateSchemaCreationScript(dialect)来创建SQL表结构schema的SQL脚本，通过Jbpm特定的execute方法（JDBC），将传入的SQL脚本执行executeUpdate执行表结构的操作。
　　要完成这个操作，要先修改hibernate.cfg.xml配置文件。