Oracle神諭

The Drools move to JBoss really is a good thing for everyone, with no down sides, key Drools developers were consulted throughout the process and all are more than happy with the situation.

Drools轉移到JBoss對每個人來說是一件好事情，沒有任何條件地，核心Drool開發人員考慮流程并且所有都更快樂的情形。

Rule engines are a specialised field, this is recognised by JBoss, and they trust us as the experts so we retain full control of development. I now get to work full time on Drools and we will hopefully be hiring another full time Drools developer. Bob McWhirter will continue to be involved in Drools, in an official JBoss capacity under a part time basis, as he continues to have other responsibilities. This will really accelerate the development process; which benefits everyone.
Rule引擎是一個專門的領域，這是被JBoss承認，并且它們信任我們作為專家，所以我們保留所有的開發控制。我現在開始在Drools上全職開發并且我們將希望雇傭其他全職的Drools開發者。Bob McWhirter將繼續保持在Drools,在一個官方的JBoss地位 under a part time basis,所以他繼續擁有其他責任。他們將真正的促進開發流程；我們收益于每個人。

Drools will continue to work as a standalone product, as part of the JBoss JEMS stack. We will of course work on great JBoss AS integration, especially with jBPM - however we will continue to fully support other AS. I want Drools to be used absolutely everywhere and will do everything I can to achieve this; I want NO artificial barriers to adoption - this has always been important to me and the main reason for not going LGPL. The license will stay BSDish, although we may change it to a standardised BSD/ASF/MIT license ?this has been planned for a while and will help to avoid confusion.

Drools將繼續作為一個獨立的項目工作，作為JBoss JEMS stack的一部分。我們將當然繼續工作JBoss AS 集成，特別是jBPM-然而我們將繼續全面支持其他AS.我想讓Drools用來被使用絕對每個地方并且做我可以去完成這個的任何事情；我想沒有假的障礙來采用--這總是對我來說很重要并且沒有進行LGPL的主要原因。這個license仍然逗留在BSDish,雖然我們可以修改他成一個標準化的BSD/ASF/MIT 的license?這已經計劃了一段時間并且幫助我們避免混亂。

Now that Drools is part of JBoss we can work on strong jBPM integration. We will bring standardised and easily understandable solutions to Workflow/BPM and Business Rules integration to the masses. I have already met with Tom Baeyens and we have identified some initial areas to work on for our first product release in Q1 2006. This is exciting work and will provide new ways of being able to build better affordable solutions without the high costs of existing specialised systems.

On a more personal note neither I nor Bob McWhirter are corporate type people, in fact Bob is famous for it!!! I would not have joined JBoss without full autonomy in an environment that would fully support my vision and the Drools community. We expected JBoss to take bully boy tactics in negotiations; however they were quite the contrary - this was unexpected and very refreshing and one of the key factors in my decision. Throughout the entire process they were surprisingly flexible; they listened to all our concerns and responded supportively - this was especially demonstrated in licensing talks, I hope the community takes note of that. While JBoss would have liked us to LGPL they respected our reasoning and never put any undue pressure on us. Since joining I have been continually asked about community feedback and response from all key JBoss people, Marc Fleury has taken a personal interest in this and repeatedly asked me if there is anything more he can do. This concern has been truly genuine and very much appreciated by me. Luckily the response has been great; we have had overwhelmingly positive feedback, especially once we clarified the licensing.

It would take 24+ months for a small company without an existing track record or infrastructure to try and build a strong brand around Drools, with all the support/consultancy/training/partner infrastructure that is needed for enterprise systems - this is a huge risk and one that I and Iterion were very much aware of. With JBoss we can achieve these in 6 months to a far greater effect, with negligible risk; as JBoss depends heavily on partners this will result in a larger ROI, due to scaling, with far less risk for them.

原文地址：http://blogs.codehaus.org/people/mproctor/archives/001192_drools_joins_jboss.html

public class PriorityQueue<E>extends AbstractQueue<E>implements Serializable
An unbounded priority queue based on a priority heap. This queue orders elements according to an order specified at construction time, which is specified either according to their natural order (see Comparable), or according to a Comparator, depending on which constructor is used. A priority queue does not permit null elements. A priority queue relying on natural ordering also does not permit insertion of non-comparable objects (doing so may result in ClassCastException).
　　一個極大的優先隊列基于一個優先堆棧。這個隊列按照一個限定在構造時間順序排列元素，這是也是按照它們的自然的順序（查看Comparable）限定的，或者按照一個Comparator,依靠使用的構造子。一個優先隊列不允許為空元素。一個優先隊列依靠自然順序也不允許插入一個非comparable對象（這樣做會產生ClassCastException的結果）。

The head of this queue is the least element with respect to the specified ordering. If multiple elements are tied for least value, the head is one of those elements -- ties are broken arbitrarily. The queue retrieval operations poll, remove, peek, and element access the element at the head of the queue.
　　這個隊列頭是最小的元素伴隨期望限定的排序。如果多個元素為最小的值約束，頭是這些元素中的一個---約束是任意打斷的。隊列獲得操作poll(推),remove(移除)，peek　和在隊列頭部的元素

A priority queue is unbounded, but has an internal capacity governing the size of an array used to store the elements on the queue. It is always at least as large as the queue size. As elements are added to a priority queue, its capacity grows automatically. The details of the growth policy are not specified.
　　一個優先隊列是極大的，但是擁有一個內部的容量調節數組的大小用來存儲在隊列中的元素。它總是至少和隊列大小是是一樣大小的。作為元素被加入一個優先隊列，它的容量是自動增加的。增加策略的細節是沒有指定的。

This class and its iterator implement all of the optional methods of the Collection and Iterator interfaces. The Iterator provided in method iterator() is not guaranteed to traverse the elements of the PriorityQueue in any particular order. If you need ordered traversal, consider using Arrays.sort(pq.toArray()).
　　這個類和它的枚舉實現所有可選的集合和枚舉接口的方法。這個枚舉支持iterator()方法是不保證在任何特定的順序遍歷PriorityQueue的元素。如果你需要順序的遍歷，考慮使用Array.sort(pq.toArray()).

Note that this implementation is not synchronized. Multiple threads should not access a PriorityQueue instance concurrently if any of the threads modifies the list structurally. Instead, use the thread-safe PriorityBlockingQueue class.
　　注意這個實現不是不同步的。多個線程不應當并發訪問一個PriorityQueue實例，如果線程在結構上線程任一個被修改。作為替換，使用線程安全的PriorityBlockingQueue類。

Implementation note: this implementation provides O(log(n)) time for the insertion methods (offer, poll, remove() and add) methods; linear time for the remove(Object) and contains(Object) methods; and constant time for the retrieval methods (peek, element, and size).

This class is a member of the Java Collections Framework.

 

Since:
1.5
See Also:
Serialized Form

Package java.util.concurrent(并發) Description

Utility classes commonly useful in concurrent programming. This package includes a few small standardized extensible frameworks, as well as some classes that provide useful functionality and are otherwise tedious(沉悶的) or difficult to implement. Here are brief(摘要的) descriptions of the main components. See also the locks(鎖) and atomic(原子的) packages.

Executors(執行者)
Interfaces. Executor is a simple standardized interface for defining custom thread-like subsystems(子系統), including thread pools(線程池), asynchronous IO(異步IO), and lightweight task frameworks(輕量級任務框架). Depending on which concrete Executor class is being used, tasks may execute in a newly(以新的方式) created thread, an existing task-execution thread, or the thread calling execute(), and may execute sequentially(繼續地) or concurrently(并發地). ExecutorService provides a more complete asynchronous(異步的) task execution framework. An ExecutorService manages queuing(隊列) and scheduling(行程安排) of tasks, and allows controlled shutdown. The ScheduledExecutorService subinterface adds support for delayed(延時的) and periodic(定期的) task execution. ExecutorServices provide methods arranging(安排的) asynchronous execution of any function expressed as Callable, the result-bearing analog(類似物) of Runnable. A Future returns the results of a function, allows determination of whether execution has completed, and provides a means to cancel execution.
Implementations. Classes ThreadPoolExecutor and ScheduledThreadPoolExecutor provide tunable(可調的), flexible(靈活的) thread pools. The Executors class provides factory methods for the most common kinds and configurations of Executors, as well as a few utility methods for using them. Other utilities based on Executors include the concrete class FutureTask providing a common extensible implementation of Futures, and ExecutorCompletionService, that assists in coordinating(計算調配中心) the processing of groups of asynchronous(異步的) tasks.
[Executor  ExecutorService ScheduledExecutorService ScheduledThreadPoolExecutor ExecutionCompletionService]

Queues(隊列)
The java.util.concurrent ConcurrentLinkedQueue class supplies an efficient scalable(可升級的) thread-safe(線程安全) non-blocking(非模塊化) FIFO queue. Five implementations in java.util.concurrent support the extended BlockingQueue interface, that defines blocking versions of put and take: LinkedBlockingQueue, ArrayBlockingQueue, SynchronousQueue, PriorityBlockingQueue, and DelayQueue. The different classes cover the most common usage contexts for producer-consumer, messaging, parallel tasking, and related concurrent designs.
[LinkedBlockingQueue ArrayBlockingQueue SynchronousQueue PriorityBlockingQueue DelayQueue]

Timing(定時)
The TimeUnit class provides multiple granularities<間隔尺寸> (including nanoseconds十億分之一秒) for specifying and controlling time-out(暫停) based operations. Most classes in the package contain operations based on time-outs in addition to(除...以外) indefinite(不確定的) waits. In all cases that time-outs are used, the time-out specifies the minimum time that the method should wait before indicating(指出) that it timed-out. Implementations make a "best effort" to detect（察覺） time-outs as soon as possible after they occur. However, an indefinite(模糊的) amount of time may elapse(流逝) between a time-out being detected and a thread actually executing again after that time-out.

Synchronizers(同步)
Four classes aid(幫助) common special-purpose synchronization idioms(語法). Semaphore(旗語) is a classic concurrency tool. CountDownLatch(Countdown 倒數計秒  latch門插銷) is a very simple yet very common utility for blocking until a given number of signals, events, or conditions hold. A CyclicBarrier(cyclic 循環的 barrier 屏障) is a resettable(可重置的) multiway(多路的) synchronization point useful in some styles of parallel programming. An Exchanger allows two threads to exchange(交換) objects at a rendezvous point(集合點), and is useful in several pipeline(管道) designs.

Concurrent Collections(并發集合)
Besides Queues, this package supplies a few Collection implementations designed for use in multithreaded contexts: ConcurrentHashMap, CopyOnWriteArrayList, and CopyOnWriteArraySet.
The "Concurrent" prefix used with some classes in this package is a shorthand(速記) indicating several differences from similar "synchronized" classes. For example java.util.Hashtable and Collections.synchronizedMap(new HashMap()) are synchronized. But ConcurrentHashMap is "concurrent". A concurrent collection is thread-safe, but not governed by a single exclusion lock. In the particular case of ConcurrentHashMap, it safely permits any number of concurrent reads as well as a tunable number of concurrent writes. "Synchronized" classes can be useful when you need to prevent all access to a collection via a single lock, at the expense of poorer scalability. In other cases in which multiple threads are expected to access a common collection, "concurrent" versions are normally preferable. And unsynchronized collections are preferable when either collections are unshared, or are accessible only when holding other locks.

Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators provide weakly consistent rather than fast-fail traversal. A weakly consistent iterator is thread-safe, but does not necessarily freeze the collection while iterating, so it may (or may not) reflect any updates since the iterator was created.

 

Since:
1.5

　　最近感覺自己一直是缺少知識的補充?，F將主要學習的東東列舉如下：
１.jboss(EJB JMS JNDI Jboss知識)，感覺自己這方面很是缺少，也沒有相應的開發經驗，jBpm中使用了jms的東東。以前做的東西大都運行在Tomcat下，但是對高端的應用服務器還不是很了解。有必要好好學習。
２.正則表達式，感覺這個非常有用，以前都沒有充分利用這個。只是最近才開始在一些腳本校驗上使用。不過還有些東西不是很明白的。
３.AOP，現在這個是有一些理論基礎，也做一個小的demo，但是對這個還是沒有徹底了解。
４.針對開源軟件進行學習，將其中的精髓總結出來，使用在我們的項目開發中。

　　看到jBPM中大量使用了subclass的用法，應該說這個是比較OO的，設計的非常合理。
　　(一)、首先先去看看Hibernate的subclass：
　　1.對于“每一個類繼承樹對應一個表”的策略來說，就需要使用<subclass>定義。
　　<subclass>
            name="className"  //子類的全名
            discriminator-value="discriminator-value"　//辨別標識，一個用于區分每個獨立的子類的值
            proxy="proxyInterface" //指定一個類或接口，在延遲加載時作為代理使用
            lazy="true|false"
            dynamic-update="true|false"
            dynamic-insert="true|false"
            entity-name="entityName"
            node="element-name">
           <property ..../>
          ......
        </subclass>
　　2.每個子類都應該定義它自己的持久化屬性和子類。<version>和<id>屬性可以從根父類繼承下去。在一棵繼承樹上的每個子類都必須定義一個唯一的discriminator-value。如果沒有指定，就會使用Java類的全限定名。
　　3.必須在子類的影射中指定extends屬性來指定已影射的超類。

　(二)在jBPM中的使用
　1.在jBPM的definition組的類機構中就采用上述的技術。其中ModuleDefinition是作為抽象父類存在的，而ContextDefinition、FileDefinition、LoggingDefinition、SchedulerDefinition、MgmtDefinition類是做為subclass存在的。
　2.在父類中使用了discriminator鑒別器的技術：在繼承策略中的“一個對象繼承樹應對應一個表”的策略中，<discriminator>元素是必須的。鑒別器字段包含標志值，用于告知持久層應該為某個特定的行創建哪一個類別的實例。例如：
  父類的影射片段：
    <discriminator type="char" column="CLASS_"/>
    <!-- M : org.jbpm.module.def.ModuleDefinition -->
    <!-- C : org.jbpm.context.def.ContextDefinition -->
    <!-- F : org.jbpm.file.def.FileDefinition -->
    <!-- L : org.jbpm.logging.def.LoggingDefinition -->
    <!-- I : org.jbpm.scheduler.def.SchedulerDefinition -->
    <!-- T : org.jbpm.taskmgmt.def.TaskMgmtDefinition -->
    <!--  :  -->
    <!--  :  -->
　3.鑒別器字段的實際值是根據<class>和<subclass>元素中的discriminator-value屬性得來的。
　例如：
　　父影射文件：
　　<class name="org.jbpm.module.def.ModuleDefinition"
         table="JBPM_MODULEDEFINITION"
         abstract="true"
         discriminator-value="M"
         lazy="false">
       子影射文件：
　　<subclass name="org.jbpm.context.def.ContextDefinition"
            extends="org.jbpm.module.def.ModuleDefinition"
            discriminator-value="C"
            lazy="false">
       </subclass>

　　有一陣沒有看jBPM的source了，正好這幾天是國慶，口袋也沒有多少米，沒有出去旅游的計劃，所以，又重新研究分析一下src。希望從中可以學習到有用的東東！
　　JbpmConfiguration，從名字上就知道是獲取jBPM的相關配置信息。不過這里寫的是一個公共的獲取properties的方法。
　　首先聲明了一個static properties（靜態屬性）的實例properties,然后使用靜態方法getProperties（），為properties獲得具體的值（取org.jbpm.jbpm.properties）。
　　然后是N多獲取方法：
　　public static String getString(String key)
　　public static String getString( String key, String defaultValue )　//如果沒有這個值，默認返回的是defaultValue
　　public static long getLong( String key, long defaultValue )
　　public static boolean getBoolean(String key, boolean defaultValue)
　　public static Object getObject(String key)
　　public static Object getObject(String key, Object defaultValue)   
　　這些為獲取String、long、boolean、Object提供基礎的支持，為以后的操作提供了很多的方便。

　　以前的做分隔符獲取一個個字符串很是麻煩，其實JDK中的String 類已經很好的解決了這個問題。正則表達式確實是個好東西！

split

public String[] split(String regex)

Splits this string around matches of the given regular expression.

This method works as if by invoking the two-argument split method with the given expression and a limit argument of zero. Trailing empty strings are therefore not included in the resulting array.

The string "boo:and:foo", for example, yields the following results with these expressions:

Regex	Result
:	{ "boo", "and", "foo" }
o	{ "b", "", ":and:f" }

Parameters:

regex - the delimiting regular expression

Returns:

the array of strings computed by splitting this string around matches of the given regular expression

Throws:

PatternSyntaxException - if the regular expression's syntax is invalid

Since:

1.4

See Also:

Pattern

<script type="text/javascript" language="javascript">
var http_request = false;
function makeRequest(url) {
http_request = false;
if (window.XMLHttpRequest) { // Mozilla, Safari,...
http_request = new XMLHttpRequest();
if(http_request.overrideMimeType){
http_request.overrideMimeType('text/xml');
}
} else if (window.ActiveXObject) { // IE
try {
http_request = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
http_request = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e) {}
}
}
if (!http_request) {
alert('Giving up Cannot create an XMLHTTP instance');
return false;
}
http_request.onreadystatechange = alertContents;
http_request.open('GET', url, true);
http_request.send(null);
}
function alertContents() {
if (http_request.readyState == 4) {
if (http_request.status == 200) {
alert(http_request.responseText);
} else {
alert('There was a problem with the request.');
}
}
}
</script>
<span style="cursor: pointer; text-decoration: underline" onclick="makeRequest('test.html')"> 發出請求</span>

原文地址：http://www.hibernate.org.cn/viewtopic.php?t=15156

Task management 任務管理
The core business of jBPM is the ability to persist the execution of a process. A situation in which this feature is extremely useful is the management of tasks and tasklists for people. jBPM allows to specify a piece of software describing an overall process which can have wait states for human tasks.
jBPM的核心邏輯是有能力持久化流程的執行。一個為人們用來管理任務和任務列表的特征的情形是非常有用的。jBPM允許指定一些軟件描述一個全面的流程，它可以為人任務擁有等待狀態。

9.1. Tasks 任務
Tasks are part of the process definition and they define how task instances must be created and assigned during process executions.
任務是流程定義的一部分，并且他們定義了任務實例如何在流程執行中必須被創建并且委派。

Tasks can be defined in task-nodes and in the process-definition. The most common way is to define one or more tasks in a task-node. In that case the task-node represents a task to be done by the user and the process execution should wait until the actor completes the task. When the actor completes the task, process execution should continue. When more tasks are specified in a task-node, the default behaviour is to wait for all the tasks to complete.
任務可以在task-nodes和process-definition中被定義。最常用的方式是在task-node中定義一個或多個任務。如果是那樣的話，task-node表現一個任務被用戶執行并且流程執行應該等待知道actor完成這個任務。當這個actor完成這個任務，流程定義應該繼續。當更多任務在task-node被定義，缺省的行為是等待所有任務的完成。

Tasks can also be specified on the process-definition. Tasks specified on the process definition can be looked up by name and referenced from within task-nodes or used from inside actions. In fact, all tasks (also in task-nodes) that are given a name can be looked up by name in the process-definition.
任務也被定義在process-definition中。指定在流程定義上的任務可以通過名稱查詢并且參考從內部的task-nodes或者從內部actions中使用。事實上，所有的給定名稱任務（也在task-nodes）可以在流程定義中通過名字查詢。

Task names must be unique in the whole process definition. Tasks can be given a priority. This priority will be used as the initial priority for each task instance that is created for this task. TaskInstances can change this initial priority afterwards.
任務名稱在整個流程定義中是非重復。任務可以被指定一個優先權。這個優先權將被使用在初始化優先權為每個為任務創建的流程實例。任務實例然后可以修改初始化優先權

9.2. Task instances
A task instance can be assigned to an actorId (java.lang.String). All task instances are stored in one table of the database (JBPM_TASKINSTANCE). By querying this table for all task instances for a given actorId, you get the task list for that perticular user.
一個任務實例可以被委派給一個actorId(java.lang.String).所有任務實例被儲存在數據庫的一個表中(JBPM_TASKINGSTANCE)。通過給定的actorId來對所有的任務實例查詢這個表，你為特定用戶得到任務列表。

The jBPM task list mechanism can combine jBPM tasks with other tasks, even when those tasks are unrelated to a process execution. That way jBPM developers can easily combine jBPM-process-tasks with tasks of other applications in one centralized task-list-repository.

這個jBPM任務列表機制可以組合jBPM任務和其他任務，甚至當這些任務于流程執行無關。那種方法jBPM開發者可以很容易的在一個集中的任務列表倉庫中組合jBPM流程任務和其他應用程序。

9.2.1. Task instance life cycle
The task instance lifecycle is straightforward: After creation, task instances can optionally be started. Then, task instances can be ended, which means that the task instance is marked as completed.
任務實例生命周期是簡單的：創建之后，任務實例可以隨意地開始。接著，任務實例可以被終結，這意味著任務實例內標志為完成。

Note that for flexibility, assignment is not part of the life cycle. So task instances can be assigned or not assigned. Task instance assignment does not have an influence on the task instance life cycle.

注意對適應性、委派不是生命周期的組成部分。所以任務實例可以被委派或者不委派。任務實例委派在生命周期任務實例中沒有影響。

Task instances are typically created by the process execution entering a task-node (with the method TaskMgmtInstance.createTaskInstance(...)). Then, a user interface component will query the database for the tasklists using the TaskMgmtSession.findTaskInstancesByActorId(...). Then, after collecting input from the user, the UI component calls TaskInstance.assign(String), TaskInstance.start() or TaskInstance.end(...).

TaskMgmtInstance.createTaskInstance(...)
TaskMgmtSession.findTaskInstancesByActorId(...)
TaskInstance.assign(String)
TaskInstance.start()
TaskInstance.end()

A task instance maintains it's state by means of date-properties : create, start and end. Those properties can be accessed by their respective getters on the TaskInstance.
一個任務實例維護它的狀態借助于日期屬性：create,start 和end. 這些屬性可以在任務實例中通過他們分別的getter獲得通道。

Currently, completed task instances are marked with an end date so that they are not fetched with subsequent（隨后） queries for tasks lists. But they remain in the JBPM_TASKINSTANCE table. JBPM_TASKINSTANCE.

9.2.2. Task instances and graph execution 任務實例和圖形執行
Task instances are the items in an actor's tasklist. Task instances can be signalling. A signalling task instance is a task instance that, when completed, can send a signal to its token to continue the process execution. Task instances can be blocking, meaning that the related token (=path of execution) is not allowed to leave the task-node before the task instance is completed. By default task instances are signalling and non-blocking.

In case（以防） more than one task instance are associated with a task-node, the process developer can specify how completion of the task instances affects continuation of the process. Following is the list of values that can be given to the signal-property of a task-node.

last: This is the default. Proceeds execution when the last task instance is completed. When no tasks are created on entrance of this node, execution is continued.
last-wait: Proceeds execution when the last task instance is completed. When no tasks are created on entrance of this node, execution waits in the task node till tasks are created.
first: Proceeds execution when the first task instance is completed. When no tasks are created on entrance of this node, execution is continued.
first-wait: Proceeds execution when the first task instance is completed. When no tasks are created on entrance of this node, execution waits in the task node till tasks are created.
unsynchronized: Execution always continues, regardless wether tasks are created or still unfinished.
never: Execution never continues, regardless wether tasks are created or still unfinished.
Task instance creation might be based upon a runtime calculation. In that case, add an ActionHandler on the node-enter event of the task-node and set the attribute create-tasks="false". Here is an example of such an action handler implementation:

public class CreateTasks implements ActionHandler {
  public void execute(ExecutionContext executionContext) throws Exception {
    Token token = executionContext.getToken();
    TaskMgmtInstance tmi = executionContext.getTaskMgmtInstance();
     
    TaskNode taskNode = (TaskNode) executionContext.getNode();
    Task changeNappy = taskNode.getTask("change nappy");

    // now, 2 task instances are created for the same task.
    tmi.createTaskInstance(changeNappy, token);
    tmi.createTaskInstance(changeNappy, token);
  }
}
As shown in the example the tasks to be created can be specified in the task-node. They could also be specified in the process-definition and fetched from the TaskMgmtDefinition. TaskMgmtDefinition extends the ProcessDefinition with task management information.

The API method for marking task instances as completed is TaskInstance.end(). Optionally, you can specify a transition in the end method. In case the completion of this task instance triggers continuation of the execution, the task-node is left over（延遲） the specified transition.

 

script腳本：
一個script是一個執行BeanShell腳本的action。缺省地，所有流程定義變量都是合法的并且無腳本變量將被寫入流程變量。下列腳本變量也是合法的：
executionContext
token
node
task
taskInstance

<process-definition>
  <event type="node-enter">
     <script>
        System.out.println("this script is enering node"+node);
     </script>
  </event>
  ...
</process-definition>

為定制缺省加載行為并且儲存變量進script，變量元素可以被用來作為script的子元素。那樣，腳本表達式不得不被放入一個腳本的子元素:expression

<prcession-definition>
  <event type="process-end">
    <expression>
      a = b+c;
    </expression>
    <variable name="XXX" access="write" mapped-name="a"/>
    <variable name="YYY" access="read" mapped-name="b"/>
    <variable name="ZZZ" access="read" mapped-name="c"/>
  </event>
</prcession-definition>

在腳本開始之前，這個流程變量YYY和ZZZ將分別作為腳本變量b和c使其合法。所有腳本完成之后，腳本變量值a被存儲進流程變量XXX.

如果access變量屬性包含"read"，這個流程變量在腳本賦值之前將被加載作為一個腳本變量。如果access變量屬性包含"write"，這個流程變量在腳本賦值以后將被加載作為一個腳本變量。