迷途書童

 

The Process Virtual Machine

流程虛擬機

by Tom Baeyens and Miguel Valdes Faura
May 8th, 2007.

Translated by Landy(landy.lxy@gmail.com)

Introduction

介紹

There are many process languages for Business Process Management (BPM), workflow and orchestration. For simplicity we'll refer to that collection as workflow for short. There are two aspects to workflow; the process modelling aspect and the software implementation aspect. The biggest problem in workflow technologies today is that they don't handle the dual nature of those technologies properly. The main goal of this paper is to fix exactly that problem.

有許多針對業(yè)務流程管理（BPM），工作流和服務編排的流程語言。為了簡單起見，我們把它們簡稱為工作流。工作流包括兩個方面：流程模型方面和軟件實現(xiàn)方面。如今，早工作流技術領域最大的問題是無法很好的處理這些技術的雙重性。這篇文章的主要目的就是為了解決這個問題。

The Process Virtual Machine does not define a process language. Instead it acknowledges some process language might be better suited for a certain situation then another and hence, there will be multiple process languages coexisting. The Process Virtual Machine will define a common model that can be shared between all the graph based execution languages. It also includes a strategy on how process constructs can be seen as software components. This will enable support for multiple process languages and also it will show much clearer how process technology fits right into software development projects.

流程虛擬機沒有定義一門流程語言。相反，它接受“一些流程語言可能相比其他流程語言能夠更好的適應特定的領域”的觀點。因此，這將導致多種流程語言同時存在。流程虛擬機為所有的基于圖的執(zhí)行語言定義了一組可共享的公共的模型。同時，它也包括“如何將流程元素視為軟件組件”的策略，這將使支持多種流程語言成為可能，它也更清晰的說明了流程技術如何合適的應用到軟件開發(fā)項目中。

Component technology

組件技術

The reason for the fragmentation in process languages is that there are many environments and features that can be handled by workflow. Up to now, the main focus was to build 'the best' process language. There is no sign yet that process languages are converging to each other in some way or another. So the new thing about Process Virtual Machine is the idea that different environments are best served with dedicated process languages.

導致流程語言分裂的原因是許多環(huán)境和特性都能夠由工作流處理。至今為止，業(yè)界主要關注于構建最好的流程語言。還沒有跡象表明所有流程語言會以某種方式收斂到一種。因此，流程虛擬機是一種“不同的環(huán)境有其適應性最好的特定的流程語言”的思路。

While every developer knows the relational model that underpins relational databases, such a conceptual model is absent for workflow. The Process Virtual Machine will fix this missing piece by defining a component model for process constructs. That way, complete process languages can be built on top of the Process Virtual Machine as a set of process construct implementations. Developers that know the Process Virtual Machine will much better understand the current process engines that are currently available. Furthermore, we expect that the Process Virtual Machine will be the basis for all next generation workflow engines.

盡管所有的開發(fā)者知道關系模型是關系型數(shù)據(jù)庫的基石，而工作流領域卻缺乏這樣的一種概念模型。流程虛擬機為流程元素定義了一套組件模型，解決了這個問題。采用這種方式，流程語言可以以添加一套流程元素實現(xiàn)的方式基于流程虛擬機來實現(xiàn)。了解流程虛擬機的開發(fā)人員能夠更好的理解當前存在的工作流引擎。將來，我們期望流程虛擬機將會成為所有下一代工作流引擎的基礎。

More and more, software development will be done in a mix of many languages. Aspects like a domain model or gluecode that binds frameworks to the domain language are best expressed in a general purpose programming language like Java. But a shift is taking place away from general purpose programming languages and leverage more frameworks for specific aspects of software development. Typically, the frameworks come with a library and Domain Specific Language (DSL). Those frameworks and languages address certain parts of software development in a more natural and easier way. Examples are process engines with process languages, rules engines with rules languages, object relational mapping frameworks with the mapping metadata, parsers based on grammars, inversion of control (IoC) containers with an object wiring language and web frameworks with their configuration files that specify navigation.

越來越多的軟件將混合使用多種語言開發(fā)。像領域模型或者將框架綁定到領域語言等方面能夠使用像Java之類的通用編程語言很好的表示。但是，轉變正在從“通用編程語言”到“更多的適應于軟件開發(fā)特定方面框架”發(fā)生。通常的，這些框架會附帶一個庫和領域特定語言（DSL）。這些框架和語言能夠更容易和自然的解決軟件開發(fā)的某個部分。例子有包含流程語言的流程引擎，包含規(guī)則語言的規(guī)則引擎，包含映射元數(shù)據(jù)的對象關系映射框架，基于語法的解析器，包含對象裝配語言的控制反轉（IOC）容器和包括制定頁面導航的配置文件的web框架。

Many of the Domain Specific Languages (DSL) that we see today are graph based execution languages. For all of those, the Process Virtual Machine is the common foundation that can be see as the masterpiece to federate DSL graph based languages by reducing maintenance, design and implementation cost.

很多當前的領域特定語言（DSL）是基于圖的執(zhí)行語言。為了減少維護、設計和實現(xiàn)成本，流程虛擬機可以作為這些語言的公共基石。

So process languages will be pluggable on top of the Process Virtual Machine.

因此，流程語言可以以可插拔的方式基于流程虛擬機之上實現(xiàn)。

Embeddable workflow

嵌入式工作流

Just a few workflow automation projects can be realized only by using process languages. The BPM Suites that preach the "no code" approach only target that kind of projects where everything must be modelled as a process. We think that workflow, BPM and orchestration can ease the implementation of some aspects of a software development project. And a software development project usually combines many aspects, only some of which could be modelled as processes.

僅有少量的工作流自動化項目能夠僅僅使用流程語言實現(xiàn)。某些宣揚“零編碼”方案的BPM套件僅僅能適應這些“必須將一切建模成流程”的項目。我們認為工作流，BPM和服務編排能夠簡化軟件開發(fā)項目的某些方面，一個軟件開發(fā)項目通常包括多個方面，僅僅部分能夠建模為流程。

In this view, workflow technology is much more broadly applicable then it is used today. Because today's process engines are not embeddable enough and because of the current fragmentation and confusion, developers still write homegrown workflow engines for their own project.

基于這種觀點，工作流技術被廣泛采納和使用。因為當前的流程引擎嵌入程度不夠和因為當前工作流技術的分裂和給用戶造成的混淆，開發(fā)者仍然為他自己的項目開發(fā)自己的工作流引擎。

The concept of embeddable workflow means that a process engines can be easily integrated into todays software development projects. This is in contrast with the traditional monolithic BPM server approach.

嵌入式工作流的概念意味著流程引擎能夠更容易的與當今的軟件開發(fā)項目整合。這與傳統(tǒng)的獨立BPM服務器方案截然不同。

In software development in general, there is a clear trend towards the use of more Domain Specific Languages (DSL). Embeddable workflow really fits with that trend: Process languages just become another language that developers can use in their projects. Workflow is complementary to old fashion plain programming. The developer should be free to select the language best suited for the job.

在一般的軟件開發(fā)過程中，更多的使用領域特定語言（DSL）成為趨勢。嵌入式工作流完全符合這種趨勢：流程語言僅僅作為另一種語言，開發(fā)者可以在他的項目中使用它。工作流與以往的plain編程互補。開發(fā)者應該能夠自由的選擇最適合與他的工作的語言。

The following aspects are crucial to make the workflow engine embeddable:

下面是使工作流引擎嵌入化的一些要點：

·         Persistence: The workflow engine itself should be decoupled from the actual persistence technology. First of all, persistence itself should be optional and in case it is required, different persistence technologies like e.g. JPA, Java serialization or XML should be pluggable. In case a relational database is used for persistence, the developer should have a choice to deploy the workflow engine's database tables separate or alongside the application's database tables or in a separate database. The latter can make the whole application much more manageable.

持久化：工作流引擎應該與特定的流程化技術解耦。首先，持久化本身應該是可選的，如果需要持久化，像JPA，Java序列化或XML之類的不同的持久化技術應該是可插拔的。如果使用關系數(shù)據(jù)庫來持久化，開發(fā)者應該能夠選擇將工作流引擎的數(shù)據(jù)庫表獨立開來部署或與應用的數(shù)據(jù)庫表在一起部署或者在單獨的數(shù)據(jù)庫中部署。后者能夠使整個應用更容易被管理。

·         Services: The services that an engine might use such as a timer service or an asynchronous message service should be pluggable so that different implementations can be used in different environments like e.g. stardard Java and enterprise Java.

服務：引擎可能使用的服務如Timer服務或異步消息服務應該是可插拔的，因此，可在不同的環(huán)境下使用不同的實現(xiàn)，如標準java和企業(yè)Java。

·         Transactions: If the workflow engine's can work with the same database connection as the application, there is no need for global or distrubuted transactions. That definitely reduces complexity. Same reasoning applies to sessions of the object relational mapper like e.g. Hibernate.

事務：如果工作流引擎可以和應用使用同一個數(shù)據(jù)庫連接，則不需要分布式事務。這將毫無疑問的降低復雜度。同樣的理由適應于對象關系映射的會話如Hibernate。

·         Libraries: Apart from the traditional monolithic deployment of a workflow engine, it often can be much more practical to deploy just the engine's libraries in the client application.

庫：除了傳統(tǒng)的獨立部署工作流引擎，通常也可以僅將引擎庫部署在客戶應用中。

·         Testability: Executable processes are software so they should be tested the same way. Tests should take process executions through different test scenarios. This should of course be integrated with the rest of the client application infrastructure.

可測試性：可執(zhí)行的流程是軟件，因此，他們應該同樣的被測試。測試應該通過不同的測試場景來執(zhí)行流程。這顯然需要流程引擎與其他客戶應用集成。

·         Binding: It should be easy to bind the process logic to the rest of the software development project. As we'll see in section Process modelling, an executable process is always a combination of the graphical diagram and technical details. Up to now, the focus of tooling is on editing the graphical diagram. But software development projects usually contain many languages like e.g. Java, process language and scripting languages. So we expect that tools will start to focus more that coherence between different artifacts in one software project. For example, a refactoring for renaming a Java class might span updates to Java classes and process definition files.

綁定：應該能夠容易的將流程邏輯綁定到其他軟件開發(fā)項目。像我們在流程建模章節(jié)看到的，一個可執(zhí)行的流程通常是符號圖和技術細節(jié)的組合。到現(xiàn)在為止，工具的關注點在編輯符號圖。但是軟件開發(fā)項目通常包括像Java，流程語言和腳本語言之類的需求語言。因此，我們期望工具應該更多的關注在同一軟件項目中的不同方面。比如，重命名一個Java類的重構應該更夠關聯(lián)更新java類和流程定義文件。

Scope

范圍

We already explained above that the Process Virtual Machine is a common foundation for graph based execution languages. The languages for which the Process Virtual Machine can be leveraged have three main characteristics:

我們已經闡述了流程虛擬機是基于圖的執(zhí)行語言的公共基礎。能夠基于流程虛擬機的語言有三個主要特征：

·         Processes are represented graphically to facilitate communication between all stakeholders

流程是用來圖形化表達參與方之間通訊的

·         The process expresses some kind of execution flow

流程表示一種執(zhí)行次序

·         Processes can potentially include wait states from the perspective of the process engine and be 'long running'

從流程引擎方面來看，流程可以潛在的包含等待狀態(tài)；流程也可以是long running的。

Any aspect in software development that meets these criteria can be built on top of the Process Virtual Machine. It's not limited to workflow or BPM as we know it today. An example of such a non trivial aspect might be pageflow; a language to describe navigation between pages in a web application.

如果軟件開發(fā)的任何方面滿足這些條件的都可以基于流程虛擬機構建。不局限于我們今天知道的工作流或BPM。一個例子是頁面流：一種在web應用中用來描述不同頁面間導航關系的語言。

Basics

基本原理

Here follow the basic principles of the Process Virtual Machine. After the basics, we'll cover a series of extensions that are needed to cover all features needed for real process languages.

這里，講述了流程虛擬機的基本原則。基本原理之后，我們將講述一系列的擴展，這些擴展覆蓋了真正的流程語言需要的所有特性。

A process is a graphical description of an execution flow. For example the procedure on processing expense notes is a process. It can be deployed in a process engine. One process can have many executions. E.g. my expense note of last Monday could have been handled by one execution of the expense note process. Another example of a process is shown in Figure 1.

流程是一個可執(zhí)行流程的圖形化描述。如，處理費用記錄的過程是一個流程。它可以部署在流程引擎中。一個流程可以有多個執(zhí)行（execution），如我上周一的費用記錄可能被費用記錄流程的一個執(zhí)行處理了。另一個流程的例子在圖一中說明了。

Figure 1: An example process for an insurance claim

圖1：保險索賠的樣例流程

The basic structure of a process is made up of nodes and transitions. Transitions have a sense of direction and hence a process forms a directed graph. Nodes can also have a set of nested nodes. Figure 2 shows how transitions and nodes can be modelled in a UML class diagram.

流程的基本結構由節(jié)點和轉移組成。轉移是有向的，因此，流程形成了一個有向圖。注意，也可以有一系列的內嵌節(jié)點。圖二說明了轉移和節(jié)點如何使用UML類圖來建模。

Figure 2: UML class diagram of nodes, transitions and the behavior

圖2：節(jié)點，轉移和行為的UML類圖

Each node in the process has a piece of Java code associated as its behaviour. The interface to associate Java code with a node is shown in Figure 3.

流程的每個節(jié)點都有一段Java代碼與它的行為關聯(lián)。關聯(lián)Java代碼和節(jié)點的接口如圖三所示。

Figure 3: The Executable interface for specifying the behaviour of nodes

圖三：指定節(jié)點行為的Executable接口

Now, let's look at the runtime data structure. An execution is a pointer that keeps track of the current position in the process graph as indicated in Figure 4.

現(xiàn)在，讓我們看看運行時的數(shù)據(jù)結構。一個執(zhí)行時跟蹤流程圖的當前位置的指針。如圖四。

Figure 4: An execution points to the current position in the process graph

圖四：一個執(zhí)行指向流程圖中的當前位置

When a new execution is started for a given process, the initial node will be positioned in the initial node of the process. After that, the execution is waiting for an external trigger. The method and class structure of Execution's is indicated in Figure 5.

如果一個指定的流程的新的執(zhí)行啟動了，流程的初始節(jié)點會被作為初始位置。然后，執(zhí)行會等待一個外部的觸發(fā)。圖五指出了執(zhí)行的方法和類結構。

Figure 5: UML class diagram of an Execution

圖五：執(zhí)行的UML類圖

An external trigger can be given with the proceed(String transitionName) method on the execution. Such an external trigger is very similar to the signal operation in finite state machines. The execution knows how to interpret the process graph. By calling the proceed method, the execution will take the specified (or the default) transition and arrives in the destination node of the transition. Then, the execution will update its node pointer and invoke the node's behaviour.

外部觸發(fā)可以由執(zhí)行的proceed(String transitionName)方法來發(fā)起。這樣的一個外部觸發(fā)與有限狀態(tài)機中的signal操作非常類似。執(zhí)行知道如何解釋流程圖。通過調用proceed方法，執(zhí)行將沿著指定的（或默認的）轉移，到達轉移的目的節(jié)點。然后，執(zhí)行會更新它的節(jié)點指針和調用節(jié)點的行為。

The node's behaviour has got access to the current state of the process through the execution that is passed in as a parameter. In the extensions that are described in detail in the full paper show how for example variables or external services will be available through the execution.

節(jié)點的行為能夠通過作為參數(shù)傳入的執(zhí)行來訪問流程的當前狀態(tài)。在本文中詳細描述了的擴展將會說明如何在執(zhí)行過程中使用樣例變量和外部服務。

On the other hand, the node's behaviour has got control over the propagation of execution. This means that the executable implementation can just behave as a wait state, continue execution, create concurrent executions or update any information in the execution.

另一方面，節(jié)點的行為通過執(zhí)行的傳播來控制。這意味著executable實現(xiàn)可以僅僅實現(xiàn)為：等待狀態(tài)，繼續(xù)執(zhí)行，創(chuàng)建并發(fā)的執(zhí)行或更新當前執(zhí)行的信息。

Let's look at two example node behaviour implementations:

讓我們看看兩個節(jié)點行為的實現(xiàn)樣例：

A task node

任務節(jié)點

The reason why task management and workflow are so closely related is because tasks for humans often translate to wait states for a software system. Processes can easily combine software operations with human tasks in the following way.

任務管理和工作流緊密相關的原因是人員的任務通常翻譯為軟件系統(tǒng)的等待狀態(tài)。流程能夠容易的將軟件操作與人員任務以下面的方式組合起來

The first thing that is needed outside of the process execution engine is a task repository, a place where tasks for people are kept. On top of this component, there is a user interface that allows for people to see their task list and complete them.

首先，任務倉庫是除了流程執(zhí)行引擎之外必要的，它是用來存儲人員的任務的。這個組件之上，有用戶界面允許人員察看他的任務列表和完成它們。

Then you can imagine the following behaviour implementation of a task node. First, some external trigger has to be given (with the proceed method) so that the process starts executing and arrives in the task node. The node behaviour implementation will create a new task for a given person in the task list component. That task also includes a reference back to the execution. Then, the node behaviour returns without propagating the execution. This means that the execution will be positioned in the task node when the proceed invocation returns.

然后，你可以想象任務節(jié)點的下面的行為實現(xiàn)。首先，應該發(fā)起一個外部觸發(fā)（通過proceed方法），因此，流程開始執(zhí)行，到達任務節(jié)點。節(jié)點行為實現(xiàn)會在節(jié)點列表組件中為指定的人創(chuàng)建一個新任務。這個任務同時也包含execution的一個引用。然后，節(jié)點行為返回，不需要傳播執(zhí)行。這意味著當proceed調用返回時，執(zhí)行會定位在任務節(jié)點。

Figure 6: Pseudo code for a task node implementation

圖6：任務節(jié)點實現(xiàn)的偽代碼

The taskName member field shows how configuration information that is specified in the process definition file, should be injected into the behaviour object.

taskName成員變量表示流程定義文件中指定的配置信息，應該注入到行為對象中。

So the execution can then be persisted during while the system is waiting for the user to complete the task. After some time, when the user completes the task, the task management component will use the reference to the execution to provide a trigger. This is done with the proceed method. Then the execution resumes, leaves the task node and continues.

因此，在系統(tǒng)等待用戶完成任務的間隔，執(zhí)行可以被持久化。一段時間后，當用戶完成任務，任務管理組件會使用執(zhí)行的引用提供一個觸發(fā)。這些通過proceed方法來完成。然后執(zhí)行恢復，離開任務節(jié)點，然后繼續(xù)后續(xù)執(zhí)行。

An email node

Email節(jié)點

An email node is different from a task node in the sense that it is automatic. An email has to be send and then the execution should immediately be propagated over the default leaving transitions. That propagation of execution is done with the invocation of the proceed method at the end of EmailNode's behaviour implementation in Figure 7.

Email節(jié)點與任務節(jié)點的不同點在它是自動的。需要發(fā)送一封Email，然后執(zhí)行應該立刻通過默認的離開轉移傳播。執(zhí)行的傳播是通過調用圖七中EmailNode行為實現(xiàn)的最后面的process方法實現(xiàn)的。

Figure 7: Pseudo code for an email node implementation

圖七：Email節(jié)點實現(xiàn)的偽代碼

Similarly as with the task node, the member fields recipient, subject and text are specified in the process definition file. The engine will inject the values into the member fields. Those values might be the result of runtime evaluation of expressions and also mappings might be applied.

與任務節(jié)點類似，成員變量recipient，subject和test在流程定義文件中指定。引擎會將這些值注入成員變量。這些可能會是運行時計算表達式的結果，映射可能也需要采用。

Now, let's discuss the main features of the basic model that we have presented so far.

現(xiàn)在，我們討論我們目前介紹的基本模型的主要特性。

Graphical representation

特性化展現(xiàn)

The basic Process Virtual Machine concepts show how graphical diagrams can be made executable. Processes are made up of nodes and transitions, hence they have a direct relation with the graphical representation. On the other hand, the behaviour member field in the Node class defines the programming logic that is executed at runtime.

流程虛擬機的基本概念展示了如何使符號圖可執(zhí)行。流程由節(jié)點和轉移組成，因此它們有有向關聯(lián)。另一方面，在Node類中的behaviour成員變量定義運行時執(zhí)行的編程邏輯。

The graphical structure of the concepts defined in Process Virtual Machine cover most constructs of process languages. Even advanced conctructs like e.g. UML super states can be mapped directly to the nestedNodes relation as defined in Figure 2. Still, process languages can extend the basic structure with new concepts such as e.g. timers, data flow or conditions.

流程虛擬機中定義的概念的圖形化結構覆蓋了流程語言的大部分元素。甚至高級元素，如UML超狀態(tài)可以直接映射到圖二中定義的nestedNodes關系。流程語言也可以使用新概念來擴展基本結構，如timers，data flow或conditions。

Wait states

等待狀態(tài)

We also saw in the task node example that nodes can represent wait states. When an execution arrives in a node and the execution.proceed() method is not invoked, the originally proceed, invoked by external client will return. That means that the execution is now in a wait state and typically it is then waiting for an external trigger. Typically, that is the right time to persist an execution.

我們在任務節(jié)點的例子中看到了節(jié)點可以表示等待狀態(tài)。當執(zhí)行到達一個節(jié)點時，不調用execution.proceed()方法, 由外部客戶端調用的初始的執(zhí)行方法會返回。這意味著執(zhí)行當前處于等待狀態(tài)，典型場景是執(zhí)行等待一個外部觸發(fā)。通常，這是持久化只執(zhí)行的合適時間。

With wait states, processes can now express execution flows that spans software operations (typically in a transaction) and wait states when the engine must wait for an external trigger. This is also known as long running processes.

通過等待狀態(tài)，流程可以表示跨軟件操作（通常在一個事務中）的執(zhí)行流和當引擎必須等待外部觸發(fā)的等待狀態(tài)。通常這也叫長運行的流程。

Synchronous execution

同步執(zhí)行

When a client invokes the proceed method, the exection will start to interpret and execute the process in that thread. An execution typically starts by taking a transition and then executing the destination node. When the execution invokes the behaviour of the destination node, it passes itself as the parameter. The node behaviour can then in turn propagate the execution onward by calling the proceed method on the execution again. Note that this is still done in the thread of the client, which is still waiting for the original proceed invocation to return.

當客戶端調用proceed方法，執(zhí)行會在那么線程中開始解析和執(zhí)行流程。執(zhí)行通常開始于選擇一個轉移，然后執(zhí)行目的節(jié)點。當執(zhí)行調用目的節(jié)點的行為，它將自己作為參數(shù)傳遞。然后節(jié)點行為可以以此向下傳播執(zhí)行通過再次調用執(zhí)行的proceed方法。注意，這仍然在客戶線程中完成，客戶端仍然在等待原來的proceed調用返回。

In other words, the execution is always interpreted in the thread of the client. When the the execution is not propagated any more, the nested proceed invocations start returning since the proceed should be the last operation in the behaviour's execute method. The proceed invocation will be blocking for the caller until a wait state is reached.

換句話說，執(zhí)行通常在客戶端線程中解釋。當執(zhí)行不再傳播，內嵌的proceed調用開始返回，因為proceed應該是behaviour的執(zhí)行方法的最后一個操作。調用者的Proceed調用會阻塞，直到到達等待狀態(tài)。

The default behaviour is to have synchronous executions because it limits the number of transactions and hence improves performance. But in case there are many automatic things to be done before the process execution reaches another wait state, Asynchronous continuations have to be considered.

默認行為是同步執(zhí)行，因為它限制了事務的數(shù)量，因此提升了性能。但是當有許多自動的事情要在流程執(zhí)行到達另外的等待狀態(tài)前完成時，應該考慮異步執(zhí)行。

Interpretation

解釋

The bulk of the interpretation of the process is delegated to the behaviour implementations. The only responsibility of the execution is to follow the transition to it's destination node and update the node pointer accordingly. That way, the execution's node pointer will always indicate the current state.

大量流程的解釋是在behaviour的實現(xiàn)中完成的。Execution的唯一職責是沿著轉移到目的節(jié)點和更新節(jié)點位置。Execution的節(jié)點指示器會始終指向當前狀態(tài)。

This is important because it means that the bulk of the behaviour of the engine is pluggable. The essence of interpreting a graph is baked in the component model. But all the rest is left up to the process construct implementations. That is why it is possible to build such diverse process languages on top of the same framework.

這一點非常重要，因為這意味著引擎的大量behaviour是可插拔的。解釋圖的本質是baked組件模型。但是，所有其他的留給了流程元素實現(xiàn)。這就是為什么能夠在同一個框架之上構建多種多樣的流程語言。

Another way of describing the responsibilities of the node implementations is the following: First, they can use any Java API to perform any kind of business logic like sending emails, creating tasks, calling web services and so on. To do this, the implementations have access to the contextual information about the process like process variables, services from the environmentand configuration information that gets injected into the member variables. After the business logic, node implementations can propagate the control flow of the process execution. The basic scenarios are wait states and propagation of the incoming execution over one a leaving transition. But in more exotic scenarios, the node implementation can reorganise the complete runtime execution datastructure as well.

下面是描述節(jié)點實現(xiàn)的職責的另一種方式：首先，能夠使用任意Java API來執(zhí)行任意業(yè)務邏輯，如發(fā)電子郵件，創(chuàng)建任務，調用web服務等等。要實現(xiàn)這樣，實現(xiàn)要求能夠訪問流程的上下文信息如流程變量，環(huán)境的服務和注入成員變量的配置信息。業(yè)務邏輯執(zhí)行完之后，節(jié)點實現(xiàn)可以傳播流程執(zhí)行的控制流。基本的場景是等待狀態(tài)和根據(jù)一個離開轉移傳播執(zhí)行。但是，在更加特定的場景中，節(jié)點實現(xiàn)也可改變整個運行時執(zhí)行數(shù)據(jù)結構。

Extensions

擴展

The previous sections explained the basic operations of the Process Virtual Machine. In the next sections we'll describe a set of extensions to this basic model to show how advanced features can be build on top.

前面的章節(jié)解釋了流程虛擬機的基本操作。后續(xù)的章節(jié)中，我們將闡述對基本模型的一組擴展來展現(xiàn)如何增加高級特性。

Variables

變量

Process variables can contain contextual information associated with a single execution. For example, in a payraise process, the desired amount and the reason could be process variables.

流程變量可以包含與單個execution關聯(lián)的上下文信息。比如，在一個加薪流程中，加薪數(shù)目和理由可作為流程變量。

Process variables can be added to the basic Process Virtual Machine by associating a set of key value pairs within an execution.

流程變量可以以將一組key-value對關聯(lián)到單個execution的方式加入流程虛擬機。

Processes or nodes can have variable declarations. Some process languages mandate variable declarations and others don't. So that is why the key value pairs should be dynamic, just like a HashMap in Java. The variable declarations could be used at runtime to initialize, destroy or to check for avaiability of a certain variable.

流程或節(jié)點可擁有變量聲明。一些流程語言強制變量聲明但是另外一些不強制。這種情況下的key-value對是動態(tài)的，就像Java中的hashmap。變量聲明可以在運行時用來初始化，銷毀或檢測特定變量是否存在。

Process variables should be Plain Old Java Objects (POJO) because the component programming model is in Java. Process languages like BPEL only store xsd types or XML snippets. In that case, the process language itself is responsible of translating those datatypes into the desired POJO type.

流程變量應該是POJO，因為組件編程模型是Java。流程語言像BPEL僅存儲xsd類型或XML片段。在這種情況下，流程語言自己應負責轉換這些數(shù)據(jù)類型為目標POJO類型。

Persistence is optional, so in general, it should be possible to store any POJO object in the process variables. Only when an execution is stored, transformations should be applied to map the POJO's to their persistable format.

持久化是可選的，因此，一般來講，應該能夠在流程變量中存儲任何POJO對象。僅當execution存儲的時候，可將POJO映射到它的持久化格式。

The section about Concurrent paths of execution will introduce a tree of executions. That tree also defines a natural scoping structure for process variables.

并行路徑執(zhí)行一章介紹了一種執(zhí)行樹。這種樹也為流程變量定義了一種域結構。

Actions

動作

An action is the crucial concept that will enable modelling freedom for the analyst, while the developer has to make the process executable.

動作是非常重要的概念，它可使得分析師獨立于模型，即使開發(fā)人員需要讓流程可執(zhí)行。

An action is a piece of programming logic that is inserted invisibly in the process graph. For example, perform a certain database update when leaving this node. Or, delete a certain file when this transition is taken. Actions can also be described as listeners to process events.

動作是不可視的插入流程圖的一段編程邏輯，當離開當前節(jié)點時完成特定的db更新。或者，當轉移選取時刪除一個特定文件。動作可被描述為流程事件的監(jiān)聽器。

The Executable interface that is shown above can be used to refer to actions.

上面的Executable接口可以用來引用動作。

An event is a point in the process where actions can be specified. The three most common events are entering a node, leaving a node and taking a transition. As an implementation detail, we mention that the Execution class can be enhanced with a fire method in the API. That way, clients, actions and node behaviour implementations can all fire events. Despite the goal of being hidden from the graphical diagram, in Figure 8, we indicate how the actions are related to the diagram just to serve this explanation.

時間是流程中可以指定動作的點。三個最常用的事件是節(jié)點進入事件，節(jié)點離開事件和轉移獲取事件。作為實現(xiàn)細節(jié)，我們提及了Execution類可以在api中以增加一個fire方法的方式增強。客戶端，動作，和節(jié)點行為實現(xiàn)可以觸發(fā)事件。盡管目的被隱藏在符號圖中了，在圖八中，我們指出來動作是如何與圖相關的。

Figure 8: Most common events

圖八：最常用的事件

But it is good to use the combination of a process element and a plain event type string to identify an event. That way, much more event types can be defined and even users could define their own event type.

但是，最好使用流程元素和簡單事件類型字符串的組合來標識一個事件。用這種方式，可以定義更多的事件類型，甚至用戶可以定義他們自己的事件類型。

Events can also be propagated. The process can have a hierarchical structure with nested nodes. If a process language implements a construct like e.g. UML super states, events on a nested node can be propagated to the enclosing superstate. That propagation can continue recursively until the level of the process defintion itself. So super states or processes might listen to all events of a certain type that are fired inside. For example, invoke this action for every transition that is taken within this superstate.

事件也可以傳播。流程可以帶有內嵌的節(jié)點，組成分層結構。如果流程語言實現(xiàn)了一個構造如UML 超state，內嵌的節(jié)點上的事件可以傳播到封閉的超狀態(tài)。傳播可以遞歸進行，直到流程定義級別為止。所以，超狀態(tài)或流程可能監(jiān)聽所有觸發(fā)的指定類型的事件。例如，為超狀態(tài)中的每一次“獲取轉移”調用動作。

Concurrent paths of execution

并行路徑執(zhí)行

One path of execution can point to one single location in the process graph. In some situations, there parts in the process that can progress independently. For instance, the shipping and billing part of a process. In those scenarios, multiple paths of execution are needed to keep track of the state for one complete process execution. To support this, the executions can be structured in a parent-child relation. A new execution for a given process acts as the main path of execution. To create concurrent paths of execution, child executions can be created. Typically, the parent execution will remain inactive in the fork (aka and-split) while the child executions are executing.

執(zhí)行的一個路徑可以指向流程圖中的單個位置。在一些情形下，流程的這些環(huán)節(jié)能夠獨立的執(zhí)行。例如，發(fā)貨和開發(fā)票環(huán)節(jié)。在這些場景中，需要execution的多個路徑來跟蹤一個完整的流程執(zhí)行的狀態(tài)。為了支撐這種情形，execution可以構造為父子關系。指定的流程的新執(zhí)行可以作為執(zhí)行的主要路徑。要創(chuàng)建execution的并行路徑，可創(chuàng)建子exection。典型的，當子執(zhí)行正在執(zhí)行時，父執(zhí)行會保持“不活動”狀態(tài)在分支（或and-split）。

Several fork and join behaviours can be implemented in as node behaviours. The fork typically launches a new execution over each of its leaving transitions. Optionally, guard conditions might be added to prevent some of the concurrent executions from being created.

一些fork和join行為可以實現(xiàn)為節(jié)點行為。For通常會為每一個離開轉移發(fā)起一個新執(zhí)行。可選的是，可以增加條件來阻止創(chuàng)建一些并行執(zhí)行。

Note that process concurrency mostly doesn't require multithreaded calculations. Assume for a second that no actions are involved and that all nodes right after the fork (aka and split) behave as wait states, like illustrated in figure 9. In that case, one database transaction should contain the operations to inactivate the parent execution and to add the two new child executions each referencing their respective wait state.

注意流程并行通常不需要多線程執(zhí)行。假定某一時刻沒有執(zhí)行任何動作，且fork（或and split）后面的所有節(jié)點都是等待狀態(tài)，就像圖9中的例子。在這種情況下，一個數(shù)據(jù)事務應該包含去激活父執(zhí)行和增加兩個新的子執(zhí)行的操作。每個子執(zhí)行應該引用各自的等待狀態(tài)。

Figure 9: Concurrent paths of execution

圖九：并行路徑執(zhí)行

Calculating the updates for that single transaction doesn't need to be done in two separate threads. In fact, those threads would have to be synchronized anyway because they operate on the same database transaction.

為那個獨立的事務的更新計算不需要在兩個獨立的線程中完成。事實上，不論怎樣，那些線程將會需要同步，因為它們操作同一個數(shù)據(jù)庫事務。

The main difference is in the join behaviour. We'll describe two examples of join implementations just to illustrate that any type of join behaviour can be implemented. The Process Virtual Machine itself doesn't include a fixed mechanism for process concurrency. Instead, the different forms of concurrency can just be implemented just like any other process construct.

主要的不同點在join行為中。我們將描述join實現(xiàn)的兩個例子來說明任意類型的join行為可以被實現(xiàn)。流程虛擬機本身沒有包括流程并行的一個固定機制。相反，不同形式的并行可以像其他任何流程元素一樣實現(xiàn)。

As long as all paths leaving a fork arrive at the same join and no other paths can arrive at that join, a simple join implementation can be build that takes advantage of the hierarchical structure of the executions: When an execution arrives in a join, it first marks the incoming execution as deactivated and then checks if there are any active siblings left. If there are no active siblings left, the parent execution is reactivated, positioned in the fork and that execution is propagated over the default leaving transition.

只要來自同一個fork的所有路徑到達同一個join，并且沒有其他的路徑可以到達那個join，一個簡單的join實現(xiàn)可以利用執(zhí)行的分層結構：當執(zhí)行到達join，它首先標記進入的執(zhí)行為去激活狀態(tài)，然后檢查是否存在活動的兄弟。如果沒有活動的兄弟，父執(zhí)行可以重新激活，定位在fork，然后執(zhí)行通過默認的離開轉移傳播。

Another approach is to count the number of executions that have arrived in a join. If that number just got the same as the number of arriving transitions, a new execution will be created, positioned in the join and propagated over the default transition. In this case the complete execution tree needs to be pruned for inactive executions after a join has been triggered.

另一個方法是去計算已經到達join的執(zhí)行的數(shù)目。如果該數(shù)目正好與到達轉移的數(shù)目相同，則新創(chuàng)建一個執(zhí)行，定位在join然后通過默認轉移傳播。在這種情況下，當join觸發(fā)之后，該完整的執(zhí)行樹需要為非激活的執(zhí)行修正。

This type of join implementation can handle unstructured combinations of forks and joins. I leave it up to the imagination of the reader to find the differences with the previously explained join behaviour. The most important point is that different types of fork and join behaviours can be implemented on top of the Process Virtual Machine.

該類型的join實現(xiàn)能夠處理fork和join的無結構組合。我留給讀者去發(fā)現(xiàn)其與前面闡述的join行為的差別。最重要的一點是不同類型的fork和join行為可以基于流程虛擬機實現(xiàn)。

Process composition

流程組成

Process composition means that a node in one process can reference another process. When an execution arrives in such a process node, that execution will wait in that node until a complete execution of the referenced process is completed.

流程組成意思是流程的一個節(jié)點可以引用另一個流程。當執(zhí)行到達這樣的流程節(jié)點時，執(zhí)行會在那個節(jié)點等待，直到引用的流程執(zhí)行完成。

Figure 10: Process composition

圖十：流程組成

This can be added to the process virtual machine by leveraging the hierarchical relation of the execution tree that was created for concurrent paths of execution. When an execution arrives in a process node, a child execution can be created for the referenced process like illustrated in Figure 10.

可以將其通過像并行路徑執(zhí)行一樣采用分層關系的執(zhí)行樹的方式增加到流程虛擬機中。當執(zhí)行到達一個流程節(jié)點，如圖10所示為引用的流程創(chuàng)建子執(zhí)行。

A check needs to be added when executions complete. In this case, executions that are completed need to check whether there is a parent execution available. If that is the case, that execution need to be propagated. The parent execution, one that originally arrived in the process node, will then leave that process node and continue over the default transition.

當執(zhí)行完成時需要增加一個檢測。在這種情況下，完成的執(zhí)行需要檢查是否存在父執(zhí)行。如果存在，執(zhí)行需要被傳播。最初到達流程節(jié)點的父執(zhí)行會離開流程節(jié)點，通過默認的轉移繼續(xù)執(zhí)行。

Asynchronous continuations

異步執(zhí)行

Up to now, all propagation of the execution was done synchronously. In some situations that might be problematic. For example suppose a process where a large pdf file has to be generated automatically after a user has completed a task. And most likely, the invocation ofexecution.proceed() will be done in the request-response cycle of the web application for the user. In that case, the web response is unnecessarily delayed with the generation of the pdf because that is done inside of the proceed method invocation. In general, this means that the client that is calling the Execution.proceed will be blocked until the process has reached a new wait state.

到目前為止，執(zhí)行的傳播是同步進行的。在某些場景下市有問題的。例如，假設當用戶完成一個任務后，流程需要自動生成一個大pdf文檔。很有可能的是，execution.proceed（）的調用是用戶在請求-應答模式的web應用下進行的，在這種情況下，web應答將不必要的為pdf的生成而等待，因為pdf生成是在proceed方法調用中完成的。一般地，這意味著調用Execution.proceed的客戶端會阻塞，直到流程到達新的等待狀態(tài)。

The Process Virtual Machine can be extended to handle these situations by using an asynchronous message queue. To see how that works, we first must define what the atomic operations are. Atomic operations cannot be interrupted. Here, we'll define two atomic operations: Executing a node and taking a transition. So execution of a node and of a transition cannot be interrupted. But in between those atomic operations, a thread can decide to stop the interpretation and instruct another thread to continue the interpretation asynchronously from that point forward.

流程虛擬機可以使用異步消息隊列擴展用來處理這些場景。為了明白它如何工作，我們首先必須定義什么是原子操作。原子操作不能中斷。這里，我們會定義兩個原子操作：執(zhí)行一個節(jié)點和獲取一個轉移。因此，執(zhí)行一個節(jié)點和執(zhí)行一個轉移不能中斷。但是在這些原子操作之間，線程可以決定停止解釋，通知另一個線程來從那一點向前繼續(xù)異步解釋。

In the node and transition elements, an extra configuration flag can be added. Let's call it the asynchronous flag. When a node has the asynchronous flag set, it will be executed asynchronously at runtime. Similar for transitions.

在節(jié)點和轉移元素中，可以增加一個額外的配置項。我們可稱它為異步標記。當一個節(jié)點設置了異步標記，它將在運行時異步執(zhí)行。轉移也是一樣的。

Remember that the execution is responsible for interpreting the graph, finding the destination node of a transition and executing the behaviour of that node. Now, when an execution arrives in an asynchronous node, the node will not be executed. But instead, a message is being sent over an asynchronous messaging system. The message contains a reference to the execution and the instruction to execute that node. After that, the Execution.proceed returns and the transaction, that contains both the process updates and the production of the asynchronous message, can be committed.

記住執(zhí)行的職責是解釋圖，找到轉移的目的節(jié)點和執(zhí)行那個節(jié)點的行為。現(xiàn)在，當執(zhí)行到達異步節(jié)點時，該節(jié)點不會執(zhí)行。但是，會通過異步消息系統(tǒng)發(fā)送一個消息。該消息包括執(zhí)行的一個引用和執(zhí)行那個節(jié)點的指示。然后，execution.proceed返回，包含流程更新和異步消息產生的事務可被提交。

At the other end of the queue, there is a component called the job executor. That component will start a new transaction, fetch a message from the queue and perform the instructions in the message. In our scenario, this means that the node will be executed. When that is done, the transaction will be committed. That transaction included consumption of the message and the new process updates.

在這個隊列的另一端，有一個叫job執(zhí)行器的組件。該組件會啟動一個新事務，從隊列中獲取一個消息，按照消息的指示執(zhí)行。在我們的場景中，這意味著會執(zhí)行那個節(jié)點。當這個完成后，事務會被提交。這個事務包括消息消費和新的流程更新。

Figure 11: Asynchronous continuations

圖十一：異步執(zhí)行

This can also be seen as a kind of transaction demarcation. Because by default the interpretation of the graph will continue until a wait state is reached. But with asynchronous continuations, it's possible to mark a position in the process where the current transaction should be committed and a new transaction should be started automatically.

這也可以看做一種事務劃分。因為默認情況下圖的解釋會繼續(xù)進行，直到到達等待狀態(tài)。但是，有了異步執(zhí)行，就可以在流程中標記一個位置，哪里應該提交當前的事務，哪里應該自動啟動一個新事務。

The tradeoff for asynchronous continuations is exception handling versus response times. We already saw in the beginning of this section that response time can be significantly reduced by introducing asynchronous continuations. But on the other hand, the downside can be that the original caller is not aware of any problems that might arise further in the process. For example, a task node is followed by an email notification node and suppose that it is crucial that this notification is sent. When the email notification node is marked as asynchronous, the task completion will be faster, but that user might not get a notification when the mail server is down.

權衡是否采用異步執(zhí)行的原則是異常處理和響應時間。我們已經在本章的開始看到響應時間能夠采用異步執(zhí)行大大的減少。但是從另一方面講，缺點是調用者無法發(fā)現(xiàn)流程中可能發(fā)生的任何問題。例如，一個任務節(jié)點后面有一個email通知節(jié)點，假定這封郵件的發(fā)送非常重要，如果email通知節(jié)點標記為異步，任務完成會非常快，但是如果郵件服務器當?shù)袅耍脩魧o法得到通知。

In case an exception occurs in the job executor, an automatic retry mechanism could be used. Most message queueing systems have a configurable number of retries before the message is sent to the dead letter queue. Administrators could monitor that dead letter queue or a timer could be added to notify the stakeholders of the process execution in case of asynchronous failure.

如果job執(zhí)行器發(fā)生了異常，可使用自動重試的機制。多數(shù)消息隊列系統(tǒng)在消息被送到死信隊列前可配置一定數(shù)量的重試。在異步失敗的情況下，管理員可以監(jiān)控死信隊列或者可以增加一個定時器來通知流程執(zhí)行的涉眾。

Process updates

流程更新

A set of process updates describe modifications to a particular process. For example additions and removals of nodes, transitions or actions.

流程更新描述對特定流程的更改。例如，增加和移除節(jié)點，轉移或動作。

With process updates, the Process Virtual Machine can be extended for two new use cases: Process inheritence and per instance process customizations.

通過流程更新，流程虛擬機可以為兩個新用戶用力擴展：流程繼承和單個實例流程定制。

Suppose a situation where for each country there is a process on how banks must do efforts to detect suspecious stock transactions. And suppose that most that the basic layout of all those processes would be the same. There are only some minor details, that are different. In that case, it might be an option to describe a single default process and then define a kind of process inheritence. A specialized process might be defined as a reference to another process plus a set of updates. Of course, the execution's interpretation algorithm have to be modified to take these process modifications into account.

假定一個場景，每個國家應有個流程用于檢測可疑的股票交易。假定大多數(shù)的流程的設計是相同的，僅有很少的細節(jié)不一樣。在這種情況下，可以選擇描述一個默認的流程，然后定義一種流程繼承。一個特定的流程可能定義為引用一個其他的流程加一些更新。當然，執(zhí)行的解釋算法應考慮相應的流程修改。

The second use case is updates per execution. Suppose that a user wants to monitor all progress for a specific execution. In that case, he could add an action on a process definition for the transition event. That means that the notification action will be executed for each transition that is taken in the whole process.

另一個用戶用例是更新每個執(zhí)行。假定一個用戶想要監(jiān)控一個特定執(zhí)行的所有進展。在這種情形下，他可以在流程定義上為轉移事件增加一個動作。這意味著這個動作會在整個流程的每個轉移獲取時被執(zhí)行。

Another example of updates per execution is removing transitions for a given execution. Suppose that in the process, there is a distinct handling for urgent packets from the handling of normal packets. Now imagine that early in the process, a user can recognizes a client that always tries to get the fast delivery while he's not entitled to it. Then this might be implemented with process updates by letting the user remove the transition for urgent handling.

更新每個執(zhí)行的另一個例子是移除給定執(zhí)行的轉移。假定在流程中，會區(qū)別處理緊急郵包和正常郵包。現(xiàn)在想象在流程的早期，一個用戶能夠認識總是嘗試取得最快的郵遞的客戶，但是他有沒有這樣的權利，這可以通過讓用戶移除用作緊急處理的轉移的流程更新方式來實現(xiàn)。

Figure 12: Process update for a single execution

圖12：為單個執(zhí)行的流程更新

History

歷史

While a process is being executed, history logs can be generated. Those history logs can contain information about when transitions were taken, when nodes are entered and when nodes are completed. Also the process variable updates and tasks can produce logs. Basically, the whole execution of a process can be logged.

One way to add configurability and flexibility is to define a loging service. The execution and the nodes can then generate log objects in the form of Java objects and pass them to the logging service. That way, log filtering and transformations can be applied centrally. Also different forms of storage can be configured in the logging service.

當執(zhí)行流程時，可生成歷史日志。歷史日志可包含信息：轉移何時獲取，何時進入節(jié)點和何時完成節(jié)點，還包括流程變量更新和任務生成日志。基本的，整個流程的執(zhí)行可被記錄。

增加可配置型和靈活性的一種方式是定義一個日志服務。執(zhí)行和解點可以以Java對象的方式生成日志對象，然后傳遞他們到日志服務，用這種方式，日志過濾和轉換可以集中應用。不同形式的存儲也能夠配置在日志服務中。

The most important use case for history logging is explained in more depth in section Business intelligence (BI).

歷史記錄最重要的用戶用例在BI章節(jié)中更深入的解釋了。

If the logs keep complete track of all the updates that are done in a process, the logs can be used to generate compensating transactions. A compensating transaction means that a new transaction will undo the effects of previous transactions. A technique to do this could be to walk through the logs in reverse order and restore the begin state as indicated in the log entries.

如果日志完整的記錄了流程中所有的更新，日志可以被用來生成補償事務。補償事務的意思是一個新事物會用于取消前一個事務的所有效果。一種實現(xiàn)技術可以是反向遍歷日志然后恢復日志實體中指定的開始狀態(tài)。

Persistence

持久化

Up to now, the Process Virtual Machine was explained in terms of objects, without any reference to persistence. This is possible because of Object Relational Mapping (ORM) technologies such asHibernate. ORM can translate between objects and database records. On the Java platform the database is accessed using JDBC. Object relational mappers can also make abstraction of the differences in the SQL dialects of databases.

到目前為止，用對象的方式解釋了流程虛擬機，沒有提及持久化。可以通過對象關系映射技術如hibernate來實現(xiàn)。ORM可以轉換對象和數(shù)據(jù)庫記錄。在Java平臺上，使用JDBC來訪問數(shù)據(jù)庫。對象關系映射也可以用來屏蔽數(shù)據(jù)庫的方言的差異。

The algorithms we have defined for process interpretation never use the database directly. Persistence of processes and executions can therefor be offered as a separate service. That way, process languages that don't need persistence, like e.g. pageflow are not required to use a database.

我們?yōu)榱鞒探忉尪x的算法不會直接使用數(shù)據(jù)庫。流程和執(zhí)行的持久化可以由一個獨立的服務提供。用這種方式，流程語言不需要持久化，比如，pageflow不需要使用數(shù)據(jù)庫。

The data in a workflow database can be split into three main compartiments like illustrated in Figure 13: Static process definition information, runtime execution information and history logs.

工作流數(shù)據(jù)庫中的數(shù)據(jù)可以如圖13所示分為三個主要部分：靜態(tài)流程定義信息，運行時執(zhí)行信息和歷史日志。

Figure 13: The three parts of a workflow database

圖13：工作流數(shù)據(jù)庫的三部分

The object relational mapper will take a complete process object graph and translate that into records in the database. That way, the complete process structure can stored in the database. For example, the node objects in the process object graph will be inserted as records in the nodes table. Since process definition information normally doesn't change, it can be cached in memory. In jBPM's case that is done using the second level cache of Hibernate.

對象關系映射會獲取一個完整的流程對象圖，轉化為數(shù)據(jù)庫記錄。完整的流程結構可以存儲在數(shù)據(jù)庫中。例如，流程對象圖中的節(jié)點對象會作為節(jié)點表的記錄插入。因為流程定義信息一般不會改變，可以將它緩存在內存中。JBPM中是使用了hibernate的二級緩存。

The runtime process execution information is typically updated in every transaction that includes a workflow operation because the execution's node pointer will have moved to a next node. In Figure 14, you can see the scenario of the workflow persistence operations in one transaction.

運行時流程執(zhí)行信息通常在每個事務中更新，包括工作流操作，因為執(zhí)行的節(jié)點指針會移到下一個節(jié)點。在圖14中，你能夠看到工作流在一個事務中的持久化操作的場景。

In this scenario, the starting situation is that an execution was already persisted in the database and now an external client wants to provide an external trigger to resume the process execution. So the execution record in the database has a foreign key column that references the node in the nodes table. To get started, the client needs the id of the execution.

在這個場景中，初始的情形是執(zhí)行已經持久化在數(shù)據(jù)庫中，現(xiàn)在，一個外部客戶端想要提供一個外部的出發(fā)來恢復流程的執(zhí)行。因此數(shù)據(jù)庫中的執(zhí)行記錄有一個引用節(jié)點表中的節(jié)點的外鍵。客戶端需要執(zhí)行的id來啟動。

In the first step, the client start a transaction and loads the execution object using the object relational mapper using the id.

在第一步中，客戶端啟動一個事務，通過使用ORM使用id裝載執(zhí)行對象。

Figure 14: The persistence scenario of a runtime workflow transaction

圖14：運行時工作流事務的持久化場景

In the second step, the client will invoke some methods on the execution object. Typically this will be the proceed-method. In general, methods will be invoked on the runtime data structure. After those method invocations, the execution is pointing to a new node. This second step was executed without any consideration of persistence.

在第二步中，客戶端會調用執(zhí)行對象的一些方法。通常會是proceed方法。通常，運行時數(shù)據(jù)結構的方法會被調用。在這些方法調用之后，執(zhí)行會指向到一個新節(jié)點。這個第二步實在沒有任何考慮持久化的前提下執(zhí)行的。

In the third step, the changes made to the execution object will be saved in the database. It's the task of the object relational mapper at this stage to analyse the execution java object structure and compare it with the data that was originally loaded from the database. The object relational mapper will then issue the nessecary insert, update and delete SQL statements to bring the database in sync with the execution object graph.

在第三步中，執(zhí)行對象的更改會保存到數(shù)據(jù)庫中。分析執(zhí)行java對象結構和對比它與最初從數(shù)據(jù)庫中裝載的對象的數(shù)據(jù)是數(shù)據(jù)關系映射工具的任務。對象關系映射工具然后會執(zhí)行必要的插入，更新和刪除sql語句，使數(shù)據(jù)庫與執(zhí)行對象圖同步。

In the case where an execution just moves to the another node, the result will be a single update statement where only the foreign key column of the execution will have to be changed to the id of the node to which the execution is pointing after the method invocation.

Then, the transaction can be committed.

在執(zhí)行僅僅移動到另一個節(jié)點的情況下，結果會僅僅是單個更新語句更新執(zhí)行表的外鍵列。

Another aspect of object relational mapping solutions that deserves attention in this context is optimistic locking. ORM solutions like Hibernate have a built-in mechanism for optimistic concurrency control. A version column is added to the database and each time an object is updated, the version number will be increased as well. But with each update, in the where clause an extra condition is added that specifies the version of the object that was originally loaded. If execution of that SQL statement returns that zero rows were updated, that transaction knows it was working with stale data and the transaction should be rolled back. For more about this, seethe hibernate reference manual.

在當前上下文中值得注意的對象關系映射方案的另一個方面是樂觀鎖。ORM方案像hibernate有內置的樂觀并發(fā)控制機制。數(shù)據(jù)庫中會增加一個版本列，每次更新對象時，版本數(shù)目會相應的增加。但是對每次更新，一個額外的用來指定初始裝載的對象的版本的條件會增加在where子句中。如果那條sql語句執(zhí)行返回0行，則事務知道他使用了臟數(shù)據(jù)，事務應該回滾。可通過Hibernate參考指南了解更多這方面的知識。

But the result of all this optimistic locking is that process engines based on the Process Virtual Machine can scale by synchronizing on the database, using this light weight concurreny control mechanism. As long a they all are working on the same database and use this optimistic concurrency, all process updates comming from multiple systems will be synchronized.

但是，樂觀鎖的結果是基于流程虛擬機的流程引擎能夠通過同步數(shù)據(jù)庫的方式擴展，使用這種輕量級的并發(fā)控制機制。只要他們都是操作同一個數(shù)據(jù)庫且使用樂觀并發(fā)控制，來自不同系統(tǒng)的所有流程更新會同步。

Timers

定時器

To add timers to the Process Virtual Machine, a timer service is required that can schedule timers to be executed in the future. Timers must have the ability to contain some contextual information and reference the program logic that needs to be executed when the timer expires.

為了給流程虛擬機增加定時器，需要一個定時器服務，它可以調度將來執(zhí)行的定時器。定時器必須有能力獲取一些上下文信息和引用定時器過期時要執(zhí)行的程序邏輯。

Let's look at the typical scenario where a wait state needs to be monitored with a timer. For example, if a user task is not completed within 2 days, notify the manager.

讓我們來看看需要用一個定時器來監(jiān)控的等待狀態(tài)的典型場景。例如，如果用戶任務沒有在兩天內完成，通知經理。

To implement this, the timer service as described above can addressed from actions on the node-enter and node-leave events as indicated in Figure 15. When the node enters, a timer is created with a given due date and it is scheduled with the timer service. Then the node will behave as a wait state until an external trigger is given.

為了實現(xiàn)它，上面描述的定時器服務可以用動作來解決，動作可基于圖15中指定的節(jié)點進入和節(jié)點離開事件。當節(jié)點進入時，使用給定的過期日期創(chuàng)建一個定時器，然后用timer服務來調度它。然后節(jié)點會進入等待狀態(tài)，直到一個外部觸發(fā)發(fā)起。

Figure 15: A node with a timer

圖15：帶一個定時器的節(jié)點

Suppose now that an external trigger is given before the due date of the timer. Then the execution will leave the node and the cancellation action will be executed. This action will cancel the timer that was created upon entering the node.

If on the other hand, the external trigger is not given, the execution will still be positioned in the node when the timer fires. In that case, the programming logic of the timer is executed. In our example that was the notification to the manager.

假定在定時器的過期日期之前，發(fā)起了一個外部觸發(fā)。然后，執(zhí)行會離開節(jié)點，取消動作會被執(zhí)行。這個動作會取消在進入節(jié)點時創(chuàng)建的定時器。

在另一方面，如果沒有外部觸發(fā)，執(zhí)行會仍然指向定時器激活的節(jié)點。在這種情形下，定時器的編程邏輯會被執(zhí)行。在我們的例子中，會通知經理。

Services

服務

In this section about services, we'll discuss an implementation aspect of the Process Virtual Machine that is crucial for embeddabity of the engine inside of the client application.

Whenever the execution or the node behaviour implementation needs some kind of service, always consider using a self made interface. Examples of such services are the asynchronous message service and the timer service as discussed above. That way, different implementations can be provided in different environments. For example, in a Java enterprise environment, the asynchronous message service will probably need to be tied to JMS. Whereas in a standard environment this might be done using an in-memory queue.

在關于服務的這一章中，我們會討論流程虛擬機的實現(xiàn)方面，這對將引擎嵌入到客戶應用中非常重要。

每當執(zhí)行或節(jié)點的行為實現(xiàn)需要某些服務時，通常考慮使用自定義的接口。這種服務的一個例子是異步消息服務和上面討論的定時器服務。基于這樣，在不同的環(huán)境中可以提供不同的實現(xiàn)。例如，在Java企業(yè)環(huán)境中，異步消息服務會可能是JMS。如果是在標準環(huán)境中，這可能會使用內存中的隊列。

A simple way to make all external services available to the execution and all the node behaviour implementations is to add a context property to the execution. The context can manage a set of named services and objects. The client knows in which environment it is running, so it constructs the context object and injects it in the execution before a method is invoked on it.

使所有外部服務對執(zhí)行和所有節(jié)點行為實現(xiàn)可用的一個簡單辦法是為執(zhí)行增加一個上下文屬性。上下文可管理一組命名服務和對象。客戶端知道它們在哪種環(huán)境中運行，因此它構造上下文對象，在調用執(zhí)行的方法前將它注入到執(zhí)行中。

This mechanism can be given an extra dimension when an Inversion of Control (IoC) container is used for the context. In that case, transactional services can be lazy created on demand during execution of a process. The typical XML based configuration files of the IoC containers can be leveraged to specify which implementations for the services need to be used.

當為上下文使用了控制反轉容器，這種機制可以給定一個額外的方面。在這種情形下，事務服務可以在流程執(zhí)行時惰性創(chuàng)建。典型的基于XML的IOC容器配置文件能夠用來指定使用服務的哪種實現(xiàn)。

Features

特性

In this section we explain the essential features of process languages and how they relate to the Process Virtual Machine. Where the PVM basics and extensions explains a strategy on implementing a common foundation for process engines, this section describes more the essential features of BPM Systems and how the Process Virtual Machine relates to those features.

本章中我們會解釋流程語言的基本特性和它們如何與流程虛擬機聯(lián)系起來。前述流程虛擬機的基本和擴展章節(jié)闡述了實現(xiàn)流程引擎的公共基礎的策略，本章會介紹更多的BPM系統(tǒng)基本特性和如何使流程虛擬機關聯(lián)到這些特性。

Process modeling

流程建模

First we need to distinct between two categories of processes: descriptive process models and executable processes.

The purpose of descriptive process models is to describe business processes to other people. They support various kinds of notations like BPMN, Event-driven Process Chains (EPC) or UML acitivty diagrams. The main goal of these languages is to define precise semantics of the notational elements, resulting in an expressive graphical language. The modeller can use the graphical constructs in great freedom for the purpose of communicating the process to the reader. Apart from the expressive notation, they may also provide value in managing large sets of interrelated diagrams and models. These processes are not executable on a runtime environment.

我們首先要區(qū)分兩類流程：描述性流程模型和可執(zhí)行的流程模型。

描述性流程模型的目的是向其他人員描述業(yè)務流程。存在許多種類的圖元支持它，像BPMN，事件驅動的流程鏈（EPC）或UML活動圖。這些語言的主要目的是定義圖元的準確語義，產生一個用于表示的圖形化語言。建模人員可以自主使用這些圖形構造來達到將流程傳達給讀者的目的。除了表示符號，可能也會在管理大量的相關聯(lián)的圖和模型方面提供價值。這些流程不能在運行環(huán)境執(zhí)行。

The second catogory aims to make process models executable on a runtime environment aka process engine. In this case, executable process models are in fact software artifacts that specify the behaviour of a computer system. In that respect executable processes are exactly the same as a programs in a Object Oriented (OO) programming language like e.g. Java, even while the format and language are completely different. So in this case, the executable process as a whole is not so free any more. Because it has to specify a particular desired behaviour of a software system.

第二類關注于使流程模型在運行環(huán)境如流程引擎可執(zhí)行。在這種情形下，可執(zhí)行的流程模型指定了計算機系統(tǒng)的行為，是事實上的軟件器件。在這些方面，可執(zhí)行的流程與面向對象語言如Java中的程序完全一樣，即使格式和語言完全不同。因此在此情形下，可執(zhí)行的流程作為一個整體不再如此隨意（指相對描述性流程而言），因為它需要指定軟件系統(tǒng)的特定目標行為。

The Process Virtual Machine defines a model for the implementation of process engines. As for any process that is executable on a process engine, processes for the Process Virtual Machine are a combination of a graphical process elements and related technical details. So the graphical diagram of an executional process can be seen as a kind of projection that excludes those technical details.

The big value of this combination is that the process diagram can serve as a common language between all stakeholders of a process, regardless of their technical skills. This is shown in Figure 16.

流程虛擬機定義了流程引擎實現(xiàn)的模型。任何在流程引擎中可執(zhí)行的流程都是由圖形化的流程元素和相關的技術細節(jié)組成的。因此，可執(zhí)行的流程的流程圖可被看作一種不包括技術細節(jié)的投影。

這種組合的巨大價值是流程圖可以作為面向流程的所有涉眾的公共語言，而不需要關心他們的技術能力。如圖16所示：

Figure 16: Technical details of a process

圖16：流程的技術細節(jié)

Business analyst have vary different technical skills. Some have none. Some have a little bit of technical skills from a previous life as a developer and other people might actually combine the roles of developer and business analyst. This translates into Figure 16 as the dotted line that can shift up or down.

業(yè)務專家有完全不同的技術能力。一些沒有，一些從事過開發(fā)者職業(yè)的會有一些技術能力，其它的可能同時承擔開發(fā)者和業(yè)務專家的角色。圖16中的可上下移動的虛線反映了這一點。

To translate that into the concepts of the Process Virtual Machine, there are three levels of detail.

要轉換那些信息成流程虛擬機的概念，存在三級細節(jié)。

1.       Process structure: These are the nodes and transitions. The graphical structure is the highest level that can always serve as a communication starting point. Even for technical illiterates.

流程結構：節(jié)點和轉移。圖形化結構通常是可作為交流的起點的最高級別。對技術文盲也是一樣。

2.      Node type: In process engines, the node type defines an exact runtime behaviour. In the Process Virtual Machine this is corresponds to the node behaviour implementations. That is the second level of detail. This typically also corresponds to the process constructs available in the pallette of the graphical editor. For example, a task node, a decision a web service invocation node and so on.

節(jié)點類型：在流程引擎中，節(jié)點類型定義了額外的運行時行為。在流程虛擬機中有對應的節(jié)點行為實現(xiàn)。這是二級細節(jié)。這通常也對應到圖形化編輯器的控件面板中的流程構件。例如，一個任務節(jié)點，一個決策，web服務調用節(jié)點等等。

3.      Configurations: The finest level of detail is the configurations that customize the process construct for a particular use of the node type. In terms of the Process Virtual Machine, this corresponds to the member field values that are injected into the Executable behaviour implementation objects. In graphical editors, usually a form pops up when selecting a node in the diagram to enter those configuration details. Examples of configurations are the URL for a web service invocation, the role or swimlane for a task assignment, the condition for a decision and so on.

配置：配置是最后級別的細節(jié)，它定制流程構件的節(jié)點類型的特定用法。從流程虛擬機的方面來講，這對應到注入到Executable行為實現(xiàn)對象的成員變量值。在圖形化編輯器中，通常在圖中選擇一個節(jié)點時會彈出一個窗口來輸入這些配置。例如調用的web服務的URL，用于任務分派的泳道的角色，決策節(jié)點的條件等等。

On top of these three traditional levels, the Process Virtual Machine has two features that we want to highlight that still give a great deal of modelling freedom to the business analyst, even for executable business processes.

First of all, if the desired behaviour of a node in a process doesn't match with any of the available process constructs in a process language, a developer is always free do write program logic to implement custom behaviour in the nodes. Secondly, in case the developer needs to add a piece of programming logic to make the process executable and this is of no interest to the business analyst, an action can be used to inject this piece program logic without a change in the graphical representation of the diagram. This provides an extra level of separation between the graphical representation and the technical execution details, keeping as much modelling freedom for the business analyst.

在這經典的三級之上，流程虛擬機有兩個特性，我們要特別指出業(yè)務專家仍然有很大的自由來建模，對可執(zhí)行的業(yè)務流程也是一樣的。

首先，如果流程節(jié)點的預期行為不匹配流程語言中的任何流程構造，開發(fā)者通常會有編寫程序邏輯來定制節(jié)點的行為的自由。其次，當開發(fā)者需要增加程序邏輯來讓流程可執(zhí)行，業(yè)務專家對這些沒有興趣，可以使用動作來注入這些編程邏輯而不需要改變圖的圖形化展現(xiàn)。這樣分離了圖形化展現(xiàn)和執(zhí)行技術細節(jié)，讓模型對業(yè)務專家更自由。

Business Intelligence (BI)

商業(yè)智能（BI）

Business intelligence is about extracting information from the history of process executions that is useful for business people. As described above in History, a lot of information can be captured from process executions. Each time an external trigger is given or when a transition is taken, this can be logged in the history database.

商業(yè)智能是從流程執(zhí)行歷史中提取對業(yè)務人員有用的信息。按照前面歷史章節(jié)中描述的，可以從流程執(zhí)行中捕獲許多信息。每次給定一個外部出發(fā)或當轉移發(fā)生時，可以記錄在歷史數(shù)據(jù)庫中。

Now the nice thing is that from those history logs, meaningful business level information can be captured. For example, "How long does each step in the process take on average?" or "What percentage of priority claims are handled within two weeks?" It is not a coincidence that these meaningful questions can be easily answered by the workflow engine's history logs because the graphical diagram was built in collaboration with business people.

There are many ways on how that historic information can be logged and processed. While outside of the scope of the Process Virtual Machine, we still want to highlight the typical processing and usage of historic infomration. Often process engines log every event in a kind of flat list style during runtime. Then, at some point (e.g. when the process execution finishes) the flat list of logs is processed and transformed in a separate database schema that is optimized for querying.

現(xiàn)在比較好的事情是可從歷史日志中捕獲有意義的業(yè)務信息。例如，“流程中的每一步平均花了多長時間？”或“有多少百分比的高優(yōu)先級的報銷單被處理了？”因為流程的圖形圖是業(yè)務人員協(xié)力完成的，因此工作流引擎的歷史日志能夠回答這些有意義的問題不是一個巧合。

有許多方法來記錄和處理這些有重要的信息。盡管這不是流程虛擬機的范疇，我們仍然想要特別指出這些重要信息的典型的處理和使用。通常，流程引擎在運行時以一種平面列表格式來記錄每一個事件，然后，在某一時刻（例如：當流程執(zhí)行完成），這些平面列表記錄會被處理和轉換到一個獨立的數(shù)據(jù)庫中，使其更易于被查詢。

Workflow engines usually record these history logs by default. Many statistics typically come out of the box and it is very easy to define new meaningfull queries on this business intelligence database. While with old fashion plain programming, this will take a lot more time and make the overall project more complex. So when in doubt about using a workflow process or plain programming, consider wether this kind of information is important for your application.

工作流引擎通常默認會記錄這些歷史日志。許多統(tǒng)計數(shù)據(jù)通常會因此產生出來，也能夠很容易的基于商業(yè)智能數(shù)據(jù)庫定義新的有意義的查詢。如果采用舊的plain編程，這將導致花費許多時間和讓整個項目更加復雜。因此，當有使用工作流或還是使用plain編程的疑問時，要考慮這些信息是否對你的應用很重要。

Task management

任務管理

Task management means that all people know exactly what they should do and when no tasks are done twice. Therefor, the right information needs to be provided to the right people at the right time. The benefits of proper task management are outside the scope of this paper. The goal of this section is to give you an idea of what task management is and how it relates to the Process Virtual Machine.

A task management component maintains a set of tasks. Task management features include direct (push) and group (pull) assignment, task forms, reassignments, notifications, and so on. The task list for a given user is typically made available through a web application and an API. The combination of task notifications and the related preferences that can be customized by users is also known as 'user awareness'.

任務管理意思是所有的人都清楚的知道他們應該做什么，不應該有任務被做兩次。因此，正確的信息需要在正確的時間提供給正確的人。從適當?shù)娜蝿展芾碇惺芤娌皇潜緯姆懂牐菊碌哪康氖歉嬖V你什么是任務管理，他如何與流程虛擬機關聯(lián)。

任務管理組件維護一個任務集合。任務管理特性包含直接（推）和集體（拉）安排，任務表單，再分配，通知等等。指定用戶的任務列表通常通過web應用和API來可用。任務通知和相關屬性的結合可由用戶定制，也可以稱作“用戶知會”。

Now, we'll zoom in to the relation between the Process Virtual Machine and a task management component. A process contains a mix of tasks for people and automatic activities. Looking from the perspective of the workflow engine, a user task represent a wait state. As we already described above, support for wait states is exactly one of the most important features of the Process Virtual Machine and workflow in general. So that is why process technologies and task management go hand in hand.

The most common scenario is when a node in the process corresponds to a single user task. In that case, a task node behaviour can be implemented as follows. When an Execution arrives in a task node, it can add task entry to the task management component. Then, the execution should wait in the task node. The new task will now appear in the assigned user's task list. As an integration between the workflow engine and the task management component, the task must keep a reference to the execution.

現(xiàn)在，我們深入流程虛擬機和任務管理組件的關系。一個流程包含給人員的一組任務和自動活動。從流程引擎的方面來看，用戶任務表示等待狀態(tài)。像我們前面已經說過了的，支持等待狀態(tài)通常是流程虛擬機或工作流的非常重要的特性。這是為什么流程技術和任務管理通常是一起的。

非常普遍的場景是當流程中的一個節(jié)點對應到單個用戶任務時，任務節(jié)點行為可以像下面所說的方式來實現(xiàn)。當Execution到達任務節(jié)點，它可以增加任務條目至任務管理組件。然后，Execution應該在任務節(jié)點等待。新創(chuàng)建的任務會出現(xiàn)在安排的用戶的任務列表中。因為工作流引擎和任務管理組件的集成，任務需要保持一個到execution的引用。

After some time, the assigned user might select that task from the task list and complete it with the user interface or te API. When a task with a related execution is completed, the task management component is responsible to invoke the execution's proceed. So completing the task triggers the execution to resume its execution.

Notifications can be built on top of Process Virtual Machine events with actions. Tasks can propagate their events like e.g. assign, duedate expired or completed to the execution. Once that integration is in place, listeners to those events can be specified as actions in the process definition or dynamically added to the execution at runtime. The dynamic subscription to task events is a crucial feature for user awareness.

一段時間后，分配的用戶會從任務列表中選擇那個任務，通過用戶界面或API來完成它。當一個包含相關的執(zhí)行的任務完成后，任務管理組件需要負責調用execution的proceed方法。因此，任務的完成會觸發(fā)execution恢復執(zhí)行。

通知可以基于流程虛擬機的事件和動作來構建。任務可以傳播它們的事件如分配，超時或完成到execution。如果做了這種集成，這些事件的監(jiān)聽器可以在流程定義中作為動作配置或者運行時動態(tài)增加到execution。任務事件的動態(tài)訂閱是用戶需要知道的重要特性。

This concludes the basic integration between task management and process execution. The many variations to this theme, like e.g. dynamic task creation, swimlanes and others can be handled by the pvm but they don't really contribute to the purpose of this article.

這章論述了任務管理和流程執(zhí)行的基本集成。這個主題的許多變化如動態(tài)任務創(chuàng)建，泳道和其它能夠被pvm處理，但是這些與本文的目的無關。

Cooperative applications and Human Interaction Management (HIM)

應用協(xié)同和人工交互管理（HIM）

From a workflow perspective, an expense notes process is completely different from building a new leasure palm-tree resort with those nice red coctails and waitresses in miniscule biki... Anyway, the difference that we want to highlight is that an expense note process is completely known and all possible scenarios can be modelled upfront. Whereas for a leasure resort, there will be no fixed process at the start. That kind of processes will be defined on the fly. The category of software systems that support those kind of ad hoc processes is called cooperative applications or Human Interaction Management (HIM).

從工作流的方面來看，一個費用記錄流程與構建一個旅游勝地完全不同…不管如何，我們要指出的不同點是費用記錄流程的所有可能場景都完全了解，能夠提前建模。而在開始構建旅游勝地前，可能不會有固定的流程。這種流程會即時定義。這一類支持那種類型的特別流程的軟件系統(tǒng)被叫做應用協(xié)同或人工交互管理。

The Process Virtual Machine as described above suggests that all processes are as predictable as submitting an expense note. That is because a distinction is made between the process model --with Node's and Transitions-- on the one hand and the runtime execution structure --with theExecution-- on the other hand. Let's call this the static approach, reflecting the static process definition.

As a side note, the more frequent a process is executed, the more predictible all the scenarios will be and the more compelling it will be to automate that process. So that is why we took the approach with a single static definitions having many executions as the default one.

前面描述的流程虛擬機提倡所有的流程都應該像費用記錄流程一樣清晰，因為流程模型—包含節(jié)點和轉移—不同于另一方面的運行時執(zhí)行結構—包含Execution—在另一方面。讓我們叫它做靜態(tài)方法，反映靜態(tài)的流程定義。

作為一個邊注，流程執(zhí)行的越頻繁，所有的場景越能被預測，流程會越可能被自動化。這是為什么我們采取一個靜態(tài)定義有多個執(zhí)行的方法的原因。

Cooperative processes can also be implemented easily on top of the process virtual machine. An execution is created before any process nodes and transitions are defined. Then typically people, roles and task nodes are created on the fly while the process is executing. So each process execution will create its own process model, whereas in the static approach the single static process model will be used for many executions.

協(xié)作流程可以基于流程虛擬機容易的實現(xiàn)。在任意流程節(jié)點和轉移定義之前創(chuàng)建一個執(zhí)行，然后，在流程執(zhí)行時，即時創(chuàng)建典型的人，角色和任務節(jié)點。因此每個流程執(zhí)行會創(chuàng)建它自己的流程模型，但是在靜態(tài)方法中，單個靜態(tài)流程模型會被許多執(zhí)行使用。

From an implementation perspective, storing, updating and removing parts of the process model is done similarly as with executional data. The only issue to keep in mind is that process definition caching needs to be turned off in such use cases.

The nice thing is that with the Process Virtual Machine its possible to build processes that mix the static and the cooperative approach. As explained in "Process updates", a basic fixed model can be defined and updates to that model can be associated to the Execution.

從實現(xiàn)方面來說，存儲，更新和刪除流程模型的部分與執(zhí)行數(shù)據(jù)的更新類似。唯一的問題是要記住在這種情形下，流程定義緩存需要關閉。

一個好的事情是可以基于流程虛擬機構建混合了靜態(tài)和協(xié)作方法的流程，像在流程更新中解釋的，一個基本的固定的模型可以被定義，對模型的更新可以關聯(lián)到Execution。

Asynchronous architectures

異步架構

Asycnrhonous architectures are another environment where workflow technology can be very useful. In such architectures, multiple machines or components communicate through queues or other forms of asynchronous messaging.

If you look at one component in such an architecture, it will receive many messages (or service invocations) that are related to one overall execution flow. That overall execution flow can be modelled and implemented as an executable process. The period between the response sent by the component and the next related message that is expected by the component translates to a wait state in the process.

This principle applies to various environments. For example a web services environment like e.g. an Enterprise Service Bus (ESB). In that case BPEL is the most appropriate language. In essence, with BPEL, new web services can be scripted as a function of other web services. But other languages like e.g. jPDL can be very convenient to orchestrate a set of Message Driven Beans (MDB) in a Java enterprise environment.

異步架構是工作流技術非常有用的另一個場景。在這種架構下，多個機器或組件通過隊列或其他形式的一步消息交互。

如果你看看在這種架構中的一個組件，在整個執(zhí)行流中，它會收到許多相關的消息（或服務調用）。這個執(zhí)行流可以用執(zhí)行流程建模和實現(xiàn)。組件發(fā)送應答到組件期望收到下一個相關的消息的間隔可轉換為流程的等待狀態(tài)。

這一原則適用于多種環(huán)境。例如，web服務環(huán)境如ESB。在這種場景下，BPEL是最合適的語言。本質上，使用bpel，新web服務能夠給予其它web服務的功能實現(xiàn)。但是其他語言如JPDL能夠非常方便的用于在java企業(yè)環(huán)境下編排一組消息驅動bean。

Process languages

This section describes the process languages for which we have proven that they can be build on top of the Process Virtual Machine.

BPEL

BPEL is a standardized service orchestration language. If you can excuse us for the overly simplified statement, we describe BPEL as an executable language to script web services as a function of other web services.

BPEL is a language that fits right on top of an Enterprise Service Bus (ESB), which is a piece of integration infrastructure. Because an ESB targets integration, services are typically described in WSDL and based on XML technologies. That is where BPEL fits with ESB's. BPEL is also based on WSDL and XML technologies.

XPDL

XPDL is a standardized BPM process language. The background of BPM Systems (BPMS) and hence of XPDL is very different from BPEL. XPDL processes describe a combination of user tasks and automated activities. All references to resources, automatic activities and applications are adressed indirectly, meaning there is no implicit assumption of a technological environment such as enterprise Java or an ESB.

XPDL 2.0 defines a complete mapping with BPMN. BPMN standardizes a graphical notation that defines the shapes, icons and decorations of process models.

jPDL

jPDL is a process language of the JBoss jBPM platform. This language is in essense the simplest wrapper around the Process Virtual Machine, to make it available in a Java environment. jPDL processes can reference Plain Old Java Objects (POJO) directly. The process variables and API's are based on standard Java too.

SEAM pageflow

This is a language that describes the navigation between web pages of a SEAM application graphically. Nodes in the diagram represent pages and transitions represent the navigation between the pages.

The nice thing about the SEAM pageflow language is that it really shows the diversity of languages that can be built on top of the Process Virtual Machine. For instance, pageflow doesn't need persistence nor transaction while pageflow executions need to be serialized in the HTTP session.

Conclusion

First of all, this paper has outlined the essential principles of workflow, BPM and orchestration. This is already very crucial knowledge for understanding today's workflow and BPM systems. But the bigger goals of this article is to facilitate a big step forward in resolving the current fragmentation and confusion around workflow technologies. Both developers and workflow tool vendors will benefit significantly from a unified model for workflow.

Secondly, a component model was introduced that shows how a base framework can be build in a programming language that allows for multiple process languages to be developed on top. This served as a clear illustration for developers to indicate what exactly a workflow engine does and when this technology is appropriate. The bigger goal of this component model is also targetted at workflow tool vendors. Both jBPM in collaboration with Bonita and Orchestra, and Microsoft independently developed a very similar component model. We believe that engines based on this component model will be much more broadly applicable because of their support for multiple process languages in multiple environments, whereas most of the current workflow systems only cover a very small niche of use cases.

As a third item, a realistic and practical approach is detailed that acknowledges and copes with the dual nature of Business Process Management (BPM). Non technically skilled business people are focussed on the graphical diagram. But we have shown that an executable business process always has a graphical and a technical part. The graphical diagram serves as the common language between the business analyst and the developer.

References

·         JBoss jBPM

·         Bonita The XPDL workflow engine by Bull hosted at OW2

·         jPDL The workflow for Java process language of JBoss jBPM

·         JBoss SEAM Pageflow The process language build on jBPM for specifying navigation between web pages

·         Orchestra The BPEL engine from Bull hosted at OW2

·         JBoss jBPM BPELThe BPEL engine from JBoss build on top of jBPM

·         Windows Workflow Foundation

·         XPDL The workflow language defined by the WfMC and supported by Bonita

·         BPELThe service orchestration language defined by OASIS

·         (TODO) The reference to the summary article at OnJava

About the authors

Tom Baeyens

Tom Baeyens is the founder and lead developer of JBoss jBPM, the open source platform for workflow, BPM and orchestration engines. His mission is to bring the value of BPM technology to the developer community. Tom is frequent speaker on this subject at international conferences working for Red Hat. He's also participating in the Java Community Process. Tom blog is calledProcess Developments and can be found at http://processdevelopments.blogspot.com/.

Miguel Valdes Faura

Miguel Valdes Faura is the Workflow Project Manager working for Bull R&D. He is also member of the OW2 Technical Council in which he is leading the Bonita workflow project. Before that he has worked in Spain in different European projects based on J2EE platform and Open Source application servers. He joined INRIA, the French Research Institute in Computer Sciences, on February 2001 co-founding the Bonita Workflow System. He is a regular speaker at international conferences : JavaOne, Internet Global Congress, Open Source World Conference, javaHispano Conference, ObjectWebCon, COSGov, JavaBin...