ColdFusion中的SOA風格架構？

Question

公司內部系統的後端變得越來越複雜，我想探討一下做SOA架構而不是沉重的單片系統的想法。我應該從哪裏開始？

我是SOA新手。這是否意味着...個別CF實例，並且他們通過遠程Web服務調用彼此通信？如何處理諸如錯誤處理和服務器停機之類的事情？如果ESB的每個部分都在ColdFusion中，ESB是否會對架構有利？

數據庫層怎麼樣？他們應該共享一個龐大的數據庫還是應該以自己的方式存儲事物？

謝謝

Answer 1

首先，你想完成什麼？對於需要相對容易地更改並且可供新程序員訪問的系統，SOA非常有用。另一方面，由於最終會分離持久性 - 因此它的交互發生在應用程序服務器上而不是數據庫中，因此您往往會有性能折衷。通常情況下，這種性能權衡是不成問題的，但如果您正在開發一個高通過事務處理系統，則可能需要通過在數據庫中放入一些算法並使這些算法違反服務細分來妥協。

所以，如果你想要的好處和不是特別關心的利弊，通過讀取話題一些適用的書籍開始：

• Martin Fowler的Patterns of Enterprise Application Architecture - 特別講究Service Layer模式
• Domain Driven Design Quickly這是一本縮寫爲「很快」的相同名稱（不必要的IMO）較長的書的精簡版本，它幫助您思考如何定義服務和每個對象層次下的對象層次結構。

你想要的趨勢是具有高級服務對象的設計，其關係通過dependency injection到service locator容器進行管理。在ColdFusion的案例ColdSpring就是一個例子。這允許object mocking，所以你可以輕鬆地進行單元測試。例如，如果這些服務存在於其他服務器上，那麼本地服務對象是作爲依賴關係被傳入的代理服務器。爲了測試這些代理被嘲笑，所以他們不必與遠程服務器通話。

關於錯誤處理和服務器停機。我假設你主要關心處理本地服務器控制之外的問題。這是使用服務代理對象的另一個原因。有沒有這個對象負責處理超時，錯誤的響應值等 - 實際上是一個anti corruption layer。

至於數據庫共享，我會構建我的表關係來反映我的服務對象關係。所以如果有問題的表有數據只通過服務相關，我不會執行任何外鍵約束。所以雖然他們可以在同一個數據庫中，但並不重要。這使您可以在其他地方移動這些服務和數據庫表，而對代碼進行相對較少的更改。

Answer 2

我聽說過SOA用來形容很多不同的設置窗口期限，所以我不知道是否有一個「正確」的答案，但核心概念是服務層。最大的好處是對於最後一個關於數據庫層的問題的答案是 - 以上都是。一旦處理存儲/持久性的邏輯被隔離在服務層中，並且應用程序調用此層，則將某些數據移動到其他服務器或在需要時將其整合到一個服務器中變得更容易。您甚至可能最終只會調用其他服務，通常稱爲service facade。

以「現實生活」爲例。假設你有一些客戶數據庫，你可以在其中存儲姓名，地址，電子郵件等等。你將這個數據庫公開爲一個Web服務，你可以獲得關於一個人的信息。在某個時候，你出去成長這個家庭釀造系統，並決定授權一個完整的CRM系統。由於您已將Web服務中所有與客戶相關的交易隔離開來，因此您只需更新該服務即可從CRM軟件而不是數據庫中獲取信息。這真是服務架構真正閃耀的地方。就錯誤處理而言，如果您的應用程序和服務全部用CF編寫，那麼您將在兩個（或所有）層上進行日誌記錄和錯誤處理。很明顯，服務器服務器的服務器中斷會非常嚴重，因爲它會影響到服務器上的所有內容。如果超時或開始南下，我們會使用監視器發送電子郵件到服務檯。在客戶端應用程序中，我發現的關鍵是爲Web服務調用設置合理的超時時間。我從來沒有見過使用ESB，但我猜測它會給你另一層抽象來管理實際的調用。這可能有助於超時等，但我不能說真的。