這是Jboss 的jBPM3.12框架的用戶指南的中文翻譯。我的翻譯風格是中英文對照，只翻譯部分我認為重要的，不翻譯簡單的英文，以免浪費你我的時間。 同時，對于其中的部分內容，我會在翻譯中做出解釋和寫上我的理解。
Chapter 4. Graph Oriented Programming面向圖表編程
4.1. Introduction介紹
This chapter can be considered the manifest for JBoss jBPM. It gives a complete overview of the vision and ideas behind current strategy and future directions of the JBoss jBPM project. This vision significantly differs from the traditional approach.
本章給出一個完全的現在的Jboss jBPM策略和未來的方向。
First of all, we believe in multiple process languages. There are different environments and different purposes that require a their own specific process language.
首先，有多種處理語言，它們應用于不同的環境和目的，需要特殊的處理語言。
Secondly, Graph Oriented Programming is a new implementation technique that serves as a basis for all graph based process languages.
第二，面向圖表編程是一個新的服務于基于圖表的業務處理語言的實現技術。
The main benefit of our approach is that it defines one base technology for all types of process languages.
Current software development relies more and more on domain specific languages. A typical Java developer will use quite a few domain specific languages. The XML-files in a project that are input for various frameworks can be considered domain specific languages.
現在的軟件開發依賴于越來越多的特定領域語言。一個典型的java開發者將使用相當多的DSL。Xml文件被許多DSL語言所使用。
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]-->
<!--[endif]-->
Figure 4.1. Positioning of graph based languages
配置基于圖表的語言
Domain specific languages for workflow, BPM, orchestration and pageflow are based on the execution of a directed graph. Others like hibernate mapping files, ioc-configuration are not. Graph Oriented Programming is the foundation for all domain specific languages that are based on executing a graph.
工作流、業務處理管理、管弦樂作曲法、頁面流的DSL是基于直接的圖表執行的。
面向圖表編程是所有基于圖表執行的DSL的基礎。
Graph Oriented Programming is a very simple technique that describes how graphs can be defined and executed on a plain OO programming language.
In Section 4.5, “Application domains”, we'll cover the most often used process languages that can be implemented using Graph Oriented Programming like workflow, BPM, orchestration管弦樂作曲法 and pageflow.
4.1.1. Domain specific languages
特定領域語言
Each process language can be considered a Domain Specific Language (DSL). The DSL perspective gives developers good insight in how process languages are related to plain OO programming. 、
每一個處理語言可以比看作是DSL特定領域語言。DSL讓開發者能夠非常好的使用簡單OO編程來處理。
This section might give the impression that we're focussed solely on programming environments. None is less true. Graph Oriented Programming includes the whole BPM product continuum from API libraries to fully fledged BPM suite products. BPM suite套件 products are complete software development environments that are centered around business processes. In that type of products, coding in programming languages is avoided as much as possible.
BPM業務處理管理套件產品是完整的軟件開發環境。它們是以業務處理為中心的。這類產品中，應該避免用編程語言編碼。而應該使用DSL語言進行配置。
An important aspect of domain specific languages is that each language has a certain grammar. That grammar can be expressed as a domain model. In case of java this is Class, Method, Field, Constructor,... In jPDL this is Node, Transition, Action,... In rules, this is condition, concequence,...
DSL語言的一個重要的方面是，每一個語言應該有一個特定的語法。語法被表示為一個領域模型。例如，Java包括類、方法、字段、構造器等。
jPDL包括：節點、轉向、動作等。
Rules規則語言是：條件，cequence等。
The main idea of DSL is that developers think in those grammars when authoring artifacts for a specific language. The IDE is build around the grammar of a language. Then, there can be different editors to author the artifacts. E.g. a jPDL process has a graphical editor and a XML source view editor. Also there can be different ways to store the same artifact: for jPDL, this could be a process XML file or the serialized object graph of nodes and transition objects. Another (theoretic) example is java: you could use the java class file format on the system. When a user starts the editor, the sources are generated. When a user saves the compiled class is saved....
DSL的主要思想是，開發者用一種特殊的語言創造東西。用這種語言比一般的通用領域語言表達能力更強。一種DSL語言，可以使用多種編輯器編輯。如,jPDL語言可以使用圖形化編輯器或者手工編寫XML源碼來編寫。
Where ten years ago, the biggest part of a developer was spend on writing code. Now a shift has taken place towards learning and using domain specific languages. This trend will still continue and the result is that developers will have a big choice between frameworks and writing software in the host platform. JBoss SEAM is a very big step in that direction.
過去，程序員主要工作是寫Java這樣的通用編程語言的代碼。今天，程序員需要些越來越多的DSL。這種趨勢將會繼續下去。DSL將會占據越來越多的領域，支持DSL的框架將會越來越多。Jboss SEAM和Spring就是其中的代表。
元數據編程，DSL將會進一步發展下去！
Some of those languages are based on execution of a graph. E.g. jPDL for workflow in Java, BPEL for service orchestration, SEAM pageflow,... Graph Oriented Programming is a common foundation for all these type of domain specific languages.
DSL中的一些語言基于圖表來執行。例如，java的工作流語言jPDL，面向服務架構的BPEL，頁面流SEAM等。
面向圖表編程是所有這些 流程 型的DSL共同的基礎。
In the future, for each language, a developer will be able to choose an editor that suites him/her best. E.g. a hard core programmer probably will prefer to edit java in the src file format cause that works really fast. But a less experienced java developer might choose a point and click editor to compose a functionality that will result in a java class. The java source editing will be much more flexible.
在將來，對于每一種語言，可能會有更多的編輯器可供選擇。如，Java橫序員既可以直接編寫源碼，也可以使用圖形化工具來操作，生成Java源碼。如UML等。
Another way of looking at these domain specific languages (including the programming languages) is from the perspective of structuring software. Object Oriented Programming (OOP) adds structure by grouping methods with their data. Aspect Oriented Programming (AOP) adds a way to extract cross cutting concerns. Dependency Injection (DI) and Inversion of Control (IoC) frameworks adds easy wiring of object graphs. Also graph based execution languages (as covered here) can be helpful to tackle complexity by structuring part of your software project around the execution of a graph.
另一個看待那些DSL語言和其他編程語言的角度是，軟件結構的前景。OOP通過把數據和方法組合在一起增加了結構。OOP提取公共方面。DI和IOC（依賴注入和反向控制----它們是一回事）提供了容易的裝配對象的方法。
基于圖表的執行語言有助于解決你的軟件在執行圖表方面的部分結構的復雜性問題。
An intial explanation on Domain Specific Languages (DSL) can be found on Martin Fowler's bliki. But the vision behind it is better elaborated in Martin's article about 'Language Workbenches'.
4.1.2. Features of graph based languages
基于圖表語言的特性
There are numerous graph based process languages. There are big differences in the environment and focus. For instance, BPEL is intended as an XML based service orchestation component on top of an Enterprise Service Bus (ESB) architecture. And a pageflow process language might define how the pages of a webapplication can be navigated. These are two completely different environments.
有眾多的基于圖表的處理語言。它們的使用環境和目標有著巨大的差異。路例如，BPEL是一個基于XML格式的服務組件，是ESB（企業服務總線）架構的頂層。
一個頁面流處理語言可能定義Web應用程序的頁面之間如何導航。這是兩個完全不同的領域。
Despite all these differences, there are two features that you'll find in almost every process language: support for wait states and a graphical represenation. This is no coincidence because it's exactly those two features that are not sufficiently supported in plain Object Oriented (OO) programming languages like Java.
不管它們有多大的不同，你可以發現幾乎所有處理語言有2個特性是一樣的：
1，支持等待狀態
2，圖形化表示；
在OO編程語言中不是十分支持這2個特性。
Graph Oriented Programming is a technique to implement these two features in an OO programming language. The dependency of Graph Oriented Programming on OO programming implies that all concrete process languages, implemented on top of Graph Oriented Programming, will have to be developed in OOP. But this does not mean that the process languages themselves expose any of this OOP nature. E.g. BPEL doesn't have any relation to OO programming and it can be implemented on top of Graph Oriented Programming.
基于圖表編程是一個在OO編程語言中實現這2個特性的技術。所有面向圖表編程的功能都依賴于OO語言去開發。但這并不意味著處理語言暴露底層OO的實現。
例如，BPEL不關聯任何OO編程語言，它能被面向圖表編程所實現。
4.1.2.1. Support for wait states支持等待狀態
An imperative programming language like Java are used to express a sequence of instructions to be executed by one system. There is no wait instruction. An imperative language is perfect for describing e.g. one request response cycle in a server. The system is continuously executing the sequence of instructions till the request is handled and the response is complete.
Java等命令式語言會飛快地執行序列化的指令，沒有等待指令。（實際有，可以讓線程等待）
But one such request is typically part of a bigger scenario. E.g. a client submits a purchase order, this purchase order is to be validated by a purchase order manager. After approval, the information must be entered in the ERP system. Many requests to the server are part of the same bigger scenario.
但那樣一個請求是一個更大的情節中的一部分。例如，一個客戶端提交一份購買訂單。一個訂單管理者確認訂單有效，然后信息進入ERP系統。
So process languages are languages to describe the bigger scenario. A very important distinction we must make here is scenarios that are executable on one system (or chestration) and scenarios that describe the protocol between multiple systems (choreography). The Graph Oriented Programming implementation technique is only targets process languages that are executable on one machine (or chestration).
所以程序語言是描述更大場景的語言。一個非常重要的區別是，一個系統內部的執行和多個系統的協議。
面向圖表語言的實現技術僅僅用于在一臺機器上執行的程序語言。
So an orchestration process describes the overall scenario in terms of one system. For example: A process is started when a client submits an order. The next step in the process is the order manager's approval. So the system must add an entry in the task list of the order manager and the wait till the order manager provides the required input. When the input is received, the process continues execution. Now a message is sent to the ERP system and again this system will wait until the response comes back.
所以，一個管弦樂程序描述一個系統的整個期間的情節。例如：一個程序開始于一個客戶端提交訂單。程序中的下一步是訂單管理員承認。所以，系統必須在訂單經理的任務列表上增加一個任務，等待訂單管理者提供需要的輸入。當輸入收到以后，程序繼續執行。現在，一個消息被發送到ERP系統中，系統將再一次等待知道ERP系統的響應返回。此時，任務結束。
So to describe the overall scenario for one system, we need a mechanism to cope with wait states.
所以，對于描述一個系統的整個場景，我們需要一個機制來處理等待狀態。----應該就是把工作定義的實例保存到數據庫中。
In most of the application domains, the execution must be persisted during the wait states. That is why blocking threads is not sufficient. Clever Java programmers might think about the Object.wait() and Object.notify(); methods. Those could be used to simulate wait states but the problem is that threads are not persistable.
在多數程序中，等待狀態應該被持久化。所以線程不能充分支持等待狀態。
Continuations is a technique to make the thread (and the context variables) persistable. This could be a sufficient to solve the wait state problem. But as we will discuss in the next section, also a graphical representation is important for many of the application domains. And continuations is a technique that is based on imperative programming, so it's unsuitable for the graphical representation.
Continuations續集 是一種持久化線程（和線程上下文變量）的技術。雖然它也能夠支持等待狀態，但是，基于命令式編程語言的“Continuations續集”不適合圖形化表示。
So an important aspect of the support for wait states is that executions need to be persistable. Different application domains might have different requirements for persisting such an execution. For most workflow, BPM and orchestration applications, the execution needs to be persisted in a relational database. Typically, a state transition in the process execution will correspond with one transaction in the database.
所以，最好的支持等待狀態的技術，是把程序執行保存起來。不同的應用程序領域對于持久化程序執行有不同的需求。對于大多數工作流、BPM(業務程序管理)和管弦樂應用程序，程序執行應該被保存在一個關系型數據庫中。典型的，在業務程序中的一個狀態轉換應用使用數據庫的一個事務。
4.1.2.2. Graphical representation圖形表示
Some aspects of software development can benefit very well from a graph based approach. Business Process Management is one of the most obvious application domains of graph based languages. In that example, the communication between a business analyst and the developer is improved using the graph based diagram of the business process as the common language. See also Section 4.5.1, “Business Process Management (BPM)”.
一些方面的軟件開發能夠非常好的借助于基于圖表的表示方法。業務程序管理BPM是最明顯的基于圖表的的語言的應用程序之一。
例如，在軟件開發者和業務分析師之間，使用基于圖表的圖來表示業務程序進行交流。因為，業務程序分析師作為領域專家，并不會使用編程語言。使用基于圖表的DSL特定領域語言便于開發者和業務程序分析師之間的交流。
Another aspect that can benefit from a graphical representation is pageflow. In this case, the pages, navigation and action commands are shown and linked together in the graphical representation.
另一個能夠從圖形表示中獲益的是頁面流。例如，頁面的導航和動作命令使用圖形化表示的方法顯示和鏈接。-----Struts的配置似乎就是一種頁面流。
In Graph Oriented Programming we target graph diagrams that represent some form of execution. That is a clear differentiation with for instance UML class diagrams, which represent a static model of the OO data structure.
在面向圖表編程中，我們的目標是使用圖表來代表一些格式的業務程序的執行。這是面向圖表編程語言和UML類圖等的一個面線的區別。UML類圖代表的是OO數據結構的一個靜態的模型。
面向圖表編程，表示的是一系列的業務程序、步驟。類似于UML的活動圖。
參考：
1，UML狀態圖：
狀態圖
在計算機系統中，當系統和用戶（也可能是其他系統）交互的時候，組成系統的對象為了適應交互要經歷必要的變化。一種表征系統變化的方法可以說是對想改變了 自己的狀態以相應事件和時間的流逝。UML 狀態圖就是展示這種變化的工具，它描述了一個對象所處的可能狀態及狀態間的轉移，并給出了狀態變化序列的起點和終點。要注意，狀態圖與以上提到的類圖、對 象圖和用例圖有著本質的不同。前3種圖能夠對一個系統或至少一組類、對象或用例建立模型，而狀態圖只是對單個對象建立模型。
另外，狀態圖和序列圖也不同。序列圖關注的是多個對象的狀態，以及它們之間的交互。而狀態圖和活動圖表示的是一個對象的狀態。
狀態圖描述一段時間內對象所處的狀態和狀態的變化。狀態的UML圖標是一個圓角矩形，狀態轉移用狀態之間的有向連線表示。
2，UML活動圖：
UML活動圖是狀態圖的一種擴展形式，它展示出對象執行某種行為時或者在業務過程中所要精力的步驟和判定點。每個步驟（活動）用一個圓角矩形（比狀態圖更 扁更圓）表示，菱形圖標代表判定點。它很像程序設計課中學到的流程圖。UML活動圖可用于表達一個對象的操作和一個業務過程。活動圖與狀態圖的主要區別 是，狀態圖圖出顯示的是狀態，而活動圖突出顯示的是活動。
Also the graphical representation can be seen as a missing feature in OO programming. There is no sensible way in which the execution of an OO program can be represented graphically. So there is no direct relation between an OO program and the graphical view.
圖形化表示也可以被看作是OO編程的一個缺失的特性。OO編程中沒有一個方法能夠使用圖形化表示。所以在OO編程和圖形視圖之間沒有直接的關聯。
In Graph Oriented Programming, the description of the graph is central and it is a real software artifact like e.g. an XML file that describes the process graph. Since the graphical view is an intrinsic part of the software, it is always in sync. There is no need for a manual translation from the graphical requirements into a software design. The software is structured around the graph.
在面向圖表編程中，圖表的描述是中心，它是真正的軟件產品。如，一個xml文件描述業務處理圖表。因此，圖形化視圖是軟件的固有部分，它總是同時存在的。不需要手工把圖形需求翻譯到一個軟件設計中。軟件的結構是圍繞圖表的。
jBPM的process definition生成3個文件。一個是xml格式的業務程序定義文件。一個是xml格式的文件，用來存儲元素的位置，另一個是jpg的圖形文件，展示業務程序定義的視圖。
4.2. Graph Oriented Programming面向圖表編程
What we present here is an implementation technique for graph based execution languages. The technique presented here is based on runtime interpretation of a graph. Other techniques for graph execution are based on message queues or code generation.
這里，我們介紹基于圖表執行語言的實現技術。這是一種運行時解釋的圖表。這樣，可以靈活的改變圖表DSL語言，實現不同的配置和運行結果。其他圖表執行的技術是基于消息隊列和代碼生成。
代碼生成，如源代碼級元數據的代碼生成；或者類載入時更改.class文件。
This section will explain the strategy on how graph execution can be implemented on top of an OO programming language. For those who are familiar with design patterns, it's a combination of the command pattern and the chain of responsibility pattern.
本節解釋我們如何在一門OO編程語言的基礎上實現圖表執行語言的策略。對于那些熟悉設計模式的人來說，這是命令模式和責任鏈模式的結合。（都屬于行為模式）
責任鏈模式讓多個處理對象能夠處理一個請求。
命令模式，使用“接口—實現類”的方式。一般作為參數把接口傳給調用方法。它能夠去除調用方法的條件判斷代碼。這是“重構”中經常用到的一種模式，常常用來去除代碼中的條件判斷語句。
We'll start off with the simplest possible model and then extend it bit by bit.
我們首先從最簡單的模型開始，一步一步擴展它。
4.2.1. The graph structure圖表結構
First of all, the structure of the graph is represented with the classes Node and Transition. A transition has a direction so the nodes have leaving- and arriving transitions.
首先，圖表的結構使用“節點”/（狀態）和“轉向”/（流程箭頭）來表示。
“轉向”有方向性。所以，“節點”有離開和到達“轉向”。
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.2. Node and Transition classes節點和轉向類
A node is a command and has an execute method. Subclasses of Node are supposed to override the execute method to implement some specific behaviour for that node type.
節點使用了命令模式，只有一個方法。
一個節點是一個命令，有一個執行方法。節點的子類支持覆蓋這個執行方法，根據節點的類型實現不同的方法。
4.2.2. An execution一個執行
The execution model that we defined on this graph structure might look similar to finite state machines or UML state diagrams. In fact Graph Oriented Programming can be used to implement those kinds of behaviours, but it also can do much more.
我們定義在圖表結構上的執行模型看上去類似于有限狀態機或者UML的狀態圖。
實際上，面向圖表編程能實現這些行為，還能做得更多。
An execution (also known as a token) is represented with a class called Execution. An execution has a reference to the current node.
一個執行（jBPM是token記號類，叫做“業務程序流程”比較合適，是一次業務程序實例的一個流程。）使用一個叫做Execution執行的類來表示。
一個執行指向現有的節點。
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.3. The Execution class執行類
Transitions are able to pass the execution from a source node to a destination node with the method take.
轉向能夠傳遞執行ExecutionContext給take方法。 執行會從從源節點到達目標節點。
jBPM中，Token等類的signal()方法表示一次“轉向”動作的執行。
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.4. The Transition take method轉向的take方法
When an execution arrives in a node, that node is executed. The Node's execute method is also responsible for propagating傳播 the execution. Propagating the execution means that a node can pass the execution that arrived in the node over one of its leaving transitions to the next node.
轉向---〉節點---〉轉向---〉節點
當一個執行到達節點后，這個節點也會被執行。這個執行也會把執行傳遞下去。通過轉向，執行點到達下一個節點。
<!--[if !vml]-->
<!--[endif]--><!--[if !vml]--><!--[endif]-->
參考：
1，jBPM中，狀態有4種匹配事件的動作：
<transition name="" to="end">
<action name="action1"></action>
</transition>
2，轉向只有一個動作。
3，動作可以有類class。會調用該“動作處理器”的唯一方法。
<event type="before-signal">
<action name="action1"></action>
</event>
<event type="after-signal">
<action name="action1"></action>
</event>
<event type="node-enter">
<action name="action1" class="com.sample.action.MessageActionHandler"></action>
<action name="action2"></action>
</event>
<event type="node-leave">
<action name="action1"></action>
</event>
Figure 4.5. The Node execute method節點執行方法
When a node's execute method does not propagate傳播 the execution, it behaves as a wait state. Also when a new execution is created, it is initialized in some start node and then waits for an event.
An event is given to an execution and it can trigger the execution to start moving. If the event given to an execution relates to a leaving transition of the current node, the execution takes that transition. The execution then will continue to propagate傳播 until it enters another node that behaves as a wait state.
<!--[if !vml]-->
<!--[endif]-->
節點/狀態有2種執行方式。一種是類似于Java等命令式的編程語言，一步步往下走；
另一種節點是等待狀態。要等待觸發。
jBPM中是單步執行，如果需要等待，可以先把“業務程序執行流程”保存進數據庫中。
如果節點沒有上面那樣的execute執行方法，那么就像start節點那樣是一個等待狀態，需要觸發事件才能繼續執行。
jBPM的jpdl中，基本上都是等待狀態。需要一步步執行。
<!--[if !vml]--><!--[endif]-->
Figure 4.6. The Execution event method執行事件方法
4.2.3. A process language一種業務處理語言
So now we can already see that the two main features are supported : wait states and a graphical representation. During wait states, an Execution just points to a node in the graph. Both the process graph and the Execution can be persisted: E.g. to a relational database with an O/R mapper like hibernate or by serializing the object graph to a file. Also you can see that the nodes and transitions form a graph and hence there is a direct coupling with a graphical representation.
<!--[if !vml]-->
<!--[endif]-->
現在，我們能夠看看面向圖表編程語言支持的2個特性：等待狀態和圖形化表示。在等待狀態期間，一個“業務程序的執行”僅僅指向“業務程序定義”的一個節點。業務程序定義/圖表和“業務程序的執行”都能夠被持久化。如，使用一個類似hibernate的o-r映射工具保存到關系數據庫中，或者序列化一個對象到文件中。
你也能看到一個圖表/“業務程序定義”的節點和轉向。因此，這也是一個與可視化表示的直接結合。
A process language is nothing more then a set of Node-implementations. Each Node-implementation corresponds with a process construct. The exact behaviour of the process construct is implemented by overriding the execute method.
一個業務處理語言除了一系列節點實現之外，沒有什么東西。每一個節點實現處理一個業務處理構件。業務處理構件的準確行為由實現類的execute方法來決定。
Here we show an example process language with 4 process constructs: a start state, a decision, a task and an end state. This example is unrelated to the jPDL process language.
這里，我們展示一個簡單的業務處理語言，它有4個業務處理構件：start狀態、決定器、任務和end狀態。它和jPDL處理語言無關，僅僅為了演示。
<!--[if !vml]--><!--[endif]-->
Figure 4.7. An example process language
一個示例業務處理語言
Concrete node objects can now be used to create process graphs in our example process language.
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.8. An example process
When creating a new execution for this process, we start by positioning the execution in the start node. So as long as the execution does not receive an event, the execution will remain positioned in the start state.
創建一個新的業務程序的業務程序執行時，它位于、指向start節點。
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.9. A new execution一個新的業務程序的執行
Now let's look at what happens when an event is fired. In this initial situation, we fire the default event that will correspond with the default transition.
初始化時，我們激活了默認的事件，這將和默認的轉向通訊。
That is done by invoking the event method on the execution object. The event method will propagate find the default leaving transition and pass the execution over the transition by invoking the take method on the transition and passing itself in as a parameter.
事件方法將找到默認的離開轉向，傳遞執行到下一個狀態。
The transition will pass on the execution to the decision node and invoke the execute method. Let's assume the decision's execute implementation performs a calculation and decides to propagate the execution by sending the 'yes'-event to the execution. That will cause the execution to continue over the 'yes' transition and the execution will arrive in the task 'doubleCheck'.
Let's assume that the execute implementation of the doubleCheck's task node is adds an entry into the checker's task list and then waits for the checker's input by not propagating the execution further.
Now, the execution will remain positioned in the doubleCheck task node. All nested invocations will start to return until the original event method returns.
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.10. An execution in the 'doubleCheck' wait state
4.2.4. Actions動作
In some application domains there must be a way to include the execution of programming logic without introducing a node for it. In Business Process Management for example this is a very important aspect. The business analyst is in charge of the graphical representation and the developer is responsible for making it executable. It is not acceptable if the developer must change the graphical diagram to include a technical detail in which the business analyst is not interested.
在許多應用程序領域，沒有導入一個節點，需要有一個方法包括進一個程序邏輯的執行。
在業務處理管理中這是非常重要的一個方面。業務分析員負責業務程序的圖形化表示。而開發人員負責是業務程序可執行。
開發者不能為了包括一個技術而改變業務程序表示圖。
An Action is also a commands with an execute method. Actions can be associated with events.
一個動作也是一個執行方法的命令。動作能夠和事件一起使用。
There are 2 basic events fired by the Node class while an execution is executing: node-leave and node-enter. Along with the events that cause transitions to be taken this gives already a good freedom of injecting programming logic into the execution of a graph.
當一個業務程序執行時，節點類有2個基本的事件：節點離開和節點進入事件。
通過引起轉向的事件，能夠把程序邏輯很自由的插入到圖形表示中。
注：yes,no 是2個轉向，在業務程序執行的代碼中進行判斷，看應該使用哪條“轉向”。
<!--[if !vml]-->
<!--[endif]--> <!--[if !vml]--><!--[endif]-->
Figure 4.11. Actions that are normally hidden from the graphical view
動作一般隱藏在視圖中
Each event can be associated with a list of actions. All the actions will be executed with the event fires.
每一個事件能夠和一系列動作關聯。
4.2.5. Code example代碼例子
In order for people to get acquinted with the principles of Graph Oriented Programming, we have developed these 4 classes in less then 130 lines of code. You can just read the code to get an idea or you can actually start playing with them and implement your own node types.
Here's the example code:
You can also download the whole (297KB) source project and start playing with it yourself. It includes an eclipse project so just importing it in your eclipse as a project should get you going. Also there are a set of tests that show basic process execution and the advanced graph execution concepts covered in the next section.
package org.jbpm.gop;
import java.util.*;
/**anodeintheprocessgraph*/
publicclass Node {
String name;
/**mapseventstotransitions
*節點的轉向名
**/
Map<String,Transition> transitions = new HashMap<String,Transition>();
/**mapseventstoactions
*動作map
**/
Map<String,List<Action>> actions = new HashMap<String,List<Action>>();
public Node(String name) {
this.name = name;
}
/**createanewtransitiontothedestinationnodeand
*associateitwiththegivenevent
*增加一個轉向到本節點。指定目標節點和轉向的名字。
*
*
**/
publicvoid addTransition(String event, Node destination) {
transitions.put(event, new Transition(destination));
}
/**addtheactiontothegivenevent
*
*給節點增加動作。
**/
publicvoid addAction(String event, Action action) {
if (actions.containsKey(event)) {
actions.get(event).add(action);
} else {
List<Action> eventActions = new ArrayList<Action>();
eventActions.add(action);
actions.put(event, eventActions);
}
}
/**tobeoverridenbyNodeimplementations.Thedefaultdoesn't
*propagatetheexecutionsoitbehavesasawaitstate.
*不考慮節點的實現。默認不傳播執行，所以它是一個等待狀態。必須要激發轉向，才能夠繼續執行。
*
**/
publicvoid execute(Execution execution) {
System.out.println("arrived in wait state "+this);
}
public String toString() { return"node '"+name+"'"; }
}
=================--------------------------------------=============
package org.jbpm.gop;
/**atransitionintheprocessgraph*/
publicclass Transition {
Node destination;
/**createsatransition
*轉向，只有目標節點指針。
*
* */
public Transition(Node destination) {
this.destination = destination;
}
}
----------===================-------------------===================
package org.jbpm.gop;
/**acommandthatcanbeinjectedintoaprocessexecution
*一個命令模式的接口，用來注入進一個業務程序的執行中。
*
* */
publicinterface Action {
/**tobeoverridenbyActionimplementations
*根據不同的執行動作需要被重寫。
*
**/
void execute(Execution execution);
}
--------===========-----------==============================------
package org.jbpm.gop;
import java.util.List;
/**onepathofexecution
*一個業務程序定義的一次執行路徑
**/
publicclass Execution {
/**pointertothecurrentnode
*指向現在節點的指針。這是業務程序執行唯一保存的東西。有了它，就可以恢復業務程序執行的流程。
* */
public Node node = null;
/**anexecutionalwaysstartsinagivennode
*一次業務程序執行總是在一個指定的開始節點執行。
*這是默認的節點對象引用。
* */
public Execution(Node node) {
this.node = node;
}
/**executesthecurrentnode'sactionsandtakestheevent'stransition
*根據事件執行動作。執行轉向的事件。
*1，離開節點事件；
*2，執行進入轉向
*
* */
publicvoid event(String event) {
System.out.println(this+" received event '"+event+"' on "+node);
fire(event);
if (node.transitions.containsKey(event)) {
System.out.println(this+" leaves "+node);
fire("leave-node");
take(node.transitions.get(event));
}
}
/**takeatransition
*執行轉向，轉向下一個節點
* */
void take(Transition transition) {
System.out.println(this+" takes transition to "+transition.destination);
node = transition.destination;
enter(transition.destination);
}
/**enterthenextnode
*進入下一個節點
* 激活目標節點的 進入節點事件。
* */
void enter(Node node) {
System.out.println(this+" enters "+node);
fire("enter-node");
node.execute(this);
}
/**firestheactionsofanodeforaspecificevent
*根據事件，執行動作。
* 實際是名-值對的名。
*
* */
void fire(String event) {
List<Action> eventActions = node.actions.get(event);
if (eventActions!=null) {
System.out.println(this+" fires actions for event '"+event);
for (Action action : eventActions)
action.execute(this);
}
}
public String toString() {return"execution";}
}
4.3. Advanced Graph Oriented Programming Extensions
高級面向圖表編程擴展
The previous section introduced the plain Graph Oriented Programming model in its simplest form. This section will discuss various aspects of graph based languages and how Graph Oriented Programming can be used or extended to meet these requirements.
4.3.1. Process variables業務程序變量
Process variables maintain the contextual data of a process execution. In an insurance claim process, the 'claimed amount', 'approved ammount' and 'isPaid' could be good examples of process variables. In many ways, they are similar to the member fields of a class.
業務程序變量維護業務程序執行的上下文關系的數據。 類似于線程的本地線程變量。它們非常類似于類的成員變量。
例如，一個保險索賠業務程序中，要求索賠金額，核準金額，已支付金額 是非常好的業務程序變量。
業務程序變量，作為Map綁定在一次業務程序執行對象上。
Graph Oriented Programming can be easily extended with support for process variables by associating a set of key-value pairs that are associated with an execution. Concurrent execution paths and process composition will complicate things a bit. Scoping rules will define the visibility of process variables in case of concurrent paths of execution or subprocesses.
'Workflow Data Patterns' is an extensive research report on the types of scoping that can be applied to process variables in the context of subprocessing and concurrent executions.
4.3.2. Concurrent executions并發執行
并發執行，指的是，一個業務程序的執行有多個并發的分支活動。
Suppose that you're developing a 'sale' process with a graph based process language for workflow. After the client submitted the order, there is a sequence of activities for billing the client and there's also a sequence of activities for shipping the items to the client. As you can imagine, the billing activies and shipping activities can be done in parallel.
假設你在使用基于業務程序的工作流圖表語言開發一個銷售業務程序。客戶提交訂單后，有一系列帳單活動和送貨個客戶的活動。帳單和送貨活動可能是平行的。
In that case, one execution will not be sufficient to keep track of the whole process state. Let's go though the steps to extend the Graph Oriented Programming model and add support for concurrent executions.
此時，一個執行將不能夠跟蹤整個業務程序的執行狀態。
我們擴展面向圖表編程模型來增加對并發執行的支持。
First, let's rename the execution to an execution path. Then we can introduce a new concept called a process execution. A process execution represents one complete execution of a process and it contains many execution paths.
首先，重命名之前的Execution類 為一個執行路徑。
它只有一個指向當前節點的指針。
引入一個新的概念----業務程序執行。 它代表一個業務程序定義的完整的執行。它包括了許多個執行路徑。
并發執行，就是執行路徑并發。 一個業務程序執行有多個執行路徑，可能是并發的。
The execution paths can be ordered hierarchically. Meaning that one root execution path is created when a new process execution is instantiated. When the root execution path is forked into multiple concurrent execution paths, the root is the parent and the newly created execution paths are all children of the root. This way, implementation of a join can become straightforward: the implementation of the join just has to verify if all sibling-execution-paths are already positioned in the join node. If that is the case, the parent execution path can resume execution leaving the join node.
執行路徑能被分層次的排序。當根路徑被分成多條并發的執行路徑使，會新建子執行路徑。 連接節點。
如果所有子執行路徑都在連接節點重新合攏，那么就能夠恢復主節點在連接節點的執行。
While the hierarchical execution paths and the join implementation based on sibling execution paths covers a large part of the use cases, other concurrency behaviour might be desirable in specific circumstances. For example when multiple merges relate to one split. In such a situation, other combinations of runtime data and merge implementations are required.
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.12. Actions that are normally hidden from the graphical view
動作一般隱藏在圖形化視圖下面
Multiple concurrent paths of execution are often mixed up with multithreaded programming. Especially in the context of workflow and BPM, these are quite different. A process specifies a state machine. Consider for a moment a state machine as being always in a stable state and state transitions are instantanious. Then you can interpret concurrent paths of execution by looking at the events that cause the state transitions. Concurrent execution then means that the events that can be handled are unrelated between the concurrent paths of execution. Now let's assume that state transitions in the process execution relates to a database transition (as explained in Section 4.3.6, “Persistence and Transactions”), then you see that multithreaded programming is actually not even required to support concurrent paths of execution.
并發執行路徑，常常意味著多線程編程。特別是工作流和業務程序管理。
一個業務程序實際是一個狀態機。狀態機在某一個時刻總是處于一個穩定的狀態，狀態轉變是即時完成的。你能夠通過觀察引起狀態轉變的事件來解釋并發執行路徑。事件的處理與并發執行路徑是不相關的。
假設，業務程序的執行中的一個狀態轉變和數據庫中的轉變關聯（通過數據庫事務，把一次轉變封裝起來），并發執行路徑實際上不需要多線程編程。
4.3.3. Process composition業務程序組合
Process composition is the ability to include a sub process as part of a super process. This advanced feature makes it possible to add abstraction to process modelling. For the business analyst, this feature is important to handle break down large models in smaller blocks.
The main idea is that the super process has a node in the graph that represents a complete execution of the sub process. When an execution enters the sub-process-node in the super process, several things are to be considered:
超級業務程序有一個圖表節點，表示一個完整的子業務程序的執行。
當一個業務程序執行進入了子節點業務程序，需要考慮下面幾件事情：
- First of all, a new execution is created for the sub process.
首先，為子業務程序創建一個新的業務程序執行。
- Optionally some of information stored in the process variables of the super process can be injected from the super process execution into the sub process execution. The most easy form is that the sub process node is configured with a set of variables that are just copied from the super process variables to the sub process variables.
保存在超級業務程序執行中的一些業務程序變量能夠插入子業務程序的執行的業務程序變量中。
- The start-node of the sub process should have only one leaving transition. Process languages that support multiple leaving transitions must have a mechanism to choose one of those transitions based on the process variables of the super process.
子業務程序的開始節點只能有一個離開轉向。
- The sub process execution is launched by sending an event that corresponds to the default leaving transition of its start state.
開始狀態的事件激發子業務程序的執行。
After the sub process entered a wait state, the super process execution will be pointing to the sub-process-node and the sub process execution will be pointing to some wait state.
When the sub process execution finishes, the super process execution can continue. The following aspects need to be considered at that time:
子業務程序完成后，父級業務程序能夠執行，需要考慮：
- Process variable information may need to be copied back from the sub process execution into the super process execution.
子類業務程序執行的變量拷到父級業務處理程序中。
- The super process execution should continue. Typically, process languages allow only one leaving transition on a sub process node. In that case the super process execution is propagated over that default single leaving transition.
- In case a sub process node is allowed more then one leaving transition, a mechanism has to be introduced to select a leaving transition. This selection can be based on either the sub process execution's variables or the end state of the sub process (a typical state machine can have multiple end states).
如果一個子業務程序允許多個離開轉向，那么需要引入一個機制來選擇離開轉向。這個選擇能夠基于子業務程序執行的變量，或者子業務程序的結束狀態。（一個典型的狀態機能夠有多個結束結束狀態）
TODO: bpel's has an implicit暗示 notion 概念of subprocessing, rather then an explicit明確的...
4.3.4. Synchronous execution同步業務程序執行路徑
4.3.5. Asynchronous continuations異步擴展
4.3.6. Persistence and Transactions持久化和事務
4.3.7. Services and the environment服務和環境
4.4. Architecture架構
4.5. Application domains架構領域
4.5.1. Business Process Management (BPM)業務程序管理
The goal of BPM is to make an organisation run more efficient. The first step is analysing and describing how work gets done in an organisation. Let's define a business process is a description of the way that people and systems work together to get a perticular job done. Once business processes are described, the search for optimisations can begin.
BPM業務程序管理的目標是使一個組織運行的更有效率。第一步是分析和描述組織內的工作如何執行。
我們定義一個業務程序，來描述人們和系統一起工作完成工作的程序、步驟。
Sometimes business processes have evolved organically and merely looking at the overall business process shows some obvious inefficiencies. Searching for modifications that make a business process more efficient is called Business Process Reengineering (BPR). Once a large part of a business process is automated, statistics and audit trails can help to find and identify these inefficiencies.
BPR業務程序/流程重組，改造現在沒有效率的業務程序。新的業務程序更有效率。一旦大部分業務程序實現自動化處理，那么統計和跟蹤就能夠幫助我們找到和標識這些低效的原因。
Another way to improve efficiency can be to automate whole or parts of the business process using information technology.
另一個改善效率的方法：使用信息技術能夠自動化部分或者整個業務程序。
Automating and modifying business processes are the most common ways of making an organisation run more efficient.
自動化和修改業務程序是最普遍的提供一個組織的工作效率的方法。
Managers continiously break down jobs into steps to be executed by their team members. For example a software development manager that organises a team-building event. In that case, the description of the business process might be done only in the head of the manager. Other situations like handling an insurance claim for a large insurance company require a more formal approach to BPM.
經理常常被他們的手下打斷工作。例如，業務程序可能僅僅在經理的大腦中有個映像。
但是，像一個大型的保險公司的保單索賠這樣的工作，就需要一個更加正式的業務程序管理BPM。
The total gain that can be obtained from managing business processes is the efficiency improvements times the number of executions of the process. The cost of managing business processes formally is the extra effort that is spent on analysing, describing, improving and automating the business processes. So that cost has to be taken into consideration when determining which processes will be selected for formal management and/or automation.
總的目標是，大量的業務程序的執行效率能夠通過管理業務程序而得到提高。正式的采用BPM管理業務程序的成本是額外的分析業務程序，描述業務程序，改進和自動化業務程序。
所有這些成本必須被認真考慮，以決定一項業務程序正式的自動化管理是否值得。
4.5.1.1. Goals of BPM systems
BPM（業務程序管理）系統的目標
4.5.1.2. Process development process
處理開發業務程序
4.5.2. Service orchestration
安排服務
orchestration is somtimes supposed to be in the context of service orchestration.
安排有時假想在安排服務。
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.13. Service
4.5.2.1. Orchestration compared to Choreography
安排和舞蹈的比較
4.5.3. Pageflow頁面流
4.5.4. Visual programming可視化編程
...targetted at less experienced developers.
針對富有經驗的開發者。
In my opinion, the current java community is a relatively small community of very hard core power users. Of course, the point and click will have a lot of restrictions cannot handle all of Java's constructs. But it will open up a hole new can of fresh (less-experienced) software developers. So different editors for a single language can target different types/levels of developers.
4.6. Embedding graph based languages
內嵌的基于圖表的語言
When the BPM engine can be completely integrated into a software development project and when even the BPM engine's database tables in integrated into the project's database, then we speak of an Embeddable BPM engine. That is the goal we target with Graph Oriented Programming: a common foundation for implementing graph based languages.
面向圖表的編程目標是： 實現基于圖表編程的一個共同的基礎。
4.7. Market市場
4.7.1. The ultimate process language最終的業務程序語言
Traditionally, the vendors賣主 have been searching for the ultimate process language. The approach is to specify a process language as a set of constructs構件. Each construct has a graphical representation and a runtime behaviour. In other words, each construct is a node type in the process graph. And a process language is just a set of node constructs.
一個業務程序語言僅僅是一系列節點構件的集合。
The idea was that the vendors were searching for the best set of process constructs to form a universally applicable process language. This vision is still found a lot today and we call it searching for the ultimate process language.
可是用于大部分場合的業務程序語言的最好的業務程序構件集合。
We believe that the focus should not be on trying to find the ultimate process language, but rather in finding a common foundation that can be used as a basis for process languages in different scenarios and different environment. Graph Oriented Programming as we present it next is to be seen as such a foundation.
我們認為找不到最終的業務程序語言，但是應該能夠找到所有業務程序語言共同的基礎。我們接下來將要向你展示的的這種面向圖表編程語言看來就是這樣一種基礎語言。
4.7.2. Fragmentation分裂
The current landscape前景 of workflow工作流, BPM業務程序管理 and orchestration安排 solutions is completely fragmented. In this section we'll describe two dimensions in this fragmentation. The first dimension is called the BPM product continuum and it's shown in the next picture. The term was originally coined by Derek Miers and Paul Harmon in 'The 2005 BPM Suites Report'.
1，不同： 編程語言環境和BPM套件的不同-------庫和BPM套件來彌合。
底層OO通用編程語言技術和基于業務的業務程序定義的跨度。
粒度相差太大。必須要使用OO制作的庫實現BPM的DSL語言系統來定義業務程序！
基于OO的BPM庫和BPM套件是解決之道。
On the left, you can see the programming languages. This side of the continuum is targeted towards the IT developers. Programming languages are the most flexible and it integrates completely with the other software developed for a perticular project. But it takes quite a bit of programming to implement a business process.
編程語言面向開發人員，但對于實現一個業務程序，粒度太小了。
On the right, there are the BPM suites套件. These BPM suites are complete software development environments targetted to be used by business analysts業務分析員. Software is developed around business processes. No programming has to be done to create executable software in these BPM suites.
<!--[if !vml]-->
<!--[endif]-->
<!--[if !vml]--><!--[endif]-->
Figure 4.14. The BPM product continuum.
BPM產品統一體
Traditional products mark 1 spot in the BPM product continuum. To be complete, these products tend to aim for the far right of the continuum. This is problematic because it results in monolithic system that is very hard to integrate into a project combines plain OOP software with business processes.
傳統產品玷污了BPM產品統一體。
芯片系統（匯編系統？）上是非常難以集成一個使用業務程序的OO軟件的。
難以把OOP軟件和業務程序整合起來。
Graph Oriented Programming can be built as a simple library that integrates nice with plain programming environment. On the other hand, this library can be packaged and predeployed on a server to become a BPM server. Then other products added and packaged together with the BPM server to become a complete BPM suite.
面向圖表編程構建于一個簡單的庫上，能與簡單編程環境很好的整合。
另一方面，這個庫能夠被打包和預部署到一個服務器上，從而成為一個BPM服務器。其他產品在其上增加和打包，成為一個完整的BPM套件。
The net result is that solutions based on Graph Oriented Programming can target the whole continuum. Depending on the requirements in a perticular project, the BPM suite can be peeled and customized to the right level of integration with the software development environment.
結果是基于圖表的編程解決方案能夠解決所有問題。依賴于項目的實際需要，BPM套件能夠去除和定制到正確的級別，和軟件開發環境整合起來。
The other dimension of fragmentation is the application domain. As show above, a BPM application domain is completely different from service orchestration or pageflow. Also in this dimension, traditional products target one single application domain, where Graph Oriented Programming covers the whole range.
傳統產品的目標是針對一個簡單的應用領域。而jBPM這樣的面向圖表語言借助于提煉出廣泛適用的構建，試圖用一種語言完全的覆蓋整個領域。
2，另一個分裂的緯度：應用程序領域的廣度。上面所示，一個BPM應用程序領域包括從服務安排到頁面流等完全不同的領域。
If we set this out in a graph, this gives a clear insight in the current market fragmentation. In the graph based languages market,在基于圖標語言的市場， prices are high and volumes are low價格高體積小. Consolidation is getting started and this technology aims to be a common foundation共同的基礎 for what is now a fragmented 分析和高軟市場前景and confusing market landscape.
<!--[if !vml]-->
<!--[endif]-->
如圖：
高端的DSL語言，解決的問題越簡單；
---高效，但是不廣泛有用。
底端的OO，解決的問題越復雜。
-----適應性廣，但是低效！
<!--[if !vml]--><!--[endif]-->
Figure 4.15. Two dimensions of fragmentation.
分裂的2個緯度
4.7.3. Other implementation techniques
其他實現技術
Based on message queues. 基于消息隊列
Based on code generation. 基于代碼生成