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配置文件。