如果架构师创建了一个有用的服务存储库，在一个公有云计算环境中，其上载、维护和保护容易吗？

　　这个问题中实际包含了几个问题，所以我将它们分开来看。

　　在云计算环境中，第一个不得不解决的问题是安全问题。无论是服务存储库、事务数据、用户相关信息或者其他，安全问题是许多云计算讨论中首要关注的问题。在我看来，更多要解决的不是云计算提供方的实际安全缺陷，而是如何消除你将自己信息的控制权交给了外部的服务提供方而产生的担心。因此，出于保护自己数据的角度考虑，你应该从提供方了解服务模型并详细咨询数据保护的细节。例如，它是不是多租户环境？如果是，每个租户数据如何界分？在命名规则上你有哪些控制权可以防止熟悉租户数据结构的人获得你的信息?此外，这些问题不是特指云计算环境中只容纳一个服务存储库，而是指云计算环境中容纳任何的应用或者任何的信息存储。

　　下一个问题是怎样将基于云的存储库进行组装。这个问题比较有挑战性，主要是目前还没有一个公认的与存储库交互的标准。多数供应商一定程度上提供了UDDI支持，然而，这更像是服务注册，而不是存储库。事实上，当IBM第一次公布WebSphere 服务注册库和存储库时，已经表明了需要一个新的标准来支撑服务注册及存储库的交互。更早些的存储库产品，例如Oracle的企业级存储库提供了专门的API，用于存储库的交互（除UDDI以外），而近期来自WSO2 和MuleSoft的产品已经包含了面向存储库元素的基于REST的接口。因此，更贴切的情况是早期的产品在一定的范围内将和平共处，不同的服务提供商提供有自己特色的服务，在某种意义上说，很难将其分类。

　　一旦组装好了你的存储库，面临的就是维护的问题。维护问题是争议最少的，因为当前大部分存储库使用了Web接口，所以软件即服务（SaaS）厂商提供类似接口也就理所当然了。如果需要自动发布，其实和初始组装存储库一样，只是数据量小些。此外，鉴于存储库之间结合的标准还不充分，相关厂商之间会存在一定差异。

　　最后一个问题，也可能是最重要的问题是,其在当前云环境下的可行性有多少。坦率地说，即使有，它们也并不广为人知，这并不奇怪。存储库工具面临的，甚至比SOA更加严峻的最大的挑战，就是要与遗存IT生态系统良好的集成。现状是，许多现有的存储库绑定在某些产品上。WEB服务与注册库则绑定在ESB与服务网关上。ITIL服务目录，配置管理数据库（CMDB）和配置管理系统（CMS）绑定在桌面产品上。业务处理存储库绑定在BPM套件集成上。SAP 或者Oracle的商业应用套件拥有业务功能、对象和更多核心的存储库。不幸的是，涵盖这些方面的企业级存储服务市场还处在原始阶段。因此，云计算存储使用同样的分类。Service-now.com上有一个服务分类，作为他们的云计算IT服务管理的一部分。Lombardi的Blueprint提供云计算的BPM产品，用于管理流程类资产。另外，存储是与应用场景紧密相关的。
 
　　抛开所有这些问题，从根本上说存储库仅仅是个数据容器。要规划好你的存储库，你应该非常清楚如何使用存储库信息。它是单独作为个人证券投资管理工具，或者你需要通过更加复杂的与自动接口的交互，以便于服务的发现、发布、状态报告等。如果是后者，我想最大的问题不是安全问题，而是找到一个可以提供稳定程序和云计算集成服务的服务提供商，就像寻找传统的应用及中间件提供商一样。