讓我們打破這種下來,到各個部件:
發件人應用 - 這是一個需要與設備進行通信的服務。
設備控制器 - 這是與硬件設備對話的應用程序。
代理 - 這就是你在Mule ESB上開發的東西。它將連接到發件人應用程序和設備控制器並將請求從發件人傳輸到控制器;然後將結果從控制器發送回發件人。
流量會是這個樣子:
- 發件人應用程序需要與設備進行通信。
- 發件人應用程序使用JSON傳輸信息。
- 代理收到此JSON請求。
- 然後代理通過HTTP聯繫設備控制器。
- 設備控制器僅與代理進行通信,並根據物理設備的結果返回0或1的結果。
- 然後,代理需要將此結果傳送給發件人應用程序。
首先,您可能會想到通過HTTP開發您的Proxy(使用HTTP Connector)。該連接器創建一個Web服務端點(基本上是一個網站),可以監聽並響應請求。
發件人應用程序通過HTTP連接到此端點並提交包含要執行的命令的JSON文檔。
您的代理然後立即聯繫設備控制器(再次通過HTTP使用相同的連接器)。
設備控制器與設備對話,然後將響應返回給您的代理服務器(通過HTTP)。
您將此響應發送回原始HTTP請求(來自發件人應用程序)。
這裏的問題是,如果有您的連接和設備控制器之間(設備控制器和物理設備或)任何延遲,連接,解除封鎖兩側(因爲你需要發送一個響應)。
如果存在很大的延遲,代理和發件人應用程序之間的HTTP連接可能會終止。
這是一樣的,當一些網站超載,並沒有迴應 - 最終瀏覽器將超時。
爲避免出現這種情況,請將您的集成拆分爲三個單獨的流程。
第一個流程將創建一個正常的HTTP連接,發件人應用程序將上傳JSON文檔。它將採用JSON文件並使用batch module(注意:僅在企業版中提供 - 對於CE版本,您必須自己編寫此邏輯)將每個條目轉換爲消息。接下來,把這條信息放在一個單獨的隊列中。將此消息的唯一標識作爲JSON響應返回給發件人應用程序。
您的第二個流程正在偵聽此隊列,每當有消息到達時,它都會連接到設備控制器並獲取響應。然後將響應寫入另一個隊列。
您的第三個流和最終流偵聽此結果隊列,將此隊列上的每條消息都轉換爲JSON/XML。然後它有一個HTTP連接器,可以查詢每個命令的結果。
在上面的設置中,您的發件人應用程序可以刪除要執行的命令的大JSON文件;對於每個命令,唯一的ID將返回給發件人應用程序。
然後它將查詢結果端點(您最後一次流程公開的內容)並將其發送給消息ID。然後結果端點將檢查此請求的狀態並用適當的代碼進行響應。
這裏是如何做到這一點的工作(從查看發件人應用的點)的一個例子:
我是輸入你的流量,Ø是發送的處理結果。
第1步 - 爲發送命令的請求被執行:
I: Sender Application > http://localhost:8080/input-commands?device=1&command=Y
O: <command><req-status>OK</req-status><id>1234-123</id></command>
第2步 - 查詢結果:
I: Sender Application > http://localhost:8080/result?id=1234-123
O: <command><id>1234-123</id><result>0</result></command>
非常感謝你爲你清晰和完整的答案。 – Rajeun 2015-03-31 12:10:36