服務保管員

讓我們想像一個美好的 SOA 幸福世界，其中企業的運算需求被分割成許多小型應用程式，這些應用程式彼此提供服務，以實現有效的協作。某個美好的早晨，消費者服務需要從供應商服務取得一些資訊。問題在於，儘管供應商服務擁有取得此資訊所需的資料和處理邏輯，但它尚未透過服務介面公開該資訊。供應商有一個潛在的服務，但它實際上還不存在。

在一個理想的世界中，消費者服務的開發人員只需要求供應商服務開發潛在服務，一切就大功告成了。但現實並非如此理想——這裡的關鍵問題在於，供應商服務的開發人員有其他事情要做，通常這些事情對他們的客戶和管理階層來說比協助消費者服務團隊更重要。

最近我與我的同事 Erik Dörnenburg 聊天，他告訴我他看到一位客戶使用一種方法來處理這個問題。他們從開源手冊中汲取靈感，並將他們所有的服務轉變為內部開源系統。這讓消費者服務開發人員可以自行撰寫服務。

我確信許多讀者看到這可能會對由此產生的混亂景象感到無奈，但就像開源專案並非允許任何人都可以編輯任何內容一樣，這個客戶使用開源風格的控制機制。特別是，每項服務都有幾個保管員——負責讓服務保持健康狀態的人員。在正常情況下，消費者開發人員實際上不會直接提交變更到供應商原始碼樹，而是會將修補程式傳送給保管員。就像開源維護者一樣，保管員會收到修補程式並審查它，以查看它是否足夠好可以提交。如果不行，就會與消費者開發人員進行對話。

正如 Erik 從 他自己的開放原始碼工作 中所熟知，審閱一個修補程式比自己進行變更要輕鬆許多。因此，儘管保管人方法並未完全消除消費者開發人員需要等待供應商開發人員的問題，但它確實大幅降低了難度。並且再次遵循開放原始碼模型，一旦保管人感到滿意，消費者開發人員便可以成為提交者。這仍然表示提交可以由保管人審閱，但可以避免保管人成為瓶頸。

與此相關的是他們對服務登錄檔的方法。我們已經看到許多精緻的產品被銷售，以提供服務登錄檔功能，以便人們可以查詢服務並了解如何使用它們。此客戶捨棄了這些產品，而改用 HumaneRegistry。

於 2012 年 5 月 24 日重新發布