關鍵字：soa 簡介
當今的企業都希望將 SOA 作為一種公開其應用程序和數據以便于用戶使用的方法。通過采用 SOA，企業資產（例如，業務流程應用程序或后端系統）可以由在這些資產公開的服務上構建的各種解決方案/應用程序使用。在這里，您可以將企業視為一組公開數據集或功能集并在其后封裝業務邏輯的服務。
現在，使用現有開發工具在這些服務上構建解決方案非常容易。通過使用 SOAP 或 WSDL 之類的標準，不同的供應商可以提供在這些服務上進行公開和開發的工具。
當企業開發了一些解決方案之后，問題就開始暴露出來。以下是一些最常見的問題：
解決方案只能使用一次。它們只能與一個或一組預先定義的服務進行通信，并且解決方案本身難以重用。更改服務后需要重新構建/重新部署解決方案。
對服務所公開的內容的理解取決于人們的想法，而不是服務定義本身。當前的標準只涵蓋了如何獲得那些服務。
很難將不同的服務集合在一起。既沒有預先定義的聚合機制，也沒有關于一個服務如何與另一個服務相聯系（服務彼此之間不了解）的定義。
按照大多數常見的用戶標準來說，解決方案 UI 難以實現，而且通常很槽糕（除非進行巨額投資）。這是因為難以在一次性解決方案中模擬當前的應用程序 UI。
大多數用戶都相當熟悉 Office 套件（Word、Excel、Outlook 等）之類的應用程序，但是當設計出一個新的應用程序/解決方案后，需要對他們進行培訓，從而增加了此類部署的成本。
由于上述原因，我們需要一個在現有服務之上構建解決方案的更好的機制。
元數據方法目前，Web 服務公開了許多有關如何使用服務的信息，但在說明提供了哪種類型的信息或功能方面，卻提供了非常少的幫助。Web 服務通常會公開 WSDL，因此工具可以輕松地查明 Web 服務公開了哪些方法和參數，但是，至于在那些方法后定義了哪些業務實體、甚至這些方法可能會影響后端系統等方面，卻提供了非常少的提示（例如，不會告知某個方法將更新后端系統）�？雌饋�，WSDL 似乎不能充分表示當今服務所公開的內容。
我們推薦一組新的元數據，它可以與某個服務相關聯，并說明該服務的用戶（解決方案開發人員）將需要了解的內容。在這個新的元數據中，我們將公開以下概念：
實體 — 將封裝一組數據或功能的抽象業務或用戶定義。例如，我們可以有一個客戶實體。
視圖 — 與某個實體相關聯的架構，它描述有關該實體的數據子集。例如，對于客戶實體，我們可以擁有多個視圖，例如，客戶聯系信息或客戶財務信息。每個視圖都符合特定的架構，它是給定上下文的實體表示形式。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/