分布式訂單編排系統中的基於事件的編排的製作方法

2023-05-31 14:11:21 3

專利名稱：分布式訂單編排系統中的基於事件的編排的製作方法
技術領域：
本發明一般涉及一種計算機系統，特別是涉及一種用於業務處理編排的計算機系統。
背景技術：
訂單管理系統是一種計算機軟體和/或硬體系統，其由多種產業來實施從而有助於訂單的輸入和處理。公司，例如庫存公司和那些使用電子商務的公司，使用訂單管理系統來接收、處理以及履行客戶的訂單。訂單管理系統可以實現通過網站購物服務或數據輸入系統來輸入訂單。該系統通常為每個訂單捕獲客戶專屬信息和/或帳戶級別信息。然後執行信用驗證或支付處理來檢查資金的可用性並確認交易。對有效訂單執行倉儲履行，包括挑選、包裝並發出所訂貨物或服務。業務處理通常由業務架構設計師/分析師進行建模。業務處理可以模擬在網絡服務環境下與不同的系統進行交換的消息。然後業務架構設計師/分析師將該模型提供給信息工程(「IT」)設計師。IT設計師使用編排語言，例如業務處理執行語言(「BPEL」)，對業務處理進行編碼。BPEL處理是在BPEL編輯器中創建的，並且調用所部署的BPEL處理。 因為IT設計師和業務架構設計師/分析師通常具有不同的技能組合(即業務架構設計師 /分析師熟悉所建模的業務處理，而IT設計師熟悉編排語言而不是業務處理)，結果IT設計師所開發的BPEL處理可能不像業務架構設計師/分析師想像的那樣工作。結果，在原始構想的業務處理模型和所實施的模型之間存在著較大分歧。業務處理還存儲著所有相關的數據直至業務處理被關閉。當業務處理長時間運行時，所有相關數據的存儲就成為試圖提高吞吐量時的瓶頸。另外，網絡服務環境下利用不同系統來使用業務處理會導致不同系統的緊密耦合。

發明內容
本發明的一個實施例涉及一種計算機可讀介質，其具有存儲於其上的指令，當被處理器所執行時，使處理器啟動事件管理器，以使用處理來處理訂單。指令包括基於存儲在資料庫中的處理狀態和元數據來確定要執行的處理步驟。指令還包括基於所確定的處理步驟產生一個事件，該事件包括執行與該處理步驟相對應的任務的指令。指令還包括在一個事件消息發送系統上發布該事件。


在下面結合附圖對優選實施例的詳細描述中，本發明的更進一步的實施例、細節、 優點和改變將會變得清晰。圖1示出了根據一個實施例的分布式訂單編排系統的一個實例。圖2示出了根據一個實施例的用於處理訂單的流程圖。圖3示出了根據一個實施例的在訂單實施的上下文中，用於提供編排處理設計和編寫環境的系統的一個實例。圖4示出了根據一個實施例的接口的實例。圖5示出了根據一個實施例的運行時間操作。圖6示出了根據一個實施例的使用流程序列器調用服務的一個實例。圖7示出了根據一個實施例的在不同的層中用於編排數據流的處理。圖8示出了根據一個實施例的用於修改一個可執行處理的方法的流程圖。圖9示出了可實現本發明一個實施例的系統的方框圖。圖10示出了根據一個實施例的分布式訂單編排系統。圖11示出了根據一個實施例的用於處理一個修改請求的方法的流程圖。圖12示出了根據一個實施例的修改請求流程的一個實例。圖13示出了根據一個實施例的可執行處理的一個實例。圖14示出了根據一個實施例的用於調整原始的可執行處理的各步驟的新的可執行處理的一個實例。圖15示出了根據一個實施例的原始的可執行處理和根據所接收的修改請求的新的可執行處理的流程圖。圖16示出了根據一個實施例的依據使用事件管理器的處理來發布一組事件的方法的流程圖。圖17示出了根據一個實施例的使用事件管理器和任務層服務來編排訂單的方法的流程圖。圖18示出了根據一個實施例的使用事件管理器、任務層服務和中介器來編排訂單的方法的流程圖。圖19示出了根據一個實施例的在訂單實現的上下文中使用事件管理器來提供編排的系統的一個實例。圖20示出了根據一個實施例的採用事件管理器的分布式訂單編排系統。圖21示出了根據一個實施例的事件消息發送系統的一個實例。圖22示出了根據一個實施例的事件消息發送系統的發布訂購消息通道的一個實例。圖23示出了根據一個實施例的在分布式訂單編排系統中管理事件的方法的流程圖。圖M示出了根據一個實施例的確定待發布的一組事件的方法的流程圖。圖25示出了根據一個實施例的事件管理器發布用於並行處理步驟的事件的一個實例。圖沈示出了根據一個實施例的事件管理器分割處理的一個實例。圖27示出了根據一個實施例的事件管理器使用事件來處理修改請求的一個實例。圖觀示出了根據一個實施例的分布式訂單編排模塊的功能性的流程圖。
具體實施例方式本發明的一個實施例涉及一種分布式訂單編排系統(「D00」)。分布式訂單編排提供了一種靈活的、可配置的基礎架構，其可被容易地定製以便符合企業的商務實踐以及現有的訂單實施系統的體系結構。分解是指把從一個或多個訂單捕獲模塊接收的數據轉換為內部規範格式以便處理該數據的過程。在一個示範實施例中，分布式訂單編排系統包括 捕獲層，用於在多個通道上捕獲客戶訂單；分解層，用於幫助確定編排處理；編排層，用於執行並編排訂單行處理；任務層服務，用於執行與任務相關的邏輯；外部接口層，用於連接外部系統；實施層；以及全局訂單承諾層，用於為用戶提供界面進行調度和提供資源。分布式訂單編排系統可以進一步地包括一個實施工作檯層，其連接系統的其它層並管理資源、 任務和分配。對以上描述的分布式訂單編排系統的各個層進行組合，從而提供一個降低了實施和維護成本的完整的訂單管理解決方案。然而，在一個可選的實施例中，捕獲層不是分布式訂單編排系統的一部分。在該可選的實施例中，捕獲層是一個單獨的系統的一部分，使用一個連接器服務來作為分布式訂單編排系統和該捕獲層之間的橋。圖1示出了根據一個實施例的分布式訂單編排系統100的一個實例。在該實施例中，分布式訂單編排系統100包括捕獲層110，其能夠在多個通道上接收並捕獲與客戶對貨物和/或服務的訂單有關的信息。該訂單可以通過圖形用戶界面來接收，例如網站購物車， 或者能夠通過任意數據輸入系統來接收。捕獲層Iio捕獲並向分解層120發送訂單信息。 然而，在一個可選實施例中，捕獲層110與分布式訂單編排系統100是分離的。在該可選的實施例中，使用一個連接器服務來作為分布式訂單編排系統100和該捕獲層110之間的橋。訂單捕獲系統捕獲的訂單具有任意必要的用於處理訂單的功能屬性，例如定價、 驗證、合格等。銷售訂單以源訂單對象的形式被饋送到分解層120。源訂單對象是從不同的捕獲系統所提交的銷售訂單對象中產生的。源訂單對象具有饋送到分解層120的通用的格式。分解層120接收訂單信息並將所接收的訂單拆分為單個的購買定單，以被發送到實施系統以及供應商來執行。分解層120可以包括分解規則工作檯，用於建立規則、規則集合以及用於訂單捕獲層110的轉換處理，它們可以從銷售角度捕獲訂單。例如在全球範圍內銷售一種膝上電腦。該膝上電腦包括一根電源線，但是客戶只購買了膝上電腦(訂單上的一行)。也就是說，銷售網站可能會只銷售該膝上電腦而不會讓再客戶單獨訂購電源線。 然而，從實施角度看，膝上電腦和電源線需要從訂單中取回。在分解層120中，存在著這樣的業務規則，即膝上電腦必須具有電源線並且電源線上的插頭必須與膝上電腦的運輸目的地國家相匹配。因此當分解模塊120完成時，訂單就具有了兩行，一行是膝上電腦，另一行是合適的電源線。這樣訂單就被分解為多個待實施的項目。而且，分解層120可以取得所接收的訂單並將其翻譯成分布式訂單編排系統100 的其它層，例如實施層160，所需的訂單格式以及訂單內容。因為捕獲層110出於兼容性目的，能夠在不同類型的系統上接收任意格式的訂單，因此分解層120就需要將訂單翻譯成與該分布式訂單編排系統100所有的其它層和/或處理相兼容並能夠被它們識別的格式。 另外，分解層120可以提供一種處理啟動能力，用來基於適當的分解規則分配並啟動訂單的編排處理。例如，基於訂單中的參數分配不同的編排處理。例如，公司可以按照實施或運輸的速度對某些客戶給予特殊待遇。例如，金卡客戶可以給予加快運輸。而且，也可以提供與客戶溝通的附加步驟。當接收到這些客戶的訂單時，它們就被分配給具有這些參數和步驟的編排處理，而其它客戶的訂單就被分配給標準處理。
分解可以使用規範對象模型來完成與訂單捕獲系統的數據格式的解耦合。分解整合處理工作在稱作企業業務對象(EB0’s)的一組通用數據結構上。它們是基於規範數據模型的。這種方法允許DOO不不必知曉所參與的應用程式並且獨立於源或目標應用程式。該模型消除了使來自不同的應用程式的數據互相直接映射的需要。如圖1所示，分布式訂單編排系統100進一步包括一個編排層130。編排層130提供了單獨的編排處理用於管理訂單和/或服務行項目。例如，編排層130可以提供業務處理管理功能，以便支持處理中的步驟的調度，包括步驟的持續時間和完成日期的計算或重新計算。編排層130還可以提供外部任務執行功能，以便支持外部任務的創建、更新、釋放和監控。外部任務是由實施系統來執行的任務。任務層服務進行特殊處理然後將數據發送到那些集成的實施系統。編排是任務層服務的調用的順序。編排層130還可以提供風險管理，以把訂單的承諾的交貨日期與當前的完成訂單的估計日期進行核對，映射到用戶定義的閾值，以及處理並逐步提高條件。編排層130可以進一步提供用於修改訂單的處理，包括一個支持處理，用以退回到提供修改訂單自動操作的階段並對訂單捕獲階段所修改的訂單更改實時編排處理。而且，可以通過實例化該編排處理來提供預計的訂單完成日期。編排層130還提供一種機制用於自動地或基於用戶請求來更新訂單狀態。一個實施例提供了一種工具，用來在訂單實施業務處理中為業務處理的模型化提供高度抽象。業務處理可以由用戶例如業務分析師來模型化，並且不需要任何IT設計師來編寫代碼以執行業務處理。在中心位置定義業務處理為用戶提供了靈活性，其中該中心位置被配置為輸入並捕獲編排並實施訂單所需的所有信息。這種中心位置的一個實例可以是基於網絡的管理用戶界面。同樣地，編排和訂單實施所需的所有信息的一個實例可以是業務調度、核心編排和修改管理所需的信息。業務處理可以確認定義了要在訂單實施處理中執行的步驟的一個或多個服務。運行時間引擎然後使用該定義並基於業務處理的定義來動態地調用這些服務。在業務環境下，業務用戶通常會面對模型設計師而不是IT人員。通過提供一種基於網絡的管理環境，業務用戶就可以設計業務處理了。處理的定義可以用業務術語而不是 IT術語來定義。特定的實施例允許管理環境脫離代碼編輯器例如BPEL編輯器之外，用來使用相關服務來定義這些處理。用戶可以將這些能夠在運行時間上執行的處理配置為可執行處理，而不需要IT的介入。這就減少了每次部署這些處理就要修改業務處理的需要。用戶在數據表上設置服務的序列。然後模型化的業務處理被用於執行一個可執行處理(也被識別為編排處理)，其可以在運行時間上被安裝及執行。在一個實施例中，「運行時間」可被定義為當接收訂單以便進行處理的時間。元數據被安裝在數據運行時間表中，並用於定義業務處理的可執行處理。元數據用於在可執行處理中調用服務。在一個實施例中，所調用的服務被封裝並且是可重複使用的。元數據用於確定怎樣和何時調用服務。而且，依靠元數據，產生輸入變量並發送給各個服務以便調用被封裝的服務。使用公共籤名來發送數據從而調用服務。不同的輸入變量可以針對不同的可執行處理中的不同的服務來公式化。輸入變量以相同方式來格式化，以便使服務能夠讀取不同的數據組並調用服務。這樣，服務就可以在不同的業務處理中重複使用，而不需重新編碼及重新部署。服務的部署表示該處理準備好發布以進行測試或生產。
分布式訂單編排系統100可以進一步包括任務層服務140，以提供用於為每個編排處理階段控制處理邏輯的封裝服務。具體地說，任務層服務140可以提供任務專用業務邏輯，使該邏輯圍繞某個請求，以便使系統100知曉何種邏輯任務與特定請求相關。需要在編排中的可執行處理中執行的步驟可以請求要被執行的任務。例如，任務層服務140能夠提供並控制處理邏輯，以安排運輸、請求運輸、更新安裝平臺、創建活動等等。任務層服務 140的輸出是標準的貨物和/或一個或多個服務請求，它們可被提供給系統100的其它層， 例如外部接口層150或實施層160。另外，任務層服務140可以接收用於更新處理邏輯或狀態的輸入。任務層服務140啟動該任務，產生用於外部系統的消息並發送該消息。產生執行該任務所需的數據結構。某些任務可以在任務層服務中預先定義。而且，客戶可是使用定義了如何創建一項任務的模板來增加其它任務。所產生的消息指示了哪個任務應當由外部系統來執行。待執行的任務是已被模型化的訂單處理的體現。例如，任務可以是為訂單開帳單。還可以包括用於執行任務的參數。向外部接口層150的外部接口發送該消息。任務層服務140轉換該消息並將其發送給外部接口層。分布式訂單編排系統100還包括外部接口層150，用於翻譯標準請求並將請求路由至外部系統以便處理。更特別地，外部接口層150可以接收從任務層服務140輸出的標準貨物和/或服務的一個或多個請求，並且如果需要的話就就提供請求的單層轉換以匹配實施系統的格式。外部接口層150所執行的轉換將數據映射到集成實施系統所需的內容和格式。分解層120的轉換是將數據轉化為系統100使用的內部格式。外部接口層150可以將來自任務層服務140的數據結構映射到外部格式。外部接口層150提供靈活的路由以便使這些請求基於業務規則路由到具體的實施系統。例如，如果多於一個運輸系統是可用於實施的，那麼業務規則將確定各個運輸請求要被發送到哪個運輸系統。外部接口層150還可以包括轉換規則工作檯，該轉換規則工作檯能夠用於建立規則、規則集合以及用於外部路由該請求的轉換數據。任務層所產生的消息可以是通用格式的。然而不同的外部系統可以使用其他的格式來通信。外部接口層確定外部系統所使用的格式並轉換該消息。例如，用戶定義的元數據可用於確定要使用哪種格式。在一個實例中，對哪些外部系統調用了所訂購的產品的映射，被用來翻譯該消息。外部系統可以是執行與處理訂單相關的任務的系統，例如可以是調度系統、運輸系統等等。當執行任務時，確定任務的結果。結果可以是調度運輸時的日期，運輸貨物的日期等等。然後結果被送回外部接口層150。分布式訂單編排系統100可以進一步包括全局訂單承諾層170，該全局訂單承諾層170提供用於調度訂單並為訂單提供資源的接口，例如圖形用戶接口。特別是在一個實施例中，全局訂單承諾層170包括一個來源經紀人，用於基於客戶概要、訂單和供應商定義等確定與訂單相關的產品和服務的最佳來源。而且，全局訂單承諾層170在分布式內部系統上提供實時的庫存儲備和未儲備以及庫存的檢查。全局訂單承諾層170的接口允許瀏覽可用性和來源信息，以便使用戶能夠瀏覽其可用性並手動修改實施貨物或服務訂單的來源。然而，在一個可選實施例中，全局訂單承諾層170是與分布式訂單編排系統100分離的。 在該可選實施例中，使用一個連接器服務來作為分布式訂單編排系統100和全局訂單承諾層170之間的橋。實施工作檯180可以作為訂單實施管理員、用戶和監管員的用戶接口，用來監控並管理訂單在系統100內的流動。在一個實施例中，實施工作檯180向用戶(例如監管員) 提供監控訂單實施任務的機制，包括允許監管員監控活動的加載並生成報告。實施工作檯 180還提供了實施處理分析，其允許業務處理設計者分析處理的度量標準，例如手動幹預的數量、發生錯誤的數量和種類、超期訂單的數量以及期望處理周期與實際周期的對比。在某些實施例中，實施系統性能的分析能力也包含在實施工作檯180中，用以提供報告和儀錶板使訂單管理者能瀏覽每個系統的訂單並分析性能。實施工作檯可以使用圖形表示法(例如圖表和曲線)來向用戶清晰地傳達系統狀態/訂單信息。由於DOO系統100具有數據參考數據，因此可以畫出合計圖表/曲線用於趨勢分析。如下所述，用戶可以從實施工作檯採取動作，例如替換所訂購的項目、將數量分割為多個訂單行、保持訂單行以防止繼續發展寸。根據一個實施例，實施工作檯180允許用戶做出與實施相關的大量訂單信息的修改，包括對實施信息(例如日期等)進行一行或多行的修改。實施工作檯180進一步允許對編排處理的監控，例如回顧編排處理的狀態，包括整個處理的進展，以及各個任務的狀態和相應的實施行和人物行。在一個實施例中，實施工作檯180包括維護訂單實施處理的機制，並允許訂單處理用戶控制與訂單相關的處理，包括暫停、編輯、取消等等。在某些實施例中，實施工作檯180還提供用於訂單和任務分配的功能。例如，實施工作檯180可以使用分配引擎來將訂單和活動分配給合適的實施資源。實施工作檯180可以包括批量對訂單進行再分配的機制，從而允許監管員從一個實施系統到另一個實施系統重新為一組訂單提供資源。實施工作檯180還提供供應率的分配和延期交貨的規則，它們能夠自動確定如何控制短缺狀況。通用收件箱可以包含在實施工作檯180中，用以允許用戶瀏覽分配給他們的活動並對任務作出響應。實施工作檯180允許用戶瀏覽正在系統100的不同層中處理的訂單。對訂單狀態的瀏覽可以從任何一個處理該訂單的層中產生。這是因為已經提供了一個端到端集成系統因。傳統的訂單系統已經將解決方案定製成不允許瀏覽不同層。通過以一個允許通用通信的格式集成各個層，就能提供一個可以從所有層中產生瀏覽的用戶接口。分布式訂單編排系統100的實例還可以包括一個實施層160。在一個實施例中，實施層160可以是面向外部實施系統的接口，並能夠用於將訂單信息和實施需求傳輸給與訂單相關的貨物和/或服務的供應商或來源。分布式訂單編排系統100的某些實施例包括一個管理用戶接口。管理用戶接口提供了對終端用戶隱藏實施執行環境的複雜性的管理服務。例如，該管理用戶接口通過一個管理環境提供產品映射，該管理環境定義了一些轉換方式，以用於在銷售視圖和供應商系統定義之間進行產品結構的映射。在該實施例中，銷售視圖指的是在下購買訂單時提供給客戶的簡單視圖。供應商系統定義指的是由貨物和/或服務供應商所使用的更具體和詳細的信息。管理用戶接口還可以提供一個編排處理工作檯用於建立用於訂單編排的處理、規則集合和參數。管理用戶接口具有一個集成的設置，包括處理順序、計劃、風險、修改管理和工作檯顯示。管理用戶接口還允許用於任務、處理和實施行的用戶定義狀態的轉變，以及用於配置約束、轉換規則和路由規則的業務規則配置。
圖2描述了根據一個實施例的用於處理訂單的簡化流程圖200。在步驟202中，分解層120接收一個訂單。在步驟204中，分解層120確定用於實施訂單的一個或多個編排處理。例如，訂單可以被分解成必須要獲得的項目或必須要執行的服務。每個項目或服務可以具有其自身的編排服務。在步驟206中，編排層130產生可執行處理用以編排這些編排服務的實施。可執行處理可以具有多個必須對每個編排服務執行的步驟。在步驟208中，任務層服務140對執行該可執行處理的各步驟所需的業務功能進行控制。為可執行處理來執行的任務可以包括建立具有信息和參數的數據結構，這些信息和參數是使外部系統執行該任務所必須的。該數據結構可以按照系統100的內部格式。例如，該任務可以是為一個訂單開帳單。並且還包括用於執行該任務的參數。在步驟210中，外部接口層對任務進行翻譯並將其路由到外部系統。然而，不同的外部系統可以使用其他的格式進行通信。外部接口層確定外部系統所使用的格式並對消息進行轉換。例如，用戶定義的元數據可以用於確定要使用的格式。在一個實例中，對哪些外部系統調用了所訂購的產品的映射，被用來翻譯該消息。在步驟212中，外部接口層150接收來自外部系統的、關於任務處理的結果。當執行任務時，就確定該任務的結果。結果可以是計劃發貨日期，發貨日期等等。在步驟214中，外部接口層150轉換消息並將其發送到任務層服務140。在步驟 216中，編排層基於該結果更新關於任務的信息。例如，結果可以存儲在表或資料庫中。然後該處理前進到下一個要被調用的服務。下面將參照圖3-8以及根據使用流程序列器進行編排的實施例，來描述更多實現編排的細節。然而，本領域技術人員將會容易地理解，更多的細節只是編排的一個實例，這種編排還可以採用許多不同的實施方式來實現，包括不使用流程序列器的可選實施例。例如，可以根據美國專利申請號12/697，756、名為「使用模板的業務處理的編排」中描述的細節來實現編排。圖3示出了根據一個實施例的在訂單實施的上下文中，用於提供編排處理設計和編寫環境的系統300的一個實例。在該實施例中，系統300包括一個編排系統302和客戶機304。儘管只提供了編排系統302和客戶機304的單個實例，但可以理解，還可以使用多個編排系統和客戶機的多個實例。而且，編排系統302和客戶機304可以是分布式計算系統的一部分。也就是，所描述的功能可以分布於各種計算設備中。客戶機304可以是一個計算設備或一組計算設備，它們被配置為允許業務處理模型化。編排系統302編排用於業務處理的可執行處理310的服務的調用和運行。如所描述的那樣，編排是要在業務處理中執行的服務的協調和調用。如所使用的，業務處理可以由用戶來模型化。業務處理是對要執行的步驟的定義。 這些步驟定義在接口 308中。可執行處理是由運行時間引擎312執行的處理。該可執行處理包括要被執行以協調服務的代碼。服務庫306包括多個可包含在業務處理中的服務。在一個實施例中，服務庫306包括可在一個訂單實施業務處理中執行的服務。訂單實施包括被執行用以實施訂單的處理。 例如，可以從訂單捕獲模塊中接收訂單。訂單可以是用於貨物、服務等。可以執行不同的服務來實施訂單，例如運輸、安裝、貨品計價等。訂單實施處理可以根據這些不同的服務來特性化。期望對於任一個訂單，這些處理中的某些或全部要被執行用以實施訂單。因此，特定的實施例針對那些期望在訂單實施處理中執行的服務而創建服務。服務可以是非可配置單元和可配置單元。非可配置單元是建立並提供給客戶的服務。非可配置單元是可被用在訂單實施處理中的單元。例如，如所期望的，必須要在訂單實施處理中執行不同的服務，例如應收帳款。因此，這些服務可以用語言來模型化，例如BPEL。 儘管描述的是BPEL，但本領域技術人員可以容易地理解，也可以使用其他的語言。可配置單元是由客戶建立並定義的服務。例如，在由用戶配置的服務周圍提供包裝器。例如，客戶需要專門對客戶的公司的運輸服務。因此，由可配置單元執行的服務可由客戶定義並建立，但包裝器允許運行時間引擎312來自動調用服務。這使得客戶能夠定義他們各自組織所需要的服務。 服務可以在不同業務處理中重新使用。服務可以被封裝並被配置為接收待執行服務的公共籤名。例如，對於每個業務處理，可以提供不同的參數(即用不同的價格訂購不同的產品，等等)。這導致了不同的輸入變量輸入到了服務中。公共籤名定義了一個數據結構，以允許對不同的可執行處理310重複使用該服務。這樣，用相同部署的服務來處理不同訂單的不同輸入變量，但是可以獲得不同的結果。以這種方式，就能抽象出訂單實施處理。 不同的用戶可以定義哪個服務要被執行而不用考慮到這些處理是如何用編排語言編碼的。接口 308可以是一個管理用戶接口。例如，圖形用戶接口允許用戶在一個抽象級別上模型化業務處理。例如，服務庫306可以被提供給客戶機304。然後用戶可以使用接口 308來定義使用了服務庫306中的服務的業務處理的步驟。用戶可以定義業務處理中的許多步驟。每個步驟可以與服務庫306中的服務相關聯。這些步驟可以存儲在數據表中，數據表可以包括由運行時間引擎312使用的元數據，用以編排可執行處理310。數據表被示為存儲在存儲器314中。可以理解，數據表可以存儲在任意區域中，例如在客戶機304、編排系統302或其他設備中。元數據可以由用戶來定義、從數據表和/或編排規則中確定。用戶定義了要調用的服務的順序以及需要的條件或並行分支，來影響業務處理規則。當用戶選擇了用於一個處理步驟的服務時，用戶也提供了附加的元數據，用於確定在運行時間中如何在訂單的處理過程中執行處理數據。例如，定義條件或並行分支。在運行時間中，運行時間引擎312接收元數據並使用元數據來確定用於編排可執行處理310的參數。運行時間引擎312使用這些參數來確定可執行處理310中的哪些步驟要執行，什麼時候執行。例如，運行時間引擎312通過調用一系列由用戶定義的步驟中的服務，來編排可執行處理310。如下更詳細的描述，也可以執行步驟的並行和條件處理。而且， 元數據能夠用於確定用來調用服務的輸入變量。在運行時間中讀取表的元數據，並調用服務，這允許執行對可執行處理310的修改，並自動地在運行時間中實現。運行時間引擎312讀取所定義的每個步驟並執行這些步驟。如果需要在服務中進行修改，用戶可以使用接口 308來增加/刪除/替換一個服務。在運行時間中，當讀取表時，可以自動地執行這種修改。圖4示出了根據一個實施例的接口 308的實例。處理級別表416概括了已被模型化的不同業務處理。如圖所示，業務處理-地毯安裝和處理1-已由用戶模型化。在處理級別表416中，處理名稱列418示出了業務處理地毯安裝業務處理和處理 1已經被模型化。描述列420描述了該處理。處理分類列422描述了處理的分類。狀態列4 是可執行處理的狀態。可執行處理310可以具有不同的狀態。例如，某些業務處理可以被批准為生產、被批准為測試、或可以是新的。被批准為生產意味著服務被批准為正常的業務使用，被批准為測試意味著被批准為進行測試，而新的是在開發中的服務。表416中的業務處理可以被選擇，並且數據表400示出了單個的業務處理的步驟細節。一個業務處理被命名為地毯安裝，數據表400的步驟細節示出了已經對地毯安裝定義的每個服務。在數據表400中，步驟列404標識了業務處理中的步驟。例如，提供步驟10_60。 用於這些步驟的服務可以在運行時間中被執行。這些步驟可以從頂部到底部按順序(或以任意其他的次序)執行。在這種情況下，執行步驟10，然後當完成後，執行步驟20，等等。另夕卜，儘管未示出，還可以使用接口 308定義條件和並行步驟。條件步驟是依賴於結果的發生的步驟(例如另一步驟的結束)，而並行步驟是並行執行的。用戶定義了步驟是條件的還是並行的。步驟名稱列406提供了用於各步驟的描述名稱。例如，提供運輸地毯、等待運輸、 安裝地毯、等待完成、開帳單等步驟。任務類型列408描述了什麼類型的任務正在被執行。例如，對於運輸地毯的任務， 外部系統可以執行運輸任務，對於開帳單的步驟，帳單系統可以為一個帳單開帳單。服務列412標識了與該步驟相關的服務。任務名稱列414是任務的名稱。例如， 那些與地毯相關的任務被命名為地毯運輸、地毯安裝、為地毯開帳單。如果正在安裝的是地毯之外的其他貨物，任務名將會不同。例如，水槽運輸、水槽安裝、為水槽開帳單將會成為這些任務的名稱。用戶可以使用接口 308來產生數據表400。用戶可以從用於服務庫306的菜單中選擇服務。例如，用戶使用菜單接口 432來從服務庫306中選擇服務。下拉菜單、拖放選項和其他的可視處理可以用於定義可執行處理310。用戶具有一個具體編排接口，用於以合適的驗證呈現業務處理數據，而不是要去學習多用途IT開發環境的複雜性。這允許用戶以抽象的方式模型化一個業務處理，但是使可執行處理310從該模型中產生和執行。服務庫306中的服務可由非可配置單元和可配置單元來構成。例如，非可配置單元設置在列440中，可配置單元設置在列442中。如圖所示，非可配置的服務包括運輸、應收帳(「AR」)、開帳單以及全局訂單承諾(「G0P」)。而且，可配置的單元被指定為A、B、C 和D。如圖所示，使用菜單412在接口 308中產生表400。表400與元數據和任意變量相關， 其中元數據描述了要被執行的服務，變量用於調用這些服務。一旦業務處理在接口 308中被模型化並通過設置處理狀態而被釋放，那麼運行時間引擎312用於編排服務的調用。圖5示出了根據一個實施例的運行時間操作。在該實施例中，表讀取器502從接口 308接收定義了業務處理的元數據。表讀取器502可以將數據複製到運行時間表506中，但這不是必須的。根據該實施例，在運行時間期間，步驟讀取器504被配置為讀取運行時間表506中的步驟。步驟讀取器504可以分析元數據並確定那些步驟應當被執行以及何時被執行。例如，步驟讀取器504驗證並行或條件分支是否與一個步驟相關。元數據還用於確定用於服務的輸入變量。輸入變量可以從元數據、查找表中的數據中確定，或者使用規則來確定。根據該實施例，步驟讀取器504使用來自服務306的封裝的服務以及元數據來組合可執行處理310。例如，為可執行處理310確定在這些步驟中被模型化的每個服務的代碼。還可以確定每個服務的輸入變量。例如，元數據用於確定輸入變量，以便使服務能處理用於業務處理的訂單。而且，可使用元數據來確定任意的合作者連結，以便允許服務與外部系統交互。基於業務處理中的步驟的定義來組合可執行處理310。由於服務是可重複使用的，用於一個服務的相同代碼可以用於不同的業務處理。然而，輸入變量或合作者連結可以是不同的。由於相同的代碼被重複使用，因此提供了可執行處理310的自動組合。在該實施例中，流程序列器508用於基於可執行處理310在適當的時間動態地調用這些步驟。如方塊507所示，步驟10可以確定要調用的服務。然後執行步驟20、30、40 和50中的一個。然後步驟60確定是否需要執行其他步驟。在這種情況下，步驟20、30、40 和50中的一個可能會被執行。流程序列器508可以依賴於接收的元數據的內容來確定相關的輸入變量。然後這些輸入變量用於調用一個服務。例如，流程序列器508可包括一個任務層讀取器510，其確定要調用的服務。任務調用器512然後動態地調用該服務。使用任意的輸入變量來調用該服務。在調用服務的過程中，執行已封裝服務的代碼來協調服務的執行。例如，準備可執行代碼並向外部系統發送一個消息來執行該服務。然後可以執行服務並且在結果接收器514處來接收結果。在一個實例中，如果任務是運輸，那麼運輸服務就對運輸系統產生一個關於貨物運輸的消息。一旦該運輸系統運輸該貨物，存儲了結果的消息就會返回到該運輸服務。在接收結果之後，驗證是否要執行更進一步的序列。例如，一個「當」活動模塊檢查是否需要處理更進一步的服務。例如，處理可以返回到流程序列器508，以便允許動態調用處理中的其他步驟。而且，該「當」活動模塊可以等待直到並行分支完成為止。因此，自動地基於該運行時間表來確定調用服務所需的信息。在一個實例中，在 BPEL中，已經創建了所有調用所必需的合作者連結，並且它們被用於調用服務。在BPEL合作者連結中所呈現出的服務被部署成BPEL處理，其不需要更多的配置就可以用在多個業務處理的定義中。當運行時間引擎調用了一個服務時，在下層BPEL處理中訪問相應的合作者連結。通過使用運行時間表中的元數據來產生服務的組合以及任意服務的修改，並且可以通過接口 308來管理。因此，用戶可以在業務處理中建立這些步驟。可執行處理310可以自動地在運行時間上組合。可執行處理310中使用的代碼不是由建立該業務處理的用戶產生。而是，可以定義元數據並用其來組合已封裝的用於可執行處理310的服務。圖6示出了根據一個實施例的使用流程序列器508調用服務的一個實例。在步驟 602，根據該實施例，確定是否需要分支。如果遇到條件聲明，處理就基於滿足了哪個條件從而前進到合適的分支。如果遇到並行分支，就產生並行流程序列實例，來執行附加的分支。 確定分支並隨後將其用在服務的調用中。然後處理前進到在其中確定服務的步驟604。然後執行各種服務。這些步驟包括調用服務步驟、調度步驟、運輸步驟、等待步驟、 帳單步驟和子處理步驟。同樣的處理序列採用並行流動的方式，直至到達合併步驟。每個流程序列包含相同的下層代碼化處理(例如BPEL處理)，但是不同的處理序列可以用在不同的可執行處理310中。也就是，一個序列可以包含調度、運輸、帳單，而另一序列可以包括調度、活動、運輸、活動、帳單，雖然包含下層代碼化處理的運行時間引擎不變。也就是說，儘管正運行著不同的可執行處理，但被調用的每個服務的代碼保持相同。
流程序列器的每個分支中包含有外部服務調用，每個可被調用的服務具有一個分支。分支包含所有用於設置應當被包括在發送給特定外部服務的消息中的數據所必須的步驟以及用于格式化從該服務接收的響應的必須的步驟。一旦完成服務，「當」活動模塊驗證是否有進一步的服務要處理，然後返回到流程序列器508、繼續處理的下一步驟或者等到任意並行分支的完成。方塊606示出了可執行處理310的概念性執行。不是所有的步驟都立即運行。例如，為步驟10調用該調用服務，並且確定要調用的服務。一旦這些完成之後，步驟608確認是否需要執行其他的步驟。在這種情況下，步驟604確定調度、運輸、等待、帳單和子處理服務應當被執行。一旦全部的流程都已完成，就會構造統一的結果集合。基於該可執行處理的定義，確定是否應當執行附加處理。執行不同的分支，每個分支調用相關的服務。服務的輸入變量從運行時間表中的元數據產生。當已執行所選的服務時，步驟608確定是否應當執行附加的服務。如果是，處理返回步驟602重複處理。如果不是，結束處理。使用表400的信息來提供服務的編排。然而，除了編排之外，服務需要與外部系統進行通信。圖7示出了根據一個實施例的在不同的層中用於編排數據流的處理。提供編排層、任務層、外部接口層和外部系統層。在一個實施例中，在編排層之前提供一個分解層 (未示出)。根據該實施例，步驟702為任務產生並發送一個調用。可以從訂單捕獲模塊接收一個訂單。這可導致任務的調用。使用在運行時間表中找到的數據來產生調用請求。請求被發送給任務層。根據該實施例，步驟704啟動該任務，產生用於外部系統的消息，並發送該消息。 所產生的消息表示哪個任務應當由該外部系統來執行。要被執行的任務是已經模型化的訂單處理的一個方面。例如，任務可以是一個訂單開帳單。還可以包括執行該服務的參數。該消息被發送到一個外部接口。根據該實施例，步驟706轉換該消息並將其發送到外部系統層。任務層產生的消息可以是通用格式的。然而，不同的外部系統可以使用其他的格式來通信。外部接口層確定外部系統所使用的格式，並轉換該消息。例如，用戶定義的元數據可以用於確定要使用的格式。在一個實例中，對什麼外部系統調用了所訂購的產品的映射，被用來翻譯該消息。根據該實施例，步驟708接收該外部系統返回的消息並處理該產生了結果的消息。該外部系統可以是執行與處理一個訂單相關的任務的系統，例如，調度系統、運輸系統等等。當執行任務的時候，確定該任務的結果。結果可以是安排好的運輸日期、運輸貨物的曰期等等。然後結果被發送回外部接口層。在該實施例中，步驟710轉換該消息並將該消息發送到任務層。步驟712基於結果更新用於該任務的信息。例如，結果可以存儲在表或資料庫中。然後處理繼續到下一個可被調用的服務。通過使用以接口 308定義的已封裝的服務，就能對可執行處理310進行修改並在運行時間中實現。例如，在處理的運行過程中對元數據的改變會影響所採用的步驟的順序以及各步驟的輸入變量。圖8示出了根據一個實施例的用於修改業務處理的方法的流程圖800。在一個實施例中，圖8的流程圖800的功能，以及圖中所示的其他流程圖的功能，是由存儲在存儲器或其他計算機可讀或有形介質中的軟體來實現的，並且由處理器來執行。在其他的實施例中，功能可以由硬體(例如通過使用特定用途集成電路(「ASIC」)、可編程門陣列(「PGA」)、 現場可編程門陣列(「FPGA」)等)，或者軟體和硬體的組合來執行。步驟802接收對業務處理的修改。例如，接口 308用於修改業務處理以包含不同的步驟。在一個實例中，步驟可以被替換、刪除或增加。步驟804接收用於修改的元數據。例如，運行時間引擎312可以接收該修改的元數據。然後步驟806修改運行時間表來反映對元數據的修改。例如，可執行處理310可被修改以包含不同服務來調用。當要調用一個服務時，步驟808讀取運行時間表以便確定要調用的服務。例如，步驟讀取器504可以在可執行處理310的處理期間讀取該表。如果運行時間表已被修改，步驟讀取器504基於修改確定要被執行的下一步驟。然後步驟810調用所確定的服務。由於可以基於不同的輸入變量調用服務，因此在業務處理中的服務被修改時，就不需要進行附加的編程來重新部署新服務。相反，可以僅修改表就能自動地調用不同的服務。然後步驟812確定是否需要執行更多的服務。如果是，處理返回到步驟806，再次讀取表來確定要執行的下一步驟。如果不是，處理結束。因此，受數據驅動的編排提供了抽象化和靈活性。抽象化指的是對處理元數據的基於網絡的管理，該元數據定義了在可執行處理中的處理步驟。在不同的業務處理上重複使用處理代碼。靈活性指的是修改處理而不需重新部署代碼的能力。對運行時間元數據的修改的使用有助於對可執行處理310的修改。抽象化使處理模型更接近於商業用戶並降低了管理成本。靈活性允許商業用戶對修改進行響應，例如當業務處理或規則修改時對業務說明書的更改。圖9示出了可實現本發明一個實施例的系統900的方框圖。在本發明的一個實施例中，圖9的系統900對應於圖3的編排系統302。系統900包括總線902或其他的通信機制，用於在系統900的部件之間發送信息。系統900還包括處理器914，可操作地耦合到總線902，用於處理信息並執行指令或操作。處理器914可以是任一種通用或專用目的處理器。系統900進一步包括存儲器904，用於存儲信息和要由處理器914執行的指令。存儲器904可包括隨機存取存儲器(「RAM」)、只讀存儲器(「ROM」)、如磁碟或光碟的靜態存儲器或者其他任意類型的機器或計算機可讀介質的任意組合。系統900進一步包括通信設備 912，例如網絡接口卡或其他通信接口，用以提供對網絡的接入。結果，用戶可以通過網絡或任意其他的方式與系統900直接或遠程地連接。在本發明的一個實施例中，用戶可以通過客戶機，例如圖3中的客戶機304，與系統900連接。計算機可讀介質可以是能夠被處理器914訪問的任意可用介質。計算機可讀介質可包括易失性和非易失性介質、可移動和非可移動介質、通信介質和存儲介質。通信介質可以包括計算機可讀指令、數據結構、程序模塊或其他以調製的數據信號為形式(例如載波，或者其他的傳輸機制)的數據，並且可以包括任意的信息傳遞介質。存儲介質可以包括RAM、快閃記憶體、ROM、可擦除可編程只讀存儲器(「EPR0M」)、電可擦除可編程只讀存儲器 (「EEPR0M」)、寄存器、硬碟、可移動盤、壓縮盤只讀存儲器(「CD-ROM」)或現有技術中所知的任意其它形式的存儲介質。
處理器914還能夠可操作地通過總線902耦合到顯示器916，例如液晶顯示器 (「IXD」)。顯示器916可以向用戶顯示信息。鍵盤918和光標控制設備920，例如計算機滑鼠，也能夠可操作地耦合到總線902，來使用戶能與系統900進行連接。根據一個實施例，存儲器904能存儲那些可在由處理器914執行時提供功能的軟體模塊。模塊可以包括作業系統906、分布式訂單編排模塊908以及其他功能模塊910。作業系統906為系統900提供作業系統的功能。分布式訂單編排模塊908執行業務處理的編排，如上所述以及如下所述。系統900還可以是更大系統的一部分。這樣，系統900可包括一個或多個附加的功能模塊910，以用於包含多個附加的功能。例如，功能模塊910還包括中間件模塊，其是來自Oracle公司的「Fusion」產品的一部分。處理器914還可以通過總線902可操作地耦合到資料庫934。資料庫934能夠以邏輯關聯的記錄或文件的集成收集來存儲數據。資料庫934可以是操作資料庫、分析資料庫、數據倉庫、分布式資料庫、終端用戶資料庫、外部資料庫、導航資料庫、存儲器內資料庫、 面向文檔的資料庫、實時資料庫、關係資料庫、面向對象資料庫或現有技術中所知的任意其它形式的資料庫。圖10示出了根據一個實施例的分布式訂單編排系統1000，該系統能夠處理修改請求。在本發明的一個實施例中，系統1000對應於圖3的系統300，並且只有系統300中的與此處的討論相關部分包含在系統1000中。為了清楚略去了系統300的所有其它部分。在圖10所示的實施例中，圖9的分布式訂單編排模塊908被表示為兩個模塊分解模塊1020和編排模塊1030。然而，本領域技術人員將會容易地意識到，單個模塊也可以提供分解模塊1020和編排模塊1030的功能，並且也包含在本發明的範圍中。而且，圖9的分布式訂單編排模塊908可以呈現為任意數量的模塊，並且也包含在本發明的範圍中。下面將參照圖10所示的分解模塊1020和編排模塊1030來描述編排的一個示例性實施例。然而，本領域技術人員將會容易地理解，所描述的實施例只是一個示意性實施例，根據可選的實施例也可以實現這種編排，並且也包含在本發明的範圍中。分解是將從一個或多個訂單捕獲模塊中接收的數據轉換為內部規範格式，用於處理該數據。如上所述，編排是要在業務處理中執行的服務的協調和調用。在一個實施例中，分解模塊1020從一個或多個訂單捕獲模塊中接收訂單，並作為一個或多個訂單捕獲模塊和編排模塊1030之間的中介。訂單捕獲模塊能夠在多個通道上捕獲訂單。在所描述的實施例中，訂單捕獲模塊由訂單捕獲模塊1010來呈現。在本發明的一個實施例中，訂單捕獲模塊1010可以捕獲由用戶通過圖3的接口 308輸入的信息。然而， 本領域技術人員將會容易地理解，訂單捕獲模塊1010可以採用其它的形式，並且也包含在本發明的範圍中。根據該實施例，分解模塊1020還可用於對從訂單捕獲模塊1010發送的對象進行翻譯和分解，其中該對象代表一個訂單。使用翻譯和分解的輸出，分解模塊1020創建了一個要發送到訂單模塊1030的分布式訂單編排訂單(「D00訂單」)。DOO訂單是用來代表從訂單捕獲模塊接收的訂單的對象，並且已被轉換為可被編排系統使用的對象格式。這樣，對 「訂單」的引用就是對訂單捕獲系統中用戶輸入的業務訂單的引用，而對「D00訂單」的引用就是對編排系統創建和實施的實體的引用，以用於代表由用戶輸入的業務訂單。DOO訂單能夠包含分布式訂單編排首標(「首標」)。首標是包含了訂單的整體分層結構的對象。DOO訂單能夠包括一個或多個群，其中群是用於收集分布式訂單編排訂單行 (「行」)的實體，用於在編排處理的一個實例中進行處理。每個群可以包含一個或多個行。 行是包含訂單的相應的行的信息的對象。每個行可以包括一個或多個分布式訂單編排實施行(「實施行」)。實施行是一個與相應的實施系統的供應活動相對應的對象，其中該實施系統能夠處理該訂單行。這樣，實施行是實施相應的實施任務的供應行。在本發明的一個實施例中，分解模塊1020對訂單的創建包含了下列步驟。首先， 創建首標。接著創建一個或多個行並與該首標相關聯。隨後，對於每個行，創建一個或多個實施行，其中一個實施行可以僅與一個行相關聯。接著，調用一個服務來為每個行分配單獨的可執行處理。然而，在本發明的某些實施例中，省略了為每個行分配單獨的可執行處理的步驟，並且用單個可執行處理來處理整個DOO訂單。在任意一個方案中，分解模塊1020基於可執行處理的名稱和創建日期來選擇一個可執行處理。最後，根據該實施例，分解模塊1020保存DOO訂單狀態。編排模塊1030在執行和實施由分解模塊1020通過可執行處理的創建而創建的 DOO訂單的同時，控制著出現事件的順序。在圖10所示的實施例中，編排模塊1030包含子模塊訂單處理管理器(「0ΡΜ」)1040，以及三個核心處理編排管理器(「0M」)1050，步驟管理器服務(「SMS」)1060，以及分割處理管理器(「SPM」)1070。然而，本領域技術人員將會容易地意識到，這是一個實例，編排模塊1030可包含任意數量的子模塊和處理，並且也包含在本發明的範圍中。根據該實施例，分解模塊1020通過傳遞DOO訂單的首標標識來調用編排模塊1030 的OPM 1040。OPM 1040能發動一個或多個可執行處理，還能連接和控制一個或多個可執行處理。OM 1050、SMS 1060和SPM 1070是構成可執行處理的核心模塊，該可執行處理在處理並實施由分解模塊1020創建的DOO訂單的同時，控制著可出現的事件的順序。OM 1050 由OPM 1040來調用，並能夠執行用於給定群的處理步驟。SMS 1060由OM 1050調用，並能夠封裝用於預處理、錯誤處理和修改管理的業務邏輯。SPM 1070由OM 1050來調用並能夠控制分割單元。分割單元定義了可執行處理中可被一起分割的一系列步驟。例如，可執行處理包括了調度、運輸和帳單的步驟。在該實例中，分割單元可以被定義為包括調度和運輸步驟，但不包括帳單步驟。基於該分割單元定義，在分割該可執行處理的方案中，可以並列執行所得到的分割步驟，並且只有當兩個步驟都完成後才能調用該帳單步驟。在該實施例中，OPM 1040確定適當的可執行處理來編排DOO訂單。對於DOO訂單中的每個群，OPM 1040通過查找一個群表並順序地發動用於該群的可執行處理，來確定可執行處理。如果可執行處理不存在，那麼在發動可執行處理之前，OPM 1040調用一個服務來組合該可執行處理。在本發明的一個實施例中，OPM 1040還能夠查詢要在首標級別上執行的任務服務的列表，並在用戶定義的序列中執行它們。OM 1050是之前標識的可執行處理的實例，其生命周期開始於OPM 1040對其的異步調用。當OM 1050執行了其所有的處理步驟之後，OM 1050停止。根據該實施例，OM 1050 用於啟動由業務處理定義的任務層服務的調用。而且，OM 1050具有區分分割單元和非分割單元的邏輯。對於分割單元，OM 1050可以啟動SPM 1070的調用，其控制著分割單元。SMS 1060也可以被OM 1050調用。在OM 1050用作處理編排引擎時，SM 1060起到步驟編排引擎的功能。特別地，在該實施例中，SMS 1060接受來自OM 1050的請求，為每個步驟取回運行時間信息，標記步驟的狀態為「已開始」，發送請求至任務層，處理來自任務層的響應，並最終將控制送回OM 1050。修改管理框架如前所述，分布式訂單編排功能的基本核心是使用編排處理以用於編排訂單。編排處理控制著在處理並實施訂單時出現的事件的順序。仍如前所述，業務處理可以是由幾個業務步驟構成的長期運行的處理。在一個實施例中，業務步驟總是由用戶來定義的，並且表示業務流程中的一個步驟。在分布式訂單的編排業務處理中的業務步驟包含任務層服務或者子處理。業務步驟不能參與處理的辦理， 這是因為如果處理的辦理被回滾，那麼它不能被自動的撤消。核心功能的一個關鍵要求是在執行和實施訂單的同時管理修改請求。修改請求包括一個引用原始訂單的新訂單。新訂單還包括對原始訂單的修改，因此，包括了對含有業務處理的業務步驟的修改。因此，修改請求將會導致對當前正執行的業務處理(以及相應的可執行處理)的顯著更改。處理辦理不足以處理該修改請求，這是因為業務處理的幾個業務步驟與外部實施系統交互，因此超出了辦理界限。因此，這些業務步驟要求特殊邏輯來容納修改請求。根據本發明的一個實施例，分布式訂單編排系統能夠接收修改請求並確定原始訂單和新訂單(也被稱為「修改訂單」)之間的修改。然後使用原始訂單和新訂單之間的修改來確定哪些業務處理修改是必要的，以響應修改請求。這樣，系統能夠應付新業務處理的步驟與正執行的或已被完成的原始業務處理的步驟有衝突的情形。除了自動調整原始業務處理的過去的業務步驟之外，分布式訂單編排系統能夠包含對還未執行的業務步驟的修改。重要的是，編排語言補償(例如BPEL補償)和分布式訂單編排修改管理是非常不同的。BPEL補償用在由於可執行處理中的錯誤條件而回滾處理中已執行的活動的效果。分布式訂單編排修改管理不僅包含對業務處理中以前執行的步驟的撤消，而且還包括對業務處理中尚未執行步驟中的修改的向前傳播。換言之，後者需要撤消或重複之前執行的步驟以及更新尚未執行的步驟的能力。而且，對以前執行的步驟的撤消不僅僅只是回滾到以前的狀態。相反，需要對服務的調用來採取適當的撤消動作。在本發明的一個實施例中，通過框架範圍向修改管理框架提供嵌套的功能範圍。 框架範圍用於以正常模式或修改模式來執行業務處理的步驟。當第一次運行分布式訂單編排系統的可執行處理時，以正常模式來運行可執行處理。在正常模式下，在適當的時間動態地執行可執行處理的步驟，如之前在單獨的部分中所描述的那樣。然而，當接收到修改請求時，分布式訂單編排系統停止了原始的可執行處理(及其所有的子處理)，並且以修改模式啟動新的可執行處理。在一個實施例中，停止原始的可執行處理包括終止原始的可執行處理。然而，在一個可選的實施例中，停止原始的可執行處理包括暫停原始的可執行處理，其中原始的可執行處理可以在隨後的時間點上進行恢復。新的可執行處理與原始的可執行處理相關以用於允許修改處理。在修改模式中，執行適當的修改步驟來自動地調整已被執行的原始的可執行處理的步驟。使用之前保存的原始的可執行處理的狀態來執行修改步驟。 一旦執行了修改步驟，就以正常模式使用新的可執行處理的當前狀態來執行新的可執行處理的剩餘步驟。在本發明的一個實施例中，可執行處理能夠在每個裡程碑處保存處理的狀態。保存的狀態可以用在修改模式中，用於撤消或重複以正常模式執行的可執行處理的步馬聚ο圖11示出了根據本發明一個實施例的處理修改請求的方法的流程圖1100。在 1110中，以正常模式執行原始的可執行處理。如前所述，當以正常模式執行可執行處理時， 可執行處理執行包含了可執行處理的步驟並為每個步驟調用相應的服務，如參照圖5所討論的。在1120中，接收修改請求。如上所討論的，該修改請求包括一個由訂單捕獲模塊捕獲的新訂單，其引用了一個原始訂單，其中新訂單包含了對原始訂單的修改。按照處理訂單的相同方式來處理修改請求，如上所討論的，創建一個新DOO訂單。在1130中，停止原始的可執行處理。停止原始的可執行處理包括停止已由該原始的可執行處理創建的任何子處理。在本發明一個實施例中，終止原始的可執行處理。在一個可選實施例中，僅暫停原始的可執行處理。在該實施例中，原始的可執行處理可以在隨後的時間點上進行恢復。在1140中，創建一個新的可執行處理。更具體地，基於新的DOO訂單創建該可執行處理，其進而基於包含在所接收的修改請求中的新訂單。在1150中，以修改模式執行新的可執行處理。當以修改模式運行新的可執行處理時，可執行處理執行修改步驟，以便更改已由原始的可執行處理執行的步驟。新的可執行處理還使用原始DOO訂單與新DOO訂單之間的差別，執行未被原始的可執行處理執行的步驟。圖12示出了根據一個實施例的詳述修改請求流程的一個實例的流程圖1200。在流程圖1200中，流程1210表示原始的可執行處理的流程。例如，原始的可執行處理可以對應於訂購地毯的業務處理。原始的可執行處理執行步驟A、B和C。在上面的實例中，步驟 A包括從庫存中選擇地毯，步驟B包括根據所要求的尺寸測量地毯，以及步驟C包括運輸地毯。在該實施例中，在完成步驟B之後但未啟動步驟C時接收一個修改請求(未示出)，其中該修改請求將地毯訂單修改成瓷磚訂單，這裡用於訂購地毯的處理和用於訂購瓷磚的處理使用了相同的業務處理。因此，原始的可執行處理被停止，新的可執行處理被啟動。在上面的實例中，新的可執行處理對應於用於訂購瓷磚的業務處理。在流程圖1200中， 流程1220表示新的可執行處理的流程。新的可執行處理執行步驟A』、B』和C』。步驟A』包括調整已完成的步驟A。對步驟A的調整可以根據下面的業務處理來採取多種形式中的一種。在所示的實例中，對步驟A的調整可以包括把從庫存中選擇地毯調整為從庫存中選擇瓷磚。如果之前所選的庫存不包括瓷磚，那麼這種調整還進一步包括選擇包含瓷磚的不同的庫存。相似地，步驟B』包括調整已完成的步驟B，並根據下面的業務處理來採取多種形式中的一種。在所示的實例中，對步驟B的調整可以包括測量瓷磚，以瓷磚的測量來代替地毯的測量。最後，步驟C』包括運輸瓷磚。由於步驟C並未由原始的可執行處理來執行，因此不需要調整步驟C，這樣，不執行對步驟C的調整。然而，是基於新訂單來執行步驟C』的，而不是基於原始訂單。這樣，在所示的實例中，步驟C』包括運輸瓷磚，而不是運輸地毯。下面將參照圖10所示的分解模塊1020和編排模塊1030來描述編排修改管理的一個示意性實施例。然而，本領域技術人員可以容易地理解，所描述的實施例僅是一個示意性實施例，也可以根據可選實施例來實現這種編排修改管理，並且仍包含在本發明的範圍內。
在一個實施例中，圖10的分解模塊1020和編排模塊1030能夠處理一個修改訂單的請求(即修改請求)並處理一個訂單。在訂單捕獲模塊發送一個修改請求的情況下，分解模塊1020按照分解模塊處理原始訂單的方式來處理該修改請求，如之前參照圖10的描述，除了下面的關鍵區別點之外。首先，根據該實施例，分解模塊1020識別出從訂單捕獲模塊接收的新訂單不是一個真正的新訂單，而是修改原始訂單的請求的一部分(即修改請求)。接著，分解模塊1020 驗證是否允許在原始訂單上進行修改。該驗證包括回顧原始訂單的狀態以及相應的可執行處理的狀態。如果訂單狀態或處理狀態具有阻止修改請求的約束條件，那麼修改請求就被拒絕。然而，如果允許修改，分解模塊1020就通知編排模塊1030準備處理修改請求。接著， 分解模塊1020創建一個新的DOO訂單。新的DOO訂單引用了原始DOO訂單。然後分解模塊 1020將新DOO訂單關聯並映射到原始DOO訂單。分解模塊1020還計算新的DOO訂單和原始DOO訂單之間的變動(δ )。最後，分解模塊1020將新的DOO訂單發送到編排模塊1030。根據該實施例，編排模塊1030能夠通過使OPM 1040監聽修改通知和修改請求來處理這些修改請求。修改通知只是來自分解模塊的一個通知，用以準備處理一個修改請求， 它不是實際的修改請求。在出現修改請求的情況下，OPM 1040首先接收一個修改通知，隨後接收實際的修改請求。當OPM 1040接收一個修改通知時，根據該實施例，OPM 1040可以通知每個由OPM 1040調用的OM 1050。基於這個通知，0Μ1050不執行任何的新任務。當OPM 1040接收一個修改請求時，OPM 1040能夠確定當前的可執行處理是否能夠接受修改請求。如果該處理不能接受修改請求，那麼OPM 1040就拒絕整個修改請求。如果處理能接受修改請求，那麼 OPM 1040就如下所述處理該修改請求。在處理該修改請求的過程中，根據該實施例，OPM 1040首先調用登記為可執行處理的每個步驟的一部分的通知服務，用以確定是否每個通知服務都能接受修改請求。如果任意一個所登記的通知服務表示它們不能接受修改請求，那麼OPM 1040就拒絕整個修改請求，結束修改請求的處理。然而，如果全部所登記的通知服務表示它們能接受修改請求，那麼就繼續修改請求處理。然後OPM 1040通知與該可執行處理相關的等待步驟以便停止。然後根據本實施例，OPM 1040將新DOO訂單與原始DOO訂單合併。在該實施例中，然後OPM 1040調整用於新DOO訂單的群信息。當分解模塊1020 創建一個新DOO訂單時，分解模塊1020創建用於每一行的新群，以及新DOO訂單的實施行。 取決於每一行和實施行是否是新的，OPM 1040能夠調整引用鍵值、激活某些群，以及去激活其他群。根據一個實施例，為了對新DOO訂單的每一行調整群信息，OPM 1040確定原始DOO 訂單中是否存在行。如果原始DOO訂單中存在行，那麼OPM 1040進一步確定新DOO訂單中是否已修改了該行。如果原始DOO訂單中不存在行，OPM 1040激活分解模塊1020為新行創建的群，並且為該行設置屬性變動。如果原始DOO訂單中存在行，並且未在新訂單中修改， OPM 1040就繼續使用來自原始DOO訂單的之前的群。如果原始DOO訂單中存在行，並且已在新訂單中修改，OPM 1040就激活分解模塊1020為所修改的行創建的群，為該行設置屬性變動，並且去激活為原始訂單所創建的之前的群。OPM 1040還執行用於新DOO訂單的每一實施行的那些步驟。然而，在可選實施例中，OPM 1040能夠基於不同的標準來調整群信息，並且仍包含在本發明的範圍內。隨後，根據該實施例，OPM 1040處理所計算的原始DOO訂單和新DOO訂單之間的變動。一旦該變動被計算出來，OPM 1040確定變動類型並執行下列一組活動中的一個。如果變動類型是一個增加行變動(即增加一個新行)，並且該行被增加到新DOO訂單中，那麼在本發明的一個實施例中，0PM1040為該行開始一個新的可執行處理，並對其和用於該新DOO訂單的其他可執行處理一起監控。在該實施例中，OPM 1040還可以修改從新 DOO訂單到原始DOO訂單的群的引用。OPM 1040可以執行這些操作而不需考慮新行是否僅增加到新DOO訂單上，或者是否新行還增加到新DOO訂單的新群上。在一個可選實施例中，如果變動類型是一個增加行變動，並且該行被增加到新DOO 訂單的現有群上，那麼OPM 1040就開始一個新的可執行處理，並如上所討論地修改引用。 另外，OPM 1040可以將新DOO訂單中新創建的群與現有群進行合併。這種合併的一個實例是基於項目關係和共享處理的定義來將新創建的群與現有群進行合併。如果變動類型是一個刪除行變動(即刪除一個行)，在本發明的一個實施例中， OPM 1040通知合適的可執行處理來刪除該行。如果變動類型是一個變動屬性修改變動(即已修改的首標、行或實施行的一個或多個變動屬性)，在一個實施例中，OPM 1040通知合適的可執行處理來更新該屬性。在本發明的一個實施例中，如果修改的屬性是一個數量屬性，就由OPM 1040來分別處理該修改以最小化調整的必要和更好的優化。特別是，對於數量增加，OPM 1040為合適的行開始新的可執行處理，並對其和用於該DOO訂單的其他可執行處理一起進行監控。然而，對於數量減少，OPM 1040將會通過以之前所討論的修改模式執行新的可執行處理來調整原始的可執行處理。如果變動類型是一個動態變動屬性變動(即已修改的首標、行或實施行的一個或多個動態變動屬性)，在一個實施例中，OPM 1040通過以之前所討論的修改模式執行可執行處理來調整原始的可執行處理。在本發明的一個實施例中，用戶可以在定義業務處理或定義業務處理的步驟時在訂單捕獲元件的接口處指出編排系統是否應該忽視對動態變動屬性的修改。動態變動屬性是用戶定義的作為變動屬性的一種屬性。最後，根據一個實施例，OPM 1040關閉新的訂單並調用新的可執行處理。在圖10 中，如之前所討論的，新的可執行處理被定義為OM 1050。關於OM 1050，根據一個實施例，OM 1050監聽修改請求。一旦OM 1050接收了修改請求，就處理該修改請求。編排處理管理如前所述，編排處理的修改管理使用了可執行處理的以往步驟的自動調整的組合，以及對可執行處理的未來步驟的修改的結合。隨後將以本發明的一個示意性實施例來描述該編排處理和編排處理的修改管理。圖13示出了根據一個實施例的可執行處理定義的一個實例。在該實施例中，圖13 示出了原始訂單的可執行處理的定義。S1、S2、S3、S4、S5、S6和S7表示可執行處理的不同步驟。CBl和CB2表示可執行處理的條件分支，用於在運行時間上根據預先定義的業務規則進行評估。例如，在CB1，編排系統評估原始訂單的行數量是否小於10。如果行數量小於 10，那麼可執行處理執行步驟S2，然後是步驟S4，再然後步驟S5。然而，如果行數量大於或等於10，那麼可執行處理執行步驟S3，然後評估條件分支CB2。在CB2，編排系統評估原始訂單的組織是否等於204或404。如果組織等於204，那麼可執行處理執行步驟S6。然而， 如果組織等於404，那麼可執行處理的執行步驟S7。在原始訂單中，如果行的數量大於10，可執行處理執行步驟S3，如果組織等於 204，那麼可執行處理執行步驟S6。如果可執行處理執行那些步驟，並且接收到把行數量降到5的修改請求，那麼新的可執行處理刪除步驟S3至S6，然後執行步驟S2、S4和S5。由於在運行時間上依靠預定的規則評估每個條件分支CBl和CB2，於是在接收到修改請求時不知道新的可執行處理採用的是哪條路徑。在請求修改的情況下中，編排系統通知原始的可執行處理停止。在一個實施例中， 編排系統通知原始的可執行處理溫和地終止(即允許任何正在運行的步驟完成而不需執行下一個步驟)。在一個可選實施例中，編排系統通知原始的可執行處理自身暫停。這樣， 在該實施例中，原始的可執行處理被暫停，但能夠在隨後的時間點上被恢復。在恢復時，原始的可執行處理將執行下一步驟。編排系統創建一個新的可執行處理，其引用了原始的可執行處理。更具體地，新的可執行處理包括引用了原始的可執行處理的原始步驟的新步驟， 並包括一個新任務。對於不需要進行調整的步驟，編排系統從原始的可執行處理複製任務完成細節和任務狀態。在本發明的一個實施例中，任務完成細節包括開始和結束日期。對於需要進行調整的步驟，編排系統簡單地從原始的可執行處理複製任務完成細節。編排系統去激活所有與原始的可執行處理相關的消息，並且以修改模式開始新的可執行處理。一旦新的可執行處理已經調整了原始的可執行處理的所有原始步驟，新的可執行處理以正常模式恢復執行剩餘的步驟。圖14示出了根據一個實施例的新的可執行處理定義的一個實例，其中新可執行處理調整原始的可執行處理的步驟。在圖14中，標題為「正常處理實例」的下面是原始的可執行處理的流程，包括步驟A、B、D、E和F以及條件分支S。標題為「補償處理實例」的下面是一個相應的新的可執行處理的流程，包括步驟A』、B』、D』、E』和F』以及條件分支S』。在修改請求的情況下，編排系統能停止原始的可執行處理的流程，並啟動新的可執行處理的流程。如果原始處理的相應的步驟(即步驟A、B、D、E和F以及條件分支S)已被執行，那麼新的可執行處理的每一步驟和條件分支(即步驟A』、B』、D』、E』和F』以及條件分支S』 ) 可以自動地調整原始處理的相應的步驟。也可以參照圖14，原始的可執行處理和新的可執行處理都能夠在每個裡程碑處將各自處理的狀態保存在資料庫中。例如，在圖14中，原始的可執行處理在裡程碑A保存狀態Si，在裡程碑B保存狀態S2，在裡程碑C保存狀態S3，在裡程碑D保存狀態S4，以及在裡程碑F保存狀態S5。圖15示出了根據一個實施例的在接收到修改請求時，原始的可執行處理和新的可執行處理的流程圖。原始的可執行處理的流程(即在圖15的圖例標識為「正常訂單流程)包括步驟1_3、5、7和9。新的可執行處理的流程，即在圖15的圖例標識流程為「修改訂單流程」)包括步驟1』 _3』、5』、7』、9』和10-11。步驟4、6和8是兩個流程所共有的(並且在圖15的圖例標識為「共有」)。
現在描述正常訂單流程的步驟。在步驟1，訂單捕獲模塊向編排系統提交一個訂單，並且編排系統的分解模塊接受該訂單。在步驟2，分解模塊轉換該訂單並創建一個原始的DOO訂單。在步驟3，分解模塊按需為原始的DOO訂單的行分配單獨的可執行處理。分解模塊還保存了原始的DOO訂單的狀態，並通過調用編排模塊的OPM來將原始的DOO訂單傳遞到編排模塊。在步驟4，OPM基於原始訂單的首標標識來查詢處理信息。對於原始訂單的每個處理，OPM調用相應的OAS和計劃服務。在步驟5，對於原始訂單的每個群，OPM調用了一個原始的可執行處理(即0M)。在步驟6，OAS調用該計劃服務並作為步驟4的一部分。在步驟7，執行原始的可執行處理。原始的可執行處理進一步調用SMS以便執行可執行處理的步驟。在步驟8，SMS取回必要的運行時間步驟實例數據。在步驟9，SMS調用與可執行處理的步驟相應的任務層服務。在圖15所示的實例中，SMS調用了分別與S1、S2和 Sn相對應的任務層服務。現在描述修改訂單流程的步驟。在步驟1』，訂單捕獲模塊向編排系統提交一個修改請求，並且編排系統的分解模塊接受該訂單，其中該修改請求包括與原始訂單相應的新訂單。在步驟2』，分解模塊轉換該新訂單並創建一個新的DOO訂單，並將新的DOO訂單標識為與原始DOO訂單相對應。分解模塊還按需為新的DOO訂單的各行分配單獨的可執行處理。然後分解模塊以修改模式調用群API。在步驟10，分解模塊調用一個將新的DOO訂單映射到原始的DOO訂單的功能，並計算兩個DOO訂單之間的變動。在步驟3』，分解模塊通過調用編排模塊的OPM來將新的DOO訂單傳遞到編排模塊。在步驟4，OPM基於新的DOO訂單的首標標識來查詢處理信息。對於新的DOO訂單的每個處理，OPM調用相應的OAS和計劃服務。在步驟5』，OPM調用了返回一組信息的應用程式模塊API，該組信息包括了原始的可執行處理的標識、與新的可執行處理相應的可執行處理的標識、原始DOO訂單的所有群、新DOO訂單的所有群以及所有變動類型，其中新的可執行處理將處理新的DOO訂單並且調整原始的可執行處理的各個步驟。對於每個修改的群，OPM將修改通知給外部系統，暫停原始的可執行處理，以便使原始的可執行處理溫和地退出並終止所有的等待步驟。OPM還將新的DOO訂單與原始的DOO訂單合併，保存原始訂單的當前狀態，並為每個修改的群以修改模式調用新的可執行處理(即0M)。在步驟6，0AS 調用該計劃服務作為步驟4的一部分。在步驟7』，執行新的可執行處理。新的可執行處理進一步調用SMS以便執行可執行處理的各個步驟。在步驟8，SMS取回必要的運行時間步驟實例數據，確定合適的補償方案，標識原始DOO訂單和新的DOO訂單之間已計算的變動，並運行合適的補償服務。在步驟 9』和11』，SMS調用與可執行處理的步驟相應的任務層服務。在圖15所示的實例中，SMS調用了分別與S1、S2和Sn相對應的任務層服務。特別地，SMS首先執行S2的補償，然後是Sn 的補償，然後是Sl的補償。接著，SMS重新執行Si、S2和Sn。關於編排的更多的實施細節在美國專利號12/617，698名為「分布式訂單編排」、 美國專利申請號12/718，585名為「分布式訂單編排系統中的修改管理框架」以及美國專利申請號12/697，756名為「使用模版的業務處理的編排」中給出了描述。基於事件的編排框架一個實施例涉及分布式訂單編排系統，在該系統中使用一組獨立的和離散的事件來編排訂單。根據該實施例，用事件管理器來替代分布式編排系統中的有狀態的可執行處理，例如可執行處理310。代替用請求/回答的交互模式來編排訂單的有狀態的可執行處理，事件管理器使用一組離散的和獨立的事件來編排訂單。在本發明的一個實施例中，事件管理器根據一個處理在事件消息發送系統上向一組用戶公布一組事件。每個訂購者消耗事件管理器所公布的一個事件，並執行基於該事件的任務。根據該實施例，當事件管理器處理分布式訂單編排系統中的不同的組成部分之間的通信時，離散的和獨立的事件使分布式訂單編排系統中的不同的組成部分去耦合。這樣，分布式訂單編排系統的第一組成部分能夠與第二組成部分通信，而不用知道第二組成部分的實施細節。本領域技術人員將會知道， 一組事件可包括單個事件或多個事件。根據該實施例，如果分布式訂單編排系統的兩個組成部分互相不直接通信，而是使用媒介來通信，例如事件消息發送系統，那麼它們是「不同的」。圖16示出了根據一個實施例的依據使用事件管理器的處理來發布一組事件的方法的流程圖。根據該實施例，流程包含事件管理器1600、資料庫1610和訂購者1620。依照該實施例，事件管理器1600是一種無狀態的可執行處理。事件管理器1600是分布式訂單編排系統中的不同的組成部分，並參照圖19和20在編排的上下文中更詳細地描述。資料庫1610是存儲著處理狀態和元數據的資料庫。處理狀態是用於處理一個訂單的處理的狀態。這樣，在該處理是一個編排處理的實施例中，該處理狀態是該編排處理的狀態。根據一個實施例，在編排一個DOO訂單的情況下，該處理狀態包括用於DOO訂單的每個首標、行和實施行的屬性值。如前所述，元數據用於在訂單中定義任務，並用於調用與那些任務相關的服務，例如任務層服務。更特別地，元數據用於確定如何以及何時調用這些服務。而且，基於元數據，產生輸入變量並發送給這些服務，以便調用所封裝的服務。這樣，根據一個實施例，處理狀態可用於確定處理中的哪些步驟已被執行，而元數據可用於確定處理中的哪些步驟要被執行以及如何執行這些步驟。資料庫1610可以是操作資料庫、分析資料庫、數據倉庫、分布式資料庫、終端用戶資料庫、外部資料庫、導航資料庫、存儲器內資料庫、面向文檔的資料庫、實時資料庫、關係資料庫、面向對象資料庫或現有技術中所知的任意其它的資料庫。根據本發明的一個實施例，圖16的資料庫1610與圖3中的存儲器314 相同。訂購者1620是用來訂購具體類型的事件的分布式訂單編排系統的不同組成部分。當訂購者1620之一接收到發布的事件時，訂購者確定所發布的事件的類型。如果所發布的事件的類型是訂購者已經訂購的，那麼訂購者就消耗該事件並執行基於所消耗的事件的任務。訂購者1620從事件管理器1600上去耦合。通常，由於這種去耦合，訂購者1620 不知道該事件管理器1600，因此也不知道所發布的事件的來源。然而，在某些實施例中，訂購者可以知道所發布的事件的來源。根據一個實施例，如將參照圖17更詳細地描述，訂購者1620包括任務層服務，該任務層服務執行基於所消耗的事件的任務。然而，這只是一個示例，在可選實施例中，訂購者1620可以是不同於事件管理器1600的分布式訂單編排系統的任意一個組成部分。現在要描述根據本發明一個實施例的如圖16所示的流程。處理開始，並在步驟1 啟動事件管理器1600。根據一個實施例，當啟動時，事件管理器1600確定處理中的哪些步驟要被執行，並發布一組事件以用於執行所確定的步驟。
在步驟2，事件管理器1600從資料庫1610中讀取一個處理狀態和元數據。基於該處理狀態和元數據，事件管理器1600確定要執行的處理的步驟，並產生一組要在事件消息發送系統上發布的事件。根據一個實施例，事件包括用以執行任務的指令，其中該任務與處理中的步驟相對應。將參照圖21來詳細描述事件以及事件管理系統。在步驟3，事件管理器1600在事件消息發送系統上發布一組事件，這些事件被傳輸到訂購者1620。在事件管理器1600發布該組事件之後，事件管理器1600就終止。如前所述，訂購者1620可以是分布式訂單編排系統的任意一個組成部分。在所描述的實施例中，訂購者1620包括訂購者1621、訂購者1622和訂購者1623。然而，本領域技術人員將會容易地理解，這只是根據一個實施例的訂購者的示意性數量，在可選實施例中， 訂購者1620可以包括任意數量的訂購者。如前所述，訂購者1620中的每個訂購者都訂購了具體類型的事件。當訂購者1620中的訂購者接收一個所發布的事件時，訂購者就確定所發布的事件的類型。如果所發布的事件的類型是訂購者已經訂購的，那麼訂購者就消耗該事件並執行基於所消耗的事件的任務。在步驟4，在訂購者1620的每個訂購者執行了其任務之後，每個訂購者更新資料庫1610的處理狀態。如前所述，處理狀態是處理的一個狀態。因此根據該實施例，更新資料庫1610中的處理狀態包括更新處理狀態用以標識訂購者1620所執行的任務已經完成。 根據本發明的一個實施例，更新處理狀態包括更新DOO訂單的至少一個屬性值。這種更新可包括更新DOO訂單的首標的至少一個屬性值，更新DOO訂單的行的至少一個屬性值，更新 DOO訂單的實施行的至少一個屬性值，或者它們的組合。根據該實施例，一旦資料庫1610的處理狀態被更新，事件管理器1600就再次啟動。一經啟動，事件管理器1600就基於資料庫1610的處理狀態和元數據確定是否(1)事件管理器1600應該產生一組新事件；(2)事件管理器1600應該在產生一組新事件之前等待另一個處理狀態的變遷；或者C3)處理狀態已到達退出狀態。如果事件管理器1600確定應該產生一組新事件，就重複步驟3和4直到處理狀態達到退出狀態。如果事件管理器1600 確定應該在產生一組新事件之前等待另一個處理狀態的變遷，事件管理器1600就終止。如果事件管理器1600確定處理狀態已到達一個退出狀態，那麼在步驟5，事件管理器1600就終止該處理。將參照圖M詳細描述事件管理器1600的確定過程。使用事件管理器在分布式訂單編排系統中處理訂單的一個實例是編排一個訂單。 更特別地，在一個分布式訂單編排系統中，編排層和任務服務層可使用一個事件管理器來通信。因此，根據本發明的一個實施例，將在編排的上下文中描述圖16所示的流程。圖17示出了根據一個實施例的使用事件管理器和任務層服務來編排訂單的方法的流程圖。根據該實施例，處理是用於編排一個訂單的編排處理。在步驟1，分布式訂單編排系統的分解層創建將被發送到該分布式訂單編排系統的一個編排層的分布式訂單編排訂單(「D00訂單」)，DOO訂單的編排被啟動。如前所述，DOO訂單是表示從分布式訂單編排系統的訂單捕獲層接收的訂單的對象，並且該訂單已被轉換為分布式訂單編排系統的編排層所使用的對象格式。當啟動DOO訂單的編排時，就啟動事件管理器1600。在步驟2，事件管理器1600從資料庫1610中讀取處理狀態和元數據。根據該實施例，處理狀態是編排訂單的編排處理的狀態。在該實施例中，處理狀態包括用於DOO訂單的每個首標、行和實施行的屬性值。而且，根據該實施例，元數據是用於在被編排的訂單中定義任務的數據，並用於調用與這些任務相關的任務層服務。基於該處理狀態和元數據，事件管理器1600確定要在事件消息發送系統上發布的一組事件。例如，如果元數據定義了創建運輸的任務，事件管理器1600就發布一個由創建運輸任務層服務訂購的事件，並被標識為 「創建運輸事件」。在步驟3，事件管理器1600在該事件消息發送系統上發布一組事件，並且將這些事件傳輸到任務層服務1720中。根據該實施例，每個事件都與一個具體的任務層服務相對應，其中該任務層服務被需要進一步編排該DOO訂單。在事件管理器1600發布該組事件之後，事件管理器1600就終止。在所示的實施例中，任務層服務1720包括任務層服務1721、任務層服務1722和任務層服務1723。然而，本領域技術人員將會容易地理解，這只是根據一個實施例的任務層服務的示意性數量，在可選實施例中，任務層服務1720可以包括任意數量的任務層服務。如前所述，任務層服務1720的每個任務層服務訂購一個具體類型的事件。例如，任務層服務 1721是一個「創建運輸」任務層服務並訂購一個事件類型「創建運輸事件」。在該實例中，任務層服務1722和1723是分別訂購不同類型事件的任務層服務。當任務層服務1720的任務層服務接收一個發布的事件時，任務層服務確定所發布的事件的類型。如果所發布的事件的類型是任務層服務已訂購的，那麼任務層服務就消耗該事件並執行基於所消耗的事件的任務。如果所發布的事件的類型不是任務層服務已訂購的類型，任務層服務就忽略該事件。在該實例中，當任務層服務1721接收一個事件管理器1600發布的事件類型「創建運輸事件」時，任務層服務1721就消耗該事件並執行一個「創建運輸」任務。當任務層服務1722 和1723接收事件類型「創建運輸事件」時，任務層服務1722和1723就忽略該事件，這是因為該事件不是任務層服務1722和1723訂購的事件類型。在步驟4，在任務層服務1720的每個任務層服務執行其任務後，每個任務層服務更新資料庫1610的處理狀態。在該實例中，任務層服務1721執行一個「創建運輸」任務，並更新資料庫1610的處理狀態。根據該實施例，處理狀態是編排處理的狀態。這樣，根據該實例，更新資料庫1610的處理狀態包括更新該處理狀態以便標識由任務層服務1721執行的「創建運輸」任務已完成。根據該實施例，更新該處理狀態包括更新DOO訂單的至少一個屬性值。這種更新可包括更新DOO訂單的首標的至少一個屬性值，更新DOO訂單的行的至少一個屬性值，更新DOO訂單的實施行的至少一個屬性值，或者它們的組合。因此，根據該實例，更新處理狀態包括基於「創建運輸」任務的執行而更新DOO訂單的至少一個屬性值。根據圖17所示的實施例，一旦更新了資料庫1610的處理狀態，事件管理器1600 就再次啟動。一經啟動，事件管理器1600就基於資料庫1610的處理狀態和元數據來確定是否(1)事件管理器1600應該產生一組新事件；(2)事件管理器1600應該在產生一組新事件之前等待另一個處理狀態的變遷；或者C3)處理狀態已到達退出狀態。如果事件管理器1600確定應該產生一組新事件，就重複步驟3和4直到處理狀態達到退出狀態。如果事件管理器1600確定應該在產生一組新事件之前等待另一個處理狀態的變遷，則事件管理器1600就終止。如果事件管理器1600確定處理狀態已到達一個退出狀態，那麼在步驟5， 事件管理器1600就終止該編排處理。然而，雖然圖17示出了在編排的上下文中的事件管理器，並示出了事件管理器可用在編排層和任務服務層之間進行通信，但本領域技術人員將會容易地理解，這只是事件管理器的一個實例。而且，本領域技術人員也將會理解，分布式訂單編排系統的任一層都能使用事件管理器與分布式訂單編排系統的另一層進行通信。例如，分基層能夠使用事件管理器與編排層進行通信。因此，根據本發明的一個實施例，事件管理器有助於分布式訂單編排系統的任意兩層或兩個組成部分之間的通信。圖18示出了根據一個實施例的使用事件管理器、任務層服務和中介器來編排訂單的方法的流程圖。圖18所示的實施例與圖17所示的實施例類似，區別在於，任務層服務 1720包括中介器17M。本領域技術人員將會容易地理解，中介器是通過從第一個處理接收數據並將所接收的數據從第一處理理解的格式轉換為第二處理理解的格式、從而允許兩個或多個處理互相通信的處理。因此，中介器用作兩個或多個處理的媒介，減少了兩個或多個處理之間的依賴性，並進而減少了耦合。另外，根據圖18所示的實施例，中介器17M訂購全局事件類型，而不是單個任務層服務訂購具體事件類型。因此，在步驟3，在事件管理器1600發布一組事件並且將這些事件傳輸到任務層服務1720之後，中介器17M就消耗各個事件並且基於事件內所包含的一組參數，中介器17M調用任務層服務1721、任務層服務 1722或任務層服務1723。被調用的任務層服務(即任務層服務1721、任務層服務1722或任務層服務172 執行基於該事件的任務。在一個可選實施例中，事件管理器不僅能控制一個或多個訂購者的任務處理，還能控制單個訂購者的子任務處理，例如任務層服務。例如，訂購者可以執行基於所消耗的事件的任務，其中該任務包括10個子任務。而且，某些子任務可以並行地執行，某些子任務可以順序地執行，並且某些子任務需要一個或多個子任務完成之後才能執行。在這種情況中， 當訂購者執行第一個子任務時，訂購者可以更新資料庫的處理狀態。基於資料庫中的該處理狀態和元數據，事件管理器可以確定哪個子任務(或哪些子任務)可被執行，並因此產生及發布一組事件。這些事件可由訂購者來消耗，並且基於這些事件，訂購者可以執行相應的一個或多個子任務。接著，訂購者可以更新處理狀態，並且可以重複該處理直到任務的所有子任務都已完成。下面將詳細地描述事件管理器，特別地，在編排的上下文中進行描述。圖19示出了根據一個實施例在訂單實施的上下文中使用事件管理器提供編排的系統1900的一個實例。在該實施例中，系統1900包括一個編排系統302和一個客戶機304。 根據該實施例，圖19的系統1900與圖3的系統300類似，區別在於系統1900包括事件管理器1910而不是可執行處理310。事件管理器1910是可由運行時間引擎312調用的無狀態的處理。事件管理器1910包含嵌入式邏輯，被配置為確定一組要發布的事件。該邏輯是從存儲器314中的元數據和用戶使用接口 308進行模型化的業務處理的狀態中獲得的。替代執行可執行處理，運行時間引擎312調用事件管理器1910來編排接口 308中已模型化的業務處理。相似於圖3所示的實施例，用戶可以使用接口 308來定義使用服務庫306中的服務的業務處理的步驟。用戶可以在業務處理中定義多個步驟。每個步驟可以與服務庫306中的服務相關聯。這些步驟可以存儲在數據表中，該數據表可以包括能被運行時間引擎312使用並用以調動事件管理器1910的元數據。基於服務庫306中用於定義業務處理的具體步驟的服務，事件管理器1910產生並發布一組被傳送給訂購者的事件，例如任務層服務。事件管理器1910通過調用一種內部方法來發布一個事件。一旦事件管理器1910發布了該組事件，事件管理器1910就終止。在訂購者消耗該組事件並執行基於該消耗的事件的任務之後，訂購者就更新已模型化的業務處理的狀態，運行時間引擎312再次調用事件管理器1910。重複該處理直到編排好模型化的業務處理，然後，事件管理器1910 終止該處理。圖20示出了根據一個實施例的利用事件管理器的分布式訂單編排系統2000。在本發明的一個實施例中，系統2000對應於圖19的系統1900，並且在系統2000中只包含了系統1900中需要進行討論的部分。為了清晰起見，省略了系統1900的其它部分。在圖20所示的實施例中，圖9的分布式訂單編排模塊908被表示為兩個模塊分解模塊1020和編排模塊1030。然而，本領域技術人員將會容易地認識到，一個模塊就可以提供分解模塊1020和編排模塊1030的功能，並且仍包含在本發明的範圍中。而且，圖9 的分布式訂單編排模塊908可以被表示為任意數量的模塊，並且這也包含在本發明的範圍中。根據該實施例，圖20的系統2000與圖10的系統1000類似，區別在於編排模塊 1030包含事件管理器2010而不是子模塊0PM1040、核心處理OM 1050、SMS 1060和SPM 1070。下面將參照圖20所示的分解模塊1020和編排模塊1030來描述編排的示意性實施例。然而，本領域技術人員將會容易地理解，所描述的實施例僅是示意性的實施例，這種編排可以根據可選實施例來實現，並仍包含在本發明的範圍中。分解模塊1020按照與之前討論過的圖10相似的方式來進行操作。編排模塊1030 控制著在處理並實施DOO訂單的同時發生的事件的順序，其中該DOO訂單是由分解模塊 1020通過事件管理器2010的調用和事件發布來創建的。根據該實施例，分解模塊1020調用編排模塊1030的事件管理器2010。更特別地， 分解模塊1020調用事件管理器2010來編排由分解模塊1020創建的DOO訂單。如前所述， 事件管理器1910是無狀態的處理，其能夠被分解模塊1020來調用。事件管理器2010包含嵌入式邏輯，被配置為確定一組要發布的事件。該邏輯是從存儲在資料庫中的元數據和處理狀態中獲得的。基於該邏輯，事件管理器2010產生並發布一組要傳送給訂購者的事件， 例如任務層服務。事件管理器2010可以通過調用一種內部方法來發布一個事件。一旦事件管理器2010發布了該組事件，事件管理器2010就終止。在訂購者消耗該組事件並執行基於該消耗的事件的任務之後，訂購者就更新存儲在資料庫中的處理狀態。分解模塊1020 再次調用事件管理器2010。重複該處理直到編排好DOO訂單，然後，事件管理器2010終止。下面將詳細地描述事件消息發送系統。應用程式可以通過消息通道(即把發送器連接到接收器的虛擬通道)傳輸數據。 消息是可以在消息通道上傳輸的數據分組。為了傳輸數據，發送器可將數據拆分為一個或多個分組，將每個分組打包為一條消息，然後在消息通道上傳輸該消息。同樣地，接收器可以接收一條消息，從該消息中提取數據，並處理該數據。消息發送系統可以重複嘗試把消息從發送器發送到接收器，直到成功為止。傳輸數據可包括在發送器處將數據排列為字節格式，將所排列的數據作為字節流從發送器傳輸到接收器，並把該數據去排列回其原始格式。即使在應用程式不知道哪個特定的接收器將會最終取回該應用程式，事件消息發送系統也能允許發送器傳輸消息。這是因為，當發送器傳輸數據時，發送器就將該數據添加到專用於傳輸這種類型的信息消息通道中。同樣地，欲接收特定信息的接收器基於其所需的數據類型選擇從什麼消息通道獲取數據。這樣，發送器就能確保接收器取回數據中其所感興趣的數據。消息可以包括兩部分首標和主體。首標可包括由消息發送系統使用的信息，該信息描述了正被傳輸的數據。主體可包括正被傳輸的數據。事件是一種表示發送器的狀態發生改變的消息。這種狀態改變可以基於外部對發送器進行動作而產生。例如，用戶可以在一個訂單捕獲層中表示他想要創建一個運輸。用戶的表示是一種外部動作，它觸發了編排層的狀態的改變。作為這種狀態的改變的結果，編排層可以使用消息通道向任務服務層傳輸一個事件，其中該事件表示用戶想要創建一個運輸。任務服務層可消耗該事件並執行一個任務，以基於該事件創建一個運輸。事件的傳輸是單向的異步動作。這意味著傳輸事件的發送器不需要等待來自接收器的響應，其中該接收器訂購該事件並消耗該事件。根據某些實施例，發送器在其發送了事件之後就終止。圖21示出了根據一個實施例的事件消息發送系統2100的一個實例。事件消息發送系統2100包括消息通道2110。如前所述，消息通道2110被配置為從發送器向接收器傳輸消息，例如事件。所示的實施例包括事件管理器2120和訂購者2130。根據該實施例，事件管理器2120可使用消息通道2110來傳輸事件。在該實施例中，事件管理器2120通過消息通道2110將一個事件傳輸給訂購者2130。訂購者2130訂購該事件，並因此接收該事件， 訂購者2130執行基於該事件的任務。雖然圖21示出了事件消息發送系統2100具有單個消息發送通道，但這只是一個示意性實施例，本領域技術人員將會容易地理解，事件消息發送系統2100可以包括任意數量的消息發送通道，並仍包含在本發明的範圍內。消息通道的類型有許多種。根據本發明的一個實施例，分布式訂單編排系統使用一個事件消息發送系統，該事件消息發送系統包括一個或多個發布-訂購消息通道。現在將詳細描述發布-訂購消息通道。圖22示出了根據一個實施例的事件消息發送系統的發布-訂購消息通道2200的一個實例。發布-訂購消息通道2200是使一個輸入通道被分割為多個輸出通道(每個輸出通道用於一個訂購者)的消息通道。所示的實施例包括一個事件管理器220以及訂購者 2220,2230和2240。根據該實施例，事件管理器2210把事件2250發布到發布-訂購消息通道2200的一個輸入通道中。發布-訂購消息通道2200然後將事件2250的一個拷貝傳輸給每個輸出通道。根據該實施例，每個輸出通道具有一個訂購者(即第一輸出通道具有訂購者2220，第二輸出通道具有訂購者2230，第三輸出通道具有訂購者2240)。每個訂購者監聽事件2250並消耗事件2250的相應的拷貝。一旦事件2250的每個拷貝都被相應的訂購者所消耗，那麼事件2250的每個拷貝就從發布-訂購消息通道2200中消失。雖然圖22示出了發布-訂購消息通道2200具有三個輸出通道和三個訂購者，但這只是一個示意性實施例，本領域技術人員將會容易地理解，發布-訂購消息通道2200可以包括任意數量的輸出通道和訂購者，並仍包含在本發明的範圍內。而且，雖然在圖22所示的實施例中對所有訂購者2220、2230和2240發布事件2250，但這只是一個示意性實施例，本領域技術人員將會容易地理解，可以向有效的訂購者的子集，甚至是單個訂購者發布事件。圖23示出了根據一個實施例在分布式訂單編排系統中管理事件的方法的流程圖。提供了編排層、任務層、外部接口層和外部系統層。在一個實施例中，在編排層之前提供一個分解層(未示出)。在包括分解層的實施例中，分解層可以調用一個服務，用以創建處理狀態和元數據並將它們存儲在資料庫中。根據該實施例，步驟2302產生一個事件並發布該事件。可以從訂單捕獲模塊接收訂單。這將導致事件被發布。使用資料庫中的處理狀態和元數據產生該事件。該事件被發送到任務層。根據該實施例，步驟2304啟動該任務，產生一個用於外部系統的消息並發送該消息。所產生的消息表示哪個任務應當由外部系統來執行。要執行的任務是已模型化的訂單處理的一個方面。例如，可為一個訂單調用該任務。也包含執行該任務所需的參數。消息被發送到一個外部接口。根據該實施例，步驟2306對消息進行轉換並將其發送給該外部層。由任務層產生的消息可以是一種通用的格式。然而不同的外部系統可以使用其它的格式進行通信。該外部接口層確定外部系統所使用的格式並轉換該消息。例如，用戶定義的元數據可用於確定要使用的格式。在一個實例中，對哪些系統調用了所訂購的產品的映射，被用來翻譯該消肩、ο根據該實施例，步驟2308接收由該外部系統返回的消息並處理該產生了一個結果的消息。該外部系統可以是執行與處理訂單相關的任務的系統，例如調度系統、運輸系統等等。當執行任務時，確定任務的結果。結果可以是安排好的運輸日期，運輸貨物的日期等。 結果然後被發送回該外部接口層。在該實施例中，步驟2310轉換該消息並將其發送到任務層。步驟2312基於結果更新資料庫中的處理狀態。然後處理進行到下一個可被產生的事件。重複處理直至處理完成。圖M示出了根據一個實施例的確定一組要發布的事件的方法的流程圖。根據一個實施例，該方法可在調用事件管理器時由事件管理器來實施，並且該方法可確定事件管理器要為具體處理髮布哪組事件。在M00，開始該方法。在M10，確定是否有處理步驟「剩餘」。換言之，確定是否有處理步驟還未執行。根據一個實施例，這種確定是基於存儲在資料庫中的處理狀態和元數據來做出的。根據一個實施例，處理狀態表示哪些處理步驟已被執行，元數據表示該處理的所有處理步驟。根據該實施例，如果一個處理步驟還未執行，但之前已被當前的實現方法所選擇，那麼處理步驟就不能被認為是「剩餘」，並且不可以被選擇。如果沒有處理步驟剩餘， 方法就在M60結束。如果剩餘了一個或多個處理步驟，那麼方法就前進到M20。在M20，選擇處理步驟。根據一個實施例，基於存儲在資料庫中的處理狀態和元數據來選擇處理步驟。例如，可以從處理狀態和元數據中來確定哪些處理步驟已被執行。這樣，就可以根據該方法選擇尚未執行的處理步驟。根據一個實施例，處理狀態表示哪些處理步驟已被執行，元數據表示該處理的所有處理步驟。根據該實施例，之前已被當前的實現方法所選擇的處理步驟不可以被選擇。在M30，確定所選擇的處理步驟是否依賴於其它的處理步驟。根據一個實施例， 確定基於存儲在資料庫中的元數據來確定所選擇的處理步驟是否依賴於其它的處理步驟。 例如，如果選擇了處理步驟4，就可以確定處理步驟4隻能在處理步驟1、2和3完成之後再執行。可選地，可以確定處理步驟4可以在任何時間來執行，而不考慮步驟1、2和3是否完成。如果確定出所選擇的處理步驟不依賴於其它的處理步驟，那麼方法就前進到M40。如果確定出處理步驟依賴於其它的處理步驟，那麼方法就前進到M50。在對40，基於所選擇的處理步驟產生一個事件並發布該事件。根據該實施例，通過發布該事件，該事件被傳輸給一個或多個訂購者。一個或多個訂購者可以消耗該事件並執行一個基於該所消耗的事件的任務，其中該消耗的事件與該處理步驟相對應。在M50，確定所選擇的處理步驟所依賴的其它處理步驟是否已完成。根據一個實施例，基於資料庫中存儲的元數據確定其它處理步驟是否已完成。例如，如果選擇了處理步驟4，並且處理步驟4依賴於步驟1、2和3，就確定處理步驟1、2和3是否已完成。如果確定出其它處理步驟已完成，那麼方法就前進到M40，並且如上所述產生一個事件並將其發布。然而，如果確定出其它處理步驟尚未完成，那麼方法就返回M10，這是因為在其它處理步驟完成之前不能執行所選擇的處理步驟。在對60，方法結束。然而，每次調用事件管理器時可以實施該方法。可以調用事件管理器直到所有的處理步驟都已執行，這樣，就可以每次實施該方法直到所有的處理步驟都已執行。根據該實施例，一旦為一個處理步驟產生一個事件並將其發布，在隨後實施該方法時該處理步驟就不可以被選擇。然而，如果選擇了一個處理步驟，但不對該處理步驟產生事件並將其發布(例如因為該處理步驟依賴於未完成的其它處理步驟)，那麼在隨後實施該方法時該處理步驟就可以被選擇。根據一個實施例，資料庫包含並行控制，以便如果兩個或多個步驟同時完成，能正確地確定出兩個或多個步驟已完成。因此，根據該實施例，可以基於資料庫的處理狀態和元數據來確定所選擇的處理步驟所依賴的其它處理步驟是否已完成。如前所述，分布式訂單編排系統的用戶可以定義一個要被調用的服務的序列，這些服務使用並行分支來影響業務處理規則。當用戶為一個處理步驟選擇一個服務時，該用戶可以提供附加的元數據，用以在運行時間上處理該訂單期間確定該處理數據如何被執行。在某個實施例中，可以定義並行分支。根據一個實施例，事件管理器可被用於為並行的處理步驟發布事件。根據該實施例，如果事件管理器基於存儲在資料庫中的處理狀態和元數據確定出兩個或多個處理步驟要並行地執行，該事件管理器就同時發布兩個或多個事件。下面將更加詳細地描述事件管理器為並行處理步驟發布事件的一個實例。圖25示出了根據一個實施例的事件管理器2500為並行處理步驟發布事件的一個實例。根據該實施例，事件管理器2500基於存儲在資料庫(未示出)中的處理狀態和元數據，確定要並行運行的三個處理步驟。事件管理器2500產生三個事件，事件2501、2502 和2503，並同時發布這三個事件。訂購者2510消耗事件2501並執行基於所消耗的事件的任務，訂購者2520消耗事件2502並執行基於所消耗的事件的任務，訂購者2530消耗事件 2503並執行基於所消耗的事件的任務。這樣，與事件2501、2502和2503相應的任務分別由訂購者2510、訂購者2520和訂購者2530並行執行。雖然在該實例中，有三個處理步驟並行運行，但本領域技術人員將會容易地理解， 這只是一個實例，任意數量的步驟都可以並行地運行。因此，在可選實施例中，事件管理器 2500可以為任意數量的並行處理髮布事件。在一個可選的實施例中，圖25所示的三個處理步驟是條件步驟而不是並行步驟。如前所述，條件步驟是依賴於結果的發生的步驟(例如另一個步驟的結束)。根據該實施例，事件管理器2500基於存儲在資料庫(未示出)中的處理狀態和元數據，確定要執行三個處理步驟中的哪一個。事件管理器2500產生事件2501、事件2502或事件2503，並發布該事件。當事件管理器2500發布事件2501時，訂購者2510消耗事件2501並並執行基於所消耗的事件的任務。同樣地，當事件管理器2500發布事件2502時，訂購者2520消耗事件2502並執行基於所消耗的事件的任務。相似地，當事件管理器2500發布事件2503時， 訂購者2530消耗事件2503並執行基於所消耗的事件的任務。仍如前所述，分布式訂單編排系統的用戶可指示一個處理要被分割為兩個或多個處理。根據一個實施例，事件管理器可用於為分割的處理步驟發布事件。根據該實施例，如果事件管理器基於存儲在資料庫中的處理狀態和元數據來確定一個處理要被分割為兩個或多個處理，該事件管理器就產生一組用於一個或多個分割單元的事件，並發布該組事件。 下面將詳細描述事件管理器分割處理和發布相應的一組事件的一個實例。圖沈示出了根據一個實施例的事件管理器沈00分割一個處理的一個實例。根據該實施例，事件管理器2600基於存儲在資料庫(未示出)中的處理狀態和元數據，確定當前的處理要被分割為兩個處理。事件管理器沈00確定處理的剩餘步驟並創建兩個分割單元，分割單元A和分割單元B。如前所定義的，分割單元定義了可被一起分割的處理中的一組連續的步驟。然後事件管理器沈00產生一組事件，事件沈01、2602、沈03和沈04，這裡事件沈01和沈02是分割單元A的一部分，事件沈03和沈04是分割單元B的一部分，每個事件與處理的一個剩餘的步驟相對應。然後事件管理器沈00發布事件沈01、2602、沈03和 2604。根據一個實施例，事件管理器沈00順序地發布事件沈01、2602、沈03和沈04。在另一個實施例中，事件管理器2600並行地發布作為分割單元A的一部分的一個事件以及作為分割單元B的一部分的一個事件，然後再並行地發布作為分割單元A的一部分的另一個事件以及作為分割單元B的一部分的另一個事件。在第三個實施例中，事件管理器沈00並行地發布事件2601,2602,2603和洸04。根據一個實施例，訂購者沈10消耗事件沈01並執行基於所消耗的事件的任務。另夕卜，訂購者2620消耗事件沈02和事件沈03，並執行基於每個所消耗的事件的任務。而且， 訂購者沈30消耗事件沈04並執行基於所消耗的事件的任務。根據一個實施例，當處理被分割時，由事件管理器沈00產生的事件相比於不分割處理時所產生的事件，可以具有不一樣的有效負載。根據該實施例，不同的有效負載可以標識與分割處理的一個步驟相對應的事件。雖然在該實例中，產生了四個事件，其中該四個事件與處理的四個步驟相對應，但本領域技術人員將會容易地理解，這只是一個實例，可以相應於任意數量的處理步驟來產生任意數量的事件。另外，雖然在該實例中，對三個訂購者發布四個事件，但本領域技術人員也將會理解，這也只是一個實例，所產生的事件可以發布給任意數量的訂購者，每個訂購者可以消耗任意數量的事件。並且，雖然在該實例中，處理被分割為兩個分割單元，但這也只是一個實例，處理可被分割為任意數量的分割單元。因此，事件管理器沈00可以將一個處理分割為任意數量的分割單元，其中每個分割單元包括任意數量的剩餘步驟。而且，事件管理器沈00能夠產生任意數量的事件，並能夠將這些事件發布給任意數量的訂購者。仍如前所述，分布式訂單編排系統的用戶可以啟動一個修改請求。如前所述，修改請求包括引用一個原始訂單的新訂單。該新訂單還包括對原始訂單的修正，因此也就包括對含有原始處理的業務步驟的修正。該原始處理可以是正在執行的，或者之前已被執行過。 根據一個實施例，事件管理器可用於處理一個修改請求。根據該實施例，如果事件管理器基於存儲在資料庫中的處理狀態和元數據確定出用戶已啟動一個修改請求，那麼事件管理器就產生一組事件，每個事件用來補償原始處理的一個步驟。下面將詳細描述事件管理器使用事件來處理修改請求的一個實例。圖27示出了根據一個實施例的事件管理器2700使用事件來處理修改請求的一個實例。根據該實施例，事件管理器2700基於存儲在資料庫(未示出)中的處理狀態和元數據來確定已經啟動一個修改請求。基於處理狀態和元數據，事件管理器2700產生一組事件以用於補償一個原始處理。在圖27所示的實施例中，事件管理器2700產生事件2701、2702 和2703，每個事件都與原始處理的一個步驟相對應。根據該實施例，事件管理器2700每次發布該組事件中的一個事件。這是因為原始處理的步驟是順序補償的，而不是並行的。在所示的實施例中，事件管理器2700首先將事件2701發布給訂購者2710。訂購者2710消耗該事件並基於所消耗的事件執行一個補償原始處理的第一步驟的任務。接著，事件管理器2700將事件2702發布給訂購者2720。訂購者2720消耗該事件並基於所消耗的事件執行一個補償原始處理的第二步驟的任務。然後，事件管理器2700將事件2703發布給訂購者2730。訂購者2730消耗該事件並基於所消耗的事件執行一個補償原始處理的第三步驟的任務。雖然在該實例中產生了三個事件，其中這三個事件與一個原始處理的三個步驟相對應，但本領域技術人員將會容易地理解，這只是一個實例，可以相應於原始處理的任意數量的步驟來產生任意數量的事件。而且，雖然在該實例中，對三個訂購者發布三個事件，但這也只是一個實例，一組事件可以發布給任意數量的訂購者。圖觀示出了根據一個實施例的分布式訂單編排模塊的功能的處理圖。根據該實施例，分布式訂單編排模塊啟動事件管理器用於使用一個處理來處理一個訂單。根據該實施例，事件管理器執行圖觀所示的功能。在觀10，基於存儲在資料庫中的處理狀態和元數據來確定要執行的一個處理步驟。在觀20，基於所確定的處理步驟來產生一個事件。根據該實施例，事件包括用於執行與該處理步驟相應的任務的指令。在觀30，在事件消息發送系統上發布該事件。這樣，根據本發明的一個實施例，分布式訂單編排系統的事件管理器可以基於存儲在資料庫中的處理狀態和元數據來產生並發布一組事件。一組訂購者可以消耗該組事件，每個訂購者可以執行基於所消耗的事件的任務。根據該實施例，分布式訂單編排系統中的組成部分可以互相去耦合，這是因為事件管理器可以處理這些組成部分之間的通信。分布式訂單編排系統中的計算可以與通信相分離。因此，分布式訂單編排系統的每個組成部分或每個層可以包括較少的原始碼，這是因為每個組成部分的原始碼可以只包括完成該組成部分的目的的功能，並且不需要包括處理與其它組成部分通信的原始碼。而且，可以對每個組成部分的原始碼進行修改，例如修改事件的有效負載，而不需要修改原始碼以修改該組成部分怎樣與其它組成部分進行通信。另夕卜，由於事件管理器是無狀態的，因此產生並保留較少的數據。因此，根據該實施例，分布式訂單編排系統可以更加可伸縮和靈活。
儘管上面是參照這裡的特定實施例來進行的描述，但這些特定實施例僅是示意性的並且是非限定性的。儘管描述了 BPEL，但可以理解其它的業務項目語言也可以使用。任意適當的程式語言都可用於實現特定實施例的例程，它們包括C、C++、Java、彙編語言等。可以採用不同的編程技術，例如過程的或者面向對象的。例程可在一個處理設備或多個處理器上執行。儘管以具體次序給出步驟、操作或計算，但是該次序可以在不同的特定實施例中進行修改。在某些特定實施例中，在說明書中順序示出的多個步驟是可以同時執行的。可以在利用指令執行系統、裝置、系統或設備使用或與它們連接的計算機可讀介質中實現這些特定實施例。能夠以軟體或硬體或它們的組合中的控制邏輯的形式來實施特定實施例。當該控制邏輯被一個或多個處理器所執行時，可操作地執行在特定實施例中描述的內容。可以使用已編程的通用目的數字計算機、使用應用程式專用集成電路來實現特定實施例，可以使用可編程邏輯設備、現場可編程門陣列、光、化學、生物、量子或納米設計的系統、元件和機制。通常，特定實施例的功能可由本領域所公知的任意方式來實現。可以使用分布式、網絡系統、元件和/或電路。數據的通信或傳輸可以是有線的、無線的或通過任意其它的方式。可以理解，在附圖中描述的一個或多個元件也可以採用更加分離或集成的方式來實現，或者在某些情形下甚至作為不能操作的元件進行移除或放棄，儘管它在某個特定的應用中是有用的。實施存儲在機器可讀介質中的程序或代碼，以便允許計算機執行上述任意一種方法，這也落入本發明的精神和範圍內。如在說明書和整個權利要求書所使用的，除非上下文中有明確的描述，「一個」、 「該」以及「所述」包括複數個引用。而且，如在說明書和整個權利要求書所使用的，除非上下文中有明確的描述，「在......中」意味著「在......中」或「在......上」。因此，雖然這裡已描述了特定實施例，但是容許在之前的描述中進行修改、各種改變以及替換，可以理解，也可以在在某些實例中採用特定實施例的某些特徵而不用相應地使用其它的特徵，這不會背離所表述的範圍和精神。因此，可以做出許多修改以便使特定的情況和材料適應基本的範圍和精神。
權利要求
1.一種用於啟動事件管理器以使用一個處理來處理訂單的設備，該設備包括 確定裝置，基於存儲在資料庫中的處理狀態和元數據來確定要執行的處理步驟；事件產生裝置，基於所確定的處理步驟產生事件，其中該事件包括執行與處理步驟相對應的任務的指令；以及發布裝置，在事件消息發送系統上發布該事件。
2.如權利要求1的設備，其中訂購者消耗所發布的事件並基於所發布的事件執行任務；以及其中該訂購者在執行該任務之後更新存儲在資料庫中的處理狀態。
3.如權利要求1的設備，其中事件管理器和訂購者分別是分布式訂單編排系統的不同組成部分。
4.如權利要求3的設備，其中事件管理器包括由編排系統調用的無狀態處理；以及其中訂購者包括任務層服務。
5.如權利要求1的設備， 其中中介器消耗所述事件；其中中介器基於包含在所述事件中的參數調用訂購者； 其中訂購者基於所發布的事件執行任務；以及其中該訂購者在執行任務之後更新存儲在資料庫中的處理狀態。
6.如權利要求1的設備，其中訂購者消耗所發布的事件；其中訂購者執行基於所發布的事件的子任務，該子任務是所述任務的組成部分； 其中訂購者在執行子任務之後更新存儲在資料庫中的處理狀態； 其中重複運行確定裝置、事件產生裝置和發布裝置，直到所述任務的所有子任務都已由訂購者執行。
7.如權利要求1的設備，其中所述處理狀態包括處理的一個狀態；以及其中所述確定裝置還包括 用於確定是否有任何的處理步驟剩餘的裝置； 用於選擇處理步驟的裝置；用於確定所選擇的處理步驟是否依賴於其他的處理步驟的裝置；以及用於當確定出所選擇的處理步驟依賴於其他的處理步驟時，確定是否所述其他的處理步驟已完成的裝置。
8.一種計算機實現的方法，用於啟動事件管理器以使用一個處理來處理訂單，該計算機實現的方法包括基於存儲在資料庫中的處理狀態和元數據來確定要執行的處理步驟； 基於所確定的處理步驟產生事件，其中該事件包括執行與處理步驟相對應的任務的指令；以及在事件消息發送系統上發布該事件。
9.如權利要求8的計算機實現的方法，其中訂購者消耗所發布的事件並基於所發布的事件執行任務；以及其中該訂購者在執行任務之後更新存儲在資料庫中的處理狀態。
10.如權利要求8的計算機實現的方法，其中所述事件管理器和訂購者分別是分布式訂單編排系統的不同組成部分。
11.如權利要求10的計算機實現的方法，其中所述事件管理器包括由編排系統調用的無狀態處理；以及其中所述訂購者包括任務層服務。
12.—種編排系統，包括 處理器；編排模塊，被配置為啟動事件管理器以使用一個處理來處理訂單；以及資料庫，被配置為存儲處理狀態和元數據，其中事件管理器被配置為基於存儲在資料庫中的處理狀態和元數據來確定要執行的處理步驟；其中事件管理器還被配置為基於所確定的處理步驟產生事件，其中該事件包括執行與處理步驟相對應的任務的指令；以及其中事件管理器還被配置為在事件消息發送系統上發布該事件。
13.如權利要求12的編排系統，其中訂購者消耗所發布的事件並基於所發布的事件執行任務；以及其中訂購者在執行任務之後更新存儲在資料庫中的處理狀態。
14.如權利要求12的編排系統，其中事件管理器和訂購者分別是分布式訂單編排系統的不同組成部分。
15.如權利要求14的編排系統，其中事件管理器包括由編排系統調用的無狀態處理；以及其中訂購者包括任務層服務。
全文摘要
本發明公開一種分布式訂單編排系統，包括一個事件管理器，被配置為基於存儲在資料庫中的處理狀態和元數據產生並發布一組事件。一組訂購者可以消耗該組事件，並且每個訂購者可以執行基於所消耗的事件的任務。
文檔編號G06Q30/00GK102467701SQ20111035590
公開日2012年5月23日 申請日期2011年11月11日 優先權日2010年11月12日
發明者A·辛格, R·阿達拉, S·賴伊辛加尼, Z·巴特 申請人:甲骨文國際公司