事務管理

Question

我們的客戶遵循SOA原則，並有設計的Web服務是非常細粒度像createCustomer，deleteCustomer等

我不知道如果細粒度的服務是可取的，因爲他們創造的事務有關的問題。例如，如果業務需求是每個客戶在創建時都必須有一個地址。因此，在這種情況下，表示組件首先調用createCustomer，然後調用createAddress。這些服務在內部使用簡單的JDBC來更新db中的相應表。由於服務是由外部組件調用的，因此它沒有辦法滿足事務性要求，即如果createAddress失敗，則createCustomer操作必須回滾。

我想，處理這個問題的方法之一是設計課程粒度服務（在單個JDBC事務中創建客戶和關聯地址）或者簡單地創建反向服務（deleteCustomer） createCustomer的行爲。

有什麼建議。謝謝

Answer 1

簡短的回答：服務的設計應該是爲了服務客戶端的方便。如果客戶被告知「打電話給這個，那麼不要忘記打電話給你」你讓他們的生活太難了。應該有一個粗粒度的服務。

一個長的答案：客戶可以合理地進入沒有地址？所以我們打電話

createCustomer(stuff but no address) 

並且結果是一個客戶的有效（如果可能不是理想的）狀態。稍後我們撥打

changeCustomerAddress (customerId, Address) 

現在持續的客戶更有用。

在這種情況下，API就好了。關鍵在於系統的完整性並不取決於客戶端代碼「記住」做些什麼，在這種情況下添加地址。但是，更有可能的是，我們不希望系統中沒有地址的客戶，在這種情況下，我認爲這是服務的責任，以確保發生這種情況，並給予主叫方錯誤發生的最少可能性。

我會看到粗粒度的createCompleteCustomer（）方法是迄今爲止最好的方法 - 這允許服務提供者一次解決問題，而不需要每個客戶端程序員實現邏輯。

替代品：

a）。有關原子事務的Web服務規範和主要供應商確實支持這些規範。原則上你實際上可以使用細粒度的方法和真正的事務來實現。實際上，當你沿着這條路線走下去時，我認爲你進入了一個複雜的世界。 b）。 @mtreit提到的有狀態接口（工作，工作，提交）。一般來說，有狀態會增加複雜性或阻礙可伸縮性。服務在哪裏保持中間狀態？如果在memeory中，那麼我們需要對特定服務實例進行關聯，並因此引入擴展和可靠性問題。如果在某些狀態或正在進行的數據庫中，那麼我們會有額外的實施複雜性。

Answer 2

如果需要事務性，可以在服務器上實現事務語義的粗粒度單一操作肯定會更容易實現。

這就是說，當然有可能構建一些方案，直到所有必要的細粒度操作成功爲止，操作的目標不會被提交。例如，執行一個Commit操作來檢查與服務器上的對象關聯的某個標誌;直到事務中的所有必要步驟都完成後才設置標誌，如果未設置標誌，則提交失敗。

當然，如果重量輕，細粒度的操作是重要的設計要求，那麼可能需要重新考慮具有事務性的需求。

Answer 3

好了，讓我們開始：

我們的客戶遵循SOA原則和 有設計的Web服務是非常 細粒像createCustomer， deleteCustomer等

沒有，客戶端已經忘記了達成SOA原則，並提出了大多數人的做法 - 界定不明確的泥潭。對於SOA原則，這個地區會走到一個更粗糙的界面（比如OData更新數據的機會主義），或者遵循過去25年中編寫的多層架構書籍的建議。對於CORBA發明的東西以及SOA管理員今天所做的所有錯誤，SOA只是另一個詞，10年前CORBA基本上出名的設計愚蠢。並不是說今天任何做SOA的人都聽說過CORBA。

我不知道如果細粒度服務 是可取的，因爲他們創造 事務有關的問題。

僅適用於不支持Web服務的用戶和平臺。認真。當然，如果您忽略了事務性問題 - 忽略編程中的事務性問題。這裏的訣竅是人們進一步發現食物鏈並非如此，只是你的客戶決定忽視常識（再次看到我對科爾巴的第一個評論）。

設計Web服務的人很清楚事務性問題，這就是爲什麼Web服務規範（WS *）實際上包含通過將提交操作移動到調用Web服務的客戶端來處理事務完整性的機制。您的客戶應該閱讀的特定規格是WS-Atomic。

如果您使用當前的技術來公開您的Web服務（也就是MS平臺上的WCF，類似的技術存在於Java世界中），那麼您可以向客戶端公開事務流信息並讓客戶端處理事務分界。這有它自己的份額問題 - 像客戶端保持交易惡意開放 - 但仍然是處理在客戶端定義的交易的唯一方式。

您給沒有平臺，只是提到java的，我指着你一些MS例子，如何能夠看： http://msdn.microsoft.com/en-us/library/ms752261.aspx

Web服務，在一般情況下，有很多更強大和更大量的深思熟慮比大多數人在做SOA時所想的要多。他們看到的大多數問題很久以前就已經解決了。但是，SOA只是多層架構的一個流行詞，但大多數人認爲這是自切片面包以來最偉大的事情，甚至不知道10年前的情況。

作爲您的客戶，我會更關心性能方面的問題。他定義的細粒度非語義Web服務對非偶然使用來說是一個性能問題，因爲您通過網絡訪問/更新小型小型小型網絡的次數會導致網絡延遲殺死您。在這種情況下創建類似於10件商品的訂單可能很容易需要30-40次網絡呼叫，這可能會花費很多時間。 SOA從一開始就宣揚（如果你忽略了那些不瞭解歷史的人的話），不要使用細粒度的調用，而是去粗略交換文檔和/或語義方法，就像OData系統一樣。