|
摘要：“有关管理连接系统的 Microsoft 体系结构系列文章”力求向业务、解决方案和基础结构架构师介绍一种管理连接系统的整体性和集成性方法，以便获得更好的性能、可追究性和业务结果。作者们提出并开发了一个框架，以寻求在整个服务生存期协调人员、过程和技术问题的方式，同时提供对 Web 服务目标的简单看法，并分析了 Web 服务生存期管理、Web 服务运行状况管理、Web 服务部署以及 Web 服务标识和访问管理等问题。 本页内容
摘要本文档分析管理连接系统中 Web 服务的体系结构问题。同时兼顾了“动态系统计划”和连接系统更为广泛的背景。本文还从资源和业务协作角度思考了 Web 服务的业务目标，以及应该如何管理该服务以达到这些目标。并且提出了一个 Web 服务管理框架，该框架旨在解决下列主题：Web 服务生存期、Web 服务运行状况管理、Web 服务部署管理以及 Web 服务标识和访问管理。 致谢非常感谢 Nelly Delgado 在本文技术写作方面的帮助，感谢 Claudette Siroky 负责制图，感谢 Tina Burden McGrayne 负责副本编辑。 作者们还希望感谢 Michel Burger、Bala Balabaskaran 及其 Connected Services Framework 项目同事对资源建模讨论做出的贡献。 简介像大多数重要的 IT 计划一样，管理 Web 服务要求对人员、过程和技术进行均衡协调。 本文，我们首先提供便于讨论以下内容的背景知识：连接系统具有的突出特征，以及识别 Web 服务在连接系统中起的作用。然后，我们简单介绍“动态系统计划”，以便为管理分布式应用程序（如，连接系统）方面的复杂任务，提供深层次的背景知识。 接下来，本文介绍如何确定 Web 服务的实际目标，以帮助更有条理地阐明管理 Web 服务的原因和方式。我们考虑从多个角度进行说明，包括资源角度和业务协作角度。 基于模型的开发和管理方法建议，可以将处理管理状态、操作和规则的 Web 服务管理框架叠加到现有的 IT 服务管理系统之上。 我们提议并开发了这样一个框架，以寻求在整个服务生存期协调人员、过程和技术问题的方式。在从一个 Web 服务目标的角度进行简单考察后，我们分析 Web 服务生存期管理、Web 服务运行状况管理、Web 服务部署以及 Web 服务标识和访问管理等问题。 什么是连接系统？从最一般的意义上讲，分布式系统是一组协同工作以完成常见功能的相关软件和硬件资源。 存在很多不同类型的分布式系统。计算机网络、群集数据库、大规模并行计算机和万维网都是分布式系统的示例。一种特定类型的分布式系统是分布式应用程序。其中，组件以透明且一致的方式就一组相关的计算任务进行协作。 连接系统是一种新兴的分布式应用程序类型。现在，随着企业所有者和开发人员寻求将人员、过程和信息结合到有效的价值链中，这种类型的应用程序越来越常见。连接系统的特征在于它们如何以类似且一致的方式组合多种反复出现的逻辑功能。这些功能包括内容丰富的用户-计算机交互、使用 Web 服务的面向服务消息处理、过程和工作流编排、标识和访问控制、共享数据以及联合。 连接系统中的每个组件都完成自己的那部分工作，以便协作完成分布式应用程序中的任务集。一个或多个组件可能提供丰富的用户界面。其他组件可能帮助协调工作流。一个组件可能充当标识服务提供者。对连接系统而言，没有必需的功能，也没有有关它的组件必须如何协同工作的规则。相反，连接系统只是一个将一组常见逻辑功能组合起来以实现其预期功能的分布式应用程序。 连接系统的这一动态和有机特征非常强大。连接系统可以随着业务需要的变化而发展；例如，系统可以轻松地扩展它的角色 — 从仅为一个小部门服务到同时为很多个组织服务。然而，只将几台计算机连接在一起的连接系统具有与范围大得多的连接系统相同的体系结构特点。 连接系统的一个特别显著的特点是：无论其作用如何特殊，每个组件都使用面向服务的方法设计并利用 Web 服务与其他组件通信。 对于该面向服务方法造成这一区别的原因，Don Box 提出了深刻的见解（Don Box：A Guide to Developing and Running Connected Systems with Indigo）： 面向服务的开发专注于从一组自治服务中生成的系统。…这一区别对人们进行的有关开发体验的假设具有深刻的影响。一组已经部署的服务是一个系统。生成单个服务的目的是使其长期发挥作用 — 给定服务的可用性和稳定性很关键。生成服务的聚合系统，其目的是为更改留有余地 — 系统必须适应在已经部署原始服务和客户端之后很长时间才出现的新服务，并且这些服务不得破坏功能。 对于连接系统的面向服务方面，以及它与这些系统逐渐成为企业特别有用的分布式应用程序之间的关系，Mike Burner 也发表过评论。（Mike Burner, Service Orientation and Its Role in Your Connected Systems Strategy。） 连接系统的管理难题在考虑如何管理这种系统时，连接系统的动态和组织特征带来了一个概念性的难题，因为它使得弄清楚整个问题的答案变得很困难。一些难以回答的简单问题包括：如何确定所讨论的连接系统实际上是什么；它应该如何运行；以及它应该由谁来使用。而且，因为这些都是管理问题，所以很多更复杂的有关策略、控制和生存期的问题也随之而来。这些问题包括：组织中的哪个人有权决定连接系统是什么；组织中的哪个人有权决定连接系统应该如何运作；以及组织中的哪个人负责在连接系统的整个生存期中了解和管理它的复杂性。 领会有机、动态连接系统，以及构成它们的更为静态和精确的 Web 服务之间的区别很有必要，这不仅对开发体验具有深刻影响，而且对于解决这些管理问题的方式也具有深刻影响。 答案是，从不同的角度来考察如何管理 Web 服务以及使用它们的连接系统。有关连接系统的所有管理问题也适用于构成该系统的 Web 服务。区别在于：尽管对于连接系统很难回答这些问题，但对于更为静态和准确的 Web 服务，这些问题却很容易解决。 虽然这种利用不同角度的方法可通过分解问题空间提供帮助，但它也带来了其他难题。特别是，具有不同的角度不应该意味着让不同的、昂贵的管理系统来处理每个角度的问题。我们需要的是可以支持这些不同的管理角度，同时又能控制一个共同的人员、过程和技术基础的整体性体系结构。 目前的 IT 服务管理系统 在目前的 IT 服务管理系统中，技术的复杂性已不是组织必须克服的唯一问题。服务管理过程的质量也会影响它们的运作能力。在很多情况下，可以将问题提炼为技术和过程中的可见性和控制问题以及用户的能力。有效的 IT 服务管理是将人员、过程和技术融合在一起。 组织的服务过程和技术的成熟度是实现这一目标的关键。当前，该行业中已经拥有了多种服务管理过程最佳做法和规范。 IT 基础结构标准库（Infrastructure Library，ITIL）是一种广为接受的 IT 服务管理方法。（IT 基础结构标准库 ITIL 是 OGC（英国商务部）的注册商标。有关 ITIL 的详细信息，英国标准化协会编撰了在 IT 服务管理 BS15000 标准中的 ITIL 中提出的最佳实践过程ITIL 过程抽象包括由一组功能角色执行的一系列任务。规则集合控制如何用表示为真实对象 (RWO) 的给定输入和预期输出来完成那些任务。随后，ITIL 服务管理功能中的过程派生自这一过程定义。 Microsoft 操作框架（Microsoft Operation Framework，MOF）是一种派生自 ITIL 和多种其他服务管理方法的规范。它包含对适合于自动执行过程的 Microsoft 产品和解决方案的修改和内联引用。MOF 定义一个用于管理更改、操作、支持和优化的高级循环过程。每个过程都包含一组由定义良好的子过程驱动的服务管理功能。 Microsoft 解决方案框架（Microsoft Solution Framework，MSF）包含两个模型，帮助指导企业通过提供 IT 解决方案来实现它们的市场远景。其中一个模型捕获团队视图，另外一个模型呈现过程视图。团队模型描述一个角色群集集合。每个角色群集都定义一组要执行的相关作业功能。过程模型旨在规定从捕获市场远景和需求到部署 IT 解决方案的逻辑步骤序列。这两个模型之间的交叉关系将各个角色执行的任务突显到过程阶段。 基于模型的管理 在目前的 IT 管理系统中，大量用于配置、诊断和调整 IT 系统的知识都储存在少数 IT 技术人员的大脑中。 这种以人为中心的模型有很多缺点：
一种被称为“基于模型的管理”的替代方法试图解决上述问题。基于模型的管理主张使用高度结构化的信息模型来捕获管理的意图和预期结果。该方法鼓励对获得预期管理结果所需的规范和任务进行主动的预先考虑。而且，该方法试图确定要在发生偏差时利用的缓解策略。 基于模型的管理是“动态系统计划”(DSI) 的核心。DSI 是为开发这样的整体性体系结构而制定的，并且专门适合于管理。DSI 是 Microsoft 及其合作伙伴的一项计划，旨在帮助 IT 团队捕获和使用知识，以便设计更加易于管理的系统以及自动执行持续性的操作。DSI 与生成便于在 IT 系统的整个生存期内创建、修改、传输和操作该系统的知识的软件有关。下列核心原则 — 知识、模型和生存期，是解决 IT 组织目前面临的复杂性和可管理性难题的关键。 下面，我们简单介绍一下 DSI；随后，我们将向读者介绍其他 DSI 信息，以获得有关从连接系统角度提出的管理问题的详细指导。在本文的其余部分中，我们将从 Web 服务的角度出发，将 DSI 置于聚焦于管理问题的背景中。 动态系统计划注 这里提供的关于 DSI 的信息节选自 Dynamic Systems Initiative Overview White Paper，您可从那里获得更多信息。 在二十世纪九十年代中期，Microsoft Research 的一个小组启动了一个重点项目，以分析中型企业和事业型企业客户在其 IT 环境中面临的运营难题。他们的目标是了解客户面临的巨大复杂性的核心驱动因素，并且设计一个能够有助于大大降低相关运营成本的软件解决方案。 在这些环境中，显然客户运行的应用程序已经演变并具有更高的分布式和面向服务特征。同时，低成本、高容量的行业标准硬件（如负载平衡器、交换机、服务器和集中式存储）已经成为这些应用程序的常见构造块和必要组成部分。这些分布式应用程序的定义绝不仅仅包含软件。 这些分布式系统的特征导致复杂性急剧地增加，并且该复杂性跨越了整个应用程序生存期。设计新系统需要大量时间和跨团队协调。部署这些新系统需要购买新硬件，并且涉及对开发工作进行多次迭代以便优化系统。运营工作的手动特征要求一些企业花费其 IT 预算的 70% 到 80% 来维护现有系统。（Accenture IT Spending 调查。） 尽管较大型企业客户对这些问题的感受更为深刻，但很多中小型企业也开始面临类似的难题。 DSI 技术原理 从核心技术角度来看，DSI 即将生成的软件支持在 IT 系统的整个生存期中创建、修改、传输和操作该系统的知识。 知识对于系统管理至关重要，这些知识包括：已部署系统的知识、系统操作环境的知识、系统设计者意图的知识以及 IT 策略的知识。 特别需要指出的是，知识可能包括：
因为 IT 组织在地理上变得更为分散，并且个人作用变得更为专业，所以他们倾向于在一个封闭的环境中运营，从而使得在 IT 生存期中交流相关的系统知识变得越来越困难。结果，组织发现非常难于跨角色协作、促进系统的设计和操作不断改进，以及执行部署、更新、修补等典型的管理任务。 在 IT 组织中形成的封闭环境，在应用程序或系统的生存期中的某个时刻与其进行交互。但是，每个封闭环境都拥有它自己的系统相关知识块,这些知识无法与该组织的其余部分有效交流。 在软件模型中捕获知识 软件模型可以用来捕获这一系统相关知识，并且促进这一知识的交流和协作 — 这是提高整个 IT 生存期的效率所需要的。 有生命的软件模型 软件模型为管理员提供了某种级别的抽象，其意义类似于蓝图之于建筑师或原型之于汽车设计师。但是，对于动态的和分布式软件环境而言，静态模型或蓝图是不够的。该模型必须是有生命的 — 它必须在系统的整个生命周期中不断演进。 在开发系统时，将定义基本规则和配置。随着该系统的部署，将添加它的配置、环境约束和要求的详细信息。在开发或增强操作最佳做法时，也可以将它们合并到模型中，从而在操作人员和模型之间提供反馈循环。最后，该模型成为一个有生命、动态的蓝图，它根据完整的分布式系统的结构、行为和特征来捕获有关该系统的知识。 请考虑一下在汽车中踩下油门时的体验。用户（此情况中为驾驶员）具有一个映射到所需行为（例如，让汽车跑得更快）的高级别抽象视图（模型）。在踩油门这一简单操作的背后，系统（此情况中为汽车控制系统）负责调整燃油吸入定时、排气阀定时、档位选择等，同时考虑发动机速度和气压等约束。它实质上是按照驾驶员的指示执行模型上的更改。 在这些动态模型中捕获知识有哪些好处呢？
软件模型支持的功能 当使用软件模型捕获所有相关系统知识时，IT 组织和 IT 系统的多项关键功能成为可能。 针对操作进行设计 创建任务关键的软件时，应用程序架构师经常需要与其负责指定数据中心体系结构的同事进行交流。在提供解决方案的过程中，人们经常发现应用程序的逻辑设计与部署环境的实际功能不一致。通常，这一通信事故会导致工作效率下降，因为开发人员和运营经理使应用程序的功能符合数据中心的现实。 使用基于模型的开发工具，Microsoft 将通过提供逻辑基础结构设计器来缩小这些差异，该设计器将使运营经理能够指定他们的部署环境和架构师，以便验证应用程序能够在指定的部署约束下正常工作。这些工具使用软件模型来捕获设计人员意图知识、操作环境知识以及 IT 控制策略知识，以确保 IT 系统的设计从一开始就能够考虑到操作和可管理性。 系统级别管理 模型可以捕获应用程序的整个结构，包括所有基础和相互关联的软件和硬件资源。管理工具可以使用这些模型提供该应用程序的运行状况和性能的系统级视图，从而使管理员能够了解系统中的更改或错误的影响以及更有效地管理应用程序。 该系统范围视图将使管理工具能够执行可靠的运行状况监视和问题解决方案，以及端到端性能和服务级别管理。 策略驱动的操作 模型还可以捕获与 IT 和公司管理相联系的策略，如 Sarbanes-Oxley 依从性或基本安全标准以及操作系统版本控制。管理工具可以使用这些模型进行所需状态的管理。 通过将真实状态的模型与依从性定义的模型进行比较，管理工具可以在允许系统访问公司资源之前使其具有依从性。 硬件资源的抽象 软件模型可以根据所有相互关联的软件和硬件组件来捕获整个系统的组成。因此，系统将包含其环境（系统要在其中部署）的硬件需求的特定说明。 这一知识将使资源管理技术能够解释这些硬件需求，并且可以由管理工具用来简化初始供应、持续性更改，或基于不断更改的业务需要从应用程序中移除硬件等操作。 服务抽象的角度本文现在将其焦点转换到从 Web 服务的角度提出的管理问题。在此过程中，我们必须首先为基本的服务抽象建立一个基础。 我们首先讨论 Don Box 的四个面向服务的原则，这些原则由 Mike Burner 进行了完美的概括（Don Box，op. cit.；Mike Burner，op. cit.）：
上述原则对于理解应该如何设计 Web 服务非常有用，并且适合于处理面向服务环境中的技术交互 — 尤其是与连接系统内的其他软件组件之间的技术交互。但是，我们仍然需要考虑如何针对业务和 IT 操作设计 Web 服务，以及如何管理它。例如，我们意识到在法律和经济领域蕴含着一组等效的业务原则，它们约束和影响着规范的 Web 服务业务功能的设计。 对于业务设计，可以采取的一个简单角度是询问 Web 服务的目标是什么。在以模型的形式标识这些目标以后，可以在整个 Web 服务生存期中使用这些目标，以确保针对操作对 Web 服务进行良好的设计、实现、测试和部署。通过在设计中保持足够的预见性，可以用应该在未满足目标时采取的缓和行为来增强模型。然后，可以使用该模型来帮助设置 IT 管理系统，以便衡量 Web 服务的性能并根据需要采取操作。 因而，难题在于标识目标是什么。可以使用多种不同的方法来解决这一难题。Web 服务可以为它的使用者（如连接系统中的其他组件）描述它是如何通过使用策略有条理地表示目标并对其进行建模的。这可以使调用应用程序知道它应该做哪些事情来符合所调用的 Web 服务的管理期望。对这一主题进行详细说明超出了本文的范围。我们在这里讨论了其中的几个方法，并且已经在该系列的其他文章中详细探讨其中一个方法。无论如何确定 Web 服务的业务目标，我们都相信，有效的 Web 服务管理开始于预先知道这些目标是什么，将它们收集到模型中，并且在整个 Web 服务生存期中使用该模型，从而让 IT 符合业务计划。 资源角度 考虑 Web 服务的总体目标时，采取一个从资源角度进行考虑的方法。该方法是由 Microsoft Communications Sector 中的 Michel Burger、Bala Balabaskaran 及其同事在 Service Network 模型中开发的。本节摘自 Michel Burger、Bala Balabaskaran 等人的题为“Service Enablement Cookbook”的未发表作品。 资源方法从其资源的角度考察 Web 服务。资源是 Web 服务及其使用者之间的消费单位。资源方法认为，一组全面的管理模型的范围应该包括提供和使用模型，以及传统的运行状况模型。 对于资源方法，Web 服务必须为使用者提供资源。然后，必须管理该资源的运行状况（包括服务级别期望），因为使用该资源的操作是针对 Web 服务执行的。最后，必须衡量（或测量）该资源的使用。资源方法假设 Web 服务在其服务边界代理一个或多个资源。不代理基础资源集的 Web 服务（如简单的随机数生成器 Web 服务），其可管理性要求不适合资源方法的范围。 对于资源方法，可以使用三种语义模型及其操作来有效地管理 Web 服务的操作功能。它们是：
标识与 Web 服务相关联的核心资源集，有助于了解需要在服务边界级别存在的三种模型的详细信息。为了 Web 服务拥有的每个资源而存在的基础模型最终将向服务模型提供大多数组件。 Service Network 中的 Web 服务代理资源。标识资源是一项至关重要的任务。 可以使用两条简单的标准来确定资源是什么：
下列几个示例说明如何标识资源：
图 1 从资源角度说明了邮箱示例。在外部使用的资源是邮箱，它必须以可用的方式提供，进行管理以使其在使用时正常工作，并且在使用后计帐（如果它以商业方式提供）。在 Web 服务的内部，很多资源被代理以提供该功能。  图 1. 邮箱 Web 服务的外部和内部资源说明 从资源角度看，Web 服务的目标主要是从 Web 服务设计者的观点定义的。这是一种用于定义 Web 服务目标的实际且有用的方法。设计工作就是将很多内部资源集中到一起，以便在较高级别的服务中提供给 Web 服务使用者。该服务的定义当然与 Web 服务的设计有关，因而也与资源角度有关，但该服务存在的原因以及它的定义方式都处于资源角度的范围之外。 业务协作角度 业务协作角度是一种比资源角度更全面的方法。该方法试图通过在企业运营级别考虑业务资源、业务事件和业务代理（人员）来理解 Web 服务的目标。它通过重点考察 Web 服务打算参与的业务协作（即，如何在业务环境中协作使用该 Web 服务），使用正式的企业运营建模来找到这些需求。然后，该方法将这些企业运营需求转换为可尽可能地直接驱动 Web 服务解决方案设计和 Web 服务运行状况模型的高保真格式。有关使用企业运营建模向 IT 组织传达企业运营需求的更多信息，请参阅位于 Microsoft Architecture Resource Center 中的“Microsoft Architecture Series on Managing Connected Systems”一文。 当两家企业在价值链中彼此协作（无论是供应商-客户的形式，还是合作伙伴-合作伙伴的形式）时，它们彼此进行的交易通常遵循两家事先协商的过程。（有关使用企业运营建模向 IT 组织传达企业运营需求的更多信息，请参阅位于 Microsoft Architecture Resource Center 中的“Microsoft Architecture Series on Managing Connected Systems”一文。）这些过程通常通过满足下列条件的合同，以充分的明确性加以定义：每个企业都清楚地知道它的角色，都可以执行它已经承诺的活动，并且在履行责任以后，可以从对方那里获得任何应得的好处或报酬。 对于在操作级别支持与其他组织的业务协作中本组织一方的工作，企业运营组织负责将其所需的基础结构准备就绪。在执行工作的过程中，企业运营组织会在定义、实现和操作业务过程集合时将合同要求映射到业务功能。企业运营组织还会与 IT 组织密切合作来支持该 IT 组织的工作，以便定义、开发和操作用来实现业务过程集合的技术解决方案。 在企业运营组织监督业务的运行时，有两个一直存在的难题，如图 2 所示：
 图 2. 业务关系漂移和企业运营漂移的说明 业务协作中的业务关系漂移是不可避免的。一家企业与另一家企业同时具有完全相同的信息是不可能的。但是，当业务协作按预期进行时，业务关系漂移不会成为问题，并且被继续隐藏起来。不同的共享活动适时地展开，不断将业务关系拉回到校准状态，并且每个企业都继续体验到它预期的结果。 业务异常发生时（预期事件延迟，或者预期事件未按顺序发生），业务关系漂移才表现为问题。通常，这一表现是级联的：一个重要的活动延迟完成，或者根本没有完成，从而导致其他活动未能开始等。企业非常难以回到同一事件，或者恢复业务关系校准状态。要弄清楚什么以及哪里出了问题，并且让事情回到正轨（如果可能），可能需要花费大量的时间、精力和金钱。 利用良好的事先计划和经验，处理业务异常的困难不在于了解要对其执行哪些操作。大多数问题都是可预料的，而良好的计划将包含某种处理完全意外事件的方式。相反，处理业务异常的困难主要在于将有关已发生异常的有用信息及时甚至提前传达给适当的人员，以便他/她能够在问题发生时（或者在问题发生以前）采取相应的行动。当正确的信息及时到达适当的人员那里时，这个人可能实现的任何干预都更有望具有更加重要的缓和效果。 将有关正在发生哪些异常的有用信息及时传达给适当的人员并不是一件轻松的任务，而且这是企业运营漂移的典型症状。预期性能未能实现，但是当前性能级别实际上仍然未知。通常情况下，用来实现业务操作校准的信息是存在的，但这些信息几乎总是零散地分布于实现业务过程（这些过程一起工作以支持业务协作）的技术解决方案中。在这些情况下，直到一段时间以后执行事后审计时，才能在企业运营级别知道未履行合同责任的事实。这样的审计（通常手动完成）发现协定服务级别协议中的某些要求得以满足或未予满足。对于未满足要求的情况，通常会评估处罚。同时，未履行责任通常会在企业运营中实时导致级联业务异常。 在两家企业之间确保业务关系校准的关键，似乎是每个企业的内部企业运营和 IT 操作组织之间的企业运营校准。如果 IT 组织有办法事先知道需要满足哪些企业运营要求，以便 IT 操作继而可以让企业运营在这些要求得不到满足时了解情况，那么，企业运营团队就可以更好地在业务关系漂移发生时（甚至在此之前）检测到可能恶化这一情况的业务异常。 将业务协作形式化的建模方法可以促进识别可能恶化业务关系漂移的情况。当这些情况被识别并转换为 IT 组织可以使用的模型时，就可以用防止企业运营漂移的方式设计、实现和操作 IT 解决方案。通过业务协作中两家企业的企业运营和 IT 操作之间的更紧密耦合，并且遵循这一方法，双方都可以获得有关共享业务活动状态的更加及时的知识。这一情况称为业务状态校准，图 3 对此进行了说明。在实现业务状态校准以后，企业运营可以更加顺利地运行，并且可以避免不必要的开销和停机。  图 3. 业务状态校准说明 图 4 中的概念性框架将企业运营建模与 IT 服务管理联系起来，并帮助解释业务协作角度。概念性框架提供一种将业务与 IT 管理任务相关联的一致方式。她将企业运营要求与现有的 IT 管理过程和功能联系起来。该概念框架包含一个服务生存期方法，该方法覆盖企业运营级别范围。  图 4. 说明业务协作角度的概念框架 企业运营建模可以用来帮助从业务协作角度标识 Web 服务的目标。该方法有助于确定 Web 服务应该存在的原因，它应该做的内容以及它应该做的方式。该方法比资源方法更为困难和复杂。该方法涉及到在企业运营域中使用很多人来开发正确的模型。然后，为了可供必须设计、实现和操作 Web 服务的 IT 人员使用，必须将这些要求转换为某种适当的形式，以便同时驱动 Web 服务解决方案设计和 Web 服务运行状况建模过程。但是，尽管在从业务协作角度确定 Web 服务目标时需要付出大量的努力，但这些目标对于帮助指导如何管理 Web 服务非常有用：这些目标与公司的操作直接有关。 Web 服务管理解密“Web 服务管理”是一个通常用于描述将新的技术解决方案应用于传统 IT 服务管理问题（如适用于 Web 服务的规范和监视）的术语。该术语还用于描述新的专用基础结构如何将 Web 服务与业务功能（如使用控制、使用计量和计帐以及客户服务系统）联系起来。该术语的范围甚至涵盖应用新工具及其运行库，它们旨在更改操作 Web 服务的行为（有时对其是透明的）。 显然，Web 服务管理跨越了很多边界，而且组织可以并且应该进行新的投资，以改善其管理 Web 服务的能力。如上文“基于模型的管理”一节中所述，在考虑 Web 服务引起的连接系统管理的复杂性时，我们尤其相信这一点。 但是，像 Web 服务管理这样伴随着喧嚣和迫切性的新术语而言，却可能引起某些方面的混乱，如组织的正确投资是什么，以及何时进行投资。该术语还可能引起这样的混乱，即现有 IT 服务管理解决方案可以在 Web 服务管理中发挥什么作用。例如，人们可能并不清楚，说明如何使用现有运行状况和性能监视基础结构的指导几乎可以直接应用于操作性 Web 服务中的问题检测。 很多开始使用 Web 服务的企业可能不熟悉服务范型。该范型变换不仅要求调整开发方法（例如，着重于四个原则），而且要求调整 IT 管理心理。管理 Web 服务的任务不太可能存在于新技术解决方案的灵丹妙药之中；相反，它目前可能一致地专注于整个服务生存期中的一组协调性活动。随着时间的推移，我们认为基于模型的管理基础结构将与这些活动相适应，并随着组织中的知识被形式化以及更为广泛地传达和应用，可以帮助这些活动自动完成。 实现该服务范型变换的能力在于，企业是否能够越过围绕 Web 服务管理短期方法的喧嚣和紧迫性，洞察到企业管理 Web 服务的动机。当这一动机明确时，企业执行该服务范型变换的程度取决于它解决以下难题的能力 — 目前的在整个服务生存期中协调和合理解决人员、过程和技术问题。 Web 服务管理框架在后面各节中，我们将说明一个框架，以便在整个服务生存期中协调和合理解决人员、过程和技术问题，使用现有的 IT 服务管理功能来解决目前的管理 Web 服务这一难题。 我们首先考虑业务协作角度以帮助定义 Web 服务目标。我们将企业运营需求应用到一个大大简化的服务模型中，然后以一种更加细致的方式描述要映射到 Web 服务实现中管理需求的逻辑实体。 接下来，我们通过分解的实体来描述 Web 服务管理问题。 最后，我们通过提供一个根植于服务生存期中的技术框架，帮助利用现有的人员、过程和技术来管理 Web 服务，从而解决这些需求和问题。 Web 服务目标和服务模型逻辑实体 图 5 说明极大简化的服务模型的逻辑实体，它从上文中阐述并且在图 4 中说明的业务协作角度派生而来。  图 5. 服务模型逻辑实体 逻辑实体以各种方式相关：
我们在应用于服务操作环境中的规则以及与完成企业运营有关的规则之间进行了区分。在服务环境中，这些规则通常与技术操作员和管理员处理的条件和操作有关。这种规则的一个示例为：“如果在过去 60 秒中处理的 SOAP 数据包的数量超过了 600，则自动提供新的 Web 服务实例。”服务级别完成规则与在企业运营级别跟踪提取的数据和事件有关。例如，服务级别规则可能做出如下声明：“如果业务服务使用者上个月已经使用了该服务 6 次以上，那么将该客户提升至下一个服务级别。” 或许图 5 中的一个事实不是那么显而易见，即服务实体无法免受新业务和技术决策引入的更新和更改。例如，在新的地理区域引入现有业务服务时，现有服务定义可能需要更改，以便考虑能够反映地区使用者保护方案的新服务参数。在另一个示例中，业务服务提供者可能决定监视新的业务事件，以作为调整库存预测的指示器。Web 服务管理环境必须处理这些服务生存期管理问题，并且提供适当的机制，以便以不太打扰业务服务使用者的方式进行版本控制、更改通知、服务部署和更新。 最后，我们不能忘记，业务服务使用者、业务服务提供者和 Web 服务操作者在网络世界中表示为数字实体。身份验证和授权过程对于控制 Web 服务的访问、使用和管理是必要的。权利用于表示授予各方的权限和特权。 Web 服务管理问题 期待 Web 服务能够提供与其他 IT 解决方案相同级别的技术命令和控制功能是合理的。但是，由于目前未对 Web 服务管理技术进行概括和实现，这一期望尚未成为现实。 尤其对于 Web 服务而言，管理信息模型必须记录不同的内部服务状态、所需的服务视图（例如，过去一小时中已经访问某个服务的次数），以及对获得这些状态和视图的方式进行控制的规则。因而，可以通过这些管理文档中包含的服务元数据来自动执行和驱动各种管理活动。 可以进一步分析图 5 所示服务模型中的逻辑实体，以便导出与管理有关的属性、入口点和面向任务的规则。这样的信息将被表示为管理元数据，以供 IT 服务管理工具用来监视和调整管理环境，以满足操作需求和企业运营需求。 例如，管理元数据可以说明 Web 服务实例以及相应的可以规范化、配置和部署的软件组件之间的映射。这些组件的属性说明已定义托管 Web 服务以便公开的事件、探测和性能计数器。运营规则集合确定如何处理规范化数据，以及如何路由服务请求以便满足服务级别需求。 Web 服务管理技术框架 在前面的几节中，我们描述了从简化的服务模型中导出的逻辑实体。然后，当我们讨论管理 Web 服务所需的机制时，我们分析了这些实体之间的关系。 本节，我们描述可以覆盖在现有人员、过程和技术功能之上以支持 Web 服务管理的技术框架。 我们已经介绍的 Web 服务管理问题可用以下方式概括：
支持上述需求的 Web 服务管理技术框架是围绕下列四个核心技术支柱（它们对应于需要解决的管理问题类别）构成的：
Web 服务生存期管理对于前面讨论的 IT 服务管理的 ITIL、MOF 和 MSF 方法，一些常见的评论包括：
同样，我们断言应该在管理 Web 服务时使用相同的生存期方法。 商业软件包难以在生产环境中部署、维护和更新。Web 服务也不例外。如图 6 所示，考虑到服务生存期中各个阶段的联系时，这一评论并不令人奇怪。  图 6. 服务生存期 使用图 7 所示服务生存期的方法能够帮助 IT 团队协同工作，以便管理 Web 服务以满足其目标。  图 7. 使用服务生存期 服务生存期方法能够帮助团队完成下列工作：
负责生存期各个阶段的人员通常在组织上是隔离的 — 有时在地理上也是隔离的。在开发有助于促进阶段间交流的工具方面，迄今为止几乎未获任何成功。因此，目前在已经实现软件的程序员和负责软件日常可用性、可靠性和安全性的操作员之间的设想中通常存在分歧。这一评论击中了基于模型开发和管理的核心 — 换言之，软件服务的设计和实现必须考虑部署和操作需求，以便减少持续的服务管理成本。 Web 服务运行状况管理因为世上不存在完美的环境，所以 Web 服务会在其执行过程中的某个时刻遇到问题。如果问题未能及时检测，未能正确诊断或者未能正确修复，那么 Web 服务可能退化到客户无法再使用它的地步。这将导致金钱和时间上的损失，并且最终在用户中造成不满。管理员需要负责在检测和修复问题的同时尽可能减少其用户的故障时间。 Web 服务运行状况模型定义 Web 服务运行正常（在正常条件下操作）或不正常（失败或退化）的含义，以及进出这些状态的转换。有关 Web 服务运行状况的适当信息对于正在运行系统的维护和诊断是必要的。运行状况模型的内容成为系统事件以及用来生成监视和自动化发现的规范的基础。 要使 Web 服务启动和运行，运营小组需要监视 Web 服务的运行状况衡量标准，及早检测问题的症状，正确地诊断问题的原因，并且在应用程序的性能令人无法接受之前修复问题。该活动被称为运行状况监视和故障排除。 要创建 Web 服务运行状况模型，建模者需要完成下列工作：
本节提供用于说明和理解运行状况模型概念的背景信息。图 8 提供一个部分服务生存期视图，说明运行状况模型何时可以有效地指定可管理性需求。该高级运行状况模型提供了基础运行状况建模框架，该框架可以进一步扩展和分析，以便标识潜在的问题、问题指示器、诊断步骤，以及为确保 Web 服务的运行状况和性能满足期望而需要采取的恢复操作。  图 8. 从运行状况模型角度看到的服务生存期 运行状态是 Web 服务正常工作能力的高级指示器。运行状态提供非定量数据，但它可以告诉管理员 Web 服务是否存在问题，并且使人了解情况的严重性。需要记住的是，运行状态是有关严重性的判断，并且几乎总是相对的。例如，一个客户可能判定 90% 的网络总饱和度水平是一种恶化状态，而另一个客户则可能认为 80% 的水平是失败状态。 图 9 中显示的运行状况与可诊断性工作流定义监视和问题恢复过程的逻辑阶段。该过程的阶段包括：
 图 9. 运行状况和可诊断性工作流 要有效地进行监视，Web 服务需要提供正确类型和级别的规范 — 它需要公开它的内部状态，报告其状态和行为的更改，并且提供管理员控制方法。这可以提供问题检测、验证、诊断和恢复所必不可少的数据。此外，规范需要是轻量级的，并且不能对应用程序的性能造成显著影响。有三种主要类型的轻量级规范化，可用于不同的方面以支持运行状况和可诊断性工作流：
Web 服务部署管理在 Web 服务满足所有测试需求后，就可以进行部署了。传统上，软件服务的部署要求准备网络基础结构、硬件和操作系统。准备工作中的同等严格性也适用于 Web 服务部署。有效的 Web 服务部署机制必须使 Web 服务映像可以集中准备和配置，并且可以通过网络和 Web 服务场环境有效地分发。配置管理必须处理不同类型的管理数据，包括：服务客户端需要遵守的服务策略；影响 Web 服务使用应用程序、系统和网络资源方式的软件设置；以及使正在运行的 Web 服务实例能够被发现和操作的服务目录信息。配置管理的技术解决方案还必须处理更改传播延迟，该延迟影响配置更改何时能够在受影响的 Web 服务中生效。 图 10 显示 Web 服务部署的逻辑体系结构。  图 10. Web 服务部署的逻辑体系结构 该逻辑体系结构包含下列实体：
一段时间以后，新的技术和业务需求将使对 Web 服务的现有实现进行技术再评估以及可能的更改成为必要。技术更改可能是从 Web 服务访问地址到消息架构更新、服务界面或名称修改的任何内容。当发生实现更改时，服务提供者面临将对服务使用者的更改影响最小化或隔离的难题。 例如，如果一家提供财务服务的本地美国企业决定将它的服务范围扩展到本国的另一个州，那么该服务需要考虑新州的消费者法规。它可能要求在该企业和消费者之间传递附加的输入和输出数据。当 Web 服务用于启用该服务时，可以考虑几个技术选择来促进新的数据交换。该企业可以选择引入新的 Web 服务界面来支持新的数据参数。或者，它可以选择使用 Web 服务代理外观来支持现有界面，并且依靠该代理来执行数据转换和内部服务路由，以便支持来自当前和新的服务使用者的消息处理请求。（对于后一选择，与服务设计的四大原则一致，服务边界在概念上向外迁移，从原来的 Web 服务实现迁移到新的 Web 服务代理外观。） 长久以来，软件行业一直在将软件版本控制技术和过程应用于传统软件开发。一些现有的版本控制技术需要在 Web 服务领域中修改和应用，以便区分服务实现和消息架构中的更改。 根据 Web 服务体系结构的不同，对 Web 服务界面或消息架构的更改可能影响 Web 服务使用者和 Web 服务代理。在任一种情况下，使用方都需要发现新的服务定义，以便与新的 Web 服务终结点进行交互。Web 服务体系结构需要指定是自动处理还是手动处理更改通知和发现。 Web 服务标识和访问管理正如本文作者之一在一篇相关文章中所述，身份和访问管理是用于管理数字身份和用于控制如何使用数字身份访问资源的过程、技术和策略的集合。 在 Web 服务管理上下文中，我们有兴趣对三个主要参与方的身份进行管理：
图 11 显示了 Web 服务身份和访问管理框架的概念体系结构。  图 11. Web 服务身份和访问管理概念性框架 访问控制的核心功能是通过下列三个起支持作用的安全机制提供的：身份验证、授权和审核（通常称为 AAA）。这三个机制依靠目录和安全服务层来完成与安全数据有关的操作。例如：存储和检索用户凭据、权利和配置文件；发现安全策略。 一个供应组件提供初始化、更新和同步与安全有关数据的功能。然后，用户管理应用程序和界面可以依靠该供应组件来创建、检索和更改标识信息，而无需直接与数据层交互。 信任关系和安全策略是身份系统中的关键元素，因为它们确定了 Web 服务将从受信任方接受的安全凭据、语句和操作的类型。信任和安全策略管理组件负责在目录和安全服务中更新这样的安全配置信息，并且负责配置 Web 服务实例以使用安全设置。 下面几节将重点讨论身份和访问管理中的几个重要概念，以及它们与 Web 服务的关系。 身份验证和一次登录 身份验证是验证身份凭据的过程。身份验证的主题可能涉及 Web 服务使用者组的成员、Web 服务提供者组的成员或 Web 服务操作人员组的成员。 大多数企业具有多个身份系统来支持现有的服务和应用程序。因此，企业用户经常面临为登录管理多个身份验证凭据的难题。一次登录机制有助于处理使用和管理多个应用程序凭据的复杂性。以服务为中心的领域中的身份和访问管理系统必须处理与现有身份系统集成以及向服务用户提供一次登录体验的难题。 权利和授权 权利是指授予身份的权限和特权，而授权是指验证给定身份具有访问受保护资源（此情况为 Web 服务）的权限的过程。 像身份验证一样，授权过程也适用于各种类别的身份所执行的不同种类的任务。对于 Web 服务使用者，Web 服务实例除了验证其有能力调用 Web 服务以外，还会检查更细致的数据访问权限，以验证使用者可以在 Web 服务响应中接收特定的数据字段。对于 Web 服务提供者和 Web 服务操作者，授权过程将分别验证以下内容：身份有权查看并更新与内部业务和操作有关的信息。 除传统的访问控制列表以外，基于角色和基于规则的授权机制经常用来表示和增强授权策略。 安全审核 服务中涉及的很多行业都是由政府法规加以管理的。例如，在美国，最近颁布的 Sarbanes-Oxley Act (Sarbox) 及其一致性要求强制 Sarbox 法律所管理的企业重新评估其现有系统，以确定是否存在可能导致其无法通过 Sarbox 审核的过程和技术差距。 既然当前企业的关注重点在于管理和透明性，就需要容易地获得能够回答“谁以及何时做了什么事情”的问题。安全审核提供了跟踪安全操作和信息访问的机制。在很多情况下，审核跟踪还需要证明法律意图和非拒绝，以便可以在法庭上将这些信息用作证据。 在通过 Web 服务扩展业务信息和操作范围以后，将审核和举证功能集成到 Web 服务实现中就变得更加关键了。前面描述的企业运营建模方法可以用来帮助标识业务协作中显示法律意图的活动。通过将这一模型转换为企业运营需求，可以帮助 IT 团队将适当的功能集成到 Web 服务实现。 隐私 隐私与企业使用和泄露个人数据有关。在很多情况下，隐私需求与正在使用个人信息的企业实体在多大合法程度上同意保护和限制使用从 Web 服务使用者那里获得的数据有关。 隐私和安全实际上是两个自相矛盾的概念 — 随着我们通过身份验证、授权和审核过程变得更加安全，跟踪、收集、关联和揭示用户信息就会变得更加容易。因此，非常重要的一点是：对于每个生成身份数据的安全条件和事件，存在一组能够限制相关数据使用的对等条件。其中一些条件可能需要转换为可由计算机增强的业务规则。这样，Web 服务实现就可以依靠这些业务规则来限制数据的可见性和访问。 身份生存期管理 身份生存期管理是指身份供应、身份停供以及更新与身份相关联的帐户、配置文件和权限的过程。 如前所述，大多数企业当前即具有身份系统。在很多情况下，Web 服务实现必须与这些当前的身份方案集成。Web 服务依靠这些系统来对身份进行身份验证和授权，以及收集电话号码等个人属性。 身份供应是在身份系统中创建和初始化帐户、凭据和属性的过程。身份停用是在身份生存期的另一端停用帐户的过程。当帐户处于活动状态时，可以更改和更新帐户信息和凭据。 通常，组织中的身份数据可能在不同的系统中传播或复制，以至于需要进行某种级别的数据同步以维护一致的身份视图。身份集成和同步技术用来解决这类身份管理问题。 身份联合 为了完成 Web 服务技术有关促进跨组织交流的承诺，组织必须能够对合作伙伴组织身份的使用进行验证和授权。身份联合是指用于管理和配置信任关系的过程和技术，以及跨安全管理域来使用身份。 在 Web 服务领域中，身份联合使组织能够将特定的安全责任委托给受信任的第三方。例如，服务提供者可以将其 Web 服务配置为信任某个众所周知的身份提供者，以便对其 Web 服务使用者的身份进行身份验证，从而在通过 Web 服务扩展其业务范围的同时简化它需要利用的身份管理基础结构。在其他情况下，Web 服务提供者可能选择将用户授权过程进一步委托给要使用该服务的业务合作伙伴的受信任身份系统。 使用 Web 服务的 Web 服务管理有关 Web 服务管理的讨论集中于 Web 服务的管理。另一个值得一提的主题是管理使用 Web 服务的 Web 服务（或其他应用程序或系统）。 无论是否被用于管理 Web 服务或其他计算软件或设备，管理基础结构都涉及到通信协议，以便促进发现托管 Web 服务实例和向事件基础结构引发管理事件等管理功能。现有的行业标准管理协议示例包括 SNMP（简单网络管理协议）和 DMTF CIM（分布式管理任务组公用信息模型）。 在为多种应用程序和基础结构服务（例如，联合身份管理）采用 Web 服务技术以后，管理协议界还意识到，面向服务的原则和 Web 服务技术还高度支持令人满意的分布式管理目标。例如，可发现性说的是动态发现托管资源的能力，而联合使管理应用程序无需完全控制即可获得受信任基础结构的可见性。 WS-Management 是一种基于 Web 服务的协议，它将少数固定操作的实用性与可伸缩的、可构成的 Web 服务体系结构组合在一起作为它的技术基础。WS-Management 在很大程度上是遵循描述管理操作的其他现有 Web 服务标准和规范的复合定义。因为该协议被定义为可构成的标准，所以可以在受到资源约束的环境中实现它，从而消除低级有线协议的需要。 小结像大多数重要的IT 计划一样，管理 Web 服务要求对人员、过程和技术进行均衡协调。 我们将 Web 服务管理的讨论植根于连接系统和“动态系统计划”的更为广泛的背景中。我们提供了一些可在确定 Web 服务的实际业务目标时考虑的角度，以便帮助您更正式地确定管理 Web 服务的原因及方式。 基于模型的开发和管理方法建议，可以将用于解决管理状态、操作和规则的 Web 服务管理框架叠加到现有 IT 服务管理系统之上。 我们提出了这样一个框架，它解决如何在整个服务生存期中协调人员、过程和技术问题这一难题。在获得 Web 服务目标角度之一的简化视图之后，我们分析了 Web 服务生存期管理、Web 服务运行状况管理、Web 服务部署以及 Web 服务身份和访问管理等问题。 |
