關鍵字：soa 可訪問性。如果有數百個服務，則需要定義一個可靠的方法，以便客戶找到正確的服務并知道如何有效地使用這些服務。我通常不建議在初始 SOA 期間采用注冊中心或統一描述、發現和集成（Universal Description, Discovery, and Integration，UDDI）。確定開始使用注冊中心的合適門檻是 50 個服務。并沒有所謂“神奇”的數字，也沒有用于選擇哪個數字的基本原則，這需要您自己做出決定。
功能。由于構建的服務較多，因此務必對每個服務的功能進行分析。確保功能重合盡可能少。例如，正在構建的新服務是否可通過對現有服務進行組合得到？此服務是否真的是新服務，或者僅是某個現有服務的不同變體？
交互。此時您可能并不知道自己對哪些東西不了解。您無法預測別人會如何（使用何種技術）、何時、何地或為什么使用某個特定的服務。必須對您的服務交互進行仔細考慮，且必須最大限度地遵循各項標準。
信息。無論服務數量如何，這個領域都不會發生改變。只要記住，在服務增多的情況下，必須對通過其中的信息量加以管理。對公共詞匯的使用就變得非常重要了，您需要開始考慮能夠定義和采用的現有 XML 標準或新標準。
流程。您組織中的 50、100 或 200 個服務如何一起工作？這些流程如何更改，這些更改如何影響每個流程？
這些方面仍然適用于您將作為企業 SOA 的一部分推出的每個服務。不過，您需要在每種情況下考慮的事情的定義擴大了。本文指出了您需要捕獲的其他信息——這并不能替代您在前一部分捕獲的每個類別的信息。
企業 SOA 的其他需求
需要為真正的企業 SOA 收集哪些其他信息？請記住，企業 SOA 的概念著眼于“變化”。使用 SOA 的基本業務需求是支持業務敏捷性——也稱為變化。開始收集這些需求時需明白一點，即沒有人真正知道正確答案是什么。您需要為每個需求類別中的變化做出計劃。成功的企業 SOA 始終處于不斷變化的狀態——它在不斷發展，持續支持隨時可能出現的改變。
此類需求的高級類別包括：
編排�，F在已經從有少量與其他應用程序交互的狀態過渡到了擁有與自己或其他企業構建的服務進行交互的服務的狀態。這些服務之間的編排或建模至關重要。作為需求的一部分，您需要對這些交互進行一些假設，并針對其進行一定的計劃。務必記錄每個服務的異步交互、服務版本控制和退役計劃等等。
安全。毫無疑問存在安全顧慮。確保您從 SOA 服務的角度認真地對待安全性問題。哪些人能夠訪問哪些服務？哪些人能夠訪問每個服務中的哪些數據？在服務間傳遞服務時，如何保護數據的安全？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
