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

發(fā)明內(nèi)容
本發(fā)明的一個實施例涉及一種計算機可讀介質(zhì)，其具有存儲于其上的指令，當(dāng)被處理器所執(zhí)行時，使處理器啟動事件管理器，以使用處理來處理訂單。指令包括基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來確定要執(zhí)行的處理步驟。指令還包括基于所確定的處理步驟產(chǎn)生一個事件，該事件包括執(zhí)行與該處理步驟相對應(yīng)的任務(wù)的指令。指令還包括在一個事件消息發(fā)送系統(tǒng)上發(fā)布該事件。


在下面結(jié)合附圖對優(yōu)選實施例的詳細(xì)描述中，本發(fā)明的更進一步的實施例、細(xì)節(jié)、 優(yōu)點和改變將會變得清晰。圖1示出了根據(jù)一個實施例的分布式訂單編排系統(tǒng)的一個實例。圖2示出了根據(jù)一個實施例的用于處理訂單的流程圖。圖3示出了根據(jù)一個實施例的在訂單實施的上下文中，用于提供編排處理設(shè)計和編寫環(huán)境的系統(tǒng)的一個實例。圖4示出了根據(jù)一個實施例的接口的實例。圖5示出了根據(jù)一個實施例的運行時間操作。圖6示出了根據(jù)一個實施例的使用流程序列器調(diào)用服務(wù)的一個實例。圖7示出了根據(jù)一個實施例的在不同的層中用于編排數(shù)據(jù)流的處理。圖8示出了根據(jù)一個實施例的用于修改一個可執(zhí)行處理的方法的流程圖。圖9示出了可實現(xiàn)本發(fā)明一個實施例的系統(tǒng)的方框圖。圖10示出了根據(jù)一個實施例的分布式訂單編排系統(tǒng)。圖11示出了根據(jù)一個實施例的用于處理一個修改請求的方法的流程圖。圖12示出了根據(jù)一個實施例的修改請求流程的一個實例。圖13示出了根據(jù)一個實施例的可執(zhí)行處理的一個實例。圖14示出了根據(jù)一個實施例的用于調(diào)整原始的可執(zhí)行處理的各步驟的新的可執(zhí)行處理的一個實例。圖15示出了根據(jù)一個實施例的原始的可執(zhí)行處理和根據(jù)所接收的修改請求的新的可執(zhí)行處理的流程圖。圖16示出了根據(jù)一個實施例的依據(jù)使用事件管理器的處理來發(fā)布一組事件的方法的流程圖。圖17示出了根據(jù)一個實施例的使用事件管理器和任務(wù)層服務(wù)來編排訂單的方法的流程圖。圖18示出了根據(jù)一個實施例的使用事件管理器、任務(wù)層服務(wù)和中介器來編排訂單的方法的流程圖。圖19示出了根據(jù)一個實施例的在訂單實現(xiàn)的上下文中使用事件管理器來提供編排的系統(tǒng)的一個實例。圖20示出了根據(jù)一個實施例的采用事件管理器的分布式訂單編排系統(tǒng)。圖21示出了根據(jù)一個實施例的事件消息發(fā)送系統(tǒng)的一個實例。圖22示出了根據(jù)一個實施例的事件消息發(fā)送系統(tǒng)的發(fā)布訂購消息通道的一個實例。圖23示出了根據(jù)一個實施例的在分布式訂單編排系統(tǒng)中管理事件的方法的流程圖。圖M示出了根據(jù)一個實施例的確定待發(fā)布的一組事件的方法的流程圖。圖25示出了根據(jù)一個實施例的事件管理器發(fā)布用于并行處理步驟的事件的一個實例。圖沈示出了根據(jù)一個實施例的事件管理器分割處理的一個實例。圖27示出了根據(jù)一個實施例的事件管理器使用事件來處理修改請求的一個實例。圖觀示出了根據(jù)一個實施例的分布式訂單編排模塊的功能性的流程圖。
具體實施例方式本發(fā)明的一個實施例涉及一種分布式訂單編排系統(tǒng)(“D00”)。分布式訂單編排提供了一種靈活的、可配置的基礎(chǔ)架構(gòu)，其可被容易地定制以便符合企業(yè)的商務(wù)實踐以及現(xiàn)有的訂單實施系統(tǒng)的體系結(jié)構(gòu)。分解是指把從一個或多個訂單捕獲模塊接收的數(shù)據(jù)轉(zhuǎn)換為內(nèi)部規(guī)范格式以便處理該數(shù)據(jù)的過程。在一個示范實施例中，分布式訂單編排系統(tǒng)包括 捕獲層，用于在多個通道上捕獲客戶訂單；分解層，用于幫助確定編排處理；編排層，用于執(zhí)行并編排訂單行處理；任務(wù)層服務(wù)，用于執(zhí)行與任務(wù)相關(guān)的邏輯；外部接口層，用于連接外部系統(tǒng)；實施層；以及全局訂單承諾層，用于為用戶提供界面進行調(diào)度和提供資源。分布式訂單編排系統(tǒng)可以進一步地包括一個實施工作臺層，其連接系統(tǒng)的其它層并管理資源、 任務(wù)和分配。對以上描述的分布式訂單編排系統(tǒng)的各個層進行組合，從而提供一個降低了實施和維護成本的完整的訂單管理解決方案。然而，在一個可選的實施例中，捕獲層不是分布式訂單編排系統(tǒng)的一部分。在該可選的實施例中，捕獲層是一個單獨的系統(tǒng)的一部分，使用一個連接器服務(wù)來作為分布式訂單編排系統(tǒng)和該捕獲層之間的橋。圖1示出了根據(jù)一個實施例的分布式訂單編排系統(tǒng)100的一個實例。在該實施例中，分布式訂單編排系統(tǒng)100包括捕獲層110，其能夠在多個通道上接收并捕獲與客戶對貨物和/或服務(wù)的訂單有關(guān)的信息。該訂單可以通過圖形用戶界面來接收，例如網(wǎng)站購物車， 或者能夠通過任意數(shù)據(jù)輸入系統(tǒng)來接收。捕獲層Iio捕獲并向分解層120發(fā)送訂單信息。 然而，在一個可選實施例中，捕獲層110與分布式訂單編排系統(tǒng)100是分離的。在該可選的實施例中，使用一個連接器服務(wù)來作為分布式訂單編排系統(tǒng)100和該捕獲層110之間的橋。訂單捕獲系統(tǒng)捕獲的訂單具有任意必要的用于處理訂單的功能屬性，例如定價、 驗證、合格等。銷售訂單以源訂單對象的形式被饋送到分解層120。源訂單對象是從不同的捕獲系統(tǒng)所提交的銷售訂單對象中產(chǎn)生的。源訂單對象具有饋送到分解層120的通用的格式。分解層120接收訂單信息并將所接收的訂單拆分為單個的購買定單，以被發(fā)送到實施系統(tǒng)以及供應(yīng)商來執(zhí)行。分解層120可以包括分解規(guī)則工作臺，用于建立規(guī)則、規(guī)則集合以及用于訂單捕獲層110的轉(zhuǎn)換處理，它們可以從銷售角度捕獲訂單。例如在全球范圍內(nèi)銷售一種膝上電腦。該膝上電腦包括一根電源線，但是客戶只購買了膝上電腦(訂單上的一行)。也就是說，銷售網(wǎng)站可能會只銷售該膝上電腦而不會讓再客戶單獨訂購電源線。 然而，從實施角度看，膝上電腦和電源線需要從訂單中取回。在分解層120中，存在著這樣的業(yè)務(wù)規(guī)則，即膝上電腦必須具有電源線并且電源線上的插頭必須與膝上電腦的運輸目的地國家相匹配。因此當(dāng)分解模塊120完成時，訂單就具有了兩行，一行是膝上電腦，另一行是合適的電源線。這樣訂單就被分解為多個待實施的項目。而且，分解層120可以取得所接收的訂單并將其翻譯成分布式訂單編排系統(tǒng)100 的其它層，例如實施層160，所需的訂單格式以及訂單內(nèi)容。因為捕獲層110出于兼容性目的，能夠在不同類型的系統(tǒng)上接收任意格式的訂單，因此分解層120就需要將訂單翻譯成與該分布式訂單編排系統(tǒng)100所有的其它層和/或處理相兼容并能夠被它們識別的格式。 另外，分解層120可以提供一種處理啟動能力，用來基于適當(dāng)?shù)姆纸庖?guī)則分配并啟動訂單的編排處理。例如，基于訂單中的參數(shù)分配不同的編排處理。例如，公司可以按照實施或運輸?shù)乃俣葘δ承┛蛻艚o予特殊待遇。例如，金卡客戶可以給予加快運輸。而且，也可以提供與客戶溝通的附加步驟。當(dāng)接收到這些客戶的訂單時，它們就被分配給具有這些參數(shù)和步驟的編排處理，而其它客戶的訂單就被分配給標(biāo)準(zhǔn)處理。
分解可以使用規(guī)范對象模型來完成與訂單捕獲系統(tǒng)的數(shù)據(jù)格式的解耦合。分解整合處理工作在稱作企業(yè)業(yè)務(wù)對象(EB0’s)的一組通用數(shù)據(jù)結(jié)構(gòu)上。它們是基于規(guī)范數(shù)據(jù)模型的。這種方法允許DOO不不必知曉所參與的應(yīng)用程序并且獨立于源或目標(biāo)應(yīng)用程序。該模型消除了使來自不同的應(yīng)用程序的數(shù)據(jù)互相直接映射的需要。如圖1所示，分布式訂單編排系統(tǒng)100進一步包括一個編排層130。編排層130提供了單獨的編排處理用于管理訂單和/或服務(wù)行項目。例如，編排層130可以提供業(yè)務(wù)處理管理功能，以便支持處理中的步驟的調(diào)度，包括步驟的持續(xù)時間和完成日期的計算或重新計算。編排層130還可以提供外部任務(wù)執(zhí)行功能，以便支持外部任務(wù)的創(chuàng)建、更新、釋放和監(jiān)控。外部任務(wù)是由實施系統(tǒng)來執(zhí)行的任務(wù)。任務(wù)層服務(wù)進行特殊處理然后將數(shù)據(jù)發(fā)送到那些集成的實施系統(tǒng)。編排是任務(wù)層服務(wù)的調(diào)用的順序。編排層130還可以提供風(fēng)險管理，以把訂單的承諾的交貨日期與當(dāng)前的完成訂單的估計日期進行核對，映射到用戶定義的閾值，以及處理并逐步提高條件。編排層130可以進一步提供用于修改訂單的處理，包括一個支持處理，用以退回到提供修改訂單自動操作的階段并對訂單捕獲階段所修改的訂單更改實時編排處理。而且，可以通過實例化該編排處理來提供預(yù)計的訂單完成日期。編排層130還提供一種機制用于自動地或基于用戶請求來更新訂單狀態(tài)。一個實施例提供了一種工具，用來在訂單實施業(yè)務(wù)處理中為業(yè)務(wù)處理的模型化提供高度抽象。業(yè)務(wù)處理可以由用戶例如業(yè)務(wù)分析師來模型化，并且不需要任何IT設(shè)計師來編寫代碼以執(zhí)行業(yè)務(wù)處理。在中心位置定義業(yè)務(wù)處理為用戶提供了靈活性，其中該中心位置被配置為輸入并捕獲編排并實施訂單所需的所有信息。這種中心位置的一個實例可以是基于網(wǎng)絡(luò)的管理用戶界面。同樣地，編排和訂單實施所需的所有信息的一個實例可以是業(yè)務(wù)調(diào)度、核心編排和修改管理所需的信息。業(yè)務(wù)處理可以確認(rèn)定義了要在訂單實施處理中執(zhí)行的步驟的一個或多個服務(wù)。運行時間引擎然后使用該定義并基于業(yè)務(wù)處理的定義來動態(tài)地調(diào)用這些服務(wù)。在業(yè)務(wù)環(huán)境下，業(yè)務(wù)用戶通常會面對模型設(shè)計師而不是IT人員。通過提供一種基于網(wǎng)絡(luò)的管理環(huán)境，業(yè)務(wù)用戶就可以設(shè)計業(yè)務(wù)處理了。處理的定義可以用業(yè)務(wù)術(shù)語而不是 IT術(shù)語來定義。特定的實施例允許管理環(huán)境脫離代碼編輯器例如BPEL編輯器之外，用來使用相關(guān)服務(wù)來定義這些處理。用戶可以將這些能夠在運行時間上執(zhí)行的處理配置為可執(zhí)行處理，而不需要IT的介入。這就減少了每次部署這些處理就要修改業(yè)務(wù)處理的需要。用戶在數(shù)據(jù)表上設(shè)置服務(wù)的序列。然后模型化的業(yè)務(wù)處理被用于執(zhí)行一個可執(zhí)行處理(也被識別為編排處理)，其可以在運行時間上被安裝及執(zhí)行。在一個實施例中，“運行時間”可被定義為當(dāng)接收訂單以便進行處理的時間。元數(shù)據(jù)被安裝在數(shù)據(jù)運行時間表中，并用于定義業(yè)務(wù)處理的可執(zhí)行處理。元數(shù)據(jù)用于在可執(zhí)行處理中調(diào)用服務(wù)。在一個實施例中，所調(diào)用的服務(wù)被封裝并且是可重復(fù)使用的。元數(shù)據(jù)用于確定怎樣和何時調(diào)用服務(wù)。而且，依靠元數(shù)據(jù)，產(chǎn)生輸入變量并發(fā)送給各個服務(wù)以便調(diào)用被封裝的服務(wù)。使用公共簽名來發(fā)送數(shù)據(jù)從而調(diào)用服務(wù)。不同的輸入變量可以針對不同的可執(zhí)行處理中的不同的服務(wù)來公式化。輸入變量以相同方式來格式化，以便使服務(wù)能夠讀取不同的數(shù)據(jù)組并調(diào)用服務(wù)。這樣，服務(wù)就可以在不同的業(yè)務(wù)處理中重復(fù)使用，而不需重新編碼及重新部署。服務(wù)的部署表示該處理準(zhǔn)備好發(fā)布以進行測試或生產(chǎn)。
分布式訂單編排系統(tǒng)100可以進一步包括任務(wù)層服務(wù)140，以提供用于為每個編排處理階段控制處理邏輯的封裝服務(wù)。具體地說，任務(wù)層服務(wù)140可以提供任務(wù)專用業(yè)務(wù)邏輯，使該邏輯圍繞某個請求，以便使系統(tǒng)100知曉何種邏輯任務(wù)與特定請求相關(guān)。需要在編排中的可執(zhí)行處理中執(zhí)行的步驟可以請求要被執(zhí)行的任務(wù)。例如，任務(wù)層服務(wù)140能夠提供并控制處理邏輯，以安排運輸、請求運輸、更新安裝平臺、創(chuàng)建活動等等。任務(wù)層服務(wù) 140的輸出是標(biāo)準(zhǔn)的貨物和/或一個或多個服務(wù)請求，它們可被提供給系統(tǒng)100的其它層， 例如外部接口層150或?qū)嵤?60。另外，任務(wù)層服務(wù)140可以接收用于更新處理邏輯或狀態(tài)的輸入。任務(wù)層服務(wù)140啟動該任務(wù)，產(chǎn)生用于外部系統(tǒng)的消息并發(fā)送該消息。產(chǎn)生執(zhí)行該任務(wù)所需的數(shù)據(jù)結(jié)構(gòu)。某些任務(wù)可以在任務(wù)層服務(wù)中預(yù)先定義。而且，客戶可是使用定義了如何創(chuàng)建一項任務(wù)的模板來增加其它任務(wù)。所產(chǎn)生的消息指示了哪個任務(wù)應(yīng)當(dāng)由外部系統(tǒng)來執(zhí)行。待執(zhí)行的任務(wù)是已被模型化的訂單處理的體現(xiàn)。例如，任務(wù)可以是為訂單開賬單。還可以包括用于執(zhí)行任務(wù)的參數(shù)。向外部接口層150的外部接口發(fā)送該消息。任務(wù)層服務(wù)140轉(zhuǎn)換該消息并將其發(fā)送給外部接口層。分布式訂單編排系統(tǒng)100還包括外部接口層150，用于翻譯標(biāo)準(zhǔn)請求并將請求路由至外部系統(tǒng)以便處理。更特別地，外部接口層150可以接收從任務(wù)層服務(wù)140輸出的標(biāo)準(zhǔn)貨物和/或服務(wù)的一個或多個請求，并且如果需要的話就就提供請求的單層轉(zhuǎn)換以匹配實施系統(tǒng)的格式。外部接口層150所執(zhí)行的轉(zhuǎn)換將數(shù)據(jù)映射到集成實施系統(tǒng)所需的內(nèi)容和格式。分解層120的轉(zhuǎn)換是將數(shù)據(jù)轉(zhuǎn)化為系統(tǒng)100使用的內(nèi)部格式。外部接口層150可以將來自任務(wù)層服務(wù)140的數(shù)據(jù)結(jié)構(gòu)映射到外部格式。外部接口層150提供靈活的路由以便使這些請求基于業(yè)務(wù)規(guī)則路由到具體的實施系統(tǒng)。例如，如果多于一個運輸系統(tǒng)是可用于實施的，那么業(yè)務(wù)規(guī)則將確定各個運輸請求要被發(fā)送到哪個運輸系統(tǒng)。外部接口層150還可以包括轉(zhuǎn)換規(guī)則工作臺，該轉(zhuǎn)換規(guī)則工作臺能夠用于建立規(guī)則、規(guī)則集合以及用于外部路由該請求的轉(zhuǎn)換數(shù)據(jù)。任務(wù)層所產(chǎn)生的消息可以是通用格式的。然而不同的外部系統(tǒng)可以使用其他的格式來通信。外部接口層確定外部系統(tǒng)所使用的格式并轉(zhuǎn)換該消息。例如，用戶定義的元數(shù)據(jù)可用于確定要使用哪種格式。在一個實例中，對哪些外部系統(tǒng)調(diào)用了所訂購的產(chǎn)品的映射，被用來翻譯該消息。外部系統(tǒng)可以是執(zhí)行與處理訂單相關(guān)的任務(wù)的系統(tǒng)，例如可以是調(diào)度系統(tǒng)、運輸系統(tǒng)等等。當(dāng)執(zhí)行任務(wù)時，確定任務(wù)的結(jié)果。結(jié)果可以是調(diào)度運輸時的日期，運輸貨物的日期等等。然后結(jié)果被送回外部接口層150。分布式訂單編排系統(tǒng)100可以進一步包括全局訂單承諾層170，該全局訂單承諾層170提供用于調(diào)度訂單并為訂單提供資源的接口，例如圖形用戶接口。特別是在一個實施例中，全局訂單承諾層170包括一個來源經(jīng)紀(jì)人，用于基于客戶概要、訂單和供應(yīng)商定義等確定與訂單相關(guān)的產(chǎn)品和服務(wù)的最佳來源。而且，全局訂單承諾層170在分布式內(nèi)部系統(tǒng)上提供實時的庫存儲備和未儲備以及庫存的檢查。全局訂單承諾層170的接口允許瀏覽可用性和來源信息，以便使用戶能夠瀏覽其可用性并手動修改實施貨物或服務(wù)訂單的來源。然而，在一個可選實施例中，全局訂單承諾層170是與分布式訂單編排系統(tǒng)100分離的。 在該可選實施例中，使用一個連接器服務(wù)來作為分布式訂單編排系統(tǒng)100和全局訂單承諾層170之間的橋。實施工作臺180可以作為訂單實施管理員、用戶和監(jiān)管員的用戶接口，用來監(jiān)控并管理訂單在系統(tǒng)100內(nèi)的流動。在一個實施例中，實施工作臺180向用戶(例如監(jiān)管員) 提供監(jiān)控訂單實施任務(wù)的機制，包括允許監(jiān)管員監(jiān)控活動的加載并生成報告。實施工作臺 180還提供了實施處理分析，其允許業(yè)務(wù)處理設(shè)計者分析處理的度量標(biāo)準(zhǔn)，例如手動干預(yù)的數(shù)量、發(fā)生錯誤的數(shù)量和種類、超期訂單的數(shù)量以及期望處理周期與實際周期的對比。在某些實施例中，實施系統(tǒng)性能的分析能力也包含在實施工作臺180中，用以提供報告和儀表板使訂單管理者能瀏覽每個系統(tǒng)的訂單并分析性能。實施工作臺可以使用圖形表示法(例如圖表和曲線)來向用戶清晰地傳達系統(tǒng)狀態(tài)/訂單信息。由于DOO系統(tǒng)100具有數(shù)據(jù)參考數(shù)據(jù)，因此可以畫出合計圖表/曲線用于趨勢分析。如下所述，用戶可以從實施工作臺采取動作，例如替換所訂購的項目、將數(shù)量分割為多個訂單行、保持訂單行以防止繼續(xù)發(fā)展寸。根據(jù)一個實施例，實施工作臺180允許用戶做出與實施相關(guān)的大量訂單信息的修改，包括對實施信息(例如日期等)進行一行或多行的修改。實施工作臺180進一步允許對編排處理的監(jiān)控，例如回顧編排處理的狀態(tài)，包括整個處理的進展，以及各個任務(wù)的狀態(tài)和相應(yīng)的實施行和人物行。在一個實施例中，實施工作臺180包括維護訂單實施處理的機制，并允許訂單處理用戶控制與訂單相關(guān)的處理，包括暫停、編輯、取消等等。在某些實施例中，實施工作臺180還提供用于訂單和任務(wù)分配的功能。例如，實施工作臺180可以使用分配引擎來將訂單和活動分配給合適的實施資源。實施工作臺180可以包括批量對訂單進行再分配的機制，從而允許監(jiān)管員從一個實施系統(tǒng)到另一個實施系統(tǒng)重新為一組訂單提供資源。實施工作臺180還提供供應(yīng)率的分配和延期交貨的規(guī)則，它們能夠自動確定如何控制短缺狀況。通用收件箱可以包含在實施工作臺180中，用以允許用戶瀏覽分配給他們的活動并對任務(wù)作出響應(yīng)。實施工作臺180允許用戶瀏覽正在系統(tǒng)100的不同層中處理的訂單。對訂單狀態(tài)的瀏覽可以從任何一個處理該訂單的層中產(chǎn)生。這是因為已經(jīng)提供了一個端到端集成系統(tǒng)因。傳統(tǒng)的訂單系統(tǒng)已經(jīng)將解決方案定制成不允許瀏覽不同層。通過以一個允許通用通信的格式集成各個層，就能提供一個可以從所有層中產(chǎn)生瀏覽的用戶接口。分布式訂單編排系統(tǒng)100的實例還可以包括一個實施層160。在一個實施例中，實施層160可以是面向外部實施系統(tǒng)的接口，并能夠用于將訂單信息和實施需求傳輸給與訂單相關(guān)的貨物和/或服務(wù)的供應(yīng)商或來源。分布式訂單編排系統(tǒng)100的某些實施例包括一個管理用戶接口。管理用戶接口提供了對終端用戶隱藏實施執(zhí)行環(huán)境的復(fù)雜性的管理服務(wù)。例如，該管理用戶接口通過一個管理環(huán)境提供產(chǎn)品映射，該管理環(huán)境定義了一些轉(zhuǎn)換方式，以用于在銷售視圖和供應(yīng)商系統(tǒng)定義之間進行產(chǎn)品結(jié)構(gòu)的映射。在該實施例中，銷售視圖指的是在下購買訂單時提供給客戶的簡單視圖。供應(yīng)商系統(tǒng)定義指的是由貨物和/或服務(wù)供應(yīng)商所使用的更具體和詳細(xì)的信息。管理用戶接口還可以提供一個編排處理工作臺用于建立用于訂單編排的處理、規(guī)則集合和參數(shù)。管理用戶接口具有一個集成的設(shè)置，包括處理順序、計劃、風(fēng)險、修改管理和工作臺顯示。管理用戶接口還允許用于任務(wù)、處理和實施行的用戶定義狀態(tài)的轉(zhuǎn)變，以及用于配置約束、轉(zhuǎn)換規(guī)則和路由規(guī)則的業(yè)務(wù)規(guī)則配置。
圖2描述了根據(jù)一個實施例的用于處理訂單的簡化流程圖200。在步驟202中，分解層120接收一個訂單。在步驟204中，分解層120確定用于實施訂單的一個或多個編排處理。例如，訂單可以被分解成必須要獲得的項目或必須要執(zhí)行的服務(wù)。每個項目或服務(wù)可以具有其自身的編排服務(wù)。在步驟206中，編排層130產(chǎn)生可執(zhí)行處理用以編排這些編排服務(wù)的實施?？蓤?zhí)行處理可以具有多個必須對每個編排服務(wù)執(zhí)行的步驟。在步驟208中，任務(wù)層服務(wù)140對執(zhí)行該可執(zhí)行處理的各步驟所需的業(yè)務(wù)功能進行控制。為可執(zhí)行處理來執(zhí)行的任務(wù)可以包括建立具有信息和參數(shù)的數(shù)據(jù)結(jié)構(gòu)，這些信息和參數(shù)是使外部系統(tǒng)執(zhí)行該任務(wù)所必須的。該數(shù)據(jù)結(jié)構(gòu)可以按照系統(tǒng)100的內(nèi)部格式。例如，該任務(wù)可以是為一個訂單開賬單。并且還包括用于執(zhí)行該任務(wù)的參數(shù)。在步驟210中，外部接口層對任務(wù)進行翻譯并將其路由到外部系統(tǒng)。然而，不同的外部系統(tǒng)可以使用其他的格式進行通信。外部接口層確定外部系統(tǒng)所使用的格式并對消息進行轉(zhuǎn)換。例如，用戶定義的元數(shù)據(jù)可以用于確定要使用的格式。在一個實例中，對哪些外部系統(tǒng)調(diào)用了所訂購的產(chǎn)品的映射，被用來翻譯該消息。在步驟212中，外部接口層150接收來自外部系統(tǒng)的、關(guān)于任務(wù)處理的結(jié)果。當(dāng)執(zhí)行任務(wù)時，就確定該任務(wù)的結(jié)果。結(jié)果可以是計劃發(fā)貨日期，發(fā)貨日期等等。在步驟214中，外部接口層150轉(zhuǎn)換消息并將其發(fā)送到任務(wù)層服務(wù)140。在步驟 216中，編排層基于該結(jié)果更新關(guān)于任務(wù)的信息。例如，結(jié)果可以存儲在表或數(shù)據(jù)庫中。然后該處理前進到下一個要被調(diào)用的服務(wù)。下面將參照圖3-8以及根據(jù)使用流程序列器進行編排的實施例，來描述更多實現(xiàn)編排的細(xì)節(jié)。然而，本領(lǐng)域技術(shù)人員將會容易地理解，更多的細(xì)節(jié)只是編排的一個實例，這種編排還可以采用許多不同的實施方式來實現(xiàn)，包括不使用流程序列器的可選實施例。例如，可以根據(jù)美國專利申請?zhí)?2/697，756、名為“使用模板的業(yè)務(wù)處理的編排”中描述的細(xì)節(jié)來實現(xiàn)編排。圖3示出了根據(jù)一個實施例的在訂單實施的上下文中，用于提供編排處理設(shè)計和編寫環(huán)境的系統(tǒng)300的一個實例。在該實施例中，系統(tǒng)300包括一個編排系統(tǒng)302和客戶機304。盡管只提供了編排系統(tǒng)302和客戶機304的單個實例，但可以理解，還可以使用多個編排系統(tǒng)和客戶機的多個實例。而且，編排系統(tǒng)302和客戶機304可以是分布式計算系統(tǒng)的一部分。也就是，所描述的功能可以分布于各種計算設(shè)備中?？蛻魴C304可以是一個計算設(shè)備或一組計算設(shè)備，它們被配置為允許業(yè)務(wù)處理模型化。編排系統(tǒng)302編排用于業(yè)務(wù)處理的可執(zhí)行處理310的服務(wù)的調(diào)用和運行。如所描述的那樣，編排是要在業(yè)務(wù)處理中執(zhí)行的服務(wù)的協(xié)調(diào)和調(diào)用。如所使用的，業(yè)務(wù)處理可以由用戶來模型化。業(yè)務(wù)處理是對要執(zhí)行的步驟的定義。 這些步驟定義在接口 308中?？蓤?zhí)行處理是由運行時間引擎312執(zhí)行的處理。該可執(zhí)行處理包括要被執(zhí)行以協(xié)調(diào)服務(wù)的代碼。服務(wù)庫306包括多個可包含在業(yè)務(wù)處理中的服務(wù)。在一個實施例中，服務(wù)庫306包括可在一個訂單實施業(yè)務(wù)處理中執(zhí)行的服務(wù)。訂單實施包括被執(zhí)行用以實施訂單的處理。 例如，可以從訂單捕獲模塊中接收訂單。訂單可以是用于貨物、服務(wù)等?？梢詧?zhí)行不同的服務(wù)來實施訂單，例如運輸、安裝、貨品計價等。訂單實施處理可以根據(jù)這些不同的服務(wù)來特性化。期望對于任一個訂單，這些處理中的某些或全部要被執(zhí)行用以實施訂單。因此，特定的實施例針對那些期望在訂單實施處理中執(zhí)行的服務(wù)而創(chuàng)建服務(wù)。服務(wù)可以是非可配置單元和可配置單元。非可配置單元是建立并提供給客戶的服務(wù)。非可配置單元是可被用在訂單實施處理中的單元。例如，如所期望的，必須要在訂單實施處理中執(zhí)行不同的服務(wù)，例如應(yīng)收帳款。因此，這些服務(wù)可以用語言來模型化，例如BPEL。 盡管描述的是BPEL，但本領(lǐng)域技術(shù)人員可以容易地理解，也可以使用其他的語言?？膳渲脝卧怯煽蛻艚⒉⒍x的服務(wù)。例如，在由用戶配置的服務(wù)周圍提供包裝器。例如，客戶需要專門對客戶的公司的運輸服務(wù)。因此，由可配置單元執(zhí)行的服務(wù)可由客戶定義并建立，但包裝器允許運行時間引擎312來自動調(diào)用服務(wù)。這使得客戶能夠定義他們各自組織所需要的服務(wù)。 服務(wù)可以在不同業(yè)務(wù)處理中重新使用。服務(wù)可以被封裝并被配置為接收待執(zhí)行服務(wù)的公共簽名。例如，對于每個業(yè)務(wù)處理，可以提供不同的參數(shù)(即用不同的價格訂購不同的產(chǎn)品，等等)。這導(dǎo)致了不同的輸入變量輸入到了服務(wù)中。公共簽名定義了一個數(shù)據(jù)結(jié)構(gòu)，以允許對不同的可執(zhí)行處理310重復(fù)使用該服務(wù)。這樣，用相同部署的服務(wù)來處理不同訂單的不同輸入變量，但是可以獲得不同的結(jié)果。以這種方式，就能抽象出訂單實施處理。 不同的用戶可以定義哪個服務(wù)要被執(zhí)行而不用考慮到這些處理是如何用編排語言編碼的。接口 308可以是一個管理用戶接口。例如，圖形用戶接口允許用戶在一個抽象級別上模型化業(yè)務(wù)處理。例如，服務(wù)庫306可以被提供給客戶機304。然后用戶可以使用接口 308來定義使用了服務(wù)庫306中的服務(wù)的業(yè)務(wù)處理的步驟。用戶可以定義業(yè)務(wù)處理中的許多步驟。每個步驟可以與服務(wù)庫306中的服務(wù)相關(guān)聯(lián)。這些步驟可以存儲在數(shù)據(jù)表中，數(shù)據(jù)表可以包括由運行時間引擎312使用的元數(shù)據(jù)，用以編排可執(zhí)行處理310。數(shù)據(jù)表被示為存儲在存儲器314中?？梢岳斫?，數(shù)據(jù)表可以存儲在任意區(qū)域中，例如在客戶機304、編排系統(tǒng)302或其他設(shè)備中。元數(shù)據(jù)可以由用戶來定義、從數(shù)據(jù)表和/或編排規(guī)則中確定。用戶定義了要調(diào)用的服務(wù)的順序以及需要的條件或并行分支，來影響業(yè)務(wù)處理規(guī)則。當(dāng)用戶選擇了用于一個處理步驟的服務(wù)時，用戶也提供了附加的元數(shù)據(jù)，用于確定在運行時間中如何在訂單的處理過程中執(zhí)行處理數(shù)據(jù)。例如，定義條件或并行分支。在運行時間中，運行時間引擎312接收元數(shù)據(jù)并使用元數(shù)據(jù)來確定用于編排可執(zhí)行處理310的參數(shù)。運行時間引擎312使用這些參數(shù)來確定可執(zhí)行處理310中的哪些步驟要執(zhí)行，什么時候執(zhí)行。例如，運行時間引擎312通過調(diào)用一系列由用戶定義的步驟中的服務(wù)，來編排可執(zhí)行處理310。如下更詳細(xì)的描述，也可以執(zhí)行步驟的并行和條件處理。而且， 元數(shù)據(jù)能夠用于確定用來調(diào)用服務(wù)的輸入變量。在運行時間中讀取表的元數(shù)據(jù)，并調(diào)用服務(wù)，這允許執(zhí)行對可執(zhí)行處理310的修改，并自動地在運行時間中實現(xiàn)。運行時間引擎312讀取所定義的每個步驟并執(zhí)行這些步驟。如果需要在服務(wù)中進行修改，用戶可以使用接口 308來增加/刪除/替換一個服務(wù)。在運行時間中，當(dāng)讀取表時，可以自動地執(zhí)行這種修改。圖4示出了根據(jù)一個實施例的接口 308的實例。處理級別表416概括了已被模型化的不同業(yè)務(wù)處理。如圖所示，業(yè)務(wù)處理-地毯安裝和處理1-已由用戶模型化。在處理級別表416中，處理名稱列418示出了業(yè)務(wù)處理地毯安裝業(yè)務(wù)處理和處理 1已經(jīng)被模型化。描述列420描述了該處理。處理分類列422描述了處理的分類。狀態(tài)列4 是可執(zhí)行處理的狀態(tài)?？蓤?zhí)行處理310可以具有不同的狀態(tài)。例如，某些業(yè)務(wù)處理可以被批準(zhǔn)為生產(chǎn)、被批準(zhǔn)為測試、或可以是新的。被批準(zhǔn)為生產(chǎn)意味著服務(wù)被批準(zhǔn)為正常的業(yè)務(wù)使用，被批準(zhǔn)為測試意味著被批準(zhǔn)為進行測試，而新的是在開發(fā)中的服務(wù)。表416中的業(yè)務(wù)處理可以被選擇，并且數(shù)據(jù)表400示出了單個的業(yè)務(wù)處理的步驟細(xì)節(jié)。一個業(yè)務(wù)處理被命名為地毯安裝，數(shù)據(jù)表400的步驟細(xì)節(jié)示出了已經(jīng)對地毯安裝定義的每個服務(wù)。在數(shù)據(jù)表400中，步驟列404標(biāo)識了業(yè)務(wù)處理中的步驟。例如，提供步驟10_60。 用于這些步驟的服務(wù)可以在運行時間中被執(zhí)行。這些步驟可以從頂部到底部按順序(或以任意其他的次序)執(zhí)行。在這種情況下，執(zhí)行步驟10，然后當(dāng)完成后，執(zhí)行步驟20，等等。另夕卜，盡管未示出，還可以使用接口 308定義條件和并行步驟。條件步驟是依賴于結(jié)果的發(fā)生的步驟(例如另一步驟的結(jié)束)，而并行步驟是并行執(zhí)行的。用戶定義了步驟是條件的還是并行的。步驟名稱列406提供了用于各步驟的描述名稱。例如，提供運輸?shù)靥骸⒌却\輸、 安裝地毯、等待完成、開賬單等步驟。任務(wù)類型列408描述了什么類型的任務(wù)正在被執(zhí)行。例如，對于運輸?shù)靥旱娜蝿?wù)， 外部系統(tǒng)可以執(zhí)行運輸任務(wù)，對于開賬單的步驟，賬單系統(tǒng)可以為一個賬單開賬單。服務(wù)列412標(biāo)識了與該步驟相關(guān)的服務(wù)。任務(wù)名稱列414是任務(wù)的名稱。例如， 那些與地毯相關(guān)的任務(wù)被命名為地毯運輸、地毯安裝、為地毯開賬單。如果正在安裝的是地毯之外的其他貨物，任務(wù)名將會不同。例如，水槽運輸、水槽安裝、為水槽開賬單將會成為這些任務(wù)的名稱。用戶可以使用接口 308來產(chǎn)生數(shù)據(jù)表400。用戶可以從用于服務(wù)庫306的菜單中選擇服務(wù)。例如，用戶使用菜單接口 432來從服務(wù)庫306中選擇服務(wù)。下拉菜單、拖放選項和其他的可視處理可以用于定義可執(zhí)行處理310。用戶具有一個具體編排接口，用于以合適的驗證呈現(xiàn)業(yè)務(wù)處理數(shù)據(jù)，而不是要去學(xué)習(xí)多用途IT開發(fā)環(huán)境的復(fù)雜性。這允許用戶以抽象的方式模型化一個業(yè)務(wù)處理，但是使可執(zhí)行處理310從該模型中產(chǎn)生和執(zhí)行。服務(wù)庫306中的服務(wù)可由非可配置單元和可配置單元來構(gòu)成。例如，非可配置單元設(shè)置在列440中，可配置單元設(shè)置在列442中。如圖所示，非可配置的服務(wù)包括運輸、應(yīng)收帳(“AR”)、開賬單以及全局訂單承諾(“G0P”)。而且，可配置的單元被指定為A、B、C 和D。如圖所示，使用菜單412在接口 308中產(chǎn)生表400。表400與元數(shù)據(jù)和任意變量相關(guān)， 其中元數(shù)據(jù)描述了要被執(zhí)行的服務(wù)，變量用于調(diào)用這些服務(wù)。一旦業(yè)務(wù)處理在接口 308中被模型化并通過設(shè)置處理狀態(tài)而被釋放，那么運行時間引擎312用于編排服務(wù)的調(diào)用。圖5示出了根據(jù)一個實施例的運行時間操作。在該實施例中，表讀取器502從接口 308接收定義了業(yè)務(wù)處理的元數(shù)據(jù)。表讀取器502可以將數(shù)據(jù)復(fù)制到運行時間表506中，但這不是必須的。根據(jù)該實施例，在運行時間期間，步驟讀取器504被配置為讀取運行時間表506中的步驟。步驟讀取器504可以分析元數(shù)據(jù)并確定那些步驟應(yīng)當(dāng)被執(zhí)行以及何時被執(zhí)行。例如，步驟讀取器504驗證并行或條件分支是否與一個步驟相關(guān)。元數(shù)據(jù)還用于確定用于服務(wù)的輸入變量。輸入變量可以從元數(shù)據(jù)、查找表中的數(shù)據(jù)中確定，或者使用規(guī)則來確定。根據(jù)該實施例，步驟讀取器504使用來自服務(wù)306的封裝的服務(wù)以及元數(shù)據(jù)來組合可執(zhí)行處理310。例如，為可執(zhí)行處理310確定在這些步驟中被模型化的每個服務(wù)的代碼。還可以確定每個服務(wù)的輸入變量。例如，元數(shù)據(jù)用于確定輸入變量，以便使服務(wù)能處理用于業(yè)務(wù)處理的訂單。而且，可使用元數(shù)據(jù)來確定任意的合作者鏈接，以便允許服務(wù)與外部系統(tǒng)交互?；跇I(yè)務(wù)處理中的步驟的定義來組合可執(zhí)行處理310。由于服務(wù)是可重復(fù)使用的，用于一個服務(wù)的相同代碼可以用于不同的業(yè)務(wù)處理。然而，輸入變量或合作者鏈接可以是不同的。由于相同的代碼被重復(fù)使用，因此提供了可執(zhí)行處理310的自動組合。在該實施例中，流程序列器508用于基于可執(zhí)行處理310在適當(dāng)?shù)臅r間動態(tài)地調(diào)用這些步驟。如方塊507所示，步驟10可以確定要調(diào)用的服務(wù)。然后執(zhí)行步驟20、30、40 和50中的一個。然后步驟60確定是否需要執(zhí)行其他步驟。在這種情況下，步驟20、30、40 和50中的一個可能會被執(zhí)行。流程序列器508可以依賴于接收的元數(shù)據(jù)的內(nèi)容來確定相關(guān)的輸入變量。然后這些輸入變量用于調(diào)用一個服務(wù)。例如，流程序列器508可包括一個任務(wù)層讀取器510，其確定要調(diào)用的服務(wù)。任務(wù)調(diào)用器512然后動態(tài)地調(diào)用該服務(wù)。使用任意的輸入變量來調(diào)用該服務(wù)。在調(diào)用服務(wù)的過程中，執(zhí)行已封裝服務(wù)的代碼來協(xié)調(diào)服務(wù)的執(zhí)行。例如，準(zhǔn)備可執(zhí)行代碼并向外部系統(tǒng)發(fā)送一個消息來執(zhí)行該服務(wù)。然后可以執(zhí)行服務(wù)并且在結(jié)果接收器514處來接收結(jié)果。在一個實例中，如果任務(wù)是運輸，那么運輸服務(wù)就對運輸系統(tǒng)產(chǎn)生一個關(guān)于貨物運輸?shù)南ⅰＲ坏┰撨\輸系統(tǒng)運輸該貨物，存儲了結(jié)果的消息就會返回到該運輸服務(wù)。在接收結(jié)果之后，驗證是否要執(zhí)行更進一步的序列。例如，一個“當(dāng)”活動模塊檢查是否需要處理更進一步的服務(wù)。例如，處理可以返回到流程序列器508，以便允許動態(tài)調(diào)用處理中的其他步驟。而且，該“當(dāng)”活動模塊可以等待直到并行分支完成為止。因此，自動地基于該運行時間表來確定調(diào)用服務(wù)所需的信息。在一個實例中，在 BPEL中，已經(jīng)創(chuàng)建了所有調(diào)用所必需的合作者鏈接，并且它們被用于調(diào)用服務(wù)。在BPEL合作者鏈接中所呈現(xiàn)出的服務(wù)被部署成BPEL處理，其不需要更多的配置就可以用在多個業(yè)務(wù)處理的定義中。當(dāng)運行時間引擎調(diào)用了一個服務(wù)時，在下層BPEL處理中訪問相應(yīng)的合作者鏈接。通過使用運行時間表中的元數(shù)據(jù)來產(chǎn)生服務(wù)的組合以及任意服務(wù)的修改，并且可以通過接口 308來管理。因此，用戶可以在業(yè)務(wù)處理中建立這些步驟?？蓤?zhí)行處理310可以自動地在運行時間上組合?？蓤?zhí)行處理310中使用的代碼不是由建立該業(yè)務(wù)處理的用戶產(chǎn)生。而是，可以定義元數(shù)據(jù)并用其來組合已封裝的用于可執(zhí)行處理310的服務(wù)。圖6示出了根據(jù)一個實施例的使用流程序列器508調(diào)用服務(wù)的一個實例。在步驟 602，根據(jù)該實施例，確定是否需要分支。如果遇到條件聲明，處理就基于滿足了哪個條件從而前進到合適的分支。如果遇到并行分支，就產(chǎn)生并行流程序列實例，來執(zhí)行附加的分支。 確定分支并隨后將其用在服務(wù)的調(diào)用中。然后處理前進到在其中確定服務(wù)的步驟604。然后執(zhí)行各種服務(wù)。這些步驟包括調(diào)用服務(wù)步驟、調(diào)度步驟、運輸步驟、等待步驟、 賬單步驟和子處理步驟。同樣的處理序列采用并行流動的方式，直至到達合并步驟。每個流程序列包含相同的下層代碼化處理(例如BPEL處理)，但是不同的處理序列可以用在不同的可執(zhí)行處理310中。也就是，一個序列可以包含調(diào)度、運輸、賬單，而另一序列可以包括調(diào)度、活動、運輸、活動、賬單，雖然包含下層代碼化處理的運行時間引擎不變。也就是說，盡管正運行著不同的可執(zhí)行處理，但被調(diào)用的每個服務(wù)的代碼保持相同。
流程序列器的每個分支中包含有外部服務(wù)調(diào)用，每個可被調(diào)用的服務(wù)具有一個分支。分支包含所有用于設(shè)置應(yīng)當(dāng)被包括在發(fā)送給特定外部服務(wù)的消息中的數(shù)據(jù)所必須的步驟以及用于格式化從該服務(wù)接收的響應(yīng)的必須的步驟。一旦完成服務(wù)，“當(dāng)”活動模塊驗證是否有進一步的服務(wù)要處理，然后返回到流程序列器508、繼續(xù)處理的下一步驟或者等到任意并行分支的完成。方塊606示出了可執(zhí)行處理310的概念性執(zhí)行。不是所有的步驟都立即運行。例如，為步驟10調(diào)用該調(diào)用服務(wù)，并且確定要調(diào)用的服務(wù)。一旦這些完成之后，步驟608確認(rèn)是否需要執(zhí)行其他的步驟。在這種情況下，步驟604確定調(diào)度、運輸、等待、賬單和子處理服務(wù)應(yīng)當(dāng)被執(zhí)行。一旦全部的流程都已完成，就會構(gòu)造統(tǒng)一的結(jié)果集合。基于該可執(zhí)行處理的定義，確定是否應(yīng)當(dāng)執(zhí)行附加處理。執(zhí)行不同的分支，每個分支調(diào)用相關(guān)的服務(wù)。服務(wù)的輸入變量從運行時間表中的元數(shù)據(jù)產(chǎn)生。當(dāng)已執(zhí)行所選的服務(wù)時，步驟608確定是否應(yīng)當(dāng)執(zhí)行附加的服務(wù)。如果是，處理返回步驟602重復(fù)處理。如果不是，結(jié)束處理。使用表400的信息來提供服務(wù)的編排。然而，除了編排之外，服務(wù)需要與外部系統(tǒng)進行通信。圖7示出了根據(jù)一個實施例的在不同的層中用于編排數(shù)據(jù)流的處理。提供編排層、任務(wù)層、外部接口層和外部系統(tǒng)層。在一個實施例中，在編排層之前提供一個分解層 (未示出)。根據(jù)該實施例，步驟702為任務(wù)產(chǎn)生并發(fā)送一個調(diào)用?？梢詮挠唵尾东@模塊接收一個訂單。這可導(dǎo)致任務(wù)的調(diào)用。使用在運行時間表中找到的數(shù)據(jù)來產(chǎn)生調(diào)用請求。請求被發(fā)送給任務(wù)層。根據(jù)該實施例，步驟704啟動該任務(wù)，產(chǎn)生用于外部系統(tǒng)的消息，并發(fā)送該消息。 所產(chǎn)生的消息表示哪個任務(wù)應(yīng)當(dāng)由該外部系統(tǒng)來執(zhí)行。要被執(zhí)行的任務(wù)是已經(jīng)模型化的訂單處理的一個方面。例如，任務(wù)可以是一個訂單開賬單。還可以包括執(zhí)行該服務(wù)的參數(shù)。該消息被發(fā)送到一個外部接口。根據(jù)該實施例，步驟706轉(zhuǎn)換該消息并將其發(fā)送到外部系統(tǒng)層。任務(wù)層產(chǎn)生的消息可以是通用格式的。然而，不同的外部系統(tǒng)可以使用其他的格式來通信。外部接口層確定外部系統(tǒng)所使用的格式，并轉(zhuǎn)換該消息。例如，用戶定義的元數(shù)據(jù)可以用于確定要使用的格式。在一個實例中，對什么外部系統(tǒng)調(diào)用了所訂購的產(chǎn)品的映射，被用來翻譯該消息。根據(jù)該實施例，步驟708接收該外部系統(tǒng)返回的消息并處理該產(chǎn)生了結(jié)果的消息。該外部系統(tǒng)可以是執(zhí)行與處理一個訂單相關(guān)的任務(wù)的系統(tǒng)，例如，調(diào)度系統(tǒng)、運輸系統(tǒng)等等。當(dāng)執(zhí)行任務(wù)的時候，確定該任務(wù)的結(jié)果。結(jié)果可以是安排好的運輸日期、運輸貨物的曰期等等。然后結(jié)果被發(fā)送回外部接口層。在該實施例中，步驟710轉(zhuǎn)換該消息并將該消息發(fā)送到任務(wù)層。步驟712基于結(jié)果更新用于該任務(wù)的信息。例如，結(jié)果可以存儲在表或數(shù)據(jù)庫中。然后處理繼續(xù)到下一個可被調(diào)用的服務(wù)。通過使用以接口 308定義的已封裝的服務(wù)，就能對可執(zhí)行處理310進行修改并在運行時間中實現(xiàn)。例如，在處理的運行過程中對元數(shù)據(jù)的改變會影響所采用的步驟的順序以及各步驟的輸入變量。圖8示出了根據(jù)一個實施例的用于修改業(yè)務(wù)處理的方法的流程圖800。在一個實施例中，圖8的流程圖800的功能，以及圖中所示的其他流程圖的功能，是由存儲在存儲器或其他計算機可讀或有形介質(zhì)中的軟件來實現(xiàn)的，并且由處理器來執(zhí)行。在其他的實施例中，功能可以由硬件(例如通過使用特定用途集成電路(“ASIC”)、可編程門陣列(“PGA”)、 現(xiàn)場可編程門陣列(“FPGA”)等)，或者軟件和硬件的組合來執(zhí)行。步驟802接收對業(yè)務(wù)處理的修改。例如，接口 308用于修改業(yè)務(wù)處理以包含不同的步驟。在一個實例中，步驟可以被替換、刪除或增加。步驟804接收用于修改的元數(shù)據(jù)。例如，運行時間引擎312可以接收該修改的元數(shù)據(jù)。然后步驟806修改運行時間表來反映對元數(shù)據(jù)的修改。例如，可執(zhí)行處理310可被修改以包含不同服務(wù)來調(diào)用。當(dāng)要調(diào)用一個服務(wù)時，步驟808讀取運行時間表以便確定要調(diào)用的服務(wù)。例如，步驟讀取器504可以在可執(zhí)行處理310的處理期間讀取該表。如果運行時間表已被修改，步驟讀取器504基于修改確定要被執(zhí)行的下一步驟。然后步驟810調(diào)用所確定的服務(wù)。由于可以基于不同的輸入變量調(diào)用服務(wù)，因此在業(yè)務(wù)處理中的服務(wù)被修改時，就不需要進行附加的編程來重新部署新服務(wù)。相反，可以僅修改表就能自動地調(diào)用不同的服務(wù)。然后步驟812確定是否需要執(zhí)行更多的服務(wù)。如果是，處理返回到步驟806，再次讀取表來確定要執(zhí)行的下一步驟。如果不是，處理結(jié)束。因此，受數(shù)據(jù)驅(qū)動的編排提供了抽象化和靈活性。抽象化指的是對處理元數(shù)據(jù)的基于網(wǎng)絡(luò)的管理，該元數(shù)據(jù)定義了在可執(zhí)行處理中的處理步驟。在不同的業(yè)務(wù)處理上重復(fù)使用處理代碼。靈活性指的是修改處理而不需重新部署代碼的能力。對運行時間元數(shù)據(jù)的修改的使用有助于對可執(zhí)行處理310的修改。抽象化使處理模型更接近于商業(yè)用戶并降低了管理成本。靈活性允許商業(yè)用戶對修改進行響應(yīng)，例如當(dāng)業(yè)務(wù)處理或規(guī)則修改時對業(yè)務(wù)說明書的更改。圖9示出了可實現(xiàn)本發(fā)明一個實施例的系統(tǒng)900的方框圖。在本發(fā)明的一個實施例中，圖9的系統(tǒng)900對應(yīng)于圖3的編排系統(tǒng)302。系統(tǒng)900包括總線902或其他的通信機制，用于在系統(tǒng)900的部件之間發(fā)送信息。系統(tǒng)900還包括處理器914，可操作地耦合到總線902，用于處理信息并執(zhí)行指令或操作。處理器914可以是任一種通用或?qū)Ｓ媚康奶幚砥鳌Ｏ到y(tǒng)900進一步包括存儲器904，用于存儲信息和要由處理器914執(zhí)行的指令。存儲器904可包括隨機存取存儲器(“RAM”)、只讀存儲器(“ROM”)、如磁盤或光盤的靜態(tài)存儲器或者其他任意類型的機器或計算機可讀介質(zhì)的任意組合。系統(tǒng)900進一步包括通信設(shè)備 912，例如網(wǎng)絡(luò)接口卡或其他通信接口，用以提供對網(wǎng)絡(luò)的接入。結(jié)果，用戶可以通過網(wǎng)絡(luò)或任意其他的方式與系統(tǒng)900直接或遠(yuǎn)程地連接。在本發(fā)明的一個實施例中，用戶可以通過客戶機，例如圖3中的客戶機304，與系統(tǒng)900連接。計算機可讀介質(zhì)可以是能夠被處理器914訪問的任意可用介質(zhì)。計算機可讀介質(zhì)可包括易失性和非易失性介質(zhì)、可移動和非可移動介質(zhì)、通信介質(zhì)和存儲介質(zhì)。通信介質(zhì)可以包括計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序模塊或其他以調(diào)制的數(shù)據(jù)信號為形式(例如載波，或者其他的傳輸機制)的數(shù)據(jù)，并且可以包括任意的信息傳遞介質(zhì)。存儲介質(zhì)可以包括RAM、閃存、ROM、可擦除可編程只讀存儲器(“EPR0M”)、電可擦除可編程只讀存儲器 (“EEPR0M”)、寄存器、硬盤、可移動盤、壓縮盤只讀存儲器(“CD-ROM”)或現(xiàn)有技術(shù)中所知的任意其它形式的存儲介質(zhì)。
處理器914還能夠可操作地通過總線902耦合到顯示器916，例如液晶顯示器 (“IXD”)。顯示器916可以向用戶顯示信息。鍵盤918和光標(biāo)控制設(shè)備920，例如計算機鼠標(biāo)，也能夠可操作地耦合到總線902，來使用戶能與系統(tǒng)900進行連接。根據(jù)一個實施例，存儲器904能存儲那些可在由處理器914執(zhí)行時提供功能的軟件模塊。模塊可以包括操作系統(tǒng)906、分布式訂單編排模塊908以及其他功能模塊910。操作系統(tǒng)906為系統(tǒng)900提供操作系統(tǒng)的功能。分布式訂單編排模塊908執(zhí)行業(yè)務(wù)處理的編排，如上所述以及如下所述。系統(tǒng)900還可以是更大系統(tǒng)的一部分。這樣，系統(tǒng)900可包括一個或多個附加的功能模塊910，以用于包含多個附加的功能。例如，功能模塊910還包括中間件模塊，其是來自O(shè)racle公司的“Fusion”產(chǎn)品的一部分。處理器914還可以通過總線902可操作地耦合到數(shù)據(jù)庫934。數(shù)據(jù)庫934能夠以邏輯關(guān)聯(lián)的記錄或文件的集成收集來存儲數(shù)據(jù)。數(shù)據(jù)庫934可以是操作數(shù)據(jù)庫、分析數(shù)據(jù)庫、數(shù)據(jù)倉庫、分布式數(shù)據(jù)庫、終端用戶數(shù)據(jù)庫、外部數(shù)據(jù)庫、導(dǎo)航數(shù)據(jù)庫、存儲器內(nèi)數(shù)據(jù)庫、 面向文檔的數(shù)據(jù)庫、實時數(shù)據(jù)庫、關(guān)系數(shù)據(jù)庫、面向?qū)ο髷?shù)據(jù)庫或現(xiàn)有技術(shù)中所知的任意其它形式的數(shù)據(jù)庫。圖10示出了根據(jù)一個實施例的分布式訂單編排系統(tǒng)1000，該系統(tǒng)能夠處理修改請求。在本發(fā)明的一個實施例中，系統(tǒng)1000對應(yīng)于圖3的系統(tǒng)300，并且只有系統(tǒng)300中的與此處的討論相關(guān)部分包含在系統(tǒng)1000中。為了清楚略去了系統(tǒng)300的所有其它部分。在圖10所示的實施例中，圖9的分布式訂單編排模塊908被表示為兩個模塊分解模塊1020和編排模塊1030。然而，本領(lǐng)域技術(shù)人員將會容易地意識到，單個模塊也可以提供分解模塊1020和編排模塊1030的功能，并且也包含在本發(fā)明的范圍中。而且，圖9的分布式訂單編排模塊908可以呈現(xiàn)為任意數(shù)量的模塊，并且也包含在本發(fā)明的范圍中。下面將參照圖10所示的分解模塊1020和編排模塊1030來描述編排的一個示例性實施例。然而，本領(lǐng)域技術(shù)人員將會容易地理解，所描述的實施例只是一個示意性實施例，根據(jù)可選的實施例也可以實現(xiàn)這種編排，并且也包含在本發(fā)明的范圍中。分解是將從一個或多個訂單捕獲模塊中接收的數(shù)據(jù)轉(zhuǎn)換為內(nèi)部規(guī)范格式，用于處理該數(shù)據(jù)。如上所述，編排是要在業(yè)務(wù)處理中執(zhí)行的服務(wù)的協(xié)調(diào)和調(diào)用。在一個實施例中，分解模塊1020從一個或多個訂單捕獲模塊中接收訂單，并作為一個或多個訂單捕獲模塊和編排模塊1030之間的中介。訂單捕獲模塊能夠在多個通道上捕獲訂單。在所描述的實施例中，訂單捕獲模塊由訂單捕獲模塊1010來呈現(xiàn)。在本發(fā)明的一個實施例中，訂單捕獲模塊1010可以捕獲由用戶通過圖3的接口 308輸入的信息。然而， 本領(lǐng)域技術(shù)人員將會容易地理解，訂單捕獲模塊1010可以采用其它的形式，并且也包含在本發(fā)明的范圍中。根據(jù)該實施例，分解模塊1020還可用于對從訂單捕獲模塊1010發(fā)送的對象進行翻譯和分解，其中該對象代表一個訂單。使用翻譯和分解的輸出，分解模塊1020創(chuàng)建了一個要發(fā)送到訂單模塊1030的分布式訂單編排訂單(“D00訂單”)。DOO訂單是用來代表從訂單捕獲模塊接收的訂單的對象，并且已被轉(zhuǎn)換為可被編排系統(tǒng)使用的對象格式。這樣，對 “訂單”的引用就是對訂單捕獲系統(tǒng)中用戶輸入的業(yè)務(wù)訂單的引用，而對“D00訂單”的引用就是對編排系統(tǒng)創(chuàng)建和實施的實體的引用，以用于代表由用戶輸入的業(yè)務(wù)訂單。DOO訂單能夠包含分布式訂單編排首標(biāo)(“首標(biāo)”)。首標(biāo)是包含了訂單的整體分層結(jié)構(gòu)的對象。DOO訂單能夠包括一個或多個群，其中群是用于收集分布式訂單編排訂單行 (“行”)的實體，用于在編排處理的一個實例中進行處理。每個群可以包含一個或多個行。 行是包含訂單的相應(yīng)的行的信息的對象。每個行可以包括一個或多個分布式訂單編排實施行(“實施行”)。實施行是一個與相應(yīng)的實施系統(tǒng)的供應(yīng)活動相對應(yīng)的對象，其中該實施系統(tǒng)能夠處理該訂單行。這樣，實施行是實施相應(yīng)的實施任務(wù)的供應(yīng)行。在本發(fā)明的一個實施例中，分解模塊1020對訂單的創(chuàng)建包含了下列步驟。首先， 創(chuàng)建首標(biāo)。接著創(chuàng)建一個或多個行并與該首標(biāo)相關(guān)聯(lián)。隨后，對于每個行，創(chuàng)建一個或多個實施行，其中一個實施行可以僅與一個行相關(guān)聯(lián)。接著，調(diào)用一個服務(wù)來為每個行分配單獨的可執(zhí)行處理。然而，在本發(fā)明的某些實施例中，省略了為每個行分配單獨的可執(zhí)行處理的步驟，并且用單個可執(zhí)行處理來處理整個DOO訂單。在任意一個方案中，分解模塊1020基于可執(zhí)行處理的名稱和創(chuàng)建日期來選擇一個可執(zhí)行處理。最后，根據(jù)該實施例，分解模塊1020保存DOO訂單狀態(tài)。編排模塊1030在執(zhí)行和實施由分解模塊1020通過可執(zhí)行處理的創(chuàng)建而創(chuàng)建的 DOO訂單的同時，控制著出現(xiàn)事件的順序。在圖10所示的實施例中，編排模塊1030包含子模塊訂單處理管理器(“0ΡΜ”)1040，以及三個核心處理編排管理器(“0M”)1050，步驟管理器服務(wù)(“SMS”)1060，以及分割處理管理器(“SPM”)1070。然而，本領(lǐng)域技術(shù)人員將會容易地意識到，這是一個實例，編排模塊1030可包含任意數(shù)量的子模塊和處理，并且也包含在本發(fā)明的范圍中。根據(jù)該實施例，分解模塊1020通過傳遞DOO訂單的首標(biāo)標(biāo)識來調(diào)用編排模塊1030 的OPM 1040。OPM 1040能發(fā)動一個或多個可執(zhí)行處理，還能連接和控制一個或多個可執(zhí)行處理。OM 1050、SMS 1060和SPM 1070是構(gòu)成可執(zhí)行處理的核心模塊，該可執(zhí)行處理在處理并實施由分解模塊1020創(chuàng)建的DOO訂單的同時，控制著可出現(xiàn)的事件的順序。OM 1050 由OPM 1040來調(diào)用，并能夠執(zhí)行用于給定群的處理步驟。SMS 1060由OM 1050調(diào)用，并能夠封裝用于預(yù)處理、錯誤處理和修改管理的業(yè)務(wù)邏輯。SPM 1070由OM 1050來調(diào)用并能夠控制分割單元。分割單元定義了可執(zhí)行處理中可被一起分割的一系列步驟。例如，可執(zhí)行處理包括了調(diào)度、運輸和賬單的步驟。在該實例中，分割單元可以被定義為包括調(diào)度和運輸步驟，但不包括賬單步驟。基于該分割單元定義，在分割該可執(zhí)行處理的方案中，可以并列執(zhí)行所得到的分割步驟，并且只有當(dāng)兩個步驟都完成后才能調(diào)用該賬單步驟。在該實施例中，OPM 1040確定適當(dāng)?shù)目蓤?zhí)行處理來編排DOO訂單。對于DOO訂單中的每個群，OPM 1040通過查找一個群表并順序地發(fā)動用于該群的可執(zhí)行處理，來確定可執(zhí)行處理。如果可執(zhí)行處理不存在，那么在發(fā)動可執(zhí)行處理之前，OPM 1040調(diào)用一個服務(wù)來組合該可執(zhí)行處理。在本發(fā)明的一個實施例中，OPM 1040還能夠查詢要在首標(biāo)級別上執(zhí)行的任務(wù)服務(wù)的列表，并在用戶定義的序列中執(zhí)行它們。OM 1050是之前標(biāo)識的可執(zhí)行處理的實例，其生命周期開始于OPM 1040對其的異步調(diào)用。當(dāng)OM 1050執(zhí)行了其所有的處理步驟之后，OM 1050停止。根據(jù)該實施例，OM 1050 用于啟動由業(yè)務(wù)處理定義的任務(wù)層服務(wù)的調(diào)用。而且，OM 1050具有區(qū)分分割單元和非分割單元的邏輯。對于分割單元，OM 1050可以啟動SPM 1070的調(diào)用，其控制著分割單元。SMS 1060也可以被OM 1050調(diào)用。在OM 1050用作處理編排引擎時，SM 1060起到步驟編排引擎的功能。特別地，在該實施例中，SMS 1060接受來自O(shè)M 1050的請求，為每個步驟取回運行時間信息，標(biāo)記步驟的狀態(tài)為“已開始”，發(fā)送請求至任務(wù)層，處理來自任務(wù)層的響應(yīng)，并最終將控制送回OM 1050。修改管理框架如前所述，分布式訂單編排功能的基本核心是使用編排處理以用于編排訂單。編排處理控制著在處理并實施訂單時出現(xiàn)的事件的順序。仍如前所述，業(yè)務(wù)處理可以是由幾個業(yè)務(wù)步驟構(gòu)成的長期運行的處理。在一個實施例中，業(yè)務(wù)步驟總是由用戶來定義的，并且表示業(yè)務(wù)流程中的一個步驟。在分布式訂單的編排業(yè)務(wù)處理中的業(yè)務(wù)步驟包含任務(wù)層服務(wù)或者子處理。業(yè)務(wù)步驟不能參與處理的辦理， 這是因為如果處理的辦理被回滾，那么它不能被自動的撤消。核心功能的一個關(guān)鍵要求是在執(zhí)行和實施訂單的同時管理修改請求。修改請求包括一個引用原始訂單的新訂單。新訂單還包括對原始訂單的修改，因此，包括了對含有業(yè)務(wù)處理的業(yè)務(wù)步驟的修改。因此，修改請求將會導(dǎo)致對當(dāng)前正執(zhí)行的業(yè)務(wù)處理(以及相應(yīng)的可執(zhí)行處理)的顯著更改。處理辦理不足以處理該修改請求，這是因為業(yè)務(wù)處理的幾個業(yè)務(wù)步驟與外部實施系統(tǒng)交互，因此超出了辦理界限。因此，這些業(yè)務(wù)步驟要求特殊邏輯來容納修改請求。根據(jù)本發(fā)明的一個實施例，分布式訂單編排系統(tǒng)能夠接收修改請求并確定原始訂單和新訂單(也被稱為“修改訂單”)之間的修改。然后使用原始訂單和新訂單之間的修改來確定哪些業(yè)務(wù)處理修改是必要的，以響應(yīng)修改請求。這樣，系統(tǒng)能夠應(yīng)付新業(yè)務(wù)處理的步驟與正執(zhí)行的或已被完成的原始業(yè)務(wù)處理的步驟有沖突的情形。除了自動調(diào)整原始業(yè)務(wù)處理的過去的業(yè)務(wù)步驟之外，分布式訂單編排系統(tǒng)能夠包含對還未執(zhí)行的業(yè)務(wù)步驟的修改。重要的是，編排語言補償(例如BPEL補償)和分布式訂單編排修改管理是非常不同的。BPEL補償用在由于可執(zhí)行處理中的錯誤條件而回滾處理中已執(zhí)行的活動的效果。分布式訂單編排修改管理不僅包含對業(yè)務(wù)處理中以前執(zhí)行的步驟的撤消，而且還包括對業(yè)務(wù)處理中尚未執(zhí)行步驟中的修改的向前傳播。換言之，后者需要撤消或重復(fù)之前執(zhí)行的步驟以及更新尚未執(zhí)行的步驟的能力。而且，對以前執(zhí)行的步驟的撤消不僅僅只是回滾到以前的狀態(tài)。相反，需要對服務(wù)的調(diào)用來采取適當(dāng)?shù)某废麆幼鳌Ｔ诒景l(fā)明的一個實施例中，通過框架范圍向修改管理框架提供嵌套的功能范圍。 框架范圍用于以正常模式或修改模式來執(zhí)行業(yè)務(wù)處理的步驟。當(dāng)?shù)谝淮芜\行分布式訂單編排系統(tǒng)的可執(zhí)行處理時，以正常模式來運行可執(zhí)行處理。在正常模式下，在適當(dāng)?shù)臅r間動態(tài)地執(zhí)行可執(zhí)行處理的步驟，如之前在單獨的部分中所描述的那樣。然而，當(dāng)接收到修改請求時，分布式訂單編排系統(tǒng)停止了原始的可執(zhí)行處理(及其所有的子處理)，并且以修改模式啟動新的可執(zhí)行處理。在一個實施例中，停止原始的可執(zhí)行處理包括終止原始的可執(zhí)行處理。然而，在一個可選的實施例中，停止原始的可執(zhí)行處理包括暫停原始的可執(zhí)行處理，其中原始的可執(zhí)行處理可以在隨后的時間點上進行恢復(fù)。新的可執(zhí)行處理與原始的可執(zhí)行處理相關(guān)以用于允許修改處理。在修改模式中，執(zhí)行適當(dāng)?shù)男薷牟襟E來自動地調(diào)整已被執(zhí)行的原始的可執(zhí)行處理的步驟。使用之前保存的原始的可執(zhí)行處理的狀態(tài)來執(zhí)行修改步驟。 一旦執(zhí)行了修改步驟，就以正常模式使用新的可執(zhí)行處理的當(dāng)前狀態(tài)來執(zhí)行新的可執(zhí)行處理的剩余步驟。在本發(fā)明的一個實施例中，可執(zhí)行處理能夠在每個里程碑處保存處理的狀態(tài)。保存的狀態(tài)可以用在修改模式中，用于撤消或重復(fù)以正常模式執(zhí)行的可執(zhí)行處理的步馬聚ο圖11示出了根據(jù)本發(fā)明一個實施例的處理修改請求的方法的流程圖1100。在 1110中，以正常模式執(zhí)行原始的可執(zhí)行處理。如前所述，當(dāng)以正常模式執(zhí)行可執(zhí)行處理時， 可執(zhí)行處理執(zhí)行包含了可執(zhí)行處理的步驟并為每個步驟調(diào)用相應(yīng)的服務(wù)，如參照圖5所討論的。在1120中，接收修改請求。如上所討論的，該修改請求包括一個由訂單捕獲模塊捕獲的新訂單，其引用了一個原始訂單，其中新訂單包含了對原始訂單的修改。按照處理訂單的相同方式來處理修改請求，如上所討論的，創(chuàng)建一個新DOO訂單。在1130中，停止原始的可執(zhí)行處理。停止原始的可執(zhí)行處理包括停止已由該原始的可執(zhí)行處理創(chuàng)建的任何子處理。在本發(fā)明一個實施例中，終止原始的可執(zhí)行處理。在一個可選實施例中，僅暫停原始的可執(zhí)行處理。在該實施例中，原始的可執(zhí)行處理可以在隨后的時間點上進行恢復(fù)。在1140中，創(chuàng)建一個新的可執(zhí)行處理。更具體地，基于新的DOO訂單創(chuàng)建該可執(zhí)行處理，其進而基于包含在所接收的修改請求中的新訂單。在1150中，以修改模式執(zhí)行新的可執(zhí)行處理。當(dāng)以修改模式運行新的可執(zhí)行處理時，可執(zhí)行處理執(zhí)行修改步驟，以便更改已由原始的可執(zhí)行處理執(zhí)行的步驟。新的可執(zhí)行處理還使用原始DOO訂單與新DOO訂單之間的差別，執(zhí)行未被原始的可執(zhí)行處理執(zhí)行的步驟。圖12示出了根據(jù)一個實施例的詳述修改請求流程的一個實例的流程圖1200。在流程圖1200中，流程1210表示原始的可執(zhí)行處理的流程。例如，原始的可執(zhí)行處理可以對應(yīng)于訂購地毯的業(yè)務(wù)處理。原始的可執(zhí)行處理執(zhí)行步驟A、B和C。在上面的實例中，步驟 A包括從庫存中選擇地毯，步驟B包括根據(jù)所要求的尺寸測量地毯，以及步驟C包括運輸?shù)靥?。在該實施例中，在完成步驟B之后但未啟動步驟C時接收一個修改請求(未示出)，其中該修改請求將地毯訂單修改成瓷磚訂單，這里用于訂購地毯的處理和用于訂購瓷磚的處理使用了相同的業(yè)務(wù)處理。因此，原始的可執(zhí)行處理被停止，新的可執(zhí)行處理被啟動。在上面的實例中，新的可執(zhí)行處理對應(yīng)于用于訂購瓷磚的業(yè)務(wù)處理。在流程圖1200中， 流程1220表示新的可執(zhí)行處理的流程。新的可執(zhí)行處理執(zhí)行步驟A’、B’和C’。步驟A’包括調(diào)整已完成的步驟A。對步驟A的調(diào)整可以根據(jù)下面的業(yè)務(wù)處理來采取多種形式中的一種。在所示的實例中，對步驟A的調(diào)整可以包括把從庫存中選擇地毯調(diào)整為從庫存中選擇瓷磚。如果之前所選的庫存不包括瓷磚，那么這種調(diào)整還進一步包括選擇包含瓷磚的不同的庫存。相似地，步驟B’包括調(diào)整已完成的步驟B，并根據(jù)下面的業(yè)務(wù)處理來采取多種形式中的一種。在所示的實例中，對步驟B的調(diào)整可以包括測量瓷磚，以瓷磚的測量來代替地毯的測量。最后，步驟C’包括運輸瓷磚。由于步驟C并未由原始的可執(zhí)行處理來執(zhí)行，因此不需要調(diào)整步驟C，這樣，不執(zhí)行對步驟C的調(diào)整。然而，是基于新訂單來執(zhí)行步驟C’的，而不是基于原始訂單。這樣，在所示的實例中，步驟C’包括運輸瓷磚，而不是運輸?shù)靥?。下面將參照圖10所示的分解模塊1020和編排模塊1030來描述編排修改管理的一個示意性實施例。然而，本領(lǐng)域技術(shù)人員可以容易地理解，所描述的實施例僅是一個示意性實施例，也可以根據(jù)可選實施例來實現(xiàn)這種編排修改管理，并且仍包含在本發(fā)明的范圍內(nèi)。
在一個實施例中，圖10的分解模塊1020和編排模塊1030能夠處理一個修改訂單的請求(即修改請求)并處理一個訂單。在訂單捕獲模塊發(fā)送一個修改請求的情況下，分解模塊1020按照分解模塊處理原始訂單的方式來處理該修改請求，如之前參照圖10的描述，除了下面的關(guān)鍵區(qū)別點之外。首先，根據(jù)該實施例，分解模塊1020識別出從訂單捕獲模塊接收的新訂單不是一個真正的新訂單，而是修改原始訂單的請求的一部分(即修改請求)。接著，分解模塊1020 驗證是否允許在原始訂單上進行修改。該驗證包括回顧原始訂單的狀態(tài)以及相應(yīng)的可執(zhí)行處理的狀態(tài)。如果訂單狀態(tài)或處理狀態(tài)具有阻止修改請求的約束條件，那么修改請求就被拒絕。然而，如果允許修改，分解模塊1020就通知編排模塊1030準(zhǔn)備處理修改請求。接著， 分解模塊1020創(chuàng)建一個新的DOO訂單。新的DOO訂單引用了原始DOO訂單。然后分解模塊 1020將新DOO訂單關(guān)聯(lián)并映射到原始DOO訂單。分解模塊1020還計算新的DOO訂單和原始DOO訂單之間的變動(δ )。最后，分解模塊1020將新的DOO訂單發(fā)送到編排模塊1030。根據(jù)該實施例，編排模塊1030能夠通過使OPM 1040監(jiān)聽修改通知和修改請求來處理這些修改請求。修改通知只是來自分解模塊的一個通知，用以準(zhǔn)備處理一個修改請求， 它不是實際的修改請求。在出現(xiàn)修改請求的情況下，OPM 1040首先接收一個修改通知，隨后接收實際的修改請求。當(dāng)OPM 1040接收一個修改通知時，根據(jù)該實施例，OPM 1040可以通知每個由OPM 1040調(diào)用的OM 1050?；谶@個通知，0Μ1050不執(zhí)行任何的新任務(wù)。當(dāng)OPM 1040接收一個修改請求時，OPM 1040能夠確定當(dāng)前的可執(zhí)行處理是否能夠接受修改請求。如果該處理不能接受修改請求，那么OPM 1040就拒絕整個修改請求。如果處理能接受修改請求，那么 OPM 1040就如下所述處理該修改請求。在處理該修改請求的過程中，根據(jù)該實施例，OPM 1040首先調(diào)用登記為可執(zhí)行處理的每個步驟的一部分的通知服務(wù)，用以確定是否每個通知服務(wù)都能接受修改請求。如果任意一個所登記的通知服務(wù)表示它們不能接受修改請求，那么OPM 1040就拒絕整個修改請求，結(jié)束修改請求的處理。然而，如果全部所登記的通知服務(wù)表示它們能接受修改請求，那么就繼續(xù)修改請求處理。然后OPM 1040通知與該可執(zhí)行處理相關(guān)的等待步驟以便停止。然后根據(jù)本實施例，OPM 1040將新DOO訂單與原始DOO訂單合并。在該實施例中，然后OPM 1040調(diào)整用于新DOO訂單的群信息。當(dāng)分解模塊1020 創(chuàng)建一個新DOO訂單時，分解模塊1020創(chuàng)建用于每一行的新群，以及新DOO訂單的實施行。 取決于每一行和實施行是否是新的，OPM 1040能夠調(diào)整引用鍵值、激活某些群，以及去激活其他群。根據(jù)一個實施例，為了對新DOO訂單的每一行調(diào)整群信息，OPM 1040確定原始DOO 訂單中是否存在行。如果原始DOO訂單中存在行，那么OPM 1040進一步確定新DOO訂單中是否已修改了該行。如果原始DOO訂單中不存在行，OPM 1040激活分解模塊1020為新行創(chuàng)建的群，并且為該行設(shè)置屬性變動。如果原始DOO訂單中存在行，并且未在新訂單中修改， OPM 1040就繼續(xù)使用來自原始DOO訂單的之前的群。如果原始DOO訂單中存在行，并且已在新訂單中修改，OPM 1040就激活分解模塊1020為所修改的行創(chuàng)建的群，為該行設(shè)置屬性變動，并且去激活為原始訂單所創(chuàng)建的之前的群。OPM 1040還執(zhí)行用于新DOO訂單的每一實施行的那些步驟。然而，在可選實施例中，OPM 1040能夠基于不同的標(biāo)準(zhǔn)來調(diào)整群信息，并且仍包含在本發(fā)明的范圍內(nèi)。隨后，根據(jù)該實施例，OPM 1040處理所計算的原始DOO訂單和新DOO訂單之間的變動。一旦該變動被計算出來，OPM 1040確定變動類型并執(zhí)行下列一組活動中的一個。如果變動類型是一個增加行變動(即增加一個新行)，并且該行被增加到新DOO訂單中，那么在本發(fā)明的一個實施例中，0PM1040為該行開始一個新的可執(zhí)行處理，并對其和用于該新DOO訂單的其他可執(zhí)行處理一起監(jiān)控。在該實施例中，OPM 1040還可以修改從新 DOO訂單到原始DOO訂單的群的引用。OPM 1040可以執(zhí)行這些操作而不需考慮新行是否僅增加到新DOO訂單上，或者是否新行還增加到新DOO訂單的新群上。在一個可選實施例中，如果變動類型是一個增加行變動，并且該行被增加到新DOO 訂單的現(xiàn)有群上，那么OPM 1040就開始一個新的可執(zhí)行處理，并如上所討論地修改引用。 另外，OPM 1040可以將新DOO訂單中新創(chuàng)建的群與現(xiàn)有群進行合并。這種合并的一個實例是基于項目關(guān)系和共享處理的定義來將新創(chuàng)建的群與現(xiàn)有群進行合并。如果變動類型是一個刪除行變動(即刪除一個行)，在本發(fā)明的一個實施例中， OPM 1040通知合適的可執(zhí)行處理來刪除該行。如果變動類型是一個變動屬性修改變動(即已修改的首標(biāo)、行或?qū)嵤┬械囊粋€或多個變動屬性)，在一個實施例中，OPM 1040通知合適的可執(zhí)行處理來更新該屬性。在本發(fā)明的一個實施例中，如果修改的屬性是一個數(shù)量屬性，就由OPM 1040來分別處理該修改以最小化調(diào)整的必要和更好的優(yōu)化。特別是，對于數(shù)量增加，OPM 1040為合適的行開始新的可執(zhí)行處理，并對其和用于該DOO訂單的其他可執(zhí)行處理一起進行監(jiān)控。然而，對于數(shù)量減少，OPM 1040將會通過以之前所討論的修改模式執(zhí)行新的可執(zhí)行處理來調(diào)整原始的可執(zhí)行處理。如果變動類型是一個動態(tài)變動屬性變動(即已修改的首標(biāo)、行或?qū)嵤┬械囊粋€或多個動態(tài)變動屬性)，在一個實施例中，OPM 1040通過以之前所討論的修改模式執(zhí)行可執(zhí)行處理來調(diào)整原始的可執(zhí)行處理。在本發(fā)明的一個實施例中，用戶可以在定義業(yè)務(wù)處理或定義業(yè)務(wù)處理的步驟時在訂單捕獲元件的接口處指出編排系統(tǒng)是否應(yīng)該忽視對動態(tài)變動屬性的修改。動態(tài)變動屬性是用戶定義的作為變動屬性的一種屬性。最后，根據(jù)一個實施例，OPM 1040關(guān)閉新的訂單并調(diào)用新的可執(zhí)行處理。在圖10 中，如之前所討論的，新的可執(zhí)行處理被定義為OM 1050。關(guān)于OM 1050，根據(jù)一個實施例，OM 1050監(jiān)聽修改請求。一旦OM 1050接收了修改請求，就處理該修改請求。編排處理管理如前所述，編排處理的修改管理使用了可執(zhí)行處理的以往步驟的自動調(diào)整的組合，以及對可執(zhí)行處理的未來步驟的修改的結(jié)合。隨后將以本發(fā)明的一個示意性實施例來描述該編排處理和編排處理的修改管理。圖13示出了根據(jù)一個實施例的可執(zhí)行處理定義的一個實例。在該實施例中，圖13 示出了原始訂單的可執(zhí)行處理的定義。S1、S2、S3、S4、S5、S6和S7表示可執(zhí)行處理的不同步驟。CBl和CB2表示可執(zhí)行處理的條件分支，用于在運行時間上根據(jù)預(yù)先定義的業(yè)務(wù)規(guī)則進行評估。例如，在CB1，編排系統(tǒng)評估原始訂單的行數(shù)量是否小于10。如果行數(shù)量小于 10，那么可執(zhí)行處理執(zhí)行步驟S2，然后是步驟S4，再然后步驟S5。然而，如果行數(shù)量大于或等于10，那么可執(zhí)行處理執(zhí)行步驟S3，然后評估條件分支CB2。在CB2，編排系統(tǒng)評估原始訂單的組織是否等于204或404。如果組織等于204，那么可執(zhí)行處理執(zhí)行步驟S6。然而， 如果組織等于404，那么可執(zhí)行處理的執(zhí)行步驟S7。在原始訂單中，如果行的數(shù)量大于10，可執(zhí)行處理執(zhí)行步驟S3，如果組織等于 204，那么可執(zhí)行處理執(zhí)行步驟S6。如果可執(zhí)行處理執(zhí)行那些步驟，并且接收到把行數(shù)量降到5的修改請求，那么新的可執(zhí)行處理刪除步驟S3至S6，然后執(zhí)行步驟S2、S4和S5。由于在運行時間上依靠預(yù)定的規(guī)則評估每個條件分支CBl和CB2，于是在接收到修改請求時不知道新的可執(zhí)行處理采用的是哪條路徑。在請求修改的情況下中，編排系統(tǒng)通知原始的可執(zhí)行處理停止。在一個實施例中， 編排系統(tǒng)通知原始的可執(zhí)行處理溫和地終止(即允許任何正在運行的步驟完成而不需執(zhí)行下一個步驟)。在一個可選實施例中，編排系統(tǒng)通知原始的可執(zhí)行處理自身暫停。這樣， 在該實施例中，原始的可執(zhí)行處理被暫停，但能夠在隨后的時間點上被恢復(fù)。在恢復(fù)時，原始的可執(zhí)行處理將執(zhí)行下一步驟。編排系統(tǒng)創(chuàng)建一個新的可執(zhí)行處理，其引用了原始的可執(zhí)行處理。更具體地，新的可執(zhí)行處理包括引用了原始的可執(zhí)行處理的原始步驟的新步驟， 并包括一個新任務(wù)。對于不需要進行調(diào)整的步驟，編排系統(tǒng)從原始的可執(zhí)行處理復(fù)制任務(wù)完成細(xì)節(jié)和任務(wù)狀態(tài)。在本發(fā)明的一個實施例中，任務(wù)完成細(xì)節(jié)包括開始和結(jié)束日期。對于需要進行調(diào)整的步驟，編排系統(tǒng)簡單地從原始的可執(zhí)行處理復(fù)制任務(wù)完成細(xì)節(jié)。編排系統(tǒng)去激活所有與原始的可執(zhí)行處理相關(guān)的消息，并且以修改模式開始新的可執(zhí)行處理。一旦新的可執(zhí)行處理已經(jīng)調(diào)整了原始的可執(zhí)行處理的所有原始步驟，新的可執(zhí)行處理以正常模式恢復(fù)執(zhí)行剩余的步驟。圖14示出了根據(jù)一個實施例的新的可執(zhí)行處理定義的一個實例，其中新可執(zhí)行處理調(diào)整原始的可執(zhí)行處理的步驟。在圖14中，標(biāo)題為“正常處理實例”的下面是原始的可執(zhí)行處理的流程，包括步驟A、B、D、E和F以及條件分支S。標(biāo)題為“補償處理實例”的下面是一個相應(yīng)的新的可執(zhí)行處理的流程，包括步驟A’、B’、D’、E’和F’以及條件分支S’。在修改請求的情況下，編排系統(tǒng)能停止原始的可執(zhí)行處理的流程，并啟動新的可執(zhí)行處理的流程。如果原始處理的相應(yīng)的步驟(即步驟A、B、D、E和F以及條件分支S)已被執(zhí)行，那么新的可執(zhí)行處理的每一步驟和條件分支(即步驟A’、B’、D’、E’和F’以及條件分支S’ ) 可以自動地調(diào)整原始處理的相應(yīng)的步驟。也可以參照圖14，原始的可執(zhí)行處理和新的可執(zhí)行處理都能夠在每個里程碑處將各自處理的狀態(tài)保存在數(shù)據(jù)庫中。例如，在圖14中，原始的可執(zhí)行處理在里程碑A保存狀態(tài)Si，在里程碑B保存狀態(tài)S2，在里程碑C保存狀態(tài)S3，在里程碑D保存狀態(tài)S4，以及在里程碑F保存狀態(tài)S5。圖15示出了根據(jù)一個實施例的在接收到修改請求時，原始的可執(zhí)行處理和新的可執(zhí)行處理的流程圖。原始的可執(zhí)行處理的流程(即在圖15的圖例標(biāo)識為“正常訂單流程)包括步驟1_3、5、7和9。新的可執(zhí)行處理的流程，即在圖15的圖例標(biāo)識流程為“修改訂單流程”)包括步驟1’ _3’、5’、7’、9’和10-11。步驟4、6和8是兩個流程所共有的(并且在圖15的圖例標(biāo)識為“共有”)。
現(xiàn)在描述正常訂單流程的步驟。在步驟1，訂單捕獲模塊向編排系統(tǒng)提交一個訂單，并且編排系統(tǒng)的分解模塊接受該訂單。在步驟2，分解模塊轉(zhuǎn)換該訂單并創(chuàng)建一個原始的DOO訂單。在步驟3，分解模塊按需為原始的DOO訂單的行分配單獨的可執(zhí)行處理。分解模塊還保存了原始的DOO訂單的狀態(tài)，并通過調(diào)用編排模塊的OPM來將原始的DOO訂單傳遞到編排模塊。在步驟4，OPM基于原始訂單的首標(biāo)標(biāo)識來查詢處理信息。對于原始訂單的每個處理，OPM調(diào)用相應(yīng)的OAS和計劃服務(wù)。在步驟5，對于原始訂單的每個群，OPM調(diào)用了一個原始的可執(zhí)行處理(即0M)。在步驟6，OAS調(diào)用該計劃服務(wù)并作為步驟4的一部分。在步驟7，執(zhí)行原始的可執(zhí)行處理。原始的可執(zhí)行處理進一步調(diào)用SMS以便執(zhí)行可執(zhí)行處理的步驟。在步驟8，SMS取回必要的運行時間步驟實例數(shù)據(jù)。在步驟9，SMS調(diào)用與可執(zhí)行處理的步驟相應(yīng)的任務(wù)層服務(wù)。在圖15所示的實例中，SMS調(diào)用了分別與S1、S2和 Sn相對應(yīng)的任務(wù)層服務(wù)?，F(xiàn)在描述修改訂單流程的步驟。在步驟1’，訂單捕獲模塊向編排系統(tǒng)提交一個修改請求，并且編排系統(tǒng)的分解模塊接受該訂單，其中該修改請求包括與原始訂單相應(yīng)的新訂單。在步驟2’，分解模塊轉(zhuǎn)換該新訂單并創(chuàng)建一個新的DOO訂單，并將新的DOO訂單標(biāo)識為與原始DOO訂單相對應(yīng)。分解模塊還按需為新的DOO訂單的各行分配單獨的可執(zhí)行處理。然后分解模塊以修改模式調(diào)用群API。在步驟10，分解模塊調(diào)用一個將新的DOO訂單映射到原始的DOO訂單的功能，并計算兩個DOO訂單之間的變動。在步驟3’，分解模塊通過調(diào)用編排模塊的OPM來將新的DOO訂單傳遞到編排模塊。在步驟4，OPM基于新的DOO訂單的首標(biāo)標(biāo)識來查詢處理信息。對于新的DOO訂單的每個處理，OPM調(diào)用相應(yīng)的OAS和計劃服務(wù)。在步驟5’，OPM調(diào)用了返回一組信息的應(yīng)用程序模塊API，該組信息包括了原始的可執(zhí)行處理的標(biāo)識、與新的可執(zhí)行處理相應(yīng)的可執(zhí)行處理的標(biāo)識、原始DOO訂單的所有群、新DOO訂單的所有群以及所有變動類型，其中新的可執(zhí)行處理將處理新的DOO訂單并且調(diào)整原始的可執(zhí)行處理的各個步驟。對于每個修改的群，OPM將修改通知給外部系統(tǒng)，暫停原始的可執(zhí)行處理，以便使原始的可執(zhí)行處理溫和地退出并終止所有的等待步驟。OPM還將新的DOO訂單與原始的DOO訂單合并，保存原始訂單的當(dāng)前狀態(tài)，并為每個修改的群以修改模式調(diào)用新的可執(zhí)行處理(即0M)。在步驟6，0AS 調(diào)用該計劃服務(wù)作為步驟4的一部分。在步驟7’，執(zhí)行新的可執(zhí)行處理。新的可執(zhí)行處理進一步調(diào)用SMS以便執(zhí)行可執(zhí)行處理的各個步驟。在步驟8，SMS取回必要的運行時間步驟實例數(shù)據(jù)，確定合適的補償方案，標(biāo)識原始DOO訂單和新的DOO訂單之間已計算的變動，并運行合適的補償服務(wù)。在步驟 9’和11’，SMS調(diào)用與可執(zhí)行處理的步驟相應(yīng)的任務(wù)層服務(wù)。在圖15所示的實例中，SMS調(diào)用了分別與S1、S2和Sn相對應(yīng)的任務(wù)層服務(wù)。特別地，SMS首先執(zhí)行S2的補償，然后是Sn 的補償，然后是Sl的補償。接著，SMS重新執(zhí)行Si、S2和Sn。關(guān)于編排的更多的實施細(xì)節(jié)在美國專利號12/617，698名為“分布式訂單編排”、 美國專利申請?zhí)?2/718，585名為“分布式訂單編排系統(tǒng)中的修改管理框架”以及美國專利申請?zhí)?2/697，756名為“使用模版的業(yè)務(wù)處理的編排”中給出了描述。基于事件的編排框架一個實施例涉及分布式訂單編排系統(tǒng)，在該系統(tǒng)中使用一組獨立的和離散的事件來編排訂單。根據(jù)該實施例，用事件管理器來替代分布式編排系統(tǒng)中的有狀態(tài)的可執(zhí)行處理，例如可執(zhí)行處理310。代替用請求/回答的交互模式來編排訂單的有狀態(tài)的可執(zhí)行處理，事件管理器使用一組離散的和獨立的事件來編排訂單。在本發(fā)明的一個實施例中，事件管理器根據(jù)一個處理在事件消息發(fā)送系統(tǒng)上向一組用戶公布一組事件。每個訂購者消耗事件管理器所公布的一個事件，并執(zhí)行基于該事件的任務(wù)。根據(jù)該實施例，當(dāng)事件管理器處理分布式訂單編排系統(tǒng)中的不同的組成部分之間的通信時，離散的和獨立的事件使分布式訂單編排系統(tǒng)中的不同的組成部分去耦合。這樣，分布式訂單編排系統(tǒng)的第一組成部分能夠與第二組成部分通信，而不用知道第二組成部分的實施細(xì)節(jié)。本領(lǐng)域技術(shù)人員將會知道， 一組事件可包括單個事件或多個事件。根據(jù)該實施例，如果分布式訂單編排系統(tǒng)的兩個組成部分互相不直接通信，而是使用媒介來通信，例如事件消息發(fā)送系統(tǒng)，那么它們是“不同的”。圖16示出了根據(jù)一個實施例的依據(jù)使用事件管理器的處理來發(fā)布一組事件的方法的流程圖。根據(jù)該實施例，流程包含事件管理器1600、數(shù)據(jù)庫1610和訂購者1620。依照該實施例，事件管理器1600是一種無狀態(tài)的可執(zhí)行處理。事件管理器1600是分布式訂單編排系統(tǒng)中的不同的組成部分，并參照圖19和20在編排的上下文中更詳細(xì)地描述。數(shù)據(jù)庫1610是存儲著處理狀態(tài)和元數(shù)據(jù)的數(shù)據(jù)庫。處理狀態(tài)是用于處理一個訂單的處理的狀態(tài)。這樣，在該處理是一個編排處理的實施例中，該處理狀態(tài)是該編排處理的狀態(tài)。根據(jù)一個實施例，在編排一個DOO訂單的情況下，該處理狀態(tài)包括用于DOO訂單的每個首標(biāo)、行和實施行的屬性值。如前所述，元數(shù)據(jù)用于在訂單中定義任務(wù)，并用于調(diào)用與那些任務(wù)相關(guān)的服務(wù)，例如任務(wù)層服務(wù)。更特別地，元數(shù)據(jù)用于確定如何以及何時調(diào)用這些服務(wù)。而且，基于元數(shù)據(jù)，產(chǎn)生輸入變量并發(fā)送給這些服務(wù)，以便調(diào)用所封裝的服務(wù)。這樣，根據(jù)一個實施例，處理狀態(tài)可用于確定處理中的哪些步驟已被執(zhí)行，而元數(shù)據(jù)可用于確定處理中的哪些步驟要被執(zhí)行以及如何執(zhí)行這些步驟。數(shù)據(jù)庫1610可以是操作數(shù)據(jù)庫、分析數(shù)據(jù)庫、數(shù)據(jù)倉庫、分布式數(shù)據(jù)庫、終端用戶數(shù)據(jù)庫、外部數(shù)據(jù)庫、導(dǎo)航數(shù)據(jù)庫、存儲器內(nèi)數(shù)據(jù)庫、面向文檔的數(shù)據(jù)庫、實時數(shù)據(jù)庫、關(guān)系數(shù)據(jù)庫、面向?qū)ο髷?shù)據(jù)庫或現(xiàn)有技術(shù)中所知的任意其它的數(shù)據(jù)庫。根據(jù)本發(fā)明的一個實施例，圖16的數(shù)據(jù)庫1610與圖3中的存儲器314 相同。訂購者1620是用來訂購具體類型的事件的分布式訂單編排系統(tǒng)的不同組成部分。當(dāng)訂購者1620之一接收到發(fā)布的事件時，訂購者確定所發(fā)布的事件的類型。如果所發(fā)布的事件的類型是訂購者已經(jīng)訂購的，那么訂購者就消耗該事件并執(zhí)行基于所消耗的事件的任務(wù)。訂購者1620從事件管理器1600上去耦合。通常，由于這種去耦合，訂購者1620 不知道該事件管理器1600，因此也不知道所發(fā)布的事件的來源。然而，在某些實施例中，訂購者可以知道所發(fā)布的事件的來源。根據(jù)一個實施例，如將參照圖17更詳細(xì)地描述，訂購者1620包括任務(wù)層服務(wù)，該任務(wù)層服務(wù)執(zhí)行基于所消耗的事件的任務(wù)。然而，這只是一個示例，在可選實施例中，訂購者1620可以是不同于事件管理器1600的分布式訂單編排系統(tǒng)的任意一個組成部分?，F(xiàn)在要描述根據(jù)本發(fā)明一個實施例的如圖16所示的流程。處理開始，并在步驟1 啟動事件管理器1600。根據(jù)一個實施例，當(dāng)啟動時，事件管理器1600確定處理中的哪些步驟要被執(zhí)行，并發(fā)布一組事件以用于執(zhí)行所確定的步驟。
在步驟2，事件管理器1600從數(shù)據(jù)庫1610中讀取一個處理狀態(tài)和元數(shù)據(jù)?；谠撎幚頎顟B(tài)和元數(shù)據(jù)，事件管理器1600確定要執(zhí)行的處理的步驟，并產(chǎn)生一組要在事件消息發(fā)送系統(tǒng)上發(fā)布的事件。根據(jù)一個實施例，事件包括用以執(zhí)行任務(wù)的指令，其中該任務(wù)與處理中的步驟相對應(yīng)。將參照圖21來詳細(xì)描述事件以及事件管理系統(tǒng)。在步驟3，事件管理器1600在事件消息發(fā)送系統(tǒng)上發(fā)布一組事件，這些事件被傳輸?shù)接嗁徴?620。在事件管理器1600發(fā)布該組事件之后，事件管理器1600就終止。如前所述，訂購者1620可以是分布式訂單編排系統(tǒng)的任意一個組成部分。在所描述的實施例中，訂購者1620包括訂購者1621、訂購者1622和訂購者1623。然而，本領(lǐng)域技術(shù)人員將會容易地理解，這只是根據(jù)一個實施例的訂購者的示意性數(shù)量，在可選實施例中， 訂購者1620可以包括任意數(shù)量的訂購者。如前所述，訂購者1620中的每個訂購者都訂購了具體類型的事件。當(dāng)訂購者1620中的訂購者接收一個所發(fā)布的事件時，訂購者就確定所發(fā)布的事件的類型。如果所發(fā)布的事件的類型是訂購者已經(jīng)訂購的，那么訂購者就消耗該事件并執(zhí)行基于所消耗的事件的任務(wù)。在步驟4，在訂購者1620的每個訂購者執(zhí)行了其任務(wù)之后，每個訂購者更新數(shù)據(jù)庫1610的處理狀態(tài)。如前所述，處理狀態(tài)是處理的一個狀態(tài)。因此根據(jù)該實施例，更新數(shù)據(jù)庫1610中的處理狀態(tài)包括更新處理狀態(tài)用以標(biāo)識訂購者1620所執(zhí)行的任務(wù)已經(jīng)完成。 根據(jù)本發(fā)明的一個實施例，更新處理狀態(tài)包括更新DOO訂單的至少一個屬性值。這種更新可包括更新DOO訂單的首標(biāo)的至少一個屬性值，更新DOO訂單的行的至少一個屬性值，更新 DOO訂單的實施行的至少一個屬性值，或者它們的組合。根據(jù)該實施例，一旦數(shù)據(jù)庫1610的處理狀態(tài)被更新，事件管理器1600就再次啟動。一經(jīng)啟動，事件管理器1600就基于數(shù)據(jù)庫1610的處理狀態(tài)和元數(shù)據(jù)確定是否(1)事件管理器1600應(yīng)該產(chǎn)生一組新事件；(2)事件管理器1600應(yīng)該在產(chǎn)生一組新事件之前等待另一個處理狀態(tài)的變遷；或者C3)處理狀態(tài)已到達退出狀態(tài)。如果事件管理器1600確定應(yīng)該產(chǎn)生一組新事件，就重復(fù)步驟3和4直到處理狀態(tài)達到退出狀態(tài)。如果事件管理器1600 確定應(yīng)該在產(chǎn)生一組新事件之前等待另一個處理狀態(tài)的變遷，事件管理器1600就終止。如果事件管理器1600確定處理狀態(tài)已到達一個退出狀態(tài)，那么在步驟5，事件管理器1600就終止該處理。將參照圖M詳細(xì)描述事件管理器1600的確定過程。使用事件管理器在分布式訂單編排系統(tǒng)中處理訂單的一個實例是編排一個訂單。 更特別地，在一個分布式訂單編排系統(tǒng)中，編排層和任務(wù)服務(wù)層可使用一個事件管理器來通信。因此，根據(jù)本發(fā)明的一個實施例，將在編排的上下文中描述圖16所示的流程。圖17示出了根據(jù)一個實施例的使用事件管理器和任務(wù)層服務(wù)來編排訂單的方法的流程圖。根據(jù)該實施例，處理是用于編排一個訂單的編排處理。在步驟1，分布式訂單編排系統(tǒng)的分解層創(chuàng)建將被發(fā)送到該分布式訂單編排系統(tǒng)的一個編排層的分布式訂單編排訂單(“D00訂單”)，DOO訂單的編排被啟動。如前所述，DOO訂單是表示從分布式訂單編排系統(tǒng)的訂單捕獲層接收的訂單的對象，并且該訂單已被轉(zhuǎn)換為分布式訂單編排系統(tǒng)的編排層所使用的對象格式。當(dāng)啟動DOO訂單的編排時，就啟動事件管理器1600。在步驟2，事件管理器1600從數(shù)據(jù)庫1610中讀取處理狀態(tài)和元數(shù)據(jù)。根據(jù)該實施例，處理狀態(tài)是編排訂單的編排處理的狀態(tài)。在該實施例中，處理狀態(tài)包括用于DOO訂單的每個首標(biāo)、行和實施行的屬性值。而且，根據(jù)該實施例，元數(shù)據(jù)是用于在被編排的訂單中定義任務(wù)的數(shù)據(jù)，并用于調(diào)用與這些任務(wù)相關(guān)的任務(wù)層服務(wù)?；谠撎幚頎顟B(tài)和元數(shù)據(jù)，事件管理器1600確定要在事件消息發(fā)送系統(tǒng)上發(fā)布的一組事件。例如，如果元數(shù)據(jù)定義了創(chuàng)建運輸?shù)娜蝿?wù)，事件管理器1600就發(fā)布一個由創(chuàng)建運輸任務(wù)層服務(wù)訂購的事件，并被標(biāo)識為 “創(chuàng)建運輸事件”。在步驟3，事件管理器1600在該事件消息發(fā)送系統(tǒng)上發(fā)布一組事件，并且將這些事件傳輸?shù)饺蝿?wù)層服務(wù)1720中。根據(jù)該實施例，每個事件都與一個具體的任務(wù)層服務(wù)相對應(yīng)，其中該任務(wù)層服務(wù)被需要進一步編排該DOO訂單。在事件管理器1600發(fā)布該組事件之后，事件管理器1600就終止。在所示的實施例中，任務(wù)層服務(wù)1720包括任務(wù)層服務(wù)1721、任務(wù)層服務(wù)1722和任務(wù)層服務(wù)1723。然而，本領(lǐng)域技術(shù)人員將會容易地理解，這只是根據(jù)一個實施例的任務(wù)層服務(wù)的示意性數(shù)量，在可選實施例中，任務(wù)層服務(wù)1720可以包括任意數(shù)量的任務(wù)層服務(wù)。如前所述，任務(wù)層服務(wù)1720的每個任務(wù)層服務(wù)訂購一個具體類型的事件。例如，任務(wù)層服務(wù) 1721是一個“創(chuàng)建運輸”任務(wù)層服務(wù)并訂購一個事件類型“創(chuàng)建運輸事件”。在該實例中，任務(wù)層服務(wù)1722和1723是分別訂購不同類型事件的任務(wù)層服務(wù)。當(dāng)任務(wù)層服務(wù)1720的任務(wù)層服務(wù)接收一個發(fā)布的事件時，任務(wù)層服務(wù)確定所發(fā)布的事件的類型。如果所發(fā)布的事件的類型是任務(wù)層服務(wù)已訂購的，那么任務(wù)層服務(wù)就消耗該事件并執(zhí)行基于所消耗的事件的任務(wù)。如果所發(fā)布的事件的類型不是任務(wù)層服務(wù)已訂購的類型，任務(wù)層服務(wù)就忽略該事件。在該實例中，當(dāng)任務(wù)層服務(wù)1721接收一個事件管理器1600發(fā)布的事件類型“創(chuàng)建運輸事件”時，任務(wù)層服務(wù)1721就消耗該事件并執(zhí)行一個“創(chuàng)建運輸”任務(wù)。當(dāng)任務(wù)層服務(wù)1722 和1723接收事件類型“創(chuàng)建運輸事件”時，任務(wù)層服務(wù)1722和1723就忽略該事件，這是因為該事件不是任務(wù)層服務(wù)1722和1723訂購的事件類型。在步驟4，在任務(wù)層服務(wù)1720的每個任務(wù)層服務(wù)執(zhí)行其任務(wù)后，每個任務(wù)層服務(wù)更新數(shù)據(jù)庫1610的處理狀態(tài)。在該實例中，任務(wù)層服務(wù)1721執(zhí)行一個“創(chuàng)建運輸”任務(wù)，并更新數(shù)據(jù)庫1610的處理狀態(tài)。根據(jù)該實施例，處理狀態(tài)是編排處理的狀態(tài)。這樣，根據(jù)該實例，更新數(shù)據(jù)庫1610的處理狀態(tài)包括更新該處理狀態(tài)以便標(biāo)識由任務(wù)層服務(wù)1721執(zhí)行的“創(chuàng)建運輸”任務(wù)已完成。根據(jù)該實施例，更新該處理狀態(tài)包括更新DOO訂單的至少一個屬性值。這種更新可包括更新DOO訂單的首標(biāo)的至少一個屬性值，更新DOO訂單的行的至少一個屬性值，更新DOO訂單的實施行的至少一個屬性值，或者它們的組合。因此，根據(jù)該實例，更新處理狀態(tài)包括基于“創(chuàng)建運輸”任務(wù)的執(zhí)行而更新DOO訂單的至少一個屬性值。根據(jù)圖17所示的實施例，一旦更新了數(shù)據(jù)庫1610的處理狀態(tài)，事件管理器1600 就再次啟動。一經(jīng)啟動，事件管理器1600就基于數(shù)據(jù)庫1610的處理狀態(tài)和元數(shù)據(jù)來確定是否(1)事件管理器1600應(yīng)該產(chǎn)生一組新事件；(2)事件管理器1600應(yīng)該在產(chǎn)生一組新事件之前等待另一個處理狀態(tài)的變遷；或者C3)處理狀態(tài)已到達退出狀態(tài)。如果事件管理器1600確定應(yīng)該產(chǎn)生一組新事件，就重復(fù)步驟3和4直到處理狀態(tài)達到退出狀態(tài)。如果事件管理器1600確定應(yīng)該在產(chǎn)生一組新事件之前等待另一個處理狀態(tài)的變遷，則事件管理器1600就終止。如果事件管理器1600確定處理狀態(tài)已到達一個退出狀態(tài)，那么在步驟5， 事件管理器1600就終止該編排處理。然而，雖然圖17示出了在編排的上下文中的事件管理器，并示出了事件管理器可用在編排層和任務(wù)服務(wù)層之間進行通信，但本領(lǐng)域技術(shù)人員將會容易地理解，這只是事件管理器的一個實例。而且，本領(lǐng)域技術(shù)人員也將會理解，分布式訂單編排系統(tǒng)的任一層都能使用事件管理器與分布式訂單編排系統(tǒng)的另一層進行通信。例如，分基層能夠使用事件管理器與編排層進行通信。因此，根據(jù)本發(fā)明的一個實施例，事件管理器有助于分布式訂單編排系統(tǒng)的任意兩層或兩個組成部分之間的通信。圖18示出了根據(jù)一個實施例的使用事件管理器、任務(wù)層服務(wù)和中介器來編排訂單的方法的流程圖。圖18所示的實施例與圖17所示的實施例類似，區(qū)別在于，任務(wù)層服務(wù) 1720包括中介器17M。本領(lǐng)域技術(shù)人員將會容易地理解，中介器是通過從第一個處理接收數(shù)據(jù)并將所接收的數(shù)據(jù)從第一處理理解的格式轉(zhuǎn)換為第二處理理解的格式、從而允許兩個或多個處理互相通信的處理。因此，中介器用作兩個或多個處理的媒介，減少了兩個或多個處理之間的依賴性，并進而減少了耦合。另外，根據(jù)圖18所示的實施例，中介器17M訂購全局事件類型，而不是單個任務(wù)層服務(wù)訂購具體事件類型。因此，在步驟3，在事件管理器1600發(fā)布一組事件并且將這些事件傳輸?shù)饺蝿?wù)層服務(wù)1720之后，中介器17M就消耗各個事件并且基于事件內(nèi)所包含的一組參數(shù)，中介器17M調(diào)用任務(wù)層服務(wù)1721、任務(wù)層服務(wù) 1722或任務(wù)層服務(wù)1723。被調(diào)用的任務(wù)層服務(wù)(即任務(wù)層服務(wù)1721、任務(wù)層服務(wù)1722或任務(wù)層服務(wù)172 執(zhí)行基于該事件的任務(wù)。在一個可選實施例中，事件管理器不僅能控制一個或多個訂購者的任務(wù)處理，還能控制單個訂購者的子任務(wù)處理，例如任務(wù)層服務(wù)。例如，訂購者可以執(zhí)行基于所消耗的事件的任務(wù)，其中該任務(wù)包括10個子任務(wù)。而且，某些子任務(wù)可以并行地執(zhí)行，某些子任務(wù)可以順序地執(zhí)行，并且某些子任務(wù)需要一個或多個子任務(wù)完成之后才能執(zhí)行。在這種情況中， 當(dāng)訂購者執(zhí)行第一個子任務(wù)時，訂購者可以更新數(shù)據(jù)庫的處理狀態(tài)?；跀?shù)據(jù)庫中的該處理狀態(tài)和元數(shù)據(jù)，事件管理器可以確定哪個子任務(wù)(或哪些子任務(wù))可被執(zhí)行，并因此產(chǎn)生及發(fā)布一組事件。這些事件可由訂購者來消耗，并且基于這些事件，訂購者可以執(zhí)行相應(yīng)的一個或多個子任務(wù)。接著，訂購者可以更新處理狀態(tài)，并且可以重復(fù)該處理直到任務(wù)的所有子任務(wù)都已完成。下面將詳細(xì)地描述事件管理器，特別地，在編排的上下文中進行描述。圖19示出了根據(jù)一個實施例在訂單實施的上下文中使用事件管理器提供編排的系統(tǒng)1900的一個實例。在該實施例中，系統(tǒng)1900包括一個編排系統(tǒng)302和一個客戶機304。 根據(jù)該實施例，圖19的系統(tǒng)1900與圖3的系統(tǒng)300類似，區(qū)別在于系統(tǒng)1900包括事件管理器1910而不是可執(zhí)行處理310。事件管理器1910是可由運行時間引擎312調(diào)用的無狀態(tài)的處理。事件管理器1910包含嵌入式邏輯，被配置為確定一組要發(fā)布的事件。該邏輯是從存儲器314中的元數(shù)據(jù)和用戶使用接口 308進行模型化的業(yè)務(wù)處理的狀態(tài)中獲得的。替代執(zhí)行可執(zhí)行處理，運行時間引擎312調(diào)用事件管理器1910來編排接口 308中已模型化的業(yè)務(wù)處理。相似于圖3所示的實施例，用戶可以使用接口 308來定義使用服務(wù)庫306中的服務(wù)的業(yè)務(wù)處理的步驟。用戶可以在業(yè)務(wù)處理中定義多個步驟。每個步驟可以與服務(wù)庫306中的服務(wù)相關(guān)聯(lián)。這些步驟可以存儲在數(shù)據(jù)表中，該數(shù)據(jù)表可以包括能被運行時間引擎312使用并用以調(diào)動事件管理器1910的元數(shù)據(jù)?；诜?wù)庫306中用于定義業(yè)務(wù)處理的具體步驟的服務(wù)，事件管理器1910產(chǎn)生并發(fā)布一組被傳送給訂購者的事件，例如任務(wù)層服務(wù)。事件管理器1910通過調(diào)用一種內(nèi)部方法來發(fā)布一個事件。一旦事件管理器1910發(fā)布了該組事件，事件管理器1910就終止。在訂購者消耗該組事件并執(zhí)行基于該消耗的事件的任務(wù)之后，訂購者就更新已模型化的業(yè)務(wù)處理的狀態(tài)，運行時間引擎312再次調(diào)用事件管理器1910。重復(fù)該處理直到編排好模型化的業(yè)務(wù)處理，然后，事件管理器1910 終止該處理。圖20示出了根據(jù)一個實施例的利用事件管理器的分布式訂單編排系統(tǒng)2000。在本發(fā)明的一個實施例中，系統(tǒng)2000對應(yīng)于圖19的系統(tǒng)1900，并且在系統(tǒng)2000中只包含了系統(tǒng)1900中需要進行討論的部分。為了清晰起見，省略了系統(tǒng)1900的其它部分。在圖20所示的實施例中，圖9的分布式訂單編排模塊908被表示為兩個模塊分解模塊1020和編排模塊1030。然而，本領(lǐng)域技術(shù)人員將會容易地認(rèn)識到，一個模塊就可以提供分解模塊1020和編排模塊1030的功能，并且仍包含在本發(fā)明的范圍中。而且，圖9 的分布式訂單編排模塊908可以被表示為任意數(shù)量的模塊，并且這也包含在本發(fā)明的范圍中。根據(jù)該實施例，圖20的系統(tǒng)2000與圖10的系統(tǒng)1000類似，區(qū)別在于編排模塊 1030包含事件管理器2010而不是子模塊0PM1040、核心處理OM 1050、SMS 1060和SPM 1070。下面將參照圖20所示的分解模塊1020和編排模塊1030來描述編排的示意性實施例。然而，本領(lǐng)域技術(shù)人員將會容易地理解，所描述的實施例僅是示意性的實施例，這種編排可以根據(jù)可選實施例來實現(xiàn)，并仍包含在本發(fā)明的范圍中。分解模塊1020按照與之前討論過的圖10相似的方式來進行操作。編排模塊1030 控制著在處理并實施DOO訂單的同時發(fā)生的事件的順序，其中該DOO訂單是由分解模塊 1020通過事件管理器2010的調(diào)用和事件發(fā)布來創(chuàng)建的。根據(jù)該實施例，分解模塊1020調(diào)用編排模塊1030的事件管理器2010。更特別地， 分解模塊1020調(diào)用事件管理器2010來編排由分解模塊1020創(chuàng)建的DOO訂單。如前所述， 事件管理器1910是無狀態(tài)的處理，其能夠被分解模塊1020來調(diào)用。事件管理器2010包含嵌入式邏輯，被配置為確定一組要發(fā)布的事件。該邏輯是從存儲在數(shù)據(jù)庫中的元數(shù)據(jù)和處理狀態(tài)中獲得的?；谠撨壿?，事件管理器2010產(chǎn)生并發(fā)布一組要傳送給訂購者的事件， 例如任務(wù)層服務(wù)。事件管理器2010可以通過調(diào)用一種內(nèi)部方法來發(fā)布一個事件。一旦事件管理器2010發(fā)布了該組事件，事件管理器2010就終止。在訂購者消耗該組事件并執(zhí)行基于該消耗的事件的任務(wù)之后，訂購者就更新存儲在數(shù)據(jù)庫中的處理狀態(tài)。分解模塊1020 再次調(diào)用事件管理器2010。重復(fù)該處理直到編排好DOO訂單，然后，事件管理器2010終止。下面將詳細(xì)地描述事件消息發(fā)送系統(tǒng)。應(yīng)用程序可以通過消息通道(即把發(fā)送器連接到接收器的虛擬通道)傳輸數(shù)據(jù)。 消息是可以在消息通道上傳輸?shù)臄?shù)據(jù)分組。為了傳輸數(shù)據(jù)，發(fā)送器可將數(shù)據(jù)拆分為一個或多個分組，將每個分組打包為一條消息，然后在消息通道上傳輸該消息。同樣地，接收器可以接收一條消息，從該消息中提取數(shù)據(jù)，并處理該數(shù)據(jù)。消息發(fā)送系統(tǒng)可以重復(fù)嘗試把消息從發(fā)送器發(fā)送到接收器，直到成功為止。傳輸數(shù)據(jù)可包括在發(fā)送器處將數(shù)據(jù)排列為字節(jié)格式，將所排列的數(shù)據(jù)作為字節(jié)流從發(fā)送器傳輸?shù)浇邮掌鳎言摂?shù)據(jù)去排列回其原始格式。即使在應(yīng)用程序不知道哪個特定的接收器將會最終取回該應(yīng)用程序，事件消息發(fā)送系統(tǒng)也能允許發(fā)送器傳輸消息。這是因為，當(dāng)發(fā)送器傳輸數(shù)據(jù)時，發(fā)送器就將該數(shù)據(jù)添加到專用于傳輸這種類型的信息消息通道中。同樣地，欲接收特定信息的接收器基于其所需的數(shù)據(jù)類型選擇從什么消息通道獲取數(shù)據(jù)。這樣，發(fā)送器就能確保接收器取回數(shù)據(jù)中其所感興趣的數(shù)據(jù)。消息可以包括兩部分首標(biāo)和主體。首標(biāo)可包括由消息發(fā)送系統(tǒng)使用的信息，該信息描述了正被傳輸?shù)臄?shù)據(jù)。主體可包括正被傳輸?shù)臄?shù)據(jù)。事件是一種表示發(fā)送器的狀態(tài)發(fā)生改變的消息。這種狀態(tài)改變可以基于外部對發(fā)送器進行動作而產(chǎn)生。例如，用戶可以在一個訂單捕獲層中表示他想要創(chuàng)建一個運輸。用戶的表示是一種外部動作，它觸發(fā)了編排層的狀態(tài)的改變。作為這種狀態(tài)的改變的結(jié)果，編排層可以使用消息通道向任務(wù)服務(wù)層傳輸一個事件，其中該事件表示用戶想要創(chuàng)建一個運輸。任務(wù)服務(wù)層可消耗該事件并執(zhí)行一個任務(wù)，以基于該事件創(chuàng)建一個運輸。事件的傳輸是單向的異步動作。這意味著傳輸事件的發(fā)送器不需要等待來自接收器的響應(yīng)，其中該接收器訂購該事件并消耗該事件。根據(jù)某些實施例，發(fā)送器在其發(fā)送了事件之后就終止。圖21示出了根據(jù)一個實施例的事件消息發(fā)送系統(tǒng)2100的一個實例。事件消息發(fā)送系統(tǒng)2100包括消息通道2110。如前所述，消息通道2110被配置為從發(fā)送器向接收器傳輸消息，例如事件。所示的實施例包括事件管理器2120和訂購者2130。根據(jù)該實施例，事件管理器2120可使用消息通道2110來傳輸事件。在該實施例中，事件管理器2120通過消息通道2110將一個事件傳輸給訂購者2130。訂購者2130訂購該事件，并因此接收該事件， 訂購者2130執(zhí)行基于該事件的任務(wù)。雖然圖21示出了事件消息發(fā)送系統(tǒng)2100具有單個消息發(fā)送通道，但這只是一個示意性實施例，本領(lǐng)域技術(shù)人員將會容易地理解，事件消息發(fā)送系統(tǒng)2100可以包括任意數(shù)量的消息發(fā)送通道，并仍包含在本發(fā)明的范圍內(nèi)。消息通道的類型有許多種。根據(jù)本發(fā)明的一個實施例，分布式訂單編排系統(tǒng)使用一個事件消息發(fā)送系統(tǒng)，該事件消息發(fā)送系統(tǒng)包括一個或多個發(fā)布-訂購消息通道。現(xiàn)在將詳細(xì)描述發(fā)布-訂購消息通道。圖22示出了根據(jù)一個實施例的事件消息發(fā)送系統(tǒng)的發(fā)布-訂購消息通道2200的一個實例。發(fā)布-訂購消息通道2200是使一個輸入通道被分割為多個輸出通道(每個輸出通道用于一個訂購者)的消息通道。所示的實施例包括一個事件管理器220以及訂購者 2220,2230和2240。根據(jù)該實施例，事件管理器2210把事件2250發(fā)布到發(fā)布-訂購消息通道2200的一個輸入通道中。發(fā)布-訂購消息通道2200然后將事件2250的一個拷貝傳輸給每個輸出通道。根據(jù)該實施例，每個輸出通道具有一個訂購者(即第一輸出通道具有訂購者2220，第二輸出通道具有訂購者2230，第三輸出通道具有訂購者2240)。每個訂購者監(jiān)聽事件2250并消耗事件2250的相應(yīng)的拷貝。一旦事件2250的每個拷貝都被相應(yīng)的訂購者所消耗，那么事件2250的每個拷貝就從發(fā)布-訂購消息通道2200中消失。雖然圖22示出了發(fā)布-訂購消息通道2200具有三個輸出通道和三個訂購者，但這只是一個示意性實施例，本領(lǐng)域技術(shù)人員將會容易地理解，發(fā)布-訂購消息通道2200可以包括任意數(shù)量的輸出通道和訂購者，并仍包含在本發(fā)明的范圍內(nèi)。而且，雖然在圖22所示的實施例中對所有訂購者2220、2230和2240發(fā)布事件2250，但這只是一個示意性實施例，本領(lǐng)域技術(shù)人員將會容易地理解，可以向有效的訂購者的子集，甚至是單個訂購者發(fā)布事件。圖23示出了根據(jù)一個實施例在分布式訂單編排系統(tǒng)中管理事件的方法的流程圖。提供了編排層、任務(wù)層、外部接口層和外部系統(tǒng)層。在一個實施例中，在編排層之前提供一個分解層(未示出)。在包括分解層的實施例中，分解層可以調(diào)用一個服務(wù)，用以創(chuàng)建處理狀態(tài)和元數(shù)據(jù)并將它們存儲在數(shù)據(jù)庫中。根據(jù)該實施例，步驟2302產(chǎn)生一個事件并發(fā)布該事件?？梢詮挠唵尾东@模塊接收訂單。這將導(dǎo)致事件被發(fā)布。使用數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)產(chǎn)生該事件。該事件被發(fā)送到任務(wù)層。根據(jù)該實施例，步驟2304啟動該任務(wù)，產(chǎn)生一個用于外部系統(tǒng)的消息并發(fā)送該消息。所產(chǎn)生的消息表示哪個任務(wù)應(yīng)當(dāng)由外部系統(tǒng)來執(zhí)行。要執(zhí)行的任務(wù)是已模型化的訂單處理的一個方面。例如，可為一個訂單調(diào)用該任務(wù)。也包含執(zhí)行該任務(wù)所需的參數(shù)。消息被發(fā)送到一個外部接口。根據(jù)該實施例，步驟2306對消息進行轉(zhuǎn)換并將其發(fā)送給該外部層。由任務(wù)層產(chǎn)生的消息可以是一種通用的格式。然而不同的外部系統(tǒng)可以使用其它的格式進行通信。該外部接口層確定外部系統(tǒng)所使用的格式并轉(zhuǎn)換該消息。例如，用戶定義的元數(shù)據(jù)可用于確定要使用的格式。在一個實例中，對哪些系統(tǒng)調(diào)用了所訂購的產(chǎn)品的映射，被用來翻譯該消肩、ο根據(jù)該實施例，步驟2308接收由該外部系統(tǒng)返回的消息并處理該產(chǎn)生了一個結(jié)果的消息。該外部系統(tǒng)可以是執(zhí)行與處理訂單相關(guān)的任務(wù)的系統(tǒng)，例如調(diào)度系統(tǒng)、運輸系統(tǒng)等等。當(dāng)執(zhí)行任務(wù)時，確定任務(wù)的結(jié)果。結(jié)果可以是安排好的運輸日期，運輸貨物的日期等。 結(jié)果然后被發(fā)送回該外部接口層。在該實施例中，步驟2310轉(zhuǎn)換該消息并將其發(fā)送到任務(wù)層。步驟2312基于結(jié)果更新數(shù)據(jù)庫中的處理狀態(tài)。然后處理進行到下一個可被產(chǎn)生的事件。重復(fù)處理直至處理完成。圖M示出了根據(jù)一個實施例的確定一組要發(fā)布的事件的方法的流程圖。根據(jù)一個實施例，該方法可在調(diào)用事件管理器時由事件管理器來實施，并且該方法可確定事件管理器要為具體處理發(fā)布哪組事件。在M00，開始該方法。在M10，確定是否有處理步驟“剩余”。換言之，確定是否有處理步驟還未執(zhí)行。根據(jù)一個實施例，這種確定是基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來做出的。根據(jù)一個實施例，處理狀態(tài)表示哪些處理步驟已被執(zhí)行，元數(shù)據(jù)表示該處理的所有處理步驟。根據(jù)該實施例，如果一個處理步驟還未執(zhí)行，但之前已被當(dāng)前的實現(xiàn)方法所選擇，那么處理步驟就不能被認(rèn)為是“剩余”，并且不可以被選擇。如果沒有處理步驟剩余， 方法就在M60結(jié)束。如果剩余了一個或多個處理步驟，那么方法就前進到M20。在M20，選擇處理步驟。根據(jù)一個實施例，基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來選擇處理步驟。例如，可以從處理狀態(tài)和元數(shù)據(jù)中來確定哪些處理步驟已被執(zhí)行。這樣，就可以根據(jù)該方法選擇尚未執(zhí)行的處理步驟。根據(jù)一個實施例，處理狀態(tài)表示哪些處理步驟已被執(zhí)行，元數(shù)據(jù)表示該處理的所有處理步驟。根據(jù)該實施例，之前已被當(dāng)前的實現(xiàn)方法所選擇的處理步驟不可以被選擇。在M30，確定所選擇的處理步驟是否依賴于其它的處理步驟。根據(jù)一個實施例， 確定基于存儲在數(shù)據(jù)庫中的元數(shù)據(jù)來確定所選擇的處理步驟是否依賴于其它的處理步驟。 例如，如果選擇了處理步驟4，就可以確定處理步驟4只能在處理步驟1、2和3完成之后再執(zhí)行?？蛇x地，可以確定處理步驟4可以在任何時間來執(zhí)行，而不考慮步驟1、2和3是否完成。如果確定出所選擇的處理步驟不依賴于其它的處理步驟，那么方法就前進到M40。如果確定出處理步驟依賴于其它的處理步驟，那么方法就前進到M50。在對40，基于所選擇的處理步驟產(chǎn)生一個事件并發(fā)布該事件。根據(jù)該實施例，通過發(fā)布該事件，該事件被傳輸給一個或多個訂購者。一個或多個訂購者可以消耗該事件并執(zhí)行一個基于該所消耗的事件的任務(wù)，其中該消耗的事件與該處理步驟相對應(yīng)。在M50，確定所選擇的處理步驟所依賴的其它處理步驟是否已完成。根據(jù)一個實施例，基于數(shù)據(jù)庫中存儲的元數(shù)據(jù)確定其它處理步驟是否已完成。例如，如果選擇了處理步驟4，并且處理步驟4依賴于步驟1、2和3，就確定處理步驟1、2和3是否已完成。如果確定出其它處理步驟已完成，那么方法就前進到M40，并且如上所述產(chǎn)生一個事件并將其發(fā)布。然而，如果確定出其它處理步驟尚未完成，那么方法就返回M10，這是因為在其它處理步驟完成之前不能執(zhí)行所選擇的處理步驟。在對60，方法結(jié)束。然而，每次調(diào)用事件管理器時可以實施該方法?？梢哉{(diào)用事件管理器直到所有的處理步驟都已執(zhí)行，這樣，就可以每次實施該方法直到所有的處理步驟都已執(zhí)行。根據(jù)該實施例，一旦為一個處理步驟產(chǎn)生一個事件并將其發(fā)布，在隨后實施該方法時該處理步驟就不可以被選擇。然而，如果選擇了一個處理步驟，但不對該處理步驟產(chǎn)生事件并將其發(fā)布(例如因為該處理步驟依賴于未完成的其它處理步驟)，那么在隨后實施該方法時該處理步驟就可以被選擇。根據(jù)一個實施例，數(shù)據(jù)庫包含并行控制，以便如果兩個或多個步驟同時完成，能正確地確定出兩個或多個步驟已完成。因此，根據(jù)該實施例，可以基于數(shù)據(jù)庫的處理狀態(tài)和元數(shù)據(jù)來確定所選擇的處理步驟所依賴的其它處理步驟是否已完成。如前所述，分布式訂單編排系統(tǒng)的用戶可以定義一個要被調(diào)用的服務(wù)的序列，這些服務(wù)使用并行分支來影響業(yè)務(wù)處理規(guī)則。當(dāng)用戶為一個處理步驟選擇一個服務(wù)時，該用戶可以提供附加的元數(shù)據(jù)，用以在運行時間上處理該訂單期間確定該處理數(shù)據(jù)如何被執(zhí)行。在某個實施例中，可以定義并行分支。根據(jù)一個實施例，事件管理器可被用于為并行的處理步驟發(fā)布事件。根據(jù)該實施例，如果事件管理器基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)確定出兩個或多個處理步驟要并行地執(zhí)行，該事件管理器就同時發(fā)布兩個或多個事件。下面將更加詳細(xì)地描述事件管理器為并行處理步驟發(fā)布事件的一個實例。圖25示出了根據(jù)一個實施例的事件管理器2500為并行處理步驟發(fā)布事件的一個實例。根據(jù)該實施例，事件管理器2500基于存儲在數(shù)據(jù)庫(未示出)中的處理狀態(tài)和元數(shù)據(jù)，確定要并行運行的三個處理步驟。事件管理器2500產(chǎn)生三個事件，事件2501、2502 和2503，并同時發(fā)布這三個事件。訂購者2510消耗事件2501并執(zhí)行基于所消耗的事件的任務(wù)，訂購者2520消耗事件2502并執(zhí)行基于所消耗的事件的任務(wù)，訂購者2530消耗事件 2503并執(zhí)行基于所消耗的事件的任務(wù)。這樣，與事件2501、2502和2503相應(yīng)的任務(wù)分別由訂購者2510、訂購者2520和訂購者2530并行執(zhí)行。雖然在該實例中，有三個處理步驟并行運行，但本領(lǐng)域技術(shù)人員將會容易地理解， 這只是一個實例，任意數(shù)量的步驟都可以并行地運行。因此，在可選實施例中，事件管理器 2500可以為任意數(shù)量的并行處理發(fā)布事件。在一個可選的實施例中，圖25所示的三個處理步驟是條件步驟而不是并行步驟。如前所述，條件步驟是依賴于結(jié)果的發(fā)生的步驟(例如另一個步驟的結(jié)束)。根據(jù)該實施例，事件管理器2500基于存儲在數(shù)據(jù)庫(未示出)中的處理狀態(tài)和元數(shù)據(jù)，確定要執(zhí)行三個處理步驟中的哪一個。事件管理器2500產(chǎn)生事件2501、事件2502或事件2503，并發(fā)布該事件。當(dāng)事件管理器2500發(fā)布事件2501時，訂購者2510消耗事件2501并并執(zhí)行基于所消耗的事件的任務(wù)。同樣地，當(dāng)事件管理器2500發(fā)布事件2502時，訂購者2520消耗事件2502并執(zhí)行基于所消耗的事件的任務(wù)。相似地，當(dāng)事件管理器2500發(fā)布事件2503時， 訂購者2530消耗事件2503并執(zhí)行基于所消耗的事件的任務(wù)。仍如前所述，分布式訂單編排系統(tǒng)的用戶可指示一個處理要被分割為兩個或多個處理。根據(jù)一個實施例，事件管理器可用于為分割的處理步驟發(fā)布事件。根據(jù)該實施例，如果事件管理器基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來確定一個處理要被分割為兩個或多個處理，該事件管理器就產(chǎn)生一組用于一個或多個分割單元的事件，并發(fā)布該組事件。 下面將詳細(xì)描述事件管理器分割處理和發(fā)布相應(yīng)的一組事件的一個實例。圖沈示出了根據(jù)一個實施例的事件管理器沈00分割一個處理的一個實例。根據(jù)該實施例，事件管理器2600基于存儲在數(shù)據(jù)庫(未示出)中的處理狀態(tài)和元數(shù)據(jù)，確定當(dāng)前的處理要被分割為兩個處理。事件管理器沈00確定處理的剩余步驟并創(chuàng)建兩個分割單元，分割單元A和分割單元B。如前所定義的，分割單元定義了可被一起分割的處理中的一組連續(xù)的步驟。然后事件管理器沈00產(chǎn)生一組事件，事件沈01、2602、沈03和沈04，這里事件沈01和沈02是分割單元A的一部分，事件沈03和沈04是分割單元B的一部分，每個事件與處理的一個剩余的步驟相對應(yīng)。然后事件管理器沈00發(fā)布事件沈01、2602、沈03和 2604。根據(jù)一個實施例，事件管理器沈00順序地發(fā)布事件沈01、2602、沈03和沈04。在另一個實施例中，事件管理器2600并行地發(fā)布作為分割單元A的一部分的一個事件以及作為分割單元B的一部分的一個事件，然后再并行地發(fā)布作為分割單元A的一部分的另一個事件以及作為分割單元B的一部分的另一個事件。在第三個實施例中，事件管理器沈00并行地發(fā)布事件2601,2602,2603和洸04。根據(jù)一個實施例，訂購者沈10消耗事件沈01并執(zhí)行基于所消耗的事件的任務(wù)。另夕卜，訂購者2620消耗事件沈02和事件沈03，并執(zhí)行基于每個所消耗的事件的任務(wù)。而且， 訂購者沈30消耗事件沈04并執(zhí)行基于所消耗的事件的任務(wù)。根據(jù)一個實施例，當(dāng)處理被分割時，由事件管理器沈00產(chǎn)生的事件相比于不分割處理時所產(chǎn)生的事件，可以具有不一樣的有效負(fù)載。根據(jù)該實施例，不同的有效負(fù)載可以標(biāo)識與分割處理的一個步驟相對應(yīng)的事件。雖然在該實例中，產(chǎn)生了四個事件，其中該四個事件與處理的四個步驟相對應(yīng)，但本領(lǐng)域技術(shù)人員將會容易地理解，這只是一個實例，可以相應(yīng)于任意數(shù)量的處理步驟來產(chǎn)生任意數(shù)量的事件。另外，雖然在該實例中，對三個訂購者發(fā)布四個事件，但本領(lǐng)域技術(shù)人員也將會理解，這也只是一個實例，所產(chǎn)生的事件可以發(fā)布給任意數(shù)量的訂購者，每個訂購者可以消耗任意數(shù)量的事件。并且，雖然在該實例中，處理被分割為兩個分割單元，但這也只是一個實例，處理可被分割為任意數(shù)量的分割單元。因此，事件管理器沈00可以將一個處理分割為任意數(shù)量的分割單元，其中每個分割單元包括任意數(shù)量的剩余步驟。而且，事件管理器沈00能夠產(chǎn)生任意數(shù)量的事件，并能夠?qū)⑦@些事件發(fā)布給任意數(shù)量的訂購者。仍如前所述，分布式訂單編排系統(tǒng)的用戶可以啟動一個修改請求。如前所述，修改請求包括引用一個原始訂單的新訂單。該新訂單還包括對原始訂單的修正，因此也就包括對含有原始處理的業(yè)務(wù)步驟的修正。該原始處理可以是正在執(zhí)行的，或者之前已被執(zhí)行過。 根據(jù)一個實施例，事件管理器可用于處理一個修改請求。根據(jù)該實施例，如果事件管理器基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)確定出用戶已啟動一個修改請求，那么事件管理器就產(chǎn)生一組事件，每個事件用來補償原始處理的一個步驟。下面將詳細(xì)描述事件管理器使用事件來處理修改請求的一個實例。圖27示出了根據(jù)一個實施例的事件管理器2700使用事件來處理修改請求的一個實例。根據(jù)該實施例，事件管理器2700基于存儲在數(shù)據(jù)庫(未示出)中的處理狀態(tài)和元數(shù)據(jù)來確定已經(jīng)啟動一個修改請求?；谔幚頎顟B(tài)和元數(shù)據(jù)，事件管理器2700產(chǎn)生一組事件以用于補償一個原始處理。在圖27所示的實施例中，事件管理器2700產(chǎn)生事件2701、2702 和2703，每個事件都與原始處理的一個步驟相對應(yīng)。根據(jù)該實施例，事件管理器2700每次發(fā)布該組事件中的一個事件。這是因為原始處理的步驟是順序補償?shù)?，而不是并行的。在所示的實施例中，事件管理?700首先將事件2701發(fā)布給訂購者2710。訂購者2710消耗該事件并基于所消耗的事件執(zhí)行一個補償原始處理的第一步驟的任務(wù)。接著，事件管理器2700將事件2702發(fā)布給訂購者2720。訂購者2720消耗該事件并基于所消耗的事件執(zhí)行一個補償原始處理的第二步驟的任務(wù)。然后，事件管理器2700將事件2703發(fā)布給訂購者2730。訂購者2730消耗該事件并基于所消耗的事件執(zhí)行一個補償原始處理的第三步驟的任務(wù)。雖然在該實例中產(chǎn)生了三個事件，其中這三個事件與一個原始處理的三個步驟相對應(yīng)，但本領(lǐng)域技術(shù)人員將會容易地理解，這只是一個實例，可以相應(yīng)于原始處理的任意數(shù)量的步驟來產(chǎn)生任意數(shù)量的事件。而且，雖然在該實例中，對三個訂購者發(fā)布三個事件，但這也只是一個實例，一組事件可以發(fā)布給任意數(shù)量的訂購者。圖觀示出了根據(jù)一個實施例的分布式訂單編排模塊的功能的處理圖。根據(jù)該實施例，分布式訂單編排模塊啟動事件管理器用于使用一個處理來處理一個訂單。根據(jù)該實施例，事件管理器執(zhí)行圖觀所示的功能。在觀10，基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來確定要執(zhí)行的一個處理步驟。在觀20，基于所確定的處理步驟來產(chǎn)生一個事件。根據(jù)該實施例，事件包括用于執(zhí)行與該處理步驟相應(yīng)的任務(wù)的指令。在觀30，在事件消息發(fā)送系統(tǒng)上發(fā)布該事件。這樣，根據(jù)本發(fā)明的一個實施例，分布式訂單編排系統(tǒng)的事件管理器可以基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來產(chǎn)生并發(fā)布一組事件。一組訂購者可以消耗該組事件，每個訂購者可以執(zhí)行基于所消耗的事件的任務(wù)。根據(jù)該實施例，分布式訂單編排系統(tǒng)中的組成部分可以互相去耦合，這是因為事件管理器可以處理這些組成部分之間的通信。分布式訂單編排系統(tǒng)中的計算可以與通信相分離。因此，分布式訂單編排系統(tǒng)的每個組成部分或每個層可以包括較少的源代碼，這是因為每個組成部分的源代碼可以只包括完成該組成部分的目的的功能，并且不需要包括處理與其它組成部分通信的源代碼。而且，可以對每個組成部分的源代碼進行修改，例如修改事件的有效負(fù)載，而不需要修改源代碼以修改該組成部分怎樣與其它組成部分進行通信。另夕卜，由于事件管理器是無狀態(tài)的，因此產(chǎn)生并保留較少的數(shù)據(jù)。因此，根據(jù)該實施例，分布式訂單編排系統(tǒng)可以更加可伸縮和靈活。
盡管上面是參照這里的特定實施例來進行的描述，但這些特定實施例僅是示意性的并且是非限定性的。盡管描述了 BPEL，但可以理解其它的業(yè)務(wù)項目語言也可以使用。任意適當(dāng)?shù)木幊陶Z言都可用于實現(xiàn)特定實施例的例程，它們包括C、C++、Java、匯編語言等。可以采用不同的編程技術(shù)，例如過程的或者面向?qū)ο蟮摹＠炭稍谝粋€處理設(shè)備或多個處理器上執(zhí)行。盡管以具體次序給出步驟、操作或計算，但是該次序可以在不同的特定實施例中進行修改。在某些特定實施例中，在說明書中順序示出的多個步驟是可以同時執(zhí)行的?？梢栽诶弥噶顖?zhí)行系統(tǒng)、裝置、系統(tǒng)或設(shè)備使用或與它們連接的計算機可讀介質(zhì)中實現(xiàn)這些特定實施例。能夠以軟件或硬件或它們的組合中的控制邏輯的形式來實施特定實施例。當(dāng)該控制邏輯被一個或多個處理器所執(zhí)行時，可操作地執(zhí)行在特定實施例中描述的內(nèi)容?？梢允褂靡丫幊痰耐ㄓ媚康臄?shù)字計算機、使用應(yīng)用程序?qū)Ｓ眉呻娐穪韺崿F(xiàn)特定實施例，可以使用可編程邏輯設(shè)備、現(xiàn)場可編程門陣列、光、化學(xué)、生物、量子或納米設(shè)計的系統(tǒng)、元件和機制。通常，特定實施例的功能可由本領(lǐng)域所公知的任意方式來實現(xiàn)。可以使用分布式、網(wǎng)絡(luò)系統(tǒng)、元件和/或電路。數(shù)據(jù)的通信或傳輸可以是有線的、無線的或通過任意其它的方式?？梢岳斫猓诟綀D中描述的一個或多個元件也可以采用更加分離或集成的方式來實現(xiàn)，或者在某些情形下甚至作為不能操作的元件進行移除或放棄，盡管它在某個特定的應(yīng)用中是有用的。實施存儲在機器可讀介質(zhì)中的程序或代碼，以便允許計算機執(zhí)行上述任意一種方法，這也落入本發(fā)明的精神和范圍內(nèi)。如在說明書和整個權(quán)利要求書所使用的，除非上下文中有明確的描述，“一個”、 “該”以及“所述”包括復(fù)數(shù)個引用。而且，如在說明書和整個權(quán)利要求書所使用的，除非上下文中有明確的描述，“在......中”意味著“在......中”或“在......上”。因此，雖然這里已描述了特定實施例，但是容許在之前的描述中進行修改、各種改變以及替換，可以理解，也可以在在某些實例中采用特定實施例的某些特征而不用相應(yīng)地使用其它的特征，這不會背離所表述的范圍和精神。因此，可以做出許多修改以便使特定的情況和材料適應(yīng)基本的范圍和精神。
權(quán)利要求
1.一種用于啟動事件管理器以使用一個處理來處理訂單的設(shè)備，該設(shè)備包括 確定裝置，基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來確定要執(zhí)行的處理步驟；事件產(chǎn)生裝置，基于所確定的處理步驟產(chǎn)生事件，其中該事件包括執(zhí)行與處理步驟相對應(yīng)的任務(wù)的指令；以及發(fā)布裝置，在事件消息發(fā)送系統(tǒng)上發(fā)布該事件。
2.如權(quán)利要求1的設(shè)備，其中訂購者消耗所發(fā)布的事件并基于所發(fā)布的事件執(zhí)行任務(wù)；以及其中該訂購者在執(zhí)行該任務(wù)之后更新存儲在數(shù)據(jù)庫中的處理狀態(tài)。
3.如權(quán)利要求1的設(shè)備，其中事件管理器和訂購者分別是分布式訂單編排系統(tǒng)的不同組成部分。
4.如權(quán)利要求3的設(shè)備，其中事件管理器包括由編排系統(tǒng)調(diào)用的無狀態(tài)處理；以及其中訂購者包括任務(wù)層服務(wù)。
5.如權(quán)利要求1的設(shè)備， 其中中介器消耗所述事件；其中中介器基于包含在所述事件中的參數(shù)調(diào)用訂購者； 其中訂購者基于所發(fā)布的事件執(zhí)行任務(wù)；以及其中該訂購者在執(zhí)行任務(wù)之后更新存儲在數(shù)據(jù)庫中的處理狀態(tài)。
6.如權(quán)利要求1的設(shè)備，其中訂購者消耗所發(fā)布的事件；其中訂購者執(zhí)行基于所發(fā)布的事件的子任務(wù)，該子任務(wù)是所述任務(wù)的組成部分； 其中訂購者在執(zhí)行子任務(wù)之后更新存儲在數(shù)據(jù)庫中的處理狀態(tài)； 其中重復(fù)運行確定裝置、事件產(chǎn)生裝置和發(fā)布裝置，直到所述任務(wù)的所有子任務(wù)都已由訂購者執(zhí)行。
7.如權(quán)利要求1的設(shè)備，其中所述處理狀態(tài)包括處理的一個狀態(tài)；以及其中所述確定裝置還包括 用于確定是否有任何的處理步驟剩余的裝置； 用于選擇處理步驟的裝置；用于確定所選擇的處理步驟是否依賴于其他的處理步驟的裝置；以及用于當(dāng)確定出所選擇的處理步驟依賴于其他的處理步驟時，確定是否所述其他的處理步驟已完成的裝置。
8.一種計算機實現(xiàn)的方法，用于啟動事件管理器以使用一個處理來處理訂單，該計算機實現(xiàn)的方法包括基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來確定要執(zhí)行的處理步驟； 基于所確定的處理步驟產(chǎn)生事件，其中該事件包括執(zhí)行與處理步驟相對應(yīng)的任務(wù)的指令；以及在事件消息發(fā)送系統(tǒng)上發(fā)布該事件。
9.如權(quán)利要求8的計算機實現(xiàn)的方法，其中訂購者消耗所發(fā)布的事件并基于所發(fā)布的事件執(zhí)行任務(wù)；以及其中該訂購者在執(zhí)行任務(wù)之后更新存儲在數(shù)據(jù)庫中的處理狀態(tài)。
10.如權(quán)利要求8的計算機實現(xiàn)的方法，其中所述事件管理器和訂購者分別是分布式訂單編排系統(tǒng)的不同組成部分。
11.如權(quán)利要求10的計算機實現(xiàn)的方法，其中所述事件管理器包括由編排系統(tǒng)調(diào)用的無狀態(tài)處理；以及其中所述訂購者包括任務(wù)層服務(wù)。
12.—種編排系統(tǒng)，包括 處理器；編排模塊，被配置為啟動事件管理器以使用一個處理來處理訂單；以及數(shù)據(jù)庫，被配置為存儲處理狀態(tài)和元數(shù)據(jù)，其中事件管理器被配置為基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)來確定要執(zhí)行的處理步驟；其中事件管理器還被配置為基于所確定的處理步驟產(chǎn)生事件，其中該事件包括執(zhí)行與處理步驟相對應(yīng)的任務(wù)的指令；以及其中事件管理器還被配置為在事件消息發(fā)送系統(tǒng)上發(fā)布該事件。
13.如權(quán)利要求12的編排系統(tǒng)，其中訂購者消耗所發(fā)布的事件并基于所發(fā)布的事件執(zhí)行任務(wù)；以及其中訂購者在執(zhí)行任務(wù)之后更新存儲在數(shù)據(jù)庫中的處理狀態(tài)。
14.如權(quán)利要求12的編排系統(tǒng)，其中事件管理器和訂購者分別是分布式訂單編排系統(tǒng)的不同組成部分。
15.如權(quán)利要求14的編排系統(tǒng)，其中事件管理器包括由編排系統(tǒng)調(diào)用的無狀態(tài)處理；以及其中訂購者包括任務(wù)層服務(wù)。
全文摘要
本發(fā)明公開一種分布式訂單編排系統(tǒng)，包括一個事件管理器，被配置為基于存儲在數(shù)據(jù)庫中的處理狀態(tài)和元數(shù)據(jù)產(chǎn)生并發(fā)布一組事件。一組訂購者可以消耗該組事件，并且每個訂購者可以執(zhí)行基于所消耗的事件的任務(wù)。
文檔編號G06Q30/00GK102467701SQ20111035590
公開日2012年5月23日 申請日期2011年11月11日 優(yōu)先權(quán)日2010年11月12日
發(fā)明者A·辛格, R·阿達拉, S·賴伊辛加尼, Z·巴特 申請人:甲骨文國際公司