SOA存储库背后的力量(一)

　　这篇文章适合于那些正在寻找或者研究一个高效的、灵活的、基于标准的途径去实现真实世界面对服务的架构(SOA)的读者们。

　　随着Web服务的生根发芽，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文件。他标准化了服务消费者和服务提供者之间策略是如何交互的。