（網絡）服務依賴關係問題

比方說，我們有一個電子商務系統，它有兩個獨立的系統：庫存管理系統（IMS）和訂單管理系統（OMS）。假設IMS提供圍繞庫存的信息（getItem，getItemQuantities等），並且OMS提供訂購服務（startOrder，addItemToOrder，finalizeOrder等）（網絡）服務依賴關係問題

這兩個系統實現爲使用不同後端的Web服務。在OMS，假設像一個簡單的模型：

public class Order { 
    private int orderId; 
    private List LineItem; 
    ... 
} 

public class LineItem { 
    private int orderId; 
    private int itemId; 
    private int quantity; 
    private int subTotal; 
    .... 
}

在IMS中，假設像模特：

public class Category { 
    private int catId; 
    private List Item; 
    ... 
} 

public class Item { 
    private int itemId; 
    .... (other attributes) 
}

您可以輕鬆地找出一個簡單的數據庫表結構來實現上述。

作爲一個用例，考慮一個客戶端將一個項目添加到訂單中。此請求需要OMS進行多個服務/數據庫調用：

驗證orderId（可選，可將此責任傳遞給數據庫）。
呼叫到IMS，以驗證傳入的itemId存在（必填由於DIFF DB）
呼叫到IMS，以驗證庫存對傳入的數量（由於requred把分差DB）
插入新記錄插入到表（必填）

從性能的角度來看，這是否有意義？你能想出更好的方法嗎？

[編輯]：作爲後續，在用戶請求OMS訂單細節的情況下，只能返回訂單ID，並且每個含有的itemId，數量和小計orderLineItems的列表。客戶實際上也希望項目的名稱和描述。是通過IMS向客戶撤回名稱/描述還是由OMS負責？

來源

2009-09-11 djunforgetable

這可以在單個服務調用中完成，這可以使單個數據庫調用存儲過程。

來源

2009-09-11 00:47:32

這個問題表明這兩個系統是分開的。此外，使用存儲過程通過在數據庫層引入緊耦合來打破SOA的主要目標（儘管這不是問題中提到的問題）。 – 2009-09-11 01:00:55

我用一個存儲過程作爲如何在低級別實現數據層的例子，來反擊關於需要多個數據庫操作的建議。 – 2009-09-11 03:11:53

從perfromance的角度來看，我會這樣做

驗證orderId的服務。

一種名爲ValidatePlaceInDetails這確實既驗證傳入的itemId存在和驗證庫存對傳入的數量

一種用於將新記錄插入到表服務。

，我們通過合併2和3

來源

2009-09-13 02:56:59 shivaspk

因此，我們基本上將驗證直至訂單管理服務。你會實現圍繞執行驗證邏輯的方法調用的Aspects嗎？或者你認爲addItemToCart操作應該知道驗證要求嗎？我會傾向於後者，但我希望看到你（和其他人）的想法:) 但似乎在任何情況下，OMS實際上是一個*複合*網絡服務？ – djunforgetable 2009-09-14 21:30:02

我看到你所描述的系統，比一個事實，即它們是獨立的其他任何問題減少服務呼叫。

但是，如果我們想象，這不能被任何不同的做法和你擔心性能，你總是可以實現某種緩存，以減少數據庫查詢的數量和順序的全部內容存儲在緩存也是如此。緩存的問題在於，在您提交訂單時，需要執行一項新的更昂貴的數據庫操作，以檢查訂購商品是否實際存貨，或者只是丟棄不可用的商品。

對於可能的緩存解決方案，請看memcached。

來源

2009-09-16 19:06:05

他們分開的原因很簡單，只要oms失敗，商店就不會停下來。用戶仍然可以訪問該網站並瀏覽，只是無法做出任何訂單... – djunforgetable 2009-10-12 22:45:03

由於這是一個SOA問題，我很好奇你爲什麼要在你的應用程序和webservices之間創建如此強大的依賴關係。

爲什麼不使用ESB，現在有一些開源的ESB，它可以使您只需調用帶有訂單信息的ESB，並且響應將是錯誤或訂單號以及您需要的任何其他信息。

你抽象出所有其他的東西，因爲它是照顧我在ESB中的規則。

一個ESB我與實驗是：https://open-esb.dev.java.net/

的好處是，你可以換出web服務，數據庫或添加新的規則，而無需更改應用程序中的任何代碼。

如果您的應用程序已分發，這非常有用。

理想情況下，您可以提供一些服務質量要求，因此VIP的訂單可以比普通人更快，新用戶可以更快更快地完成前兩次，這樣他們可以看到有多快你的系統是。

在ESB中添加性能會受到影響，但有一些優勢，例如鬆散耦合，可以彌補這一點，因爲現在您已經與ESB Web服務的wsdl之外的任何更改隔離了。

來源

2009-09-22 00:10:29

我只會向IMS發出一個請求，請求檢查項目X是否實際存在。如果它不是一個有效的項目，IMS應返回一些結果代碼，說明我請求了一個無效的項目。這樣你就可以省去一次往返IMS的旅程。如果我請求的商品數量不足，我希望另一個結果代碼說明。

來源

2009-10-01 07:03:53

忘了SOA一會兒。

您有兩個獨立的系統和至少一個需要對它們進行一致更新的常見操作。

您不僅需要考慮檢查庫存，而且還需要考慮減少庫存，並且大概只有在訂單行的增加時纔是正確的。

你打算如何確保一致性？我們可以設計各種方法（2PC交易，或記錄保留，或補償交易，或樂觀的批量對賬工作），但在我看來SOA或不是Web服務，或者我們仍然不需要解決這些問題。

很明顯，爲了提高效率，我們希望減少系統部件之間通信的次數，以實現用水量功能。因此，已經提出了「檢查和做」的模式。然而，至少在其原始形式中，這樣的模式往往不適應失敗路徑。

這可能是最好的想出幾個短路。例如，當訂單行被添加時，我們實際上並不檢查庫存。（可能UI已經顯示了庫存，因此已經進行了比較近期的檢查）因此，我們在訂單最終放置時檢查庫存，然後告訴用戶「不能這樣做」或「您可能需要等待一兩個星期的一些點，你想繼續「。

隨着狡猾，我們可以使許多操作只更新一個後端系統的任何一個服務調用。

來源

2009-10-16 16:27:02 djna

（網絡）服務依賴關係問題

回答

相關問題