如何进行SOA运行时的服务监视和管理

日期: 2010-09-14 作者:IBM 来源:TechTarget中国 英文

  服务监视和管理使您能够监视您的服务并提供管理和治理方法,它在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解决方案的架构

  图 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 是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服务的监视和分析

  图 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中的服务概览

  图 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. TEP中的服务概览

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

  ITCAM for SOA平台收集服务的QoS数据,比如这些服务的可用性和性能。

  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。

  WESB将收到一个客户服务请求。客户身份令牌和其他相关信息将被封装到客户请求消息中。

  当接收到消息后,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代码应当拒绝这个端点。

  请求者将被绑定到所选的服务端点并随后调用它。具有低优先权的客户将被路由到第一个服务端点,而高优先权的客户将被路由到第二个服务端点。

  具有高优先权的客户将被路由到第二个服务端点。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  SOA架构师定义服务并将其注册到WSRR。

  安全架构师通过Tivoli? Security Policy Manager (TSPM) 编写安全策略。Tivoli? Security Policy Manager是一款IBM产品,帮助加强应用程序访问、为遵从性提供便利,以及支持在整个IT基础架构中进行运营治理。它可以充当一个策略管理点(Policy Administration Point,PAP)。安全架构师将从WSRR检索服务定义并将策略绑定到服务。

  随后,安全架构师可以分配这些服务并将策略分配给WSRR。WSRR充当一个策略分发目标(Policy Distribute Target,PDT)。

  安全架构师还可以分配这些服务并将策略直接分配给DataPower。那么DataPower将充当PDT。

  不管哪一种组件充当PDT,所有这些服务和分配的策略最终都必须由DataPower订阅。DataPower充当策略增强节点(Policy Enforcement Point,PEP)。在DataPower中将为这种服务创建一个Web服务代理。并且在 DataPower 中还将设置WS-Policy配置参数和WS-Proxy设置。

  客户向该组织提供的服务提交一个请求。该请求将首先被路由到Web Service Proxy,并且必须通过身份验证且遵守由安全架构师定义的策略。此时,DataPower将增强预定义的策略。

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

  首先,对于消息级别的保护来说,SOA架构师希望对企业内的特定消息流增强消息级别的保护。安全架构师将登录到TSPM UI并编写一个策略,该策略要求通过SAML断言对消息进行加密和身份验证。安全架构师随后将这个策略附加到所提供的服务,在TSPM中配置安全性策略并将其从TSPM中分配到WSRR。DataPowe 将被配置为同步WSRR订阅,以从WSRR中检索包含策略的WSDL。安全架构师在DataPower中创建了一个简单的Web服务代理。客户请求将被路由到该 Web 服务代理,这样安全策略将强制服务消息在服务事务调用期间添加消息保护。服务的消费者必须使用一个已被加密的服务请求消息流以及一个已被添加到流中的SAML令牌访问服务提供商。在这种场景中,将利用IBMWebSphere? 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生命周期内监视服务并提供管理和治理方法。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

作者

IBM
IBM

相关推荐

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • SOA治理模型核心:人

    治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。

  • 揭秘New Relic APM技术细节

    New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响

  • 仅凭SOA和云无法解决业务数据管理风险问题

    SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。