引言：SOA 实现的关键组成部分

　　最近发表的很多文章（Longworth、Clement、Seeley）都将注册中心/存储库功能定义为面向服务的体系结构（Service-Oriented Architecture，SOA）的关键组成部分。例如，David Longworth 于 2005 年在 Loosely Coupled 文章指出：“注册中心/存储库如何实现可以决定企业 SOA 的成败”(Longworth)。他认为注册中心/存储库应该具有以下功能：

　　开发效率。允许组织跟踪现有服务和服务相关构件，从而允许对现有企业服务相关资产进行重用。

　　运行时治理。允许组织对服务端点地址进行虚拟化和集中控制。
　　根据 Luc Clement（也在其 Loosely Coupled 文章中对此进行了讨论）的观点，缺少注册中心功能经常会导致出现以下问题 (Clement)：

　　缺乏应用程序一致性和完整性，而且缺乏能够确保企业服务的设计和开发的一致性和完整性的治理机制。

　　难以对应用程序功能进行相关和重用，其中包括缺乏查找解决具体业务问题和支持所需流程的现有服务的功能。

　　会得到不通用且难于维护的软件，还会出现导致服务使用者与提供者间的紧密位置耦合的直接服务调用。

　　不幸的是，其中的大部分文章都将服务存储库和注册中心的运行时和设计方面混杂在一起，将其视为同一个系统。而实际上，这二者在 SOA 实现中扮演着截然不同的角色。

　　通过本文，您将了解存储库和注册中心的角色以及各自在 SOA 实现中的使用方法。

　　服务存储库

　　SOA 具有企业级的本质 (Lublinsky)，需要设计和实现团队进行大量的协作。

　　设计业务流程的分析人员需要找到提供这些流程所需功能的服务。找到最适合解决特定业务问题的服务对流程实现的成功极为关键。不过，功能本身并不足以保证服务的适用性。关于服务级别协议（Service-Level Agreements，SLA）或安全需求等非功能需求的问题，可帮助潜在服务使用者评估为给定解决方案挑选的服务集是否将正常地进行协作。最后，必须对服务依赖关系加以处理。这些注意事项允许分析人员评估解决方案的总体复杂情况，以及使用此解决方案所带来的潜在变更的影响。

　　技术人员对现有服务投资组合也同样感兴趣，不过他们的兴趣却是源自另一个角度。应用程序架构师的工作重点是服务设计和实现，如是否在现有应用程序的基础上构建特定服务，或是否为实现引入业务规则引擎等。通过考虑这些事项，服务开发人员可以构建更为可靠、维护更方便的服务实现。

　　基础设施架构师的工作重点是访问和过程，如服务应放置在隔离区（DeMilitarized Zone，DMZ）内还是放置在其外。通过考虑这些事项，可以定义服务和服务使用者部署的基础设施需求。其关注的另一个区域是服务使用率，如服务调用的峰值和平均数量。通过利用这一信息，架构师能以主动方式管理服务容量和做出关于服务退役的决策。

　　总之，整个企业的涉众都对各种服务相关的信息感兴趣，不过其角度和目标有所不同而已。此信息的临时 分发模式（例如电子表格）可能对于管理小型社区使用的少量服务已经足够了。不过，这种方式并不能通过进行扩展来满足面向服务的体系结构 (SOA) 的目标（即可重用性、一致性等等）。静态 HTML 页面提供服务信息的方式很快就变得落伍了。类似地，如果通过“叫架构师帮忙”的方法来沟通关于可用服务和已规划服务的知识，就会使得关键资源成为信息瓶颈。

　　也就是说，企业级 SOA 实现中的所有服务相关构件都变成了企业级的资产，需要用于存储以上所有信息的集中资产存储库。存储库还应该向所有 SOA 涉众提供协作功能（能够进行搜索、修改等）。这样的存储库将所有服务相关的信息源集成到一起，包括设计构件、运行时拓扑、服务监视和管理解决方案收集的信息、服务代码存储库等。它提供了所有此类信息的统一表示形式，允许涉众根据自己的工作职能以集中的方式对其进行访问。请参见图 1。

　　图 1. 基本服务存储库交互

 
　　服务存储库提供支持完整的服务生命周期（从服务初步构想开始，包括设计、实现、部署、使用和维护各个阶段，如图 2 中所示）所需的信息。

　　图 2. 经过简化的服务生命周期

 
　　在系统分解过程中，业务分析人员将确定新服务的需求。将根据现有服务的功能对这些需求进行评估，并会将新服务插入存储库中。这些服务得到批准后，将创建相应的服务契约并也将存储在存储库中。

　　此时服务进入实现阶段。开发团队负责创建和维护服务实现构件，并将其存储在存储库中。实现完成并经过测试后，会将其部署到生产环境中。接下来将使用部署信息对存储库信息进行扩充。

　　在正常的服务使用期间，会定期从服务管理和监视系统将其使用率数据（包括关于服务使用者及其位置的信息）导入到存储库中。随着时间的推移，将在存储库中创建和捕获服务使用缺陷和其他需求。经过相应的审批后，会将其转换为服务增强或新服务版本（也在存储库中捕获）。

　　服务存储库的基本功能如下所述（请参见 Sun Microsystem’s guide）：

　　服务归类与发现。服务存储的主要目的是为了提供基于构件特定的元数据查找构件的功能。此元数据通常包含在构件自身中。因此，当新构件发布到存储库时，服务存储库应该自动提取此元数据（基于归类策略）。例如，可以在服务定义归类期间自动捕获以下信息：
　　
　　指向服务定义文档导入的辅助文档的链接（如 XML 模式文档、消息传递语义定义等）
　　服务契约文档使用的 XML 名称空间
　　接口的名称和描述以及服务契约使用的 XML 类型
　　指向控制服务调用和执行的策略的链接
　　为了实现归类，需要获得存储库中放入的每个构件的元数据定义。元数据必须足够丰富和灵活，以支持存储在存储库中的不同类型的服务构件以及每个构件的发展。存储在服务存储库中的元数据需包括业务分析人员和服务设计人员对现有服务进行发现，并决定其对给定解决方案的适用性时使用的所有信息。因此，存储库应该提供可扩展的发现功能，而且此功能需要能够适应各种领域特定的发现查询。此需求通常转换为存储库支持多种业务相关的分类法的能力。

　　验证。查找不符合企业标准的构件没有任何价值。作为服务相关信息的访问点，服务存储库应该执行组织和领域特定的业务规则，从而确保这些构件遵循企业的策略和标准。由于能够执行验证，因而使得存储库成为了 SOA 治理的一个重要部分。

　　依赖关系管理。服务相关信息通常包括多个相互关联的构件、如服务接口、消息模式、实现代码、使用概要等。此外，服务本身也可以供其他服务或业务流程重用。随着服务的数量增加，跟踪所有这些依赖关系并评估变更影响会变得越来越困难。服务存储库支持对服务构件间的关系进行管理，从而简化了此任务。存储库应提供标准关系类型；还应该允许组织根据自己的额外需求对这些类型进行扩展，以包括其他类型。

　　服务发展与版本控制。服务创建之后，通常会随着时间的推移而有所发展。这个发展可能是服务功能、语义消息传递和实现中的变更引起的。其中的很多变更都将要求创建和部署新版本的服务。为了跟踪所有的版本控制信息，服务存储库应该为所有构件提供版本控制功能，而不考虑其类型如何。

　　此外，服务存储库应该提供对变更/版本控制通知的订阅功能，以通知利益方关于即将进行的变更和当前变更的信息。通过这样，存储库就可以向所有利益方（服务使用者开发团队）提供变更信息。此类订阅机制应该允许指定所关心的事件类型，从而防止订阅者被通知所“淹没”。

　　构件发布治理。随着服务存储库成为所有关于服务相关资产的信息的中央集合，它将需要与其他企业资产存储库相同的治理措施。这种类型的治理通常包括发布服务相关构件的权限和构件发布审批流程。

　　支持多种构件类型。创建服务存储库过程中面临的主要挑战之一是服务相关构件巨大的多样性，包括定义服务接口和消息传递模式的 XML 文档、实现代码、UML 关系图及文本文档。通过使用不同资产类型的通用表示形式，可极大地简化存储库实现。