概要
這篇文章適合于那些正在尋找或者研究一個高效的、靈活的、基于標準的途徑去實現真實世界面對服務的架構（SOA）的讀者們。
隨著網絡服務的生根發芽，SOA作為發展和提升軟件架構質量的可行之道，我們不得不承認SOA數據的總量也在迅速膨脹。而且，隨著網絡服務標準在功能上的拓寬， SOA必須支持這些日新月異的新標準。我們必須清醒地熟悉到我們需要存儲、治理、查詢、操作、移植SOA數據，并且頻繁地通過程序訪問SOA數據。一個用來制作mid-tier cache的用例可以用來顯示那些技術無關的、可重用的、富功能化的服務，因此可以用來提高SOA的可測量性和運行表現。
此外，隨著企業越來越熱衷于和合作伙伴的頻繁協作，如何處理復雜多變的模式將成為一項挑戰。因此，我們不僅需要一個簡單的
xml持久性機制，我們還需要一個native 的XML 的數據治理服務器來滿足SOA數據治理的復雜需要。SOA的基本原則就是為不同引用提供低耦合的解決方案。因此，數據由程序產生并服務于程序，并且數據的存儲和使用都已經被良好地優化。
在傳統的SOA中，數據存儲的方法通常是地址相關的，并且對具體程序來說是特定的。而一個SOA存儲庫是一種處理分布式SOA數據持久化的的機制。這是一項復雜的企業級技術，不僅可以處理數據的持久化和caching，并且可以進行生命周期治理、安全、發現、并且可以從不同的面對服務的程序中轉換分布式的數據，這些程序例如silo應用，web門戶、商業過程和移動應用程序。本質上，SOA數據本性上是短暫的和流動的。因此，它需要一個native的數據存儲來聚合針對特定服務的相關數據，這與運行的應用本身無關；而不會為各個獨立的應用分派數據來生成服務，否則，數據的存取將會由于沒有通用性而存取不便。SOA數據通常是存儲在關系
數據庫或者文件系統上的，但這種方式往往不能很好地處理SOA數據。
Elliotte Harold，在他的文章"Managing XML Data： Native XML Databases，" （IBM developerWorks， June 2005）里明確地表示了native XML數據庫的好處。用他的原話說，“當你手上的工具只有一把錘子時，所有的東西都看上去像個釘子。當你唯一的工具是關系數據庫時，所有的東西仿佛都可以制成一張表。但實際上，事實遠比一張張表要復雜。數據并不是都可以制成表的，并且數據通常可以從和該數據本身結構類似的工具中獲益。所以，當數據是XML形式，對應的治理工具也最好是一個native的XML數據庫。
基于 XML的SOA 數據實際上不能輕松地在關系數據庫上建模。 關系數據庫模式的擴展性很弱， 這經常不能適應不斷發展的SOA數據模式，這個缺點在企業間的伙伴合作中更為顯著。文件系統同樣不能提供高級的查找和治理能力，而這些需求在一個SOA中是很基本的。所以，由于這些本質性的差別，我們非常地肯定，這些XML的數據應該是以XML方式來持久化、治理和處理?？紤]到復雜多變并且不斷發展的網絡服務標準列表，他們包括大量的OASIS initiatives，例如Web Services Business
PRocess Execution Language （WSBPEL）， Web Services Security， Web Services Distributed Management （WSDM）， ebXML Collaboration Protocol Profile and Agreement （CPPA）， and Web Services Policy Framework （WS-Policy），還有大量的World Wide Web的initiatives，以及過時的REST-based XML .
瀏覽過這些類似于字母湯（譯者注：字母湯是一種罐頭湯，里面是切成ABC字母圖案的細面條，讓小朋友邊喝湯邊把里面的字母排成單詞來玩。）的標準，我們會發現，基本上，這些標準通常由由XML schema來描述，例如WS-Policy XML Schema， the Collaboration Protocol Profile （CPP） XML Schema， the Collaboration Protocol Agreement （CPA） XML Schema.再次強調，假如數據是XML形式，它就應該以XML方式來存儲、治理和對待參照圖1的WS_Policy Schema 與WS-Policy 框架標準相關的ws-policy.xsd文件。他標準化了服務消費者和服務提供者之間策略是如何交互的。
Figure 1. WS-Policy XML Schema
正如圖1所顯示的，與WS-Policy相關聯的數據和元數據用XML形式表示，并且用XML持久機制來方便地進行存儲和治理。同樣的，CPP， CPA，和網絡安全服務細節也同樣可以在XML持久機制下被本地化地存儲和治理
SOA中的Mid-tier caching
SOAs需要持久化的機制來持久信息，例如應用程序中每個商業步驟的狀態、長期的商業執行進程的狀態、Web services的治理、信息的監視、可用Web services的列表，還有更多。通常，大部分的這類信息是被頻繁請求和訪問的，因此這就產生了middle tier中cache的需要，它減輕了由于大量訪問同樣信息存儲而帶來的運行瓶頸。
當SOA數據和元數據都是XML時，我們提議建立一個簡單，但是有效的mid-tier caching架構，這包括一個充當mid-tier cache的XML數據庫和大量的XQuery-powered服務。一個SOA存儲庫可以通過一個有效的mid-tier caching提高原SOA的運行效率、可靠性、富功能性以及重用性。而這一切是由以下的服務驅動的：
基于策略的caching服務：為了提高運行效率和服務質量一個基于策略的caching服務可以建立基于XQuery的策略，而對一些低效服務進行cache.這些策略在cache被更新前同樣被構造成包括time-to-live.基于time-of-day請求的策略可以決定cache中的數據對該請求是否合法或者源數據是否必須使用。
同樣，基于服務可用性的策略可以確認當前服務是否可用，結果是否可以從緩存中獲得。一個cache的更新控制可以基于時間或者通過其他的配置變量來觸發XML的持久性機制。這種設計同樣可以包括對XML持久性機制服務請求而帶來的動態just-in-time日志跟蹤。
數據用途重定向服務：為了富功能化和提高運行效率。
一個數據用途重定向服務可以答應附加的過濾器和服務結果內容的搜尋標準。并且，XQuery可以被用來驅動重用內容的轉換和提供對返回結果內容的分析和報告。XQuery還可以傳遞部分結果集和生成基于多個服務內容聚合的最終結果集。
數據抽象服務：為了簡化部署和方便維護。擁有一個數據抽象服務， 系統中的web services就沒有必要再熟悉所有單獨的數據源。圖2顯示了一個Web services的很好的例子，消除了為每個操作開發單獨的客戶端和web services的需要。這樣的話，異構的數據源例如JDBC、HTTP、WSDL或文件系統的數據源治理都可以使用這個服務。
Figure 2. A data abstraction service eliminates the requirement of different Web services clients for different
Operations.
除此之外，既然服務可以運行在任何系統上，一個SOA存儲庫可以被用來整合SOA中的各種服務，也可以通過與數據處理盡可能接近的數據收集來減緩center-tier process-abstracting遠程服務的效率問題。作為一個在central-tier的persistence layer，SOA存儲庫可以用來存儲事務數據從而實現很多用途，包括分析和集成治理，例如日志記錄。通過在central-tier處理抽象與合成的數據元素，一個集中的SOA數據存儲庫形成了。
現存的SOA技術，例如企業服務總線和orchestration引擎都可以部署SOA存儲庫進行狀態治理、工作流持久化和信息持久化。一個SOA存儲庫同樣可以在SOA注冊中提供持久化中樞，不管他們是UDDI （Universal， Descr
iption， Discovery， and Integration） 還是ebXML 注冊，從而來答應發現、發布、簽定服務。
對SOA中復雜多變的XML數據治理的需要
正如前面討論過，web services和SOA在產生了大量復雜的、作為程序間交換的data-rich XML消息形式的新數據，而這些數據必須存儲然后用來審核和分析。當我們看著這些可以實現SOA的各種各樣的技術，很明顯的是，SOA的要害特征和帶來的好處構成了廠商在這個領域的準則。如圖3，這些功能構成了核心的SOA和web services的基礎構造——Web services 治理——Web services監視——SOA治理——Web services安全——SOA持久化和caching——SOA發現、發布和簽署。
Figure 3. Core Web services infrastrUCture （Source： Burton Group）。
我們可以用下列方式描述XML數據治理的用途——SOA元數據的持久化——SOA的發現、發布和簽署——Web services治理數據的持久化——加速caching——服務集成——服務策略的caching和治理
SOA中XML數據治理還可以：——監視、日志、審核的持久化——安全能力的持久化——SOA治理——SOA OLAP數據和元數據的移植和持久化——商業伙伴的檔案和協議的持久化——消息的持久化——狀態治理——Schema 版本化
Native XML數據治理服務器概覽一個XML數據治理服務器（XDMS）不僅僅是一個XML數據的數據倉庫。一個XMDS是一個復雜的系統，必須具有可適應性，可測量性和高效性。實際中，大部分XML數據的治理服務器不能滿足這些苛刻的需要。XDMS中最典型的是我們并不需要預先知道任何關于XML文檔結構的知識。任何合法的XML文檔例如XML，網絡服務描述語言（WSDL），CPPA，XML Schema 或者Extensible Stylesheep Language Transformation可以被隨意插入，然后native的XML數據治理服務器可以自動生成需要的內部結構來滿足這些存儲。并且，XML數據治理服務器支持事務處理、索引、schema或者DTD驗證（有些支持schema versioning）、擴展連接和服務鏡像。一個XDMS解決方案必須也能夠存儲非XML數據，例如二進制數據，因此要提供一個能夠存儲任何我們可能需要的內容的解決方案。
對SOA存儲庫操作的native XML接口是XQuery.為了探究XML數據庫的完全潛力，XQuery是一個用來生成、治理、檢測、治理XML數據的途徑。XQuery還提供了一個標準的方案來統一異構的數據源來使得他們看起來像一個單獨的服務器。
XQuery介紹
XQuery是一個多功能的語言。例如，表達式可以合成從而隨意生成復雜的對一個或多個XML數據集合的查詢。XQuery同時提供了基于XML模式和DTD的強類型機制和基于原始 XML數據的弱類型機制
XQuery數據模型XQuery數據模型比XML Infoset and Post-Schema Validation Infoset （PSVI）的XML數據模型更具有擴展性。XQuery通過數據模型的操作來定義，但他約束了數據模型中文檔和事例的組織。這個數據模型由被搜索的XML數據、所有中間值和最終查詢結果組成。他支持可以產生非XML數據、XML碎片和類型與非類型數據的中間表達式。
XQuery和XML模式對XML數據有相同的類型概念。XQuery提供基于XML Schema內置類型和用戶自定義的Schema類型。Query同樣支持在現存的XML Schema數據類型之外的數據類型XQuery數據模型和類型系統的
組件如下：
XQuery表達式有一個靜態的類型和一個動態的類型。靜態的類型適合那些編譯時運行的表達式。動態的類型適合那些表達式的結果并且在運行時運用的表示式
靜態的類型和動態類型的比較:
靜態：對應文擋與查詢的類型索引的集合
動態：治理查詢是如何進行的數值索引規則的集合
XQuery syntax
幾個可以被用在語法查詢中的XQuery表達式的類型
除此之外，XQuery的實現可以被擴展。更多的復雜實現包括對文件系統、HTTP、Web Services、
java數據連接橋（JDBC）,Java消息服務和其他數據源的支持
圖4中，XQuery提供了對native XML數據治理服務器的整合，作為一個靈活的和基于標準的持久性機制。
Figure 4. XML-based persistence mechanism for SOA.
我們推薦native XML數據治理服務器的使用（如圖4所示），來作為對SOA持久化的一個好的實現。一個native的XML數據治理服務器可以被用來進行SOA內部服務的整合，因為服務是本地獨立的。 David S. Linthicum在他的一篇題為"The Importance of Persistence within a SOA“，的blog中提到，服務的整合、持久性問題、存儲、事務數據的處理、集中的原數據是作為面對信息服務集成的要害方面。整合的服務同樣可以通過使數據接近數據處理的組件而提高系統效率。在central tier使用一個原生的XML數據治理服務器答應架構師們為分析和日志而存儲事務處理信息。
SOA中，XQuery使用實例
XQuery在SOA中的強大能力表現在許多復雜的查詢功能。下面的這些例子證實一個具體的XQuery實現是怎么被一個具體的native XML數據治理服務器無縫整合的。
例 1：使用XQuery往WSDL中插入操作
