第4章面向圖的程式設計
4.1. 介紹
本章可以給出JBoss jBPM的明細單，完整的願景概覽、目前戰略下的理念以及JBoss jBPM項目未來的方向。這一願景和傳統的取向相比有極大的不同。
首先，我們相信複合流程（multiple process）語言。不同環境和不同目的要求他們自己特定的流程語言。
其次，面向圖形的程式設計是一個新的技術實作，這種技術實作是針對所有基于圖的流程語言的基礎。 這樣做的最主要的好處就是它定義了一種針對所有類型的流程語言基礎技術。 當今的軟體開發越來越多的依賴領域特定語言。一個典型的java開發人員将使用相當多的領域特定語言。項目中的XML檔案作為各種架構的輸入就可以認為是領域特定語言。
圖 4-1 基于圖的語言的定位
工作流、BPM、orchestration 和pageflow的領域特定語言是基于定向圖執行之上的。其他的像hibernate的映射檔案、ioc-configuration則不是這樣的。面向圖的程式設計是基于執行圖的領域特定語言的基礎。
面向圖的程式設計語言是非常簡單的技術，它描述了如何定義圖和被執行在純OO程式設計語言上。 在 4.5 應用領域，我們将涉及大多數的常用的流程語言，這些語言都是可以使用面向圖的程式設計方法來實作的，如工作流、BPM、編排（orchestration）和pageflow。
4.1.1. 域特定語言
每一流程語言都能被認為是一個領域特定語言（Domain Specific Language ,DSL）。DSL透視圖讓開發人員能很好的了解流程語言和純OO程式設計如何關聯的。 本節也許會留下我們單純地專注在以程式設計環境為中心的印象。這是千真萬确的。面向圖的程式設計包含了從API庫到完全成熟的BPM成套産品的整個BPM産品線。這套Bpm産品是完整的軟體開發環境，這個環境是以業務流程為中心的。在那種類型的産品中，在程式語言中的編碼被盡可能的避免了。 一個重要的領域特定語言的方面就是每一種語言都有某種文法。那種文法能夠被表述為一個領域模型。 假如是java的話，這就是類、方法、域和構造器等等，而對于jPDL就是節點、轉換和動作等等，而對于規則（rules），這就是條件和結果等等。 DSL的主旨就是開發人員當使用特定的語言創作為工件時可以考慮那些文法。IDE工具建立語言文法。然後，不同的編輯器就能創作工件。例如：jPDL流程有一個圖形編輯器和一個XML源代碼檢視編輯器。而且有不同的方法來存儲相同的工件：對于jPDL來說，這可能是一個流程XML檔案或序列化了的節點和轉換的對象圖。 另一個（理論上的）例子是java：你可以在系統上使用java類檔案格式。當使用者啟動編輯器時，源檔案就被生成了。當使用者儲存時這個編譯過的類也就被儲存了… 10年前，開發人員最大部分的精力花在寫代碼上了。現在一個轉換已經取代了這個位置，他們而是去學習和使用領域特定語言。這種趨勢仍将繼續而且導緻的結果就是開發人員将在架構和在主機平台上開發軟體之間有了更大的選擇。JBoss SEAM正走向那個方向。
那些語言中的一些是基于圖執行之上的。例如：java的工作流jPDL、服務編排的BPEL和SEAM pageflow等等，對于所有這些類型的領域特定語言，面向圖的程式設計是一個通用基礎。
将來，對于每一個語言、開發人員能夠選擇一個适合自己的最好的編輯器。例如：重量級的程式員可能更喜歡以源檔案格式編輯java，因為那樣工作真的很快。但是缺少經驗的java開發人員可能會選擇一個通過點選編輯器就能編寫一個功功能性的java類。Java源編輯将更加靈活。 檢視這些領域特定語言（包括程式設計語言）的另一種方式是從結構化軟體透視圖。面向對象的程式設計（OOP）使用資料通過分組設計方法增加結構。面向切面程式設計（AOP）增加一個方法結構通過分組方法去提取關注的交叉切面。依賴注入（DI）和反轉控制（IoC）架構增加簡易的對象圖配線。而且通過結構化圖執行周圍的軟體項目的一部分，基于執行語言的圖（這提及的）是能有幫助的去處理複雜性的事務。
一個在領域特定語言（DSL）的基本解釋能夠在Martin Fowler的部落格（bliki）上找到。但它之後的願景在Martin的關于《Language Workbenches》的文章中有更加詳細的說明。
4.1.2. 基于圖的語言的屬性
有為數衆多的基于圖的流程語言。在環境和焦點裡有很大的不同。舉例來講，BPEL作為一個XML被計劃，這個XML是基于在企業服務總線（Enterprise Service Bus ,ESB）架構之上的服務編排元件的。并且pageflow流程語言可以解釋web應用的頁面是如何能夠被導航的。這些是兩種完全不同的環境。
盡管有這些不同，你也會發現在幾乎每一個流程語言裡有兩個特征：等待狀态支援（support for wait states）和圖示（graphical representation）。這不是偶然的因為這兩種特征在純粹的面向對象程式設計語言（如java）中沒有被充分的支援。
面向圖的程式設計是一種用面向對象程式設計語言去實作的技術。面向圖的程式設計對OOP的依賴意味着實作于面向圖的程式設計的所有具體流程語言将使用OOP來開發。但是這不是說流程語言本身暴露出了這種OOP的任何特性。例如：BPEL和OO程式設計沒有任何關系并且它可以在面向圖的程式設計上被實作。
4.1.2.1. 等待狀态支援
指令式的程式設計語言（如java）常被用來表示一個系統中被執行的順序指令。沒有等待指令。指令式的語言描述起來是完美的，例如一個伺服器的請求響應周期。系統将連續執行順序指令直到請求被處理并且完成響應。 但一個這樣的請求是較大的場景典型代表。例如：用戶端送出一個采購訂單，這一訂單将被采購經理驗證。在審批後，這一資訊必須錄入到ERP系統中去。大量的對伺服器的請求是相同的大場景的部分。 是以流程語言是描述較大場景的語言。一個非常重要的差別是我們必須認為這是一個系統（編排）上是可執行的場景，而且場景也是在多系統（安排）間可以描述協定的。 基于圖的程式設計實作技術隻是瞄準可以在機器（編排機）上執行的流程語言。 是以一個編排流程根據一個系統描述整個場景.例如：當用戶端送出一個訂單時開始流程。流程的下一步是訂單經理審批。是以系統必須在訂單經理的任務清單中增加一個入口點和一個等待（狀态）直到訂單經理處理這個請求的輸入。當這個輸入接收後，流程繼續執行。現在一個消息送達到ERP中流程處理待狀态直到響應消息傳回。 是以為一個系統描述整個場景，我們需要一個應付等待狀态的機制。 在大多數的應用領域，執行必須在等待狀态時被持久化。那也就是為什麼隻阻塞線程是不足夠的原因。聰明的Java程式員也許會考慮Object.wait()和Object.notify()方法。那種處理用于模拟等待狀态還可以，但問題是線程是不可被持久化的。 連續（Continuations）是使線程（和上下文變量）可持久化的技術。這個也許是足夠解決等待狀态問題的了。而且我們也将在下一節讨論，圖示在許多應用領域也是重要的。而且連續（Continuations）是一個基于指令式程式設計的技術，是以它是不适合的對于圖形表示。 是以支援等待狀态的一個重要的方面就是執行需要是可持久化的。不同的應用領域也許有不同的需求來持久化這樣一個執行。對于大多數工作流，BPM和編排應用，執行需要在關系資料庫中持久化。代表性的是，一個流程執行中的狀态轉換将和資料庫中的一個轉換進行通信。
4.1.2.2. 圖形化表示
軟體開發的某些方面得益于基于圖的途徑是非常好的。業務流程管理是基于圖的語言的應用領域中的最明顯的一個。在那個例子中，在業務分析和開發人員間的通訊是被改進的用基于圖的業務流程圖解像通用語言那樣。參考4.5.1 業務流程管理（BPM）節
另一方面能夠從圖示中得益的是頁面流（pageflow）。假若那樣的話，在圖示裡頁面、導航和動作指令是被顯示和連結在一起的。 在面向圖的程式設計裡，我們瞄準表示一些執行的表單的圖表。那是和諸如UML類圖有明顯的差別的，這種UML類圖表示一個OO資料結構的靜态模型。 此外圖形表示可以被看作在OO程式設計中錯過的特性。而且也沒有什麼明智的方法能夠以圖形化的表示OO程式的執行。是以在OO程式和圖形視圖間沒有什麼直接關系。 面向圖程式設計，是以圖為中心并且是一個的真正的軟體制品，如描述流程圖的XML檔案。因為圖形視圖是軟體的固有部分，它總是同步的。無須将一個圖形需求插翻譯成軟體設計。軟體是以圖進行組織的。
4.2. 面向圖的程式設計
這裡我們展示的是一個基于圖的執行語言的實作技術。這裡展示的技術是基于與圖內建的運作時的，其他的圖執行技術都是基于消息隊列或代碼生成的。
本節會解釋這個政策如何在OO程式設計語言上實作圖執行。那些同設計模型是相似的，它是指令模式（command pattern）和責任鍊模式（chain of responsibility pattern）的結合體
我們将用最簡單的可能模型來開始并一點點的擴充它。
4.2.1. 圖結構
首先，圖的結構是用節點（Node）和轉換（Transition）類來表示的。一個轉換有一個方向，是以節點具有了離開和到達轉換（的事件）。
圖 4-2 節點和轉換類
4.2.2. 執行
執行（execution）模型在圖結構上定義，它看起來像一個有限狀态機或UML狀态圖。實際上面向圖程式設計能夠用來實作那些各類的行為，但是也可以做更多的事。 一個執行（也叫令牌[token]）用一個叫做Execution的類來表示。一個執行有一個一目前節點的引用。
圖 4-3 執行（Execution）類
轉換能夠用方法take從源節點到目标節點通過執行。
圖 4-4 轉換（Transition）的take方法
當一個執行到達節點時，那個節點被執行。這個節點執行方法來負責傳播這個執行。傳播執行意味着能夠傳遞執行到節點，也就是通過它的離開轉換到下一個節點。
圖 4-5 節點（Node）的execute方法
當一個節點的execute方法不能傳播執行時，它表現為一個等待狀态。而且當一個新的執行被建立時，它被初始為一個開始節點并且等待一個事件。 事件（event）被賦給一個執行而且它有觸發執行開始移動。如果事件賦給與目前節點相關的離開轉換的話，執行将處理那個轉換。執行然後将繼續傳播直到它進入另一個具有等待行為的節點。
圖 4-6 執行的event方法
4.2.3. 流程語言
是以現在我們能夠看到已經支援了兩個主要的特性：等待狀态和圖形化表示。 在等待狀态期間，執行隻是指向圖中的一個節點。流程圖和執行都能被持久化。例如：使用O/R映射工具存到一個關系資料庫中或者是序列化圖存成一個檔案。 此外你可以看到那個節點和轉換形成圖并且以後是直接和一個圖示結合的。 流程語言無非是一系列節點實作。每個節點實作和流程構圖（constructs）進行通信。流程構圖的需要的行為通過覆寫execute方法來實作。 這裡顯示一個有4個構圖的流程語言的例子：一個開始狀态、一個條件、一個任務和一個結束狀态。這個例子沒有關聯jPDL流程語言。
圖 4-6 流程語言示例
具體的節點對象現在可以用來建立流程圖在我們流程語言示例中。
圖 4-8 流程示例
當建立一個流程的新的執行時，我們開始定位這個執行在開始節點。是以隻要執行不接收到一個事件，這個執行就将一直定位在開始狀态。
圖 4-9 新執行
現在讓我們看下當一個事件到達時會發生什麼。在最初狀态下，我們擊發預設的事件将和缺少的轉換進行通信。 也就是在執行對象上調用事件方法。這個事件方法将傳播找到缺少的離開轉換并傳遞執行通過轉換，調用轉換的take方法并将其自己作為一個參數進行傳遞。 這個轉換将傳遞執行到決策節點并調用execute方法。讓我們假設這個決策的execute方法發送了“是”這個事件到執行上。那将導緻這個執行繼續通過“是”轉換并且執行将到達任務節點——“仔細檢查”。 讓我們假設執行“仔細檢查”任務節點的實作加一個入口刊檢查員的任務清單，然後等待檢查員輸入而不會進一步傳播執行。 現在，執行将一直定位在“極細檢查”任務節點。所有的嵌套調用将開始運作直到那個最初的事件方法傳回。
圖 4-10 在“仔細檢查”等待狀态的執行
4.2.4. 動作
在一些應用領域一定有一種方法來包含程式設計邏輯的執行，而不用為它引入節點。在業務流程管理示例這是一個非常重要的方面。業務分析負責圖形表示而開發人員負責讓其執行。如果開發人員必須改變圖表來囊括業務分析中沒有吸引力的技術細節的話将是不可接受的。 一個動作也是一個執行方法的指令。動作能夠同僚件關聯。 當執行正在執行時，有兩個基本事件：節點離開和結節進入被Node類擊發。連同僚件一起。 伴随有引起了要被處理的轉換的事件，使得自由的注入程式設計邏輯進入這個圖的執行。
圖 4-11 圖形視圖中的隐藏動作
每個事件可以關聯一系列的動作清單。所有的動作将随着事件的觸發而被執行。
4.2.5. 同步執行
預設的執行的傳播是同步的。在4.3.4 異步連續 節，我們将要看到預設行為是如何被改變的。
當事件送到執行時，執行開始。那個執行将要開始傳播通過轉換并進入節點。如果節點決定傳播這個執行，這個 take 方法被調用了在離開轉換上而且這個執行進一步傳播。通過預設，所有的這些傳播作為嵌套方法調用被處理。那就意味着當執行已經進入新的等待狀态時，原始事件方法隻能傳回。是以這個執行在一個事件方法的調用期間能夠周遊多個節點。 典型的，signal方法在轉換内部被調用了。這就意味着在一個轉換裡，在流程圖上這個執行可以通過多個節點潛在地移動。那個結果在系統上有很大的程度的性能益處，即每個節點需要一個轉換。 另一個同步執行的益處是有更多的異常處理選項。如果所有節點是被同步執行的，所有執行的傳播将被嵌套方法調用。當signal方法傳回時，這個signal方法的調用方将知道新的等待狀态已經到而且沒有問題發生。
4.2.6. 代碼示例
為了讓人們了解面向圖的程式設計的原則，我們用少于130行的代碼寫了四個類。你可以隻是讀代碼就能想法或者你能真正的和他們一起開始工作及實作自己的節點類型。 這有示例代碼：
l Execution.java
l Node.java
l Transition.java
l Action.java
你可以下載下傳整個源項目（297KB）并且自己開始。它包含一個eclipse項目，是以你隻要在你的eclipse中導入它就可以開始了。在下一節還提及了一系列的用來顯示基本的流程執行和進階的圖執行概念測試。
4.3. 面向擴充圖的程式設計
上一部分介紹了純面向圖程式設計模型用它的最簡單的表單。這部分将讨論基于圖語言的各個方面以及面向圖的程式設計怎樣才能被使用或擴充這些需求。
4.3.1. 流程變量
流程變量維護流程執行的上下文資料。在一個保險說明流程時在，'claimed amount'、'approved amount' 和 'isPaid'是流程變量的好例子。在許多方面，他們是同類的成員域是相似的。
面向圖的設計有了流程變量支援可以容易地被擴充，這些流程變量是與執行關聯的一系列的鍵值（key-value）對。并發執行路徑（Concurrent execution paths）和流程組成（process composition）将是有點複雜的事。如果發生執行的并發路徑或子流程那麼界定（scoping）規則将定義流程變量的可視性。
工作流資料模型是一個通用的研究報告，在界定類型上的這個報告可以被應用到子流程和并發執行中的流程變量。
4.3.2. 并發執行
假設你使用工作流基于圖的流程語言開發一個“sale”流程。在用戶端送出訂單後中，有一系列的用戶端記賬活動并且還有一系列的有關運輸項目的活動。正像你想象的一樣，記賬活動和運輸活動能夠被并行處理。 那樣的話，一個執行将不足以保持整個流程狀态的跟蹤。讓我們逐漸來擴充基于圖程式設計模型并增加并發執行支援。 首先，讓我們重命名空上執行到一個執行路徑。然後我們可以引入新的概念叫流程執行（process execution）。流程執行代表一個完整的流程執行并且包含多個執行路徑。 這個執行路徑可以被分層排序。那也就意味着當新的流程執行被執行個體化時一個根執行路徑被建立。當一個根執行路徑分叉進入多個并發執行路徑時，這個根是父親，新建立的執行路徑稱為這個根的孩子。這樣的話，結合實作可以變成直接的：這個結合實作就不得不去檢查所有的兄弟執行路徑（sibling-execution-paths）已經處在結合節點了。如果那樣的話，這個父執行路徑可以恢複執行離開結合節點。 當層級執行路徑和基于兄弟執行路徑的結合實作覆寫了用例的大部分時，其他的并發行為在這種情形下也許是合适的。例如當多個合并關聯到一個分裂時。在這樣的形式下，其他的運作時資料的合并以了合并實作是必須的。
圖 4-12 并發路徑執行
執行的多并發路經常與多線程程式設計混淆。尤其在工作流和BPM的上下文中，這些是完全不同的。流程指狀态機。考慮狀态機總是在一個穩定狀态和瞬間的狀态轉換中。這樣你就可以通過檢視導緻狀态轉換的事件來解析執行的并發路徑。并發執行的意思是被處理的事件和并發執行路徑兩者間是無關的。現在讓我們假設在流程執行中的狀态轉換和資料庫轉換是相關的（也在4.3.5 持久化和事件節被解釋了），那麼你将發現多線程程式設計是完全不需要支援執行的并發路徑的。
4.3.3. 流程組成
流程組成是去包含作為超流程（super process）部分的子流程（sub process）的這個能力。這個進階的屬性使得增加一個抽象到流程模型成為可能。對于事務分析，這個屬性處理在較小的闆塊裡中止大模型是重要的。 這個主旨思想是超流程有在圖中有一個代表完整子流程執行的節點。當執行進入超流程的子流程節點（sub-process-node）時，将要考慮幾個事情：
l 首先，為子流程建立新執行
l 可選的，一些存儲在超流程中的流程變量資訊能夠從超流程執行注入子流程執行。最容易的形式是子流程配置一系列的用來把變量從超流程複制到子流程的變量。
l 子流程的開始節點（start-node）應該隻有一個離開轉換。支援多離開轉換的流程語言必須有一個選擇那些基于超流程的流程變量的轉換中的一個轉換的機制。
l 子流程執行通過發送一個響應開始狀态預設轉換的事件被啟動。
在子流程進入等待狀态後，超流程執行将訓示子流程節點和子流程執行在一些等待狀态。 當子流程執行完成時，超流程執行能夠繼續。下列方面那時是需要被考慮的：
l 流程變量資訊可能需要從子流程執行中複制回超流程執行。
l 超流程執行将要繼續。典型地，流程語言隻允許在子流程節點上有一個離開轉換。那樣的話超流程執行被傳播通過那個預設的離開轉換。
l 如果子流程節點被允許多于一個的離開轉換，一個機制将被引入到選擇離開轉換中。這個選擇能夠基于子流程執行的變量也可以是子流程的結束狀态（典型狀态機能有多個結束狀态）。
WS-BPEL有一個子流程處理的隐性概念，要是顯式的就好了。調用将開始新的子流程。然後超流程将有一個直到子流程結束的等待的接收活動。是以正常的調用和接收被特殊的活動取代了。
4.3.4. 異步連續
以上的，我們看到了去異步執行流程的預設行為直到有一個等待狀态。典型地這全部的狀态變換被打包成一個轉換。在這部分裡，你将看到如何在流程語言裡劃分轉換邊界。異步連續意思是流程可以異步地繼續。這就意味着第一個轉換将發送一個消息。那個消息代表一個連續指令。然後這個消息接收器執行第二個轉換指令。然後這個流程繼續它的自動執行，但是它分開了兩個轉換。
為了增加異步連續到面向圖的程式設計，需要一個消息系統，這樣的一個內建了你的程式設計邏輯的系統允許消息事務發送和接收。消息系統也被叫做面向消息的中間件（message oriented middleware, MOM）而且Java消息服務（Java Message Service , JMS）是用在這個系統上的标準API。
有三個執行能夠被異步地繼續的地方： l 在節點的execute方法前。即進入節點後。 l 當執行将要通過一個轉換進行傳播時。即在離開節點前。 l 每個動作裡也可以被異步的執行。 讓我們詳細地考慮下第一種情形當他被顯示在下列圖形中。假設某些事件導緻一個執行通過圖開始傳播而且在“generatePdf”節點轉換将要調用 execute 方法。取代直接地在“generatePdf”節點上的execute方法調用，新的消息指令正在使用一個指針到建立到執行。指令消息應該被解析為作為“通過執行節點繼續這個執行”。這個消息通過消息隊列被發送到指令執行器。這個指令執行器從消息執行器取得消息并以這個執行作為參數來調用節點的execute方法。
圖 4-13 異步連續
注意現在兩個獨立的事務被涉及了。從初始事件發起的一個事務。那個事務包含了移動這個執行進入“generatePdf”節點并發送指令消息。在第二個事務中，指令消息被消費掉并且節點的execute方法以執行為參數被調用。在這兩個事務之間，執行應該被到來的事件阻塞。
4.3.5. 持久化和事務
流程定義資訊（像節點、轉換和動作）和執行資訊（像執行）兩者都可以被存儲在關系資料庫中。ORM解決方案（像Hibernate/EJB3）可以用來做映射在資料庫記錄和OOP對象之間。 所有流程定義資訊是靜态的。是以它可以被緩存在記憶體中。這給了一系列的性能提高。不過每個轉換中的運作時執行資料将不得不從資料庫中被加載。 轉換通常相當于執行上的事件方法。當事件正在被處理的時候轉換開始。這個事件方法将觸發執行繼續直到新的等待狀态到達。當那個發生時，執行的事件方法傳回并且轉換結束。 這整個事件方法調用的變換就是執行已經被移動了，它的節點指針從一個節點到另一個節點。這個ORM解決可以計算出原始資料庫狀态和被更新的java對象之間的差異。然後那些變化将在執行事件方法的結束點被刷到資料庫中。在我們的例子中這是一個執行上的SQL更新（update）語句，設定節點指針到新（等待狀态）節點。 類似hibernate/EJB3的ORM解決方案中，它們在每個session中同不同的對象集一起工作。這就意味着所有通路Node實作是被序列化了的并且隻要代碼使用執行資料（不是靜态變量、執行個體）的話就移除寫線程安全的代碼的必要性。
4.3.6. 服務和環境
節點可能想利用可插撥的服務或新的節點實作可能想使用新服務，這還是個未知數在設計時。為了适應這方面，一個服務架構應該被增加到面向圖的程式設計中，以至于節點可以通路何意的服務和配置。 基本上，有兩方面：
l 向下傳遞執行上下文對象（上面提到的包裹了執行對象傳遞被傳遞）
l 線程本地執行上下文
執行上下文包含通過“環境”來通路服務是可用的。這個環境是用戶端代碼（代碼調用Execution.event(String)加上一個可選的用戶端代碼的運作容器）。 服務的例子是定時器服務、異步的消息服務和資料庫服務（java.sql.Connection）等等。
4.4. 注意事項
4.4.1. 運作時資料隔離
面向圖的程式設計清晰地從運作時資料中（執行）中分離了定義資料（節點、轉換和動作）。 是以代替了進入節點的傳播執行，任何節點實作可以重新安排代表執行的整個運作時資料。這就創造了許多為實作不同形式的fork.split和結合（join/merge）行為的靈活性。 此外，定義資訊是靜态的而且從不變化。這個對于各種各樣的執行優化是重要的。
4.4.2. GOP與其他技術相比
在這部分我們描述下面向圖的程式和其它的實作技術如何被用于基于圖的執行語言。 在基于面向消息的中間件（MOM）的執行引擎中，執行通過沿着消息隊列傳遞的消息來表示的。每一個流程圖中的節點是通過系統中的消息隊列來表示的。實際上，面向圖的程式設計是基于MOM的執行的超集。 在面向圖的程式設計（GOP）中，預設的，從一個等待狀态到另一個等待狀态移動執行的計算是被同步完成的。在這份檔案的後部分，我們将提到用來解釋MOM怎樣才能夠被用來在流程同步中做一步的異步連續擴充。是以基于MOM的執行在所有節點被異步地執行方面同面向圖的程式設計是相似的。 另一種被用來實作工作流、BPM和編排系統的技術是代碼生成。在那個方案中，基于圖的流程被翻譯成指令式的程式設計邏輯（如java）。這個被生成的程式設計邏輯對于外部的觸發器有一個方法，它可以在等待狀态後被給出。那些方法将計算轉換到一個新的等待狀态。這一技術是在流程版本能力和實踐中被限制的，因為代碼生成已經被證明在軟體開發流程中是不實用和具有瓶頸的。
4.4.3. GOP 與Petri網比較
學術界，長時間以來，對于工作流和業務流程模組化一直集中在petri網上，這主要是因為petri網是支援執行的并發路徑唯一的精确定義的模型。由于數學基礎的原因，許多有趣的驗證和完整性算法可以被定義。 在petri網和GOP間最大的差異就是他們的本質。Petri網是一數學模型，而GOP是一個實作技術或設計模式。 GOP可以用來實作petri網。Petri網位置（places）和petri網轉換可以作為兩個不同的節點類型來實作。Petri網弧（arcs）相當于GOP的轉換。一個petri網令牌（token）相當于GOP執行。 已經被定義在petri網上較高層的擴充（extensions）也可以用GOP的術語進行定義。 GOP自身并不支援分析算法當他們被定義在petri網上時。那是因為GOP沒有一個具體的解釋。分析算法隻能定義在具有确定設計時解釋的模型上。GOP在另一方面也支援具有非确定設計時解釋節點。GOP節點實作可以潛在的去做任何運作時計算類型和決定，以及執行如何被傳播。分析算法隻能被定義在具體的流程語言上，因為這個節點實作讓确定設計時解釋成這個節點類型。
4.5. 應用領域
4.5.1. 業務流程管理 (BPM)
4.5.1.1. BPM不同方面
BPM的目标是讓一個組織能夠更高效的運作。第一步是分析和描述出組織是如何完成工作的。讓我們定義一個業務流程即人和系統一起工作來完成一個特定的工作的方法的描述。一旦業務流程被描述了搜尋優化就可以開始了。 有時業務流程已經有組織地被演化并且隻是看這整個的業務流程顯示某些明顯的無效率。查找出使這些業務流程更加高效的修正稱為業務流程重建（Business Process Reengineering ,BPR）。一旦流程大部分是自動地、統計和稽核追蹤能幫助查找并辨別出這些無效性。 另一種提高效率的方式能夠使用資訊技術去自動化業務流程整體或部分。 自動化和修改業務流程是使組織更加高效地運作的最通用方式。總之重要的是注意那些是業務流程管理的部分内容。 經理不斷地被他們的組員打斷工作，進入被執行的步驟。例如一個軟體開發經理組織一個團隊建設事件。假使那樣的話，業務流程的描述可能隻在經理的前面完成。其他的情形像一個大保險公司處理一樁保險索賠而需要一個更正式的BPM方案。 總收入能夠從管理業務流程并改進一定數量的業務流程執行時間效率中獲得。管理業務流程正式化的成本是花費在分析、描述、改進和自動化業務流程上的額外成果。是以當決定哪一個流程将被選出來進行正規化管理及自動化時這些成本就不得不被考慮。這個解釋就是要集中在高複發率的過程上。
4.5.1.2. BPM 系統的目标
BPM系統的主要目标是促進商務流程的自動化。在為業務流程建構軟體中，兩個角色能夠被差別：業務流程分析人員和開發人員，在小點的團隊裡，這兩個角色當然可以是一個人。業務分析人員研究、描述業務流程并指出軟體需求，而開發人員建立可執行的軟體。 傳統BPM套件試着開始從業務分析模型并且按他們的方式向下完成可執行軟體。他們 試着最小化技術技能需求，以至于業務分析人員能夠生産出可執行軟體。所有這一切不可避免的是以圖為中心的，技術細節擾動着分析人員的世界。
圖 4-14 傳統的BPM方案
在我們的視野裡，中心思想是業務分析人員和開發人員使用通用的語言進行溝通在流程的圖形視圖的幫助下。 技術技能将總是必須的當開發軟體。業務分析人員負責圖形化視圖并且不應該去被迫處理流程的技術面。 沒有那些技術面流程将不會完全的定義而且以後它是不可執行的。開發人員負責技術實作面。技術面不應該要求圖的改變。
圖 4-15 改進的BPM方案
4.5.2. 服務編排
最多的被公認服務編排語言的名稱BPEL。服務編排常在企業服務總線（Enterprise Service Bus,ESB）的上下文中看到。ESB是企業級的中央通信主幹。它內建了許多的相異的系統而且基于XML技術。
假設在你的ESB上你有A、B和C 三個服務。服務編排是用來寫作為現有服務的一個函數的一個新的服務的基于圖的執行語言。例如使用編排腳本，一個新服務D能夠作為服務A、B和C的函數而被寫。
圖 4-16 服務
4.6. 基于嵌入圖的語言
當BPM引擎能夠被完全地整合到一個軟體開發項目中、甚至BPM引擎的資料表也被整合到項目的資料庫中時，然後我們提到可嵌入的BPM引擎。那就是我們用GOP瞄準的這個目标：一個基于圖的語言實作的通用基礎。
4.7. 市場
4.7.1. 終極流程語言
傳統上，廠商正在找終極的流程語言。這個方案是用來指定流程語言作為一系列的構成（construct）。每個構成有一個圖形表示和一個運作時行為。換句話說，在流程圖中每個構成是一個節點類型。這樣流程語言隻是一系列的節點構成。 這個思想是廠商正在找最好的流程構成去形成一個統一的可應用流程語言。這個想法今天還是發現了許多而且我們稱它為終極流程語言。 我們相信這一焦點不放在試着去找終極流程語言，而是去找在不同的場景和不同的環境中都能夠被用來作為流程語言根基的通用基礎。我們提出的GOP下一步将被看作這樣的一個基礎。
4.7.2. 相關資訊
目前工作流景色，BPM和編排解決方案完全地分立的。這部分我們将描述下兩個分裂的次元。第一個次元叫BPM産品線（BPM product continuum），它被展示在下一幅圖檔中。這個術語最初是被Derek Miers和Paul Harmon在《The 2005 BPM Suites Report》中引入的。
在左邊，你可以看到程式設計語言。連續體的這邊被瞄準在IT開發人員。程式設計語言是最靈活的而且它完整地內建了為特定的項目而開發的其他軟體。它帶來了相當多的程式去實作業務流程。 右邊，有一個BPM套件。這個套件是完整的被用來瞄準用于業務分析軟體開發環境。軟體圍繞業務流程被開發。無須程式設計不得不被做用來在BPM套件裡建立可執行的軟體。
圖 4-16 BPM産品線
4.7.3. 其他實作技術
基于消息隊列技術。 基于代碼生成技術。 謝謝大家的細節閱讀，技術和能力有限，差錯在所難免，誠惶誠恐。如有問題望大家不吝賜教，虛心學習和交流，
!