SOA服務分離

Question

我希望編寫一些Web服務。

什么定義了一個“服務”單元。 我注意到，作為一個項目的一部分，您可以有多個.svc服務文件。

您通常如何細分服務？ 例如，銀行應用程序：

您是否需要一項服務（.svc）？

• 客戶
  • AddClient（客戶newClient）
  • DeleteClient（客戶端客戶端）
• 帳戶
  • SetName（字符串名稱）
  • SetType（AccountType類型）
• 傳遞
  • SendMoney（客戶客戶端等）
  • ReceiveMoney（客戶客戶端等）
• 房屋貸款
  • AddNewHomeLoan（）;
  • 刪除房屋貸款

有沒有將實體分組的方法？ 例如，代替接收轉賬服務，您可以在帳戶服務中放入發送和接收資金，因為您可以接收和發送帳戶。

這也帶來了關於方法和參數的另一個問題。 如果我想添加一個編輯客戶端，通常會添加一個諸如EditClient（Client client，Client newClient）之類的方法，然后用另一個客戶端對象替換整個客戶端嗎？ 還是您將添加用於編輯客戶端的單獨方法，例如：客戶端服務下的EditName（客戶端客戶端，字符串名稱）？

我想適當地列出適合我的Web服務的運營合同。

Answer 1

在設計Web服務時，我需要遵循一些粗略的規則，尤其是對於公開​​（某些定義的組之外的應用程序/用戶可能會使用這些服務）的公開服務。

1. 最大工作單元：Web服務（實際上是任何RPC服務）是在單獨的（通常）機器上運行的另一軟件，即使在同一機器上對其進行調用（與本地函數調用不同）也要花錢。 請牢記這一點，並構建可能接受盡可能多的數據的功能。 不要依賴服務器之間的往返來通信和完成業務運營單元。 例如，沒有流程“創建帳戶”需要調用“添加用戶”，“創建帳戶”，“將用戶與帳戶關聯”，“更新用戶詳細信息”，“激活帳戶”來完成該過程。 而是具有一個“ createUserWithAccount”函數來完成一次操作。
2. 最小的等待時間：請記住這些服務稱為內聯，如果您的進程花了很長時間使進程被殺死，則是由不耐煩的用戶，介於兩者之間的服務或假設錯誤的看門狗進程。 您可能會考慮選擇返回“票證”的服務，以便呼叫者隨后可以檢查。 在大多數情況下，這並非絕對必要，但是對於可能需要一分鍾以上運行的流程，您可能需要這種方法
3. 定義明確的接口：確保您的服務定義明確，最好鍵入不可知的定義。 與類型無關的定義為確保您使用易於通信的通用類型，並且對客戶端實現者幾乎沒有意外副作用的可能性。 許多人喜歡使用XML作為消息傳輸的基礎，並將所有細節隱藏在其中。
4. 計划變更：服務已經存在很長時間（通過設計），並且同時暴露給外部實施者。 這意味着他們將需要進行更改，但是客戶要求可能會阻止您輕松進行更改。 構建界面時，請考慮使用版本控制或使用傳輸編碼（例如XML），這些編碼可讓您修改傳輸的數據而無需修改調用接口。 查看API（例如Windows API）如何處理此問題，以獲取有關如何解決問題的一些想法。
5. 安全性是一流的設計目標： 任何人都可以調用服務接口。 您必須期望它們會被各種用戶調用，這些用戶可能已通過或未通過身份驗證，並且可能會或可能不會具有惡意。 計划將安全性安排在適當的位置，而不是僅依靠一種機制來驗證所有內容都是安全的。 有幾種方法可以解決安全問題，如果內部使用您的服務，您可以放輕松一些，但是對於公共服務，您需要考慮安全的工作方式，並確保安全在所有服務中保持一致。

希望能有所幫助。

• 這些是從福勒等人那里獲得的一般策略。 這只是我對應如何處理的看法。

Answer 2

我建議閱讀Martin Fowler的《企業體系結構模式》 。 這應該為面向服務的軟件提供許多組織策略。

Answer 3

我更喜歡按功能而不是結構分開服務。 該技術在Eric Evans的“ 域驅動設計”中進行了深入討論。 造成這種變化的因素之一是變化率。 功能區域傾向於以相似的速度變化。

結構性（不良）：

• 客戶
• 帳戶
• 貸款

功能性（良好）：

• 開票
• 供應
• 貸款批准

Answer 4

除了GrayWizardx的出色回答，我還要再說一點。

嘗試將所有服務定義保持在功能/業務級別。 服務名稱應具有良好的高級“ ChangeDeliveryAddress”，“ QueryOrderStatus”類型名稱，並且接口定義本身應僅包含業務實體和最少數量的“技術”字段。 即接口與實現完全分離。

如果發現使用“ NextOrderLineWithinPage”之類的服務，則可能是您的設計出了點問題。