SOA架構
下圖顯示了SOA參考架構，其中包括Web應用層、服務層、應用層和基礎架構層。
2.3.1 Web 應用層
此層的主要要求是所有業務系統和解決方案都可從任何支持的瀏覽器中訪問。這一層是用戶界面或
者表示層，包含企業基礎架構服務和應用程序等組件的業務邏輯。
2.3.1.1 打包的應用程序
通常情況下，企業會批准滿足其大多數業務要求的最佳的打包應用程序，然後讓IT組織和系統集成
人員對打包的應用程序進行處理以便滿足其需要。此類打包的應用程序的示例包括客戶關係管理、
企業資源計劃或特定行業的成套應用系統。
現在大多數打包的應用程序都是基於Internet協議的，這意味着用戶可以使用任何支持的瀏覽器訪問
許多功能。有些最新應用程序可以將有限的功能組作爲離散的協作服務或外部控制的業務流程公開。
利用打包的應用程序的最佳實踐包括：
_ 限制自定義開發的數量，使得維護和升級簡單廉價
_ 嘗試獲得世界級的標準實現，從而減少集成和維護成本
_ 在可能的情況下使用打包的應用程序提供的UI和業務流程
_ 利用發佈的應用程序編程接口（API）而不是直接訪問數據庫。
下面是在SOA成熟度模型中採用打包的應用程序的規定方法：
2.3.1.1.1 開發Web 應用程序
_ 部署可由任何瀏覽器訪問的應用程序的最新版本；最好是支持適當的門戶標準（如WSRP）的
版本。
_ 公開供自定義應用程序使用的應用程序服務，最好是作爲Web服務。這可能要求適配器允許訪
問應用程序。應用程序的一些最近版本能夠通過集成網關或Web服務直接訪問應用程序服務。
_ 通過合併企業外觀（模板、皮膚、骨架和CSS）以及集成企業單點登錄解決方案以提供完美的
用戶體驗。
_ 通過集成到企業標識和存取管理程序（通常是LDAP）將身份驗證具體化。
2.3.1.1.2 開發複合應用程序
_ 標識可以作爲複合應用程序在企業之間共享的業務對象
_ 將事件通知（觸發器）發送到複合應用程序以啓動特定操作
_ 修改業務流程和用戶界面以啓用複合應用程序
_ 公開附加業務服務以便複合應用程序能夠與打包的應用程序同步。
2.3.1.1.3 自動化業務流程
_ 瞭解並建模業務流程以便標識重構機會
_ 標識業務流程中可由業務流程引擎自動化的可重用部分
_ 擴展公開的服務和業務流程的數目
_ 減少和合並部署的應用程序的數目。
2.3.1.2 自定義應用程序
組織可以選擇開發自定義應用程序以創建獨一無二的品牌併爲客戶和合作伙伴提供獨特的體驗。這
要求爲內部和外部用戶提供一致的完美接口。公司通常傾向於開發自定義應用程序，而不是對打包
的應用程序進行自定義，因爲：
_ 修改核心事務的用戶導航和用戶界面並非易事
_ 大多數主要的打包應用程序並非基於公開的或標準技術，無法對其性能進行調整以適應業務需
要
_ 專有開發模型使查找資源或快速部署新業務功能變得困難
_ 與其他技術的集成不太容易實現，導致點對點的集成或者數據質量低下。
自定義應用程序的開發具有如下三個選項：
1、在應用程序服務器上開發和部署自定義應用程序
2、利用門戶開發和部署自定義應用程序
3、使用基於開放標準的工具或者專用開發工具開發強大的客戶端。
對於選項1和2，IT組織的第一個步驟是確定開發自定義應用程序的方法、基礎架構和工具。此外，
IT組織需要定義治理和組織模型以便開發自定義解決方案。
對於選項3，強大的客戶端自定義應用程序通常是使用SWING、Visual Studio或類似工具開發的。
這些強大客戶端中的大多數都需要與一些外部系統相連接，建議的方法是利用開發標準（如SOAP、
Web服務、XMPP或WebDAV），而不是直接訪問外部資源。此方法使得IT組織可以方便地支持和
升級集成。
2.3.1.2.1 自定義應用程序業務需求
大多數企業都已經部署了外部站點以及多個內部站點和應用程序，以支持各個業務單位的不同需要。
第一個步驟是在企業之間標準化這些站點的外觀和基礎架構，使得客戶、合作伙伴或員工可以比較
方便地獲得他們要查找的信息。
此階段的業務要求包括：
_ 統一外部站點上的用戶體驗，使得潛在用戶、合作伙伴、客戶和分析人員能夠方便地找到他們
想要查找的信息
_ 跨所有內部和外部站點標準化外觀，並標準化發佈內容的過程和流程
_ 爲所有員工、承包商、合作伙伴和客戶創建一個my<company name>站點以便提供個性化的服
務和內容
_ 提供的所有內部和外部站點的保密信息的安全訪問
_ 提供具有高可靠性、可用性和可伸縮性的環境
_ 通過公共門戶幫助銘記（branding）和訪問多個應用程序
_ 允許用戶在登錄一次後訪問所有服務
_ 基於用戶的角色和責任提供個性化服務
_ 通過平臺或環境的標準化降低維護多個系統和應用程序的維護成本
_ 標準化外觀以消除多種用戶培訓要求
_ 降低操作和支持成本，允許IT將稀缺的資源部署在開發新功能上。
2.3.1.2.2 自定義應用程序架構方法
由於門戶提供了一組經驗證的功能來支持表示層，大多數IT組織已經開始標準化門戶以便開發自定
義應用程序。
這個建議的架構具有以下優點：
_ 遵循SOA原則以提高各個級別的重用性
_ 提供在數週內而不是數月內提供產品或服務的能力（當具有了穩定的框架時）
_ 將產品用在它最擅長的領域，例如，使用門戶進行基於權限的演示
_ 允許業務將服務組合起來以便提供新功能
_ 在域層提取數據源和相互關係，從而將更改源系統的影響降到最小
_ 使用鬆耦合的表示和業務邏輯使其更可靠，更可伸縮。
擬用結構中的每一個層都扮演着特定的角色：
表示層：“門戶”負責處理所有表示服務。Portlet可促進用戶體驗的提升，其中portlet充當應用程序
的一個視圖。
業務委派層：業務委派層是負責表示層和業務層之間的通信的組件。它們可提取訪問業務層時所包
含的通信細則和複雜性。此層包括一個模型視圖控制器框架，可幫助用戶瀏覽網站。
服務層：服務層包含應用程序服務器的功能。該層由公開高級業務功能性的無狀態功能組成。它具
有一個會話表面，這是到業務層的入口點，可提取處理來自表示層的細粒度業務實體的詳細信息。
大多數業務邏輯都可以直接在會話表面或應用程序對象的子層上實現。
域層：域層也使用核心應用程序服務器。它是定義一致業務概念的業務實體集合。由於這些組件表
示不變狀態，此層中需要使用處理數據庫存儲的技術。Entity Bean可用於實現對象模型的一些組件。
或者，簡單傳統Java對象（POJO）在數據訪問對象（DAO）的幫助下提供一致性。Entity Bean是
實現此層的最佳機制，但是，如果對象模型比較複雜，則需要將此技術進行組合。
2.3.1.2.3 自定義應用程序框架組件
自定義應用程序框架組件可擴展應用程序服務平臺中固有的服務。框架組件包括：
數據服務：爲應用程序提供的持久層。容器管理足夠健壯，可以利用CMP完成大多數簡單的事務，
但作爲處理複雜事務的選則應該提供DAO。
記錄服務：應用程序用來記錄和跟蹤錯誤和活動的服務。要記錄的消息類型包括要跟蹤爲進行診斷
而記錄的所有問題、錯誤或故障以及爲審計跟蹤和用法分析而記錄的活動的調試消息。每個企業都
應該標準化應用程序使用的記錄服務，最理想的是利用JDK 1.4提供的功能。如果記錄服務在整個企
業都一致，則允許工作人員更有效地確定性能或事務瓶頸。記錄服務應標準化機制，使其與企業內
的整個開發社區進行通信，並確保與標準的兼容。不需要爲此服務開發特定代碼。
異常處理：管理和傳達異常的機制。它與記錄服務的類似之處在於團隊應該利用標準應用程序服務
器功能。團隊需要確定使用哪個機制並傳達給企業內的整個開發社區。無需爲此服務開發特定代碼，
但如果團隊提供了處理異常的示例的話也會十分有用。
部署/應用程序配置：記錄配置詳細信息的文檔。這涉及標準化在各種環境下構建和部署應用程序的
機制，包括開發、QA、UAT、階段劃分和生產。
監控：監控過程的標準化和文檔記錄。由於操作人員必須監控平臺和應用程序並預測性地解決問題，
IT內的大多數部門都已經標識和部署了監控工具。問題在於要標準化並集成監控過程和技術，以確
保所有系統中的數據的一致性。企業可能需要購買或開發並部署附加的專業監控工具。
搜索框架：搜索數據的共享功能。大多數門戶應用程序都需要以表格形式向用戶顯示數據。團隊不
應讓每個開發人員都試圖解決此問題，而應開發一個可應用於全部應用程序和門戶的“搜索框架”。
下圖演示了一個用作搜索框架的基礎架構。
搜索框架提供：
_ 基於用戶輸入的動態查詢生成
_ 排序次序、合併，等等
_ 用於顯示的全部搜索結果
_ 一致的搜索處理機制
_ 字符轉義和通配符解釋
_ 標記頁數
_ 從應用程序提取所有數據庫訪問代碼
_ 用作輸入的標準
_ java.util.List 等標準中需要的搜索結果
_ 外部文件上的查詢
_ 處理公共UI任務的實用程序
_ 標記頁數
_ 標準一致性。
通知框架：到所有應用程序的單個通知客戶端。它應該支持到通知引擎的同步和異步接口，還應提
供通過多個通道發送通知的能力。
到不同通道的接口應該根據業務要求進行開發。
服務代理框架：提取服務實現詳細信息。團隊可在本地或遠程部署服務，而不一定要使用服務的實
現詳細信息或位置對調用應用程序進行編程。相反，服務定位器會確定服務的位置並通過合適的方
式進行調用。這支持多種代理，例如EJB、Web服務和服務總線代理；也可根據要求開發附加代理
類型。這也可由業務委派層用於將表示層從服務層分離開來。
安全框架：提供安全功能的企業級層。由於當前企業安全解決方案無法滿足他們全部的業務需要，
大多數應用程序項目團隊都開發了自己的安全層。支持客戶端的安全框架可減少（如果不能消除）
爲每個應用程序開發自定義安全代碼的需要。下面是安全框架應該提供的一些功能：
_ 單點登錄（SSO）：登錄一次後無需再次登錄就可以在應用程序之間來回切換的功能
_ 訪問控制：用於三個主要領域的一組安全功能：
_ 身份驗證：確定與應用程序交互的用戶的身份
_ 授權：確定用戶是否允許執行特定操作
_ 審計：跟蹤用戶執行的操作。
此外還需要幾個輔助業務，例如註冊、權限授予以及權限查詢。這些功能應作爲可由不同的應用程
序使用和重用的一般框架提供，每個功能都具有稍有不同的需要，但其基本要求都相同，包括：
_ 身份管理：具有多個用於管理一組應用程序或服務的訪問控制信息的存儲區可能會導致嚴重的
管理問題。身份管理可通過集中訪問控制管理功能以及跨企業供應用戶提供幫助。
_ 整合用戶配置文件：門戶提供這個功能的目的是允許應用程序擴展基本配置文件。此功能從多
個數據源提取用戶配置文件，例如從應用程序特定的儲存庫提取基本配置文件和應用程序特定
的配置文件。
_ 註冊、委派管理、供應和儲存庫：這些都是在訪問控制頂部構建的，用於滿足應用程序特定的
業務需要的安全擴展功能。或者，也可能是與訪問控制集成的打包的解決方案。
門戶產品可提供這些非自有功能的一大部分。如果不具有自己的開發自定義應用程序的門戶，IT組
織將必須開發和支持此功能。
2.3.1.3 門戶服務
門戶服務管理應用程序的表示層。表示層通常都是基於權限的，因此需要支持此功能。
表示：門戶表示功能爲每個應用程序組提供外觀、模板、構架和樣式表。它還包括一些示例應用程
序，來幫助開始開發和利用門戶導航功能，包括用於垂直導航條和水平選項卡。
個性化：門戶提供個性化服務，例如portlet佈局和背景模板選擇。本文將在“企業安全”的配置文
件管理部分介紹應用程序環境下的附加個性化。
身份驗證：所有門戶產品都提供此功能。最佳實踐就是使這項服務具體化。大多數企業都在其內部
實現了全局目錄服務（如LDAP）。自定義應用程序框架應提供一個身份驗證界面並使服務具體化。
單點登錄（SSO）： ）： 企業應該不需要多次登錄就能提供完美的用戶體驗。此框架組件不僅要支持自
定義應用程序，還應該支持打包的應用程序和企業服務。
2.3.1.4 企業基礎架構服務
這些是基於應用程序的服務，該服務可供整個外部和內部用戶羣使用。大多數企業服務都是基礎架
構組件，用戶可將其中的一些組件提供的功能作爲應用程序使用。下面是企業服務的一些示例。
目錄服務：這是在全企業範圍內提供的標準目錄服務，通常與電子郵件服務結合使用。大多數企業
都實現了元目錄，以便跨企業管理身份。
個人信息管理：這是標準的電子郵件、日曆和地址簿功能，其中包括從任何通道訪問這些信息的功
能。
協作：這提供了白板、電話會議、即時消息傳遞、論壇、新聞組和工作區等功能。
企業內容管理系統：這是驅動自定義應用程序如知識管理、資產或合同管理以及協作的基礎架構服
務。規定方法是利用門戶或內容管理提供商提供的API。所有領先的內容管理系統都提供了開發用於
上傳和編寫內容的模板以及用於管理批准流程的工作流的功能。
下面是實現企業內容管理系統的最佳實踐：
_ 首先定義分類信息，理想情況是創建企業級分類信息。
_ 創建單個文件基礎或儲存庫或企業級基礎。這可能不太實用，但想法很好。
_ 將所有內容發佈到生產環境中的單個位置，並將所有應用程序配置爲從該位置檢索內容，以便
降低TCO。
_ 培訓作者和內容審批人以使用該系統。
_ 通過讓提供商的架構師參與每個項目 與內容管理系統提供商緊密合作，尤其是在項目的設計階
段。
_ 利用預先構建的portlet編寫、審查和管理內容。
_ 在SI或內容管理系統（CMS）提供商的專業人員的幫助下將業務流程映射到CMS工作流。
搜索服務：這就使得所有外部或內部用戶都可以找到他們有權訪問的信息。存在多個搜索解決方案：
1. 關鍵字搜索，大多數用戶都習慣的標準搜索功能
2. 自然語言搜索，通常用於剛剛使用該技術，想要通過使用自己當地的語言詢問問題來查找
信息的非技術用戶或Internet用戶
3. 聯合搜索，允許搜索結構化和非結構化的數據類型。
搜索引擎的集成非常簡單直觀。搜索引擎按請求的順序處理XML或HTTP請求並返回結果。
搜索引擎與內容管理系統緊密協作。下面是最大程度地利用搜索引擎的一些最佳實踐。
_ 爲內容管理系統創建企業級分類信息。
_ 爲內容定義元標記，並將其用於門戶以便根據用戶權限向用戶顯示內容
_ 使用搜索引擎根據需要crawl和創建多個集合和子集合
_ 根據需要在不同業務單位之間進行聯合搜索
_ 利用門戶標記和權限保護安全內容
_ 在應用程序服務器級別存儲安全內容。
對於大型站點，crawl整個內容儲存庫的時間很成問題。根據業務需要，公司可以通過如下方式解決
這個問題：創建多個集合併在搜索條件中包含所有集合，週期性執行部分crawl，設置多個搜索引擎，
以及利用聯合搜索。這有助於與搜索解決方案提供商協作開發架構和流程。
2.3.1.5 企業（基於角色的）門戶
通過實現本文檔中定義的網絡層組件，企業可獲得下圖中描述的“當前狀態”。
在這種狀態下，IT組織可以以客戶應用程序、打包的應用程序、企業服務或這些組件的組合的形式
快速部署業務解決方案。自定義應用程序框架允許業務提供格外好的用戶體驗。不過，它也具有如
下缺點：
_ 重新樹立品牌（re-branding）用戶體驗可能會要求對所有站點進行更改。
_ 用戶仍然需要知道每個站點的URL。通過採用一些最佳實踐可以將這個缺點的程度減輕，但無
法完全消除。
_ 此模型可能會導致每個點解決方案的硬件和軟件冗餘。這是因爲每個業務單位都想要調度自己
的維護窗口，而實現這個目標的唯一方式就是爲每個點解決方案提供專用的基礎架構。
目標狀態是利用聯合門戶的概念創建基於角色的企業級門戶。此方法的優點如下所示：
_ 爲所有員工、客戶、合作伙伴和其他用戶提供一個入口點。
_ 基於用戶角色的應用程序（Portlet）訪問
_ 硬件和軟件基礎架構的整合
_ 總是打開的功能
_ 更簡單的站點重新冠名
_ 聯合門戶通過利用服務提供的多通道交付。
2.3.2 服務層
服務層是SOA的主要啓用程序，包括本節中描述的組件。
它允許在企業之間進行集成與業務流程自動化。此層基於粗粒度、鬆耦合的和基於標準的服務的
SOA原則。它通過爲減少的應用程序和基礎架構複雜性，業務服務增加的重用性，以及服務編排能
力，來幫助IT響應不斷變化的業務需要。
2.3.2.1 服務總線
服務總線是爲IT靈活性和與業務需求的調整提供面向服務的基礎架構的關鍵組件。它應該與服務注
冊表和服務管理組件進行完美集成，以便加速配置和部署管理並簡化企業之間共享服務的管理。
該服務總線應該能夠通過任何協議接受任何同步或異步消息，並根據配置規則將其路由到目的地。
此外，它應該能夠將消息轉換爲目標要求的格式。由於這控制消費者和生產者之間的消息流，服務
總線在管理、監控和實施服務級別方面具有獨特的地位。
上圖表示企業服務總線（ESB）。ESB充當動態可配置的消息和服務代理。它提供了以下功能：
_ 異構環境之間的消息代理
_ 支持異步、同步、發佈和訂閱消息傳遞
_ 支持同步和異步橋接
_ 支持多種消息格式，包括SOAP、帶附件的SOAP、XML、結構化非XML數據、原始數據、
文本以及帶附件的電子郵件
_ 服務端點之間的異構傳輸
_ 支持多種協議，例如文件、FTP、HTTP(s)、多JMS提供商、RMI、Web服務、CORBA、
DCOM以及電子郵件（POP、SMTP和IMAP）和SIP。
_ 允許消費者與生產者交談的消息轉換，但不提供完全成熟的轉換引擎
_ 配置驅動的路由
_ 基於策略進行消息路由，或者調用外部服務以支持複雜路由
_ 支持點對點和一對多路由方案，允許請求-響應和發佈-訂閱模型
_ 監控
_ 帶搜索功能的服務監控、記錄和審計功能
_ 捕獲消息和傳輸屬性的關鍵統計數據，包括消息調用、錯誤、性能、容量和SLA違反情況
_ 高可用性
_ 支持集羣並跨集羣收集統計信息以審查違反SLA的情況
_ 簡化服務供應
_ 通過配置動態部署新的服務版本
_ 在設計、階段劃分和生產之間遷移配置的服務和資源
_ 支持消息資源的多個版本，通過靈活路由進行選擇性的服務訪問來配置這些版本。
_ 可配置的策略驅動安全
_ 支持用於進行身份驗證、加密-解密和數字簽名的最新的安全標準
_ 支持用於HTTP和JMS傳輸的SSL
_ 支持多個身份驗證模型
_ 策略驅動的SLA執行
_ 根據各種屬性建立SLA，包括吞吐時間、處理容量、消息處理的成功/失敗比率、錯誤數、
安全違反情況和模式驗證問題
_ 使用靈活的機制啓動自動警告或啓用操作人員啓動的對規則違反情況的響應，這些機制包
括電子郵件通知、觸發的JMS消息、觸發的帶JMS消息的集成過程，帶JMS消息的Web服
務調用或者管理控制檯警告。
下面是服務總線的一些最佳實踐：
_ 在任何時候服務數目超過50時採用服務總線。如果服務數目超過150則必須使用服務總線。
_ 從小型規模開始，例如將目標定位單個複合應用程序或爲跨越多個系統的分部業務流程。
_ 考慮讓多個LOB根據自己的策略管理自己的服務總線，並使用一個跨不同的業務單元共享服務
的可充當代理的企業級服務總線。
_ 確定是部署供應商提供的服務總線還是內部開發的抽象層。
2.3.2.2 服務註冊表
SOA要求服務是粗粒度、鬆耦合的和基於標準的服務。開發和部署服務後，必須爲架構師、開發人
員、操作人員和業務經理提供可用的服務目錄。
上圖演示了服務註冊表的架構。服務生產商爲服務消費者用於運行時綁定的服務註冊表發佈了服務。
註冊表還可充當業務策略在運行時執行的記錄系統。
服務註冊表應該提供下面的功能：
_ 核心服務，包括複製、UDDI數據存儲和安全
_ 信息服務，包括數據驗證、SOA映射、高級分類以及業務數據訪問服務
_ 生命週期服務，包括批准和更改管理、更改通知、業務服務發現和QoS管理
_ 配置的基於Web的業務服務控制檯
_ 與領先的啓用、管理和安全產品連接的獨立於平臺的開放架構。
服務註冊表的最佳實踐包括：
_ 從小規模開始並逐步增長
_ 將服務註冊表的每次實現複製到企業服務註冊表
_ 爲架構師、開發人員和操作人員提供服務瀏覽功能以幫助實現重用和標識服務依賴關係
_ 維護服務合同信息以及服務定義
_ 對所有服務進行版本控制。
上圖演示了服務註冊表的架構。服務生產商爲服務消費者用於運行時綁定的服務註冊表發佈了服務。
註冊表還可充當業務策略在運行時執行的記錄系統。
服務註冊表應該提供下面的功能：
_ 核心服務，包括複製、UDDI數據存儲和安全
_ 信息服務，包括數據驗證、SOA映射、高級分類以及業務數據訪問服務
_ 生命週期服務，包括批准和更改管理、更改通知、業務服務發現和QoS管理
_ 配置的基於Web的業務服務控制檯
_ 與領先的啓用、管理和安全產品連接的獨立於平臺的開放架構。
服務註冊表的最佳實踐包括：
_ 從小規模開始並逐步增長
_ 將服務註冊表的每次實現複製到企業服務註冊表
_ 爲架構師、開發人員和操作人員提供服務瀏覽功能以幫助實現重用和標識服務依賴關係
_ 維護服務合同信息以及服務定義
_ 對所有服務進行版本控制。
2.3.2.3 SOA 儲存庫
SOA儲存庫是在服務生命週期（從項目初期到完成）中管理元數據的關鍵組件。其主要目的是存儲
詳細元數據以便在部署前管理和治理資產。SOA儲存庫存儲服務定義，以便團隊可以檢查企業內定
義了哪些服務。SOA儲存庫還存儲了其他類型的元數據，包括過程映射、業務規則、實體和關係、
編排、轉換、參考數據模型、業務活動和事件、審計要求、角色和授權映射，以及治理規則和策略。
儲存庫還可通過標識和管理依賴關係以最大化重用率來幫助減少“服務sprawl”。如果儲存庫中包
含來自組織的所有產品的元數據，則可爲架構師和IT決策人員提供有關服務、系統和數據依賴關係
的有價值的總體觀點。爲了幫助業務、IT和操作人員進行正確的決策，SOA儲存庫應該將有價值的
資產存儲爲標準化治理流程、供銷業務和技術最佳實踐以及開發方針。
SOA存儲庫可在設計階段幫助治理SOA資產。他們允許在SOA生命週期的不同階段共享元數據，並
在資產填充到儲存庫中時提供一個理想的位置以觸發批准工作流。儲存庫可幫助確保在資產在其生
命週期中得到合適的批准，同時降低服務的“獨立開發”並支持進行較高程度的重用。
SOA儲存庫還提供了一箇中心位置，用於管理與運行時執行（如路由、安全和SLA）的服務關聯的
策略。儲存庫的依賴關係跟蹤和影響分析功能可幫助團隊管理對策略或其他資產的更改，並預測性
地分析更改對其他資產的影響。
SOA儲存庫應提供如下內容：
_ 發佈和發現元數據（服務、業務流程、用戶交互等）的能力
_ 按類別、複合應用程序名稱、服務描述、範圍（如分部或部門）或者儲存庫內跟蹤的任何其他
元數據類型進行的複雜的元數據搜索
_ 服務依賴關係映射，用於跟蹤服務依賴的資產以及依賴於此服務的資產
_ 元數據更改的通知
_ 可擴展元數據分類信息，以便業務可以根據自己的要求自定義分類信息
__授權過程，用於控制哪些人可以創建和操作儲存庫中包含的元數據
_ 所有資產的版本信息的維護
_ 影響分析，用於在進行更改前預測性地測量更改的影響
_ 與開發環境同步的開放的可擴展界面
_ 與其他外部存儲的同步，例如註冊表或其他儲存庫
_ 基於設計時策略的元數據的設計時語義驗證
_ 批准工作流，用於提升或拒絕元數據
_ 多個同步儲存庫的聯合和分區。
根據服務及其依賴關係的數目，爲三個以上的項目採用SOA的IT組織可能會需要SOA儲存庫，尤其
當他們具有多個分佈式開發團隊以及許多服務時。如果組織成熟到可以重用服務來開發複合應用程
序、流程或服務，就需要使用儲存庫以便管理和治理重用性。
2.3.2.4 服務管理器
企業內的SOA實現變得越成熟，對總體服務管理器的需要就越發強烈。此服務管理器的主要功能在
於管理、監控和報告整個企業內的所有服務。下面是服務管理器需要提供的一些功能：
_ 管理和維護整個企業的服務級別
_ 跨企業映射和管理服務層次結構，併爲操作提供依賴關係指標
_ 檢測和管理異常情況
_ 審查和監控業務事務，並提供審查動態事務的功能
_ 管理服務生命週期並在部署前進行驗證
_ 跨不同的系統提供非插入式服務發現功能
_ 管理多個服務總線和服務註冊基礎架構並與之集成
_ 利用現有監控基礎架構。
2.3.2.5 共享數據服務
共享數據服務提供了多項關鍵功能：
_ 電子數據互換（EDI），使用網絡在不同公司之間傳輸數據
_ 數據操作
_ 提取、轉換和加載（ETL）
_ 企業信息集成（EII）
_ 數據質量
_ 數據匹配引擎
_ 數據工作
_ 工作流。
EDI和ETL是傳統的方法，對於以批量模式處理大量數據尤其有用。不過，SOA有一個要求，就是能
夠將一些EDI/ETL功能作爲服務調用。例如，電子基金轉帳必須從事件觸發的源系統填充操作數據
存儲。
2.3.2.5.1 企業信息集成（EII ）
EII引用軟件系統，此軟件系統可從各種內部和外部源獲取不同格式的數據並將其看作單個數據源。
EII應該提供以下功能：
_ 跨多個源的數據建模
_ 查詢（讀寫）開發以便從多個數據源提取信息。
_ 支持多種數據源，例如數據庫、文件、應用程序適配器、LDAP和Web服務
_ 數據轉換
_ 數據驗證
_ 使用RMI或Web服務將數據服務公開到客戶應用程序。
_ 堅持SQL、XQuery、XML、Web服務、JDBC以及J2EE等標準。
雖然定義了服務數據對象（SDO）標準以簡化和統一應用程序處理數據的方式，但業界尚未清楚地
定義EII的標準。所有供應商都具有自己擴展，來處理對於每個數據存儲的數據讀取、數據更新以及
數據插入操作。