运行时的服务监视和管理

概述

服务监视和管理使您能够监视您的服务并提供管理和治理方法，它在 SOA 的整个生命周期中变得日益重要。它允许组织对已部署的服务进行控制，并灵活地安排服务部署和交互来满足业务需求。这可以实现对生命周期的有效管理，而这又是 SOA 治理的关键目标。本文将介绍一款基于 IBM 产品的服务监视和管理框架 IBM Services Monitoring and Management（简称 ISMM）。这些产品包括 IBM® WebSphere® Service Registry and Repository V6.2、IBM® Tivoli® Composite Application Manager for SOA V7.1.1、WebSphere® Application Server V7.0 和 Tivoli® Security Policy Manager V7.0 以及 WebSphere DataPower V3.7.3，本文将演示它们的新特性。更重要的是，如今日益严重的服务安全性问题也将通过 ISMM 解决。

SOA 生命周期中遇到的问题以及 ISMM 解决方案架构

随着面向服务架构（SOA）的广泛应用，业务变得越来越灵活，业务流程越来越动态，交互越来越容易，成本越来越低。与此同时，也在不断涌现新的问题。企业并没有从 SOA 获得他们所预期的所有优点。

遭遇的第一个问题就是如何像其他任何资源一样管理和控制服务。服务是企业内部的宝贵资产。必须像管理其他任何资源那样对服务进行管理。但是目前而言，服务的监视和管理是非常困难的任务。几乎没人知道究竟存在多少服务，它们位于哪些位置，它们可以做什么。IT 组织不具备有关服务的使用和状态的信息，也没有办法了解哪些服务正在运行。大量的服务被两次或多次地重复。这些重复的 Web 服务必须被标识出来。因此，必须收集和分析服务使用统计数据。唯有这样，才能实现降低 SOA 维护成本的承诺。

第二个问题是如何监视和利用服务质量（QoS）。业务流程中使用的服务不可能是静态的。在某些环境下，必须在运行时从基于 QoS 的服务集中选择服务。此时只应该使用可用的 Web 服务。甚至不能尝试调用离线的 Web 服务。有时，我们需要发现表现很差的服务端点并根据配置的阈值将它们变为不可用。因此，服务调用可以根据 QoS 路由。

第三个问题是如何动态的报告服务的健康情况和警告。客户需要在业务级别来监视服务的健康指标，从而帮助识别是否出现 Service Level Agreement（SLA）违背和服务中断，并找到一种方法来呈现这些指标。此外，在检测到违背时必须自动发送警告，以提醒管理员采取相应措施。

第四个问题是如何解决安全性问题。企业意识到服务不能够在内部使用，因为它们是不可信的。还存在许多来自外部访问的安全威胁。由于缺乏安全性，他们不能够将服务公开给客户、合作伙伴和供应商。由于合作伙伴需要访问多个身份验证和授权系统，因此服务的使用变得非常的繁琐。因此，服务安全性问题也成为亟待解决的一个重要问题。

为了解决这些问题，基于 IBM 产品和解决方案的 IBM Services Monitoring and Management Framework 应运而生。下面是 ISMM 解决方案的架构。

图 1. ISMM 解决方案的架构

图 1 是ISMM 解决方案的设计架构 ISMM。我们将它分为三个层次。第一层是客户层。在这个层中，服务可以被提供给客户和业务合作伙伴。考虑到安全性，我们需要对服务请求进行身份验证和授权，因为我们添加了一个 DMZ (Demilitarized Zone) 作为第二层，用以实现授权和身份验证。

在企业内部是 Enterprise 层，这是最重要的一层。Directory Server 存储用户概要文件并提供一个可信的身份数据基础架构来实现身份验证。Process Servers 是一个高性能的业务流程自动化引擎，用于帮助生成符合企业目标的流程。Enterprise Service Bus（缩写为 ESB）帮助实现成本更低的快速灵活的应用程序集成，并与下一代互联性（interconnectivity）建立联系。Process Servers 和已部署的 ESB 还有助于根据 QoS 动态判断要使用的服务。

Service Registry & Repository 为 SOA 服务、策略和相关元数据提供了服务可视性和治理（Service Visibility and Governance），以及对 SOA 治理的支持。安全性策略（Security Policy）帮助增强应用程序访问、为遵从性提供便利，并支持在整个 IT 基础架构中进行运营管理。所有这些组件都基于 IT Service Management (ITSM)，后者对您的 SOA 生命周期进行监视，从而确保高可用性和性能。ITSM 提供了集成的管理工具，可以加速并简化 SOA 问题的识别和解决。

图 2. ISMM 解决方案的产品映射

图 2 是 ISMM 解决方案的产品映射。您可以将图 2 中的每一个产品映射到图 1 中的对应组件。WebSphere® DataPower SOA Appliance 在这里用作安全网关，用于对服务请求进行身份验证和授权。Tivoli® Directory Server 此处用作 Directory Server，用于存储用户概要文件。WebSphere® ESB 被作为 ESB 使用，用于实现基于 QoS 的服务选择和路由。WebSphere® Service Registry and Repository 产品此处用作 Service Registry and Repository 组件，用于实现服务注册和管理。Tivoli® Security Policy Manager 在这里被用作 Security Policy 组件，用于管理安全性策略。Tivoli® Composite Application Manager for SOA 平台作为 ITSM，用于监视和管理 QoS 数据。

我们的 ISMM 解决方案可以通过这些 IBM 产品实现，使您能够在整个 SOA 生命周期内监视您的服务并提供管理和治理方法。

“Rogue 服务” 的控制和消除

图 3. Rogue 服务的监视和分析

服务必须像其他任何服务那样进行管理。只有这样，才能监视服务并解决问题。ITCAM for SOA 平台只能够监视已调用的服务并收集这些服务的使用情况、性能和可用性元数据。WSRR 是服务的注册和存储库中心，服务必须被注册到 WSRR 中。在这种场景下，使用 Discovery Library Adapters（简称为 DLA）来传输这些元数据，DLA 是一个特殊的程序，它从源应用程序提取数据并使用 Identity Markup Language XML 格式生成一个名为 discovery library adapter book 的 XML 文件。当 DLA 生成一个 DLA book 文件后，用户可以将这种文件加载到 TCORE 并在 Tivoli® Enterprise Portal 上显示它。这个文件包含服务、服务端口、操作、业务流程以及部署这些内容的应用服务器和计算机系统之间的关系。ISMM 中使用了两种源，一种是 ITCAM for SOA，其中包括运行的服务信息，另一种是 WSRR，其中包括已注册的服务的信息。您可以查看 ITCAM for SOA 信息中心获得更多细节。

当成功加载 DLA Books 后，将在 ITCAM for SOA 上自动构建服务到服务之间的关系和拓扑结构。服务使用情况、注册状态、流和关系都将显示在 Tivoli® Enterprise Portal 上。

可以从图 4 看到，Rogue 服务就是那些被标以红色矩形的服务。这些服务表示已被 ITSM 观察到但尚未注册到 Service Registry and Repository 中的服务。这类服务被称为 Rogue 服务。你还可以找到已注册到 WSRR 但一直没有被调用的服务。如图 4 所示，这类服务使用黄色矩形标识，并被称为 shelf-ware 服务。shelf-ware 服务的数量越少，SOA 解决方案的实现越好。还有其他一些服务，它们只被观察到但未进行注册，可以将之称为 Rigid 服务。Rigid 服务不受控制并将破坏服务管理。因此必须消除这类型的服务。

图 4. TEP 中的服务概览

通过上面的流程，可以识别出重复的 Web 服务，并且可以报告未使用的服务，从而限制 shelf-ware 服务的数量。IT 组织将能够了解已部署服务的使用情况并了解哪些服务正在运行。只有这样，才能够实现降低 SOA 维护成本的承诺。

---

回页首

监视和利用服务的 QoS

服务质量（QoS），比如性能和可用性，可以被收集并加以利用，以实现动态的服务端点解决方案。由于业务变得越来越动态，业务流程中使用的 Web 服务不可能一成不变。必须在运行时从一个外部服务注册表中定义的服务集中选择 Web 服务。并且，我们还需要服务可用性管理。应该只使用可用的 Web 服务，甚至不能尝试调用任何离线的 Web 服务。因此，必须发现表现较差的服务端点并根据配置的阈值使其不可用。

通过 ISMM 解决方案，使用 WSRR、ITCAM for SOA Platform 和 Enterprise Service Bus，ESB 可以使用一个中介（mediation）从 WSRR 动态检索服务健康消息来发送服务请求，确保服务具有满意的质量。并且 ITCAM for SOA Platform 将监视运行中的服务并更新 WSRR 中的服务元数据，以为性能、可用性等反映当前运行时状态。

图 5. TEP 中的服务概览

图 5 展示了对备选服务统计数据的检索以及某个服务端点的动态选择和延迟绑定。可以从图 5 中看到，ITCAM for SOA 平台、WebSphere® Enterprise Service Bus、WebSphere® Service Registry and Repository 在这个场景中都得到了使用。根据客户的请求动态选择了提供商服务。完整的过程为：

1. ITCAM for SOA 平台收集服务的 QoS 数据，比如这些服务的可用性和性能。
2. ITCAM for SOA Integration Module 将所有收集的 QoS 数据同步到 WSRR 以更新相应的服务元数据。可以参考 ftp://ftp.software.ibm.com/software/integration/support/supportpacs /individual/sa04_UserGuide_6.0.2.pdf，详细了解 ITCAM for SOA Integration Module。
3. WESB 将收到一个客户服务请求。客户身份令牌和其他相关信息将被封装到客户请求消息中。
4. 当接收到消息后，ESB 将从 WESB 中读取策略消息和属性，执行一种匹配算法，并根据环境中已观察到的服务质量选择将要使用的服务。您可以紧接着 WESB 的 Endpoint Lookup 原语之后添加一个 “Custom Mediation” 原语，“Custom Mediation” 将对 WSRR Endpoint Lookup 结果分类并选择 “最快的” 端点。在选择 “最快的” 端点时，“Custom Mediation” 原语中的 Java™ 代码将根据 WSRR “ResponseTime” 属性的升序对 Endpoint Lookup 结果排序，并将路由目标（目标 url）设置为具有最低 “ResponseTime” 的 URL。这个 “Custom Primitive” 还有一个可提升的属性（例如 “ResponseLimit”）。在上面的 Java 代码中，如果 WSRR “ResponseTime” 大于这个可提升的属性（“ResponseLimit”），那么 Java 代码应当拒绝这个端点。
5. 请求者将被绑定到所选的服务端点并随后调用它。具有低优先权的客户将被路由到第一个服务端点，而高优先权的客户将被路由到第二个服务端点。
6. 具有高优先权的客户将被路由到第二个服务端点。

动态报告服务健康状况和警告

服务水平协议（SLA）是服务提供商和客户之间达成的一个正式约定，确保网络性能可以被量化并维持在一个指定的水平。然而，性能较差的服务端点常常导致 SLA 无法被满足。必须对生产环境中的服务进行监视和管理，以确保它们能够满足其服务水平协议。

在 ISMM 中，IBM Tivoli® Composite Application Manager for SOA（简称为 ITCAM for SOA）平台还可以被用于允许运营商在业务级别监视服务组，以对 SLA 违背和服务中断划分优先级。您可以使用 Tivoli® Enterprise Portal（简称为 TEP）来查看由 ITCAM for SOA 提供的信息并判断引起服务运行时问题的根本原因。

首先，许多服务组将被创建，如图 6 所示。一个服务组就是一组相关的服务操作，它们联合起来表示或封装您的企业内的一个业务功能或应用程序。它可能包含一个服务流、一个流的子集或任何操作集，表示所监视环境中对您有意义的内容。

图 6. 服务健康状况的客户视图

如果服务组的默认状态是健康的，那么意味着该组中的所有服务都没有出现问题。这将使用一个绿色的选中标记标识。服务组对象将显示一些健康指标，比如性能（响应时间，以秒为单位）数据和数量（消息数），后者每 2.5 分钟计算一次（默认）并显示在服务组视图中。如果这些指标超出了由运营者定义的阈值，那么将会触发某些场景并激活警告。

服务组的不可用性正是基于这类场景，这与服务组的前端服务有关。这些定制的场景通常使用由 ITCAM for SOA 提供的服务不可用性属性和指标。

图 7. 不健康服务组的警告

服务组目前已经成功进行了定义。所有服务性能和容量数据都可以显示在此视图中。如果所监视的服务组出现了异常，警告将被触发并显示在视图中。如图 7 所示，一个名为 VerifyCreditServiceGroup 的服务组被标记以一个巨大的红色叉号。这表示该组中的某些服务处于较差的性能状态并且会导致关键场景被触发。您可以下钻（双击带有红色叉号的节点）到 Interaction Detail 视图来查看该组中的每一个服务的详细状态，以找出发生的问题。

ISMM 可以在服务水平协议被违背之前为其提供更好的管理和主动监视，并向管理员发出有关任何潜在问题的警告。ISMM 还支持使用运行时指标，以供稍后在高级场景中进行服务选择时使用。

基于策略的服务安全性管理

在 SOA 的实现过程中，几乎每时每刻以及每一个位置都会发生与安全性有关的问题。服务不能在内部使用，因为它们无法取得信任。来自外部访问的安全威胁导致投资流失，因而对我们的业务造成很大的影响。由于不能保证安全性，您无法将服务公开给客户、合作伙伴和供应商。如果按照传统的方式解决这些问题，那么服务的使用将变得非常复杂，因为需要使用多个身份验证和授权系统来实现合作伙伴访问。要利用如此多的服务来在各种不同的业务背景下获得最大的商业效益，必须谨慎考虑的一个因素就是安全性策略管理。您的最佳选择就是 ISMM。这些问题都可以通过 ISMM 解决。

图 8. 基于策略的服务安全性管理

在 ISMM 中，将通过创建和管理策略来控制身份验证和对 Web 服务的消息级别的保护。还提供了通过策略实现的服务安全访问控制。如下面所述，一个基于策略的服务安全管理的典型流程可以分为五大步骤。

1. SOA 架构师定义服务并将其注册到 WSRR。
2. 安全架构师通过 Tivoli® Security Policy Manager (TSPM) 编写安全策略。Tivoli® Security Policy Manager 是一款 IBM 产品，帮助加强应用程序访问、为遵从性提供便利，以及支持在整个 IT 基础架构中进行运营治理。它可以充当一个策略管理点（Policy Administration Point，PAP）。安全架构师将从 WSRR 检索服务定义并将策略绑定到服务。
3. 随后，安全架构师可以分配这些服务并将策略分配给 WSRR。WSRR 充当一个策略分发目标（Policy Distribute Target，PDT）。
4. 安全架构师还可以分配这些服务并将策略直接分配给 DataPower。那么 DataPower 将充当 PDT。
5. 不管哪一种组件充当 PDT，所有这些服务和分配的策略最终都必须由 DataPower 订阅。DataPower 充当策略增强节点（Policy Enforcement Point，PEP）。在 DataPower 中将为这种服务创建一个 Web 服务代理。并且在 DataPower 中还将设置 WS-Policy 配置参数和 WS-Proxy 设置。
6. 客户向该组织提供的服务提交一个请求。该请求将首先被路由到 Web Service Proxy，并且必须通过身份验证且遵守由安全架构师定义的策略。此时，DataPower 将增强预定义的策略。

ISMM 中审查和检验了三种类型的安全策略 —— 消息级别的保护、基于角色的授权以及基于规则的授权。

首先，对于消息级别的保护来说，SOA 架构师希望对企业内的特定消息流增强消息级别的保护。安全架构师将登录到 TSPM UI 并编写一个策略，该策略要求通过 SAML 断言对消息进行加密和身份验证。安全架构师随后将这个策略附加到所提供的服务，在 TSPM 中配置安全性策略并将其从 TSPM 中分配到 WSRR。DataPower 将被配置为同步 WSRR 订阅，以从 WSRR 中检索包含策略的 WSDL。安全架构师在 DataPower 中创建了一个简单的 Web 服务代理。客户请求将被路由到该 Web 服务代理，这样安全策略将强制服务消息在服务事务调用期间添加消息保护。服务的消费者必须使用一个已被加密的服务请求消息流以及一个已被添加到流中的 SAML 令牌访问服务提供商。在这种场景中，将利用 IBM WebSphere® DataPower 设备作为策略决策点（Policy Decision Point，PDP）和策略实施点（Policy Enforcement Point，PEP）。

其次，对于基于角色的授权，安全架构师将从注册表发现并导入服务，将角色映射到现有的身份系统 —— IBM Tivoli® Directory Server，然后编写、配置安全策略，并将安全策略从 TSPM 分配到 DataPower。如果客户不属于角色的成员之一，那么客户对服务的请求将被拒绝。安全架构师可以修改角色的成员关系以将角色授予客户。只有这种情况下，客户才可以访问这些服务。例如，UpdateEmployeeSalary 服务被用来更新员工的基本工资，并且只能够被具有 Manager 角色的人访问。Jack 是这家公司的员工。他无权访问这个 UpdateEmployeeSalary 服务，因为他不是 “Manager”。在这个场景中，IBM WebSphere® DataPower 设备被作为策略决策点（PDP）和策略实施点（PEP）。

第三，对于基于规则的授权，规则将要求具有特定的权限。安全架构师可以编写一个规则，表示具有某些条件和权限才能访问提供的服务。

结束语

由 ISMM 实现的服务监视和管理展示了服务组件以及服务和业务流程的生命周期内的治理决策。ISMM 帮助我们理解 SOA 治理、安全性和管理的关键方面。ISMM 还帮助我们描述了 IBM SOA Foundation 产品，这些产品为 Runtime for SOA 的服务治理提供了集成解决方案。您可以理解如何使用 ISMM 在运行时实施某些治理。ISMM 使您能够在整个 SOA 生命周期内监视服务并提供管理和治理方法。

<!-- CMA ID: 517809 --><!-- Site ID: 10 --><!-- XSLT stylesheet used to transform this file: dw-article-6.0-beta.xsl -->

参考资料

学习

• “Use SLAs in a Web services context, Part 1: Guarantee your Web service with a SLA”（developerWorks，2004 年 10 月）是应当被归入 SLA 的一份指南，它给出了一些在将 Web 服务作为已公开的服务（包含到 SLA 中）投入到生产环境之前对其进行 SOAP 互操作性测试的例子。
  
  
• 进一步了解 WebSphere Process Server。
  
  
• 进一步了解 WebSphere Enterprise Server Bus。
  
  
• 进一步了解 WebSphere Service Registry and Repository。
  
  
• 进一步了解 Tivoli Security Policy Manager。
  
  
• 进一步了解 Tivoli Composite Application Manager for SOA。
  
  
• 查阅 信息中心，了解 Tivoli Composite Application Manager for SOA。
  
  
• 进一步了解 Tivoli Security Policy Manager。
  
  
• 在 developerWorks 的 SOA 和 Web 服务专区 中，获得增强架构技能所需的资源。
  
  
• 浏览 技术书店，获得有关这些主题和其他技术主题的图书。
  
  

获得产品和技术

• 下载 IBM 产品评估版 或 在线试用 IBM SOA Sandbox，开始使用来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

原文：http://www.ibm.com/developerworks/cn/webservices/ws-servicemonitoring/?ca=drs-tp4608