在大多數非平凡的SOA環境中，很難跟蹤系統之間不斷發展的集成，除非有明確的發布和查找適當信息的方法。 概述IT環境，定義當前或將要連接的內容，是維護環境的先決條件。 缺少這種情況通常會導致“面向意大利面條的環境”的感覺，并且不愿大膽嘗試。

這句話聽起來很明顯，但實際上并不總是考慮在內。 一些組織要么沒有這樣的集中式集成控制，要么因為“妨礙了一切”而停止使用它。 充其量，這意味著集成信息被保存在某些關鍵人物的頭上，這很冒險。 通常，在這樣的地方的團隊不敢“在某些情況下仍然依賴它們”更新服務合同，而是在需要更新時隨時復制它們，這與SOA相反。

有時，一個好主意只需要退后幾步即可正確應用。 我在這篇文章中解釋了為什么我認為對SOA路線圖的需求應能激發大多數Web服務（包括非敏感服務）上存在安全訪問限制。

為什么這么簡單的想法很難付諸實踐？

有幾個因素可以促使團隊跳過這一重要的文檔編制步驟：

• 其他重要的短期任務的緊迫性，以及團隊不斷地“撲滅大火”的感覺，沒有時間做其他事情
• 缺少明確標識的中央存儲庫，該存儲庫用于在何處訪問和發布此類信息（例如SOA注冊中心或存儲庫），或者缺乏對這些信息的使用。
• 缺乏集中式的管理，無法監督整合

從人為因素的角度來看，“我已經受夠了”綜合癥會使這種情況惡化。 在復雜的多團隊/多項目環境中，已經為眼前的問題所困擾的個人通常不會主動尋找其他項目難以解決（并解決）的依賴問題。 我們需要對此進行預測并積極幫助那些團隊，同時要記住，他們要處理的其他問題當然也很重要。

以上內容的核心根源是，在可能的情況下，更容易跳過集成的驗證/文檔步驟。 我們必須通過宣傳集中式集成信息的價值以及提高實現無證集成的難度來扭轉這種感覺。

我們需要的

我們需要一個易于使用的過程來收集，驗證和發布系統之間當前和將來的依賴關系。 一個關鍵方面是以“足夠的治理”方式使它保持簡單并與實際使用它的人保持聯系。

四個主要組成部分似乎是：

• 一個清晰的過程，用于請求新的集成或更新現有的集成。 這包括從業務和技術角度進行驗證，以確保環境保持盡可能清潔和面向未來。 如果執行了EA工作，那么大多數請求都來自EA團隊或來自EA團隊，這使得此步驟變得微不足道！ 在實踐中，當項目團隊在詳細的設計或實施階段確定所需的依賴關系時，也將來自項目團隊。
• 一個明確標識且易于訪問的存儲庫，可在其中查找當前和計劃中的集成。 該存儲庫必須包括每個未來依賴項的版本控制以及棄用/停用計劃。
• 負責更新中央存儲庫的團隊，使路線圖保持最新。 如果可以的話，通常是EA團隊。
• 在技??術層面上，如果不涉及上述三個組件，則無法執行集成。 這應避免在合同更新引發問題之前一直隱藏的“幻影依賴項”。

在實踐中，第四個組件應是企業范圍內的IT原則，該原則規定每個Web Service實現必須要求調用應用程序具有安全授權。 當服務需要時，這將不會阻止其他安全機制的存在，例如，傳輸帶有發起原始業務操作的人工用戶身份的票證（REST和SOAP都允許同時存在多個安全令牌）。

通常必須通過將技術文檔和代碼示例附加到IT原理上來簡化該原理的實現。 因為我們不希望同事之間互相攻擊，所以可以采取低風險的方法，其目的只是確保讓EA團隊更容易建立幻影依賴。 使用SOAP時，我的建議是使用簡單的WS-UsernameToken策略，并為每個客戶端應用程序關聯一個用戶名/密碼對。 使用REST時，一種眾所周知的機制是使用HMAC，將請求的一部分與隨機數和/或到期日期一起進行哈希處理（此機制類似于Amazon S3所使用的機制）。

結論

在本文中，我試圖解釋為什么我認為在每個Web服務中系統地采用一個簡單的安全策略有助于跟蹤IT狀況，并確保SOA治理團隊看不到“幻影依賴項”。 此安全策略的實施必須簡單易行，并得到幫助文檔的支持，并且不能過于強大，僅足以確保EA團隊了解所有集成實施。

參考：來自Svend博客的 JCG合作伙伴 Svend Vanderveken的Web服務安全性和SOA路線圖的人為因素 。