|
引言
本文将介绍如何在企业服务总线（Enterprise Service Bus，ESB）环境中（使用 WebSphere Message Broker（以下称为 Message Broker）作为 ESB 实现）使用 WebSphere Service Registry and Repository（以下称为 Registry and Repository）。通过 Registry and Repository，与端点服务交互的 ESB 中介可以更好地支持环境中的更改。在此交互中，ESB 使用 Registry and Repository 作为提供关于服务端点信息（服务元数据）的动态查询机制。这意味着，当服务端点环境中出现更改时，关联的 ESB 中介并不会更改。
Message Broker 和 Registry and Repository 之间的交互由 Message Broker Version 6 Client for WebSphere Service Registry and Repository 提供。有关更多信息及下载此产品扩展的链接，请参见参考资料。扩展中包括一系列 Message Broker 节点，可供在构建 Message Broker 流时使用。这些节点封装对 Registry and Repository 和缓存机制的 API 调用，能提高交互的效率。
本文假定您熟悉 SOA 及 WebSphere Message Broker 的基本概念。
背景知识
SOA 通过重用、松散耦合、灵活性、互操作性、集成和治理提供了业务敏捷性和弹性。在这些方面，SOA 的一个主要支持功能是，将服务描述同其实现分离，并在整个服务生命周期使用与服务描述关联的描述性元数据。基于标准的服务元数据构件（如 Web 服务定义语言 (WSDL)、XML 模式、策略或服务组件体系结构 (SCA) 文档）捕获有关服务能够做什么、如何调用它或它希望其他服务做什么的详细信息。可以将语义注释及其他元数据与这些构件相关联，以提供对潜在服务用户的相关认识，了解如何和何时使用它以及它服务于什么目的。
Message Broker 是提供了强大消息中介功能（包括转换和服务端点路由）的 ESB 实现。常见 ESB 使用模式之一涉及到使用作为组织的公开（或外部提供的）服务构造的中介。这些中介或 Message Broker 流处理传入消息，并就需要在传入消息请求中执行的任务或步骤作出决策。这通常涉及到将传入消息的执行委托给一个或多个服务（称为后端服务）。
Registry and Repository 是用于服务交互端点描述的主元数据存储库。这包括使用 SOAP/HTTP 绑定来实现 WSDL 接口的传统 Web 服务，以及广泛的 SOA 服务，这些 SOA 服务可以使用 WSDL、XSD 和策略声明来进行描述，但是可以使用一系列协议并按照各种各样的编程模型来实现。作为服务元数据的副本，Registry and Repository 建立了用于查找和管理从各种源获得的服务元数据的中心点，这些源包括服务应用程序部署和其他服务元数据及端点注册中心和存储库。其中还包括关于服务端点的最新信息，在关于将 ESB 与服务注册中心集成的后续讨论中这些信息将非常重要。
使用服务注册中心提高 ESB 灵活性
如上所述，常见的 ESB 中介模式是将中介构造为组织的公开（或外部提供的）服务的方式，如图 1 中所示：
图 1. 使用 ESB 的公开服务
中介所委托到的后端服务通常在开发时指定，在消息流开发期间，通常指定关于要使用的各种服务端点的静态信息。随着 SOA 环境的灵活性和响应能力的提高，服务端点定义（元数据）中可能出现大量更改，使得静态定义中介变得极为脆弱。为了更改中介以适应改变的服务端点，可能会带来与开发更改的成本、部署这些新服务的延迟和监视中介更改的潜在业务和操作流程相关的问题。
接下来我们以包含要调用后端服务（如 Web 服务）端点的中介为例。此端点使用静态 RUL 或其他描述服务绑定的元数据表示。在需要进行更改时，如部署新 Web 服务时，中介现在需要调用或部署新的后端服务，而后者需要对传入消息进行转换或采用完全不同的协议实现，那么此静态内容会让中介变得极为脆弱。
您可以通过开发不再依赖于静态定义的服务端点信息来处理中介脆弱的问题。为此，需要能够获得关于服务端点的最新信息的位置，并需要有效访问此信息机制。以前尝试解决此问题时通常都依赖于采用某种形式的数据存储区访问，如关系数据库或队列。这些机制受到很多制约，即其专用性、与中介访问数据库相关的性能问题以及使用手动编码解决方案的维护问题。
服务注册中心（如 WebSphere Service Registry and Repository）能为之前的手动编码机制提供中间件解决方案。您可以从 Registry and Repository 访问关于服务元数据的最新信息，从而让中介免于受到服务元数据（服务端点）更改的影响。例如，通过使用 Registry and Repository，可以确保始终调用特定服务端点的最新版本，或根据输入消息中的某种选择标准选择特定的端点服务。
使用 Registry and Repository 的中介保持了最大的灵活性，因为决策中使用的元数据内容已经外部化，如图 2 中所示：
图 2. 将服务注册中心与 ESB 结合使用
ESB 和服务注册中心交互
ESB 使用服务注册中心获得关于需要调用的服务的元数据。此元数据可以为特定服务端点、受支持的端口类型、满足某个 SLA 需求的服务或其他元数据。在图 3 中，可以看到当在 ESB（本例中为 Message Broker）上调用中介时，ESB 将使用特定的节点处理传入消息，以访问服务注册中心 (Registry and Repository) 中必要的元数据。ESB 然后将使用检索到的元数据设置要调用的正确端点，确定备选执行路径，执行策略或执行其他操作。
图 3. Registry and Repository 在 ESB 中的位置
了解注册中心内容
Registry and Repository 内容模型的最基本构建块是服务元数据构件文档（物理文档），如 XSD 或 WSDL 文件。这些服务元数据文档在 Registry and Repository 中进行存储和管理。任意服务元数据构件类型都可以存储在 Registry and Repository 中；不过，Registry and Repository 为众所周知的以下 SOA 元数据类型提供了高级功能：WSDL、XSD、WS-Policy 和 SCDL。这些类型的服务元数据文档的内容组成了 Registry and Repository 的逻辑模型。该逻辑模型包含各种实体，诸如与 WSDL 文件相关的 portType、port 和 message，以及与 XSD 文档相关的 complexType 或 simpleType。逻辑模型的元素具有属性和关系，用于反映其基础物理文档中定义的特征子集。例如，WSDLService 元素有一个 namespace 属性和一个与它所包含的端口的关系。
Registry and Repository 中还有一种实体，这种实体不严格地称为概念，它是一种通用对象，用于表示 Registry and Repository 中没有物理文档的任何对象。概念可以用于表示某个其他元数据中的内容，如 Portlet 目录中的 Portlet、资产存储库中的资产、源代码库中的服务实现构件或配置管理数据库中关于 SOA 基础设施拓扑的信息。也可以将其用于对物理构件进行分组，以便进行检索等其他工作。
除了与服务元数据文档直接相关的内容外，Registry and Repository 还支持大量用户定义的元数据类型，这些元数据类型用于对服务元数据进行补充，以说明其语义，称为服务描述元数据。Registry and Repository 支持三种类型的服务语义元数据类型：Properties、Relationships 和 Classifiers。用户可以将属性 businessValue 与表示 WSDL 文件的物理模型实体关联，或定义表示 portType 的逻辑模型实体和表示 XML 文档的物理模型之间的新关系 makesUseOf；或者创建分类器 importantThings 并将其与逻辑模型中的 port 实体及表示物理文档的物理模型实体关联。这支持语义查询针对服务元数据的各个元素，以及在做出更改前进行有意义的依赖项分析。
Registry and Repository 的主用户界面是使用 Registry and Repository 运行时部署的 Web 应用程序。此界面支持一组预期用户角色，并提供以下功能：
- 查询、流览和检索
- 发布和标注
- 治理活动，包括导入/导出和影响分析
此用户界面由透视图窗格、导航树窗格和详细信息窗格组成，如图 4 中所示：
图 4. Registry and Repository Web 界面
您可以使用 Web 界面对 Registry and Repository 内容的视图进行自定义。一组用户界面定义文件描述了组成 Registry and Repository 界面的各个组件的内容和布局。另外还支持角色特定的透视图。
针对 Registry and Repository 的 Message Broker 客户端支持
针对 Registry and Repository 的 Message Broker 客户端提供通过两个通用节点对 Message Broker 运行时访问 Registry and Repository 的支持。这些节点可提高 Message Broker 流或中介的灵活性，能够更好地适应企业中的更改，而且不会带来更改、测试和重新部署中介的成本。
第一个用于访问 Registry and Repository 的通用 Message Broker 节点可访问特定 Web 服务的元数据并设置恰当的端点和协议，以便调用服务。此节点称为 SRRetrieveITService 节点，其图标如下所示：
在此节点的 Properties 对话框中，可以指定如何基于各种不同的属性检索服务。例如，特定的服务可以基于其 PortType 名称、命名空间和版本进行检索。名称、命名空间和版本的组合可唯一地表示特定服务。还可以指定基于一组特定标准检索服务实现或端口，如匹配一组特定的用户定义属性或特定分类。有关详细信息，请参见示例。
图 5. SRRetrieveITService 节点的 Properties 对话框
Message Broker 所支持的用于访问 Registry and Repository 的另一个通用节点是 SRRetrieveEntity。此节点用于获取 Registry and Repository 中包含的任意实体的内容。它并不会建立任何与执行相关的环境规定，而是将实体的全部内容向中介提供。中介然后可以根据需要使用此信息。SRRetrieveEntity 节点的图标如下所示：
SRRetrieveEntity Properties 对话框与上面所示类似，只是此节点允许显式访问 Registry and Repository 中的任何实体，而不仅仅是服务。这意味着 Message Broker 流可以获得实体的全部元数据（包括其内容），然后根据需要使用该元数据或内容。例如，Message Broker 流可以使用此节点来访问策略文档，并将其作为内容来执行特定的一组策略。与 SRRetrieveITService 节点类似，SRRetrieveEntity 节点允许按照其 matchPolicy 的指定返回多个实体，这样就允许中介通过单个 Registry and Repository 请求检索多个文档并根据需要使用。
图 6. SRRetrieveEntity 节点的 Properties 对话框
用于调用从 Registry and Repository 获得的 Web 服务的示例 Message Broker 流
让我们假定一个中介需要侦听特定的请求，此请求检索特定 Web 服务的请求，然后执行服务。图 7 中所示的 Message Broker 流可执行这些操作，其中使用内置 HTTP Input 节点侦听请求，使用 SRRetrieveITService 节点从 Registry and Repository 检索特定的 Web 服务，使用内置 HTTP Request 节点进行执行。如果未找到服务，Message Broker 会将消息路由到对应的 Failure 或 NoMatch 输出终端。
图 7. 使用 SRRetrieveITService 节点的示例 Message Broker 流
在此 Message Broker 流的开发期间，使用了 SRRetrieveITService 节点的 Properties 对话框指定用于查找在运行时检索和执行的特定Web 服务的条件，如图 8 中所示。在我们的示例中，Properties 对话框执行检索 PortType Name 为 DemoCustomer 且 PortType Namespace 为 http://demo.sr.eis.ibm.com 的 Web 服务。而且，检索到的服务还必须包含用户属性 policy 和 country（值分别为 RM 和 USA），且必须分类为 http://eis.ibm.com/ServiceRegistry/BusinessDomain/GenericObjectTypes#CustomerRelated。只会检索满足所有这些条件的服务。最后，此对话框指定 Match Policy 为 One，即只会检索满足所有这些条件的单个服务。如果不能在 Registry and Repository 中找到请求的服务，则将消息路由到节点的 NoMatch 终端，并由 Post NoMatch Message Broker ComputeNode 处理执行工作。
图 8. 示例流中的 SRRetrieveITService 的 Properties 对话框
上面所示的 SRRetrieveITService 节点的 Properties 对话框指定应该检索的服务。您可以使用 Registry and Repository 控制台验证将检索的服务。为此，请选择 Service Metadata => PortTypes，以显示所有注册的端口类型，然后选择指定的服务（我们的示例中为 DemoCustomer）。在详细信息窗格中，可以确认名称和命名空间满足 Message Broker SRRetrieveITService 节点属性中指定的条件，如图 9 中所示：
图 9. 示例流中使用的 portType 的 Registry and Repository 详细信息视图
在此示例中，Message Broker 节点的属性还指定检索具有特定用户属性的服务。您可以使用 Registry and Repository 控制台来检查这些用户属性的端口（本例中为 DemoCustomer），如图 10 中所示：
图 10. 示例流中使用的用户属性的 Registry and Repository 详细信息视图
最后，可以使用 Registry and Repository 控制台检查端口是否包含指定分类，如图 11 中所示：
图 11. 示例流中使用的分类的 Registry and Repository 视图
在此示例中，我们已经了解了 Message Broker 节点的属性中指定的值如何用于基于一组特定的条件定位和检索 Registry and Repository 中定义的服务。通过使用 Registry and Repository 控制台查看服务的 Location（如图 12 中所示），可以标识要调用的实际服务（在本例中为一个 Web 服务）：
图 12. 示例流中使用的 WebService 端点的 Registry and Repository 视图
如果需要更改此 Web 服务的端点，将需要更改原始物理文档（例如，WSDL）。然后可以在不影响 Message Broker 流的情况下将其重新导入 Registry and Repository。执行中介时，将会从 Registry and Repository 检索更新后的端点。
用于访问任意 Registry and Repository 实体的示例 Message Broker 流
在图 13 中所示的此示例 Message Broker 流中，SRRetrieveEntity 节点用于从特定实体检索所有元数据内容。这可以为 Registry and Repository 中包含的任何实体（如策略文档）。示例流然后使用内置 ComputeNode 显示所检索的示例的内容（仅用于进行演示）。在实际的流中，流应该使用实体的内容来执行其他逻辑或执行特定的策略。
图 13. 使用 SRRetrieveEntity 节点的示例 Message Broker 流
如前面的示例中所示，节点属性（本例中为 SRRetrieveEntity 节点的属性）用于在 Registry and Repository 中定位和检索满足指定条件的实体。如果满足这些条件，将检索实体的所有元数据并将其存储在 Message Broker LocalEnvironment 中。内容或元数据的任何部分都可以随后供 Message Broker 流使用。图 14 显示了在执行 SRRetrieveEntity 节点后 Message Broker LocalEnvironment 的示例内容：
图 14. 执行 SRRetrieveEntity 节点后的 Message Broker LocalEnvironment 示例
总结
正如本文中提到的，ESB 容易受到其交互的服务元数据更改的影响。这是因为服务端点信息在构建时以静态方式存储在 ESB 中介中。对此元数据的更改可能会给企业带来极大的时间、效率和响应能力损失。对利用 SOA 的动态潜能感兴趣的开发人员会发现这一点碍手碍脚，从成本的角度是不能接受的。不过，通过使用服务注册中心来检索此元数据，可以构建更为灵活的 ESB 中介，降低其脆弱性，从而得到相对不易受到更改影响的总体环境。通过 WebSphere Message Broker 和 WebSphere Service Registry and Repository，可以提高 ESB 的动态性和灵活性，能更好地适应企业的需求。就业务而言，这意味着能在减少总体成本的同时提高响应能力。
|
