我們正在研究駱駝用於新系統;我們的一種情況是啓動了一系列步驟，並且集合中的某些步驟可能需要幾小時或幾天才能執行。我們需要在長時間完成這些步驟後執行其他步驟。「長跑路線」的駱駝構造是什麼？
我們還需要讓系統在重啓過程中存活下來，而這些步驟中的某些「路由」正在進行中，即系統可能會重新啓動，並且我們需要正在進行的「路由」保持其狀態並且拿起他們離開的地方。
我知道我們可以使用排隊消息傳遞系統，比如JMS，並且放入這樣一個隊列的消息可以被處理爲持久的。我不清楚駱駝是如何（或是否）） - 我們是否需要將每個隊列之後的步驟作爲自己的路線處理，以便在啓動時從隊列中讀取？這將把我們的處理步驟分解成比我們更多的「路線」，但也許這就是它的完成方式。
是/有駱駝構建/輔助這種系統的構造？如果我知道他們的術語和基本輪廓，我可能會想出來，但我真正需要的是對結構做什麼的解釋。
您指的是路由中消息的異步處理。駱駝有幾個組件可以用來實現這一點。
SEDA/JVM可用作JMS組件的低開銷替代品，並且在某些情況下，我會專門使用它們。在你的情況下，持久化元素是必需的，所以SEDA/JVM不是一種選擇，但爲了簡單起見，示例將使用SEDA，因爲你可以快速地獲得一些基礎知識並運行。
該示例將假設以下我們有一個計時器，它啓動，然後有兩個進程需要運行。參見下圖：
在此路由消息流是計時器和兩個過程之間豆同步。
如果我們想要使這些步驟異步，我們需要將每一步都分解成它自己的路線。然後，我們將使用開頭列出的其中一個組件連接這些路線。見下圖：
通知我們有三個路線，每條路線的路線只中有一個「處理」的步驟。路由測試只有一個定時器，它將消息發送到名爲processOne的SEDA隊列。該消息在SEDA隊列中收到併發送給Process_One bean。在此之後，它被髮送到稱爲processTwo的SEDA隊列，在那裏它被接收並傳遞給Process_Two bean。所有這些都是異步完成的。
一旦理解了概念，您就可以用JMS替換SEDA組件。我懷疑狀態跟蹤將成爲最複雜的部分，因爲Camel使異步部分變得簡單。
駱駝不是一個人類工作流程/持久的任務系統。對於那種看看BPMS系統。駱駝更適合實時/近實時的集成。
對於長期任務，您可以在消息代理或數據庫或BPMS等外部系統中持久保存其狀態，然後可以使用駱駝路由處理並從一個狀態轉移到下一個狀態 - 或駱駝適合的位置，如集成與許多不同的系統，你可以用200 +駱駝組件做OOTB。
駱駝提供優雅的關機，因此您可以安全地關閉或重新啓動駱駝。但是，如果發生崩潰的可能性不大，如果您正在談論倖存的系統崩潰，您可能需要查看交易和冪等性。