这是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. 基于代码生成