最近发表的很多文章（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涉众提供协作功能（能够进行搜索、修改等）。这样的存储库将所有服务相关的信息源集成到一起，包括设计构件、运行时拓扑、服务监视和管理解决方案收集的信息、服务代码存储库等。它提供了所有此类信息的统一表示形式，允许涉众根据自己的工作职能以集中的方式对其进行访问。

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

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

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

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

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

　　服务归类与发现。服务存储的主要目的是为了提供基于构件特定的元数据查找构件的功能。此元数据通常包含在构件自身中。因此，当新构件发布到存储库时，服务存储库应该自动提取此元数据（基于归类策略）。例如，可以在服务定义归类期间自动捕获以下信息：

• 　　指向服务定义文档导入的辅助文档的链接（如XML模式文档、消息传递语义定义等）
• 　　服务契约文档使用的XML名称空间
• 　　接口的名称和描述以及服务契约使用的XML类型
• 　　指向控制服务调用和执行的策略的链接

　　为了实现归类，需要获得存储库中放入的每个构件的元数据定义。元数据必须足够丰富和灵活，以支持存储在存储库中的不同类型的服务构件以及每个构件的发展。存储在服务存储库中的元数据需包括业务分析人员和服务设计人员对现有服务进行发现，并决定其对给定解决方案的适用性时使用的所有信息。因此，存储库应该提供可扩展的发现功能，而且此功能需要能够适应各种领域特定的发现查询。此需求通常转换为存储库支持多种业务相关的分类法的能力。

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

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

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

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

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

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

　　服务注册中心

　　创建服务的目的是为了供需要使用该服务实现的功能的使用者调用。调用服务需要知道其位置，即服务端点地址。在最简单的情况下，端点地址可以硬编码到服务使用者的实现中。（Java和.NET环境中都采用这种方式来基于服务的Web服务描述语言（Web Services Description Language，WSDL）生成Web服务使用者。因此，发现很多当前系统使用硬编码端点地址应该不会令人感到意外。）此方法将服务使用者实现与服务位置紧密耦合（地址耦合）。

　　为了在这样紧密耦合的实现中包含服务地址变更，需要对服务使用者实现进行修改。这很容易出错，而且随着服务数量的增加，扩展性也不好。如果应用于多环境（开发、测试、质量保证、生产）的情况，只会让问题变得更为复杂。

　　通过将端点地址外部化到配置文件中，可在一定程度上改进此实现。此方法更为灵活，因为它将端点地址从使用者的代码中删除，将其外部化到配置文件中。这样，服务使用者能够在不必更改服务使用者代码的情况下包含地址更改。不过，这个选项也会在使用者和服务数量增加（配置文件也会随之增加）的情况下遇到可扩展性问题。

　　通过使用专门动态地将服务查询解析为端点地址和调用策略的组件（即服务注册中心），可提供此问题最为灵活和最易于维护的解决方案。在这种情况下，服务注册中心包含关于服务部署的所有信息、其位置以及每个位置与调用关联的策略。

　　Steve Vinoski在其IEEE Internet Computing文章“The social side of services”中指出，服务注册中心的可用性会随着服务数量的增加而提高 (Vinoski)。他写道：

　　解决这些棘手麻烦的通常的技术方法是：

　　1.为了使服务作为整体进行操作，它们需要彼此相互了解。

　　2.为了让服务彼此相互了解，必须将其通过硬性方式连接起来，或者能够动态地找到彼此。

　　3.硬编码将很困难，因为这意味着紧密耦合，而且稍后使用其他服务实现进行替换时存在潜在困难。

　　4.那么，为了促进动态发现，服务需要有一个能宣传自己并了解其他服务的地方。

　　5.这当然就是注册中心了！

　　服务注册中心的概念最初是由 Web 服务体系结构组引入的，该团队将统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）注册中心定义为服务使用者和提供者间的“匹配器”。当时确定的 UDDI 的责任是基于使用者所需的功能提供服务提供者动态选择。其角色与黄页类似。尽管多个供应商和标准组织大量推广，但将 UDDI 用于进行服务匹配的用途从来没有实现。今天 UDDI 的主要用途仅限于存储 WSDL 文件，供在使用者的设计阶段使用。

　　服务注册中心一个更为实际的用法是，在运行时基于服务使用者所请求的服务名和策略查找服务。在此情况下，服务定义在使用者开发期间可用，注册中心的使用仅限于服务端点地址和动态绑定的运行时解析。服务端点地址的后期绑定降低了位置耦合。此解决方案消除了在服务使用者实现中硬编码服务端点地址或将其存储到配置文件的需求。此外，注册中心还允许对服务端点地址及关联的调用策略进行集中管理。

　　典型的服务注册中心实现支持以下两个可能的端点地址解析与路由模型之一：

　　直接路由。在此模型中，查询注册中心所需的信息驻留在使用者中。此信息包括一组受支持和需要的策略。注册中心找到匹配的服务后，使用者将决定使用哪个服务并将请求直接路由到此服务。

　　基于中间层进行路由.此模型依赖中间层处理路由。服务使用者并不必直接与服务进行交互。相反，所有服务请求都定向到中间层，中间层借助使用者特定的信息查询注册中心，决定使用哪个服务并动态地将所有请求路由到该服务。此模型与企业应用程序集成（Enterprise Application Integration，EAI）代理类似，后者会接收消息，并基于内部注册中心将其路由到相应的目的地。很多企业服务总线（Enterprise Service Bus，ESB）实现提供对基于上下文的路由中间层模型的支持。

　　下面对这两种方法进行了比较。

　　直接路由

　　优点：提供最佳的调用性能。提供最小的基础设施开销，特别在使用面向消息的中间件（Message-Oriented Middleware，MOM）作为传输时效果更明显。

　　缺点：根据使用者实现不同，更改使用者策略文件可能仍然需要重新启动/重新构建使用者。

　　基于中间层进行路由

　　优点：提供有关如何选择潜在服务的集中决策点，使服务使用者不必存储和处理调用信息。

　　缺点：对于不同的使用者/服务要求不同的SLA的情况，中间层必须能够支持其中最严格的SLA。由于有额外的网络跃点，总体调用性能可能会受到影响。中间层代表了一个额外的（有时候是唯一的）故障点。引入中间层通常要求提供额外的基础设施。

　　存储库还是注册中心？

　　正如我们看到的，服务存储库和服务注册中心在整个企业 SOA 实现中都占有一席之地。服务存储库是企业 SOA 治理的基础，支持对所有服务相关的信息进行集中管理，包括设计、实现和使用构件。服务注册中心是服务位置虚拟化的基础，允许对所有企业服务的位置和调用策略进行集中控制。服务存储库与注册中心的主要区别在于：

　　存储库包括服务的所有设计和开发构件，设计工具在设计和构建时可能会需要这些构件。相反，注册中心包含运行时绑定所需的此信息的子集。

　　服务存储库经过了优化，能存储大量资产和支持大量用户进行临时查询来查找这些资产。在这种情况下，主要设计需求是灵活的分类和查询支持以及存储库本身的可伸缩性及用户友好界面。另一方面，服务注册中心针对服务端点地址的运行时查询进行了优化。主要设计需求是查找性能和高可用性。

　　对存储库的访问在企业边界内进行。相反，经常需要从企业内部和外部访问注册中心。

　　因此，我们最后看到的不是在服务存储库和注册中心之间进行选择，成功的SOA实现中需要同时使用这两者。我们需要决定的是在哪些场合使用哪个的问题。务必要对这两个概念加以区分，因为它们各自有不同的用途。