概要
这篇文章适合于那些正在寻找或者研究一个高效的、灵活的、基于标准的途径去实现真实世界面对服务的架构（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， Description， 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中插入操作
