有效管理服务的生命周期是SOA计划赢得成功的基石。此类管理的设计时方面包括以下领域：服务编目、建模方法、以及有关构建和复合服务的概念等。本文集中探讨服务生命周期的运行时方面，它包括发布和供应服务、将服务集成到复合应用程序中、部署服务，监控和管理服务的使用，以及在实际设置（比如生产）下评估服务的效用。请参阅理解SOA中的服务生命周期：设计时一文，获得该系列以及上述设计时方面的介绍。

　　简介

　　图1所示的Shared Service Lifecycle（SSLC）模型提供了贯穿本文讨论的一致路线图。在适当的时候，我会深入进行更全面的讨论，以支持SSLC运行时阶段的需求，并且在服务复合和变更处理等方面提供最佳实践建议。

　　图1：Shared Service Lifecycle（SSLC）

　　实施SOA计划的组织，无论大小，往往会形成以支持服务的当前或所需业务流程为主要任务的小组。这些服务工程团队的主要任务可能是研究与SSLC相关的特定方面，也可能是SSLC的整个生命周期。本文第一部分引入了一个假想的组织，其中负责整个SSLC的服务工程团队建模并构建了多种服务，以支持组织的需求。现在，这支团队必须将这些服务公开为组织内的运行时产物。

　　在深入探讨SSLC的运行时方面之前，我们先来看看这个假想的组织，它为一个电子商务站点提供书籍和电影，以便销售。如图2所示，服务工程团队开发了一个需求目录，该目录用来为服务的创建提供路线图。

　　图2：需求目录

　　使用需求目录，即可确定依赖关系，以及规划对于SOA计划的价值。正如SSLC的构建阶段一样，运行时方面利用该目录锁定工作方向；然后，就可以进一步定义所需工作，并通过查看如何通过服务分层复合应用程序来理解依赖关系。一旦工程团队理解了企业的需求，就能利用SSLC设计时阶段创建的那些服务，集中关注将这些服务投入生产的运行时需求。本文后续部分将重点阐述SSLC的各个方面以及成功管理SOA Shared Service Lifecycle的运行时方面的相关活动。

　　复合应用程序和服务分层

　　此前，我描述了传统应用程序开发和SOA实践之间的差异，SOA实践是一种突破单体应用程序的局限性、缩短开发/发布/测试周期的途径。只有专注于复合应用程序的概念才能获得这样的敏捷性。按定义来说，复合就是把一些现有和新建服务装配到一起，从而创造出满足业务需求的新功能。在成熟的SOA环境中，通过使用为快速满足业务需求而复合的现有服务，即可将完整的业务应用程序可能装配在一起。为确保此供应过程的灵活性，服务工程团队在设计时必须非常谨慎，避免把业务逻辑编码到服务实现中。另外，为了保证在供应时不会丧失这样的敏捷性，SSLC的运行时阶段应集中保证服务契约、策略和元数据不会给未来的需求造成阻碍。获得这种运行时灵活性的一种方法就是要设计和提供一些服务，来定义一些层，这些层可能会形成系统的逻辑和概念分层。

　　在SOA计划中，复合是通过以高度有序的方式利用现有资产的能力而实现业务灵活性的一个完整组成部分。以我的经验看来，许多企业在过于细粒度的层面上开发服务，以至于许多小的特定服务的增殖难以复合成更大的逻辑服务。对服务定义和构造采取分层定义的方法，服务工程团队更可能获得满足现在和未来业务需求所必需的粗细粒度合理的混合服务。

　　为了说明分层服务的概念，我们来考察一下需求目录（如上图2所示）中定义的电子商务和企业内部网示例，它确定了整合组织的企业库存系统和相关流程的的长期需求。BEA SOA Domain Whitepaper（PDF）中定义了许多可能存在于企业面向服务环境中的逻辑层，它们构成了SOA参考架构的一部分。这些层——信息和访问、共享业务服务、复合服务和表现服务，是定义职责分离的极佳途径。我们还可以从更为细粒度角度观察服务需求，从而进一步分解这些服务。这样的角度应对了把服务组织成物理、规范、逻辑类和应用服务类的需求。下面就让我们详细地了解它们。

　　物理服务

　　信息和访问服务可能表示以原始形式检索数据的功能。看一下需求目录，需求之一就是要能读取订单。物理服务可按照与图3类似的方式定义。

　　图 3.订单物理服务

　　以上定义的物理服务可构成企业参考架构的信息和访问层的一部分。这样一个服务应该支持特定数据源上的细粒度CRUD（创建、读取、更新、删除）操作。

　　规范服务

　　规范服务定义企业信息的标准视图。通常，这样的视图会使用像SWIFT这样的业界标准格式或其他特定于企业所属行业的标准。通过建立通用的混合语，清晰的生产者层（producer layer）就开始成形了。这个标准层独立于物理服务，可作为共享服务或复合应用程序的起源使用。

　　从上面定义的物理服务可以看出，物理服务已被建模为返回一份订单的原始表示。服务工程团队现在必需实现一个概念层，来返回标准规范模型。一开始，如果订单服务返回了所需的一切数据，您也许会觉得订单的规范模型没有存在的必要。再看看前面服务工程团队开发的需求目录，它显示出，这个假想的企业不只有用于书籍或录像的库存系统，从长远角度来看，企业还有整合这些系统的要求。在抽象层面上定义同时表示书籍和录像的标准规范，您也就开始以一种非常灵活的方式获得这种透明性了。

　　图4所示的订单服务定义为接受标准规范，这种标准规范以xml模式定义，与以传入的xml文档为基础的多个库存系统交互。

　　图 4.基于规范的订单服务

　　服务实现以消息上下文为依据，处理需要物理库存系统的逻辑。

　　逻辑服务

　　在企业内建立标准规范结构时产生了一个问题，就是这些结构需要支持大量的数据资源占用。结果，当服务的所有使用者真正想要的是结果的较小子集时，由于从此类一般服务返回的信息过多，使用者可能要担心性能降低。建立逻辑服务提供了更细粒度级别的交互，而不会牺牲在规范结构上构建的好处。而且，上游应用程序（upstream applications）可能需要对信息进行逻辑分组，例如客户的单一视图。标准的逻辑服务提供了复合功能，还提供了重用和缩短上市时间等立竿见影的收益。目前的工具，比如BEA的AquaLogic Data Services Platform，也提供在执行时编译出（compile-out）这些层的功能；这就带来了高度优化的查询，而不会牺牲设计时和运行时的灵活性。图5的示例定义了客户配置文件服务，它提供了消费信息的逻辑分组。

　　图 5.客户配置文件逻辑服务

　　为了为下游服务（downstream service）的使用快速提供标准应用程序结构，而且几乎不需编写新功能，该客户配置文件服务描述了在整个需求目录中复合服务的能力。

　　应用服务

　　最后，服务工程团队可能会开发许多应用服务，旨在供应用程序以独立于业务线的方式直接使用。需求目录中，有两种特顶的受众可能对客户配置文件服务感兴趣：想要更新信息、核对订单等等的实际客户；可能有兴趣在所有订购了某本书籍（举例来说）的客户上运行报告的内部网用户。结果是，服务工程团队可能会生产两种特定于应用程序的服务。正如SOA Domain Whitepaper（PDF）中定义的那样，这些服务可能通过像portlet这样的表示服务而公开。

　　SSLC的运行时阶段

　　更深入地理解了SOA中分层服务的重要性之后，现在让我们来集中探讨SSLC的运行时阶段。如果管理得当，这些阶段可能会提供一种关键因素，实现由SOA计划驱策的企业灵活性和敏捷性。以下部分就这些方面进行详细讨论。

　　发布和供应

　　SSLC的发布和供应阶段集中关注：为发布服务需要做些什么，并建立服务使用边界。特别地，这个阶段应建立SOA管理的控制点，并通过定义诸如服务接口和契约等方面促进服务重用。

　　考虑发布和供应服务时，充分理解正在处理服务的哪些“片段”是非常重要的。在这个阶段，服务实现被视为设计时的静态工件，而不是供应团队的责任。供给团队应集中关注以下方面：

　　服务接口

　　服务接口为客户提供了一种基于标准的机制，使客户能够根据它所提供的契约访问此实现所提供的功能性。服务接口将发布服务以便使用。

　　服务契约

　　此契约应包含功能元数据（表示如何与服务交互）和非功能元数据（表示哪些条件和限制适用于希望使用该服务的用户）。通过确保该服务实现中未出现某些逻辑，比如使用的条件和限制，服务也就更可能通过多种方式复合，服务工程团队或企业尚未考虑到这些方式中的大多数。服务契约在运行时可作更改，而无需在实现中重新编译代码，认识到这一点很重要，诀窍就在于有效地利用这种灵活性。

　　元数据和策略

　　我的经验显示出，要支持一种切实启用了服务重用和复合的服务，就要定义元数据和策略。建立真正灵活的SOA环境时，元数据的管理就是求窍门所在。通过定义一系列策略，即可轻松在实现外部管理单个服务或一类服务的运行时控制。这些策略不仅定义了哪些规则适用于哪些客户，而且还在谁可在何时供应哪些内容的方面定义了服务本身。元数据驱动策略的额外优点是，它们可在动态条件下强制实施，比如用户会话上下文和消息有效载荷。

　　通过集中关注SSLC的运行时需求，控制和管理开始在成功管理SOA计划中发挥越来越重要的作用。结果，应将服务发布为某种形式的注册库，使其能够支持一个服务生命周期的配置和变更管理方面。此注册库也可与一个企业存储库集成，而该存储库又可能存储了另外的一些相关信息。需要特别注意的是，控制点应该通过工具来建立，应该向现有客户通知一项服务的更改，如有需要，应建立潜在的管理策略为用户提供时间窗口，以便他们能迁移到一个新版本的服务。所有这些信息都可存放在存储库里面，并且可通过注册库向服务用户展示。

　　集成和部署

　　SSLC和SOA以提高灵活性和敏捷性为成功的中心原则。服务重用是达成这些目标的一种方法。如SSLC的构建和复合阶段所提到那样，服务可作为部分新服务的实现使用。这听起来似乎是显而易见的，但做出以下声明很重要：确保设计时，复合服务不会影响SSLC的集成和部署阶段的灵活性。依靠对动态装配服务的服务的服务实现来支持业务需求可能导致以下问题：在后续阶段引入更改时存在依赖项和版本不一致。因而，建议您利用动态工具，比如Business Process Modeling（BPM），来促进服务联接的往返，而不要将其嵌入服务实现。另一种方法是在服务实现中利用代理服务，而不使用真实的业务服务终端。通过利用Enterprise Service Bus公开代理服务，物理服务就可能独立于消费服务而更改。（当然，如果服务接口做出了逆向更改，用户将通过一个已建立的管理流程得到通知。）

　　遗憾的是，运行时服务的动态装配不会自然而然地实现。无缝集成和部署的能力需要一个去耦的服务环境，该环境以如下需求为目标：降低服务之间或智能终端之间的点对点关系——这表示一种服务实现包含了编码逻辑，它以一种尚未明确规划（编码）的方式制约了服务的重用。另外，服务工程团队必须认识到，服务必然会随时间而更改，旧版本退役，必然会有新版本发布。在集成和部署阶段，应将注意力集中在对服务的多个版本的支持，这些版本可能需要在一段特定的时期内共存。这样的需求与先前提到的管理控制重叠，以确定适当的活动来制约服务，避免使组织的注意力蔓延到一种原始的、不受控制的生产者混乱状态，或者，如我的一位同事意味深长地指出：“在享用美味的IT糖果时，也必须咽下无味的IT蔬菜。”

　　为了在SOA计划中支持这种动态性，您需要了解基于配置的路由机制（而不是硬编码终端），它有能力询问一个服务请求的有效载荷或上下文，并以一种基于配置的方法恰当地发送它。更进一步，该环境需要支持无缝的变更控制，而这样的控制提供了对变更信息的更精确审计（请记住，通过避免依从性等方面的成本，您会获得了SOA的大量财政收益！）；提供了将配置聚集到可管理组中的能力；提供了实时更改和同时会话以支持透明更改控制；当然，还提供了出现问题时进行回滚的能力。

　　最后，SSLC的集成和部署阶段应支持基于角色操作的视图的概念。这些视图应允许复合服务的委托配置，而不仅仅将其可见性和变更管理功能限制在发布和供应阶段定义的服务契约之内。如果将注意力完全集中在单个服务和在这种层次上管理变更的能力，组织可能无法实现复合应用程序的全部收益，并且将处于以下危险之中：后退到传统应用程序开发的某些实践，从而导致产生一些难以监控的系统，并造成与中断-修复式的回归测试相关的关注。

　　安全和管理

　　组织中的计划只有在得到恰当的管理，能够响应业务需求和要求时，才能取得成功。在SOA的功能中，这必然会实现更好地理解在其中使用服务的上下文，从而为正确的客户提供更高的服务质量。通常，我会将标识专门化的经济模型视为经济中提高生产概率曲线的一种方式。这里没有必要过于深入地探究经济理论，使一种共享服务基础架构能够通过前摄性、响应性的途径理解使用需求，这种能力可提供更高水平的客户服务或适用性。在经济术语中，这可能与理解服务的聚合需求相关。

　　SSLC的安全和管理阶段应允许组织通过策略，而不是服务实现，来管理安全约束。就可调用该服务的协议而言，服务策略可将这些方面表示为传输层安全性，还可利用WS-Security标准来确保互操作性。当然，低级数据安全性可通过抽象数据服务或某种形式的分布式授权引擎来管理。特别地，对SSLC来说，这种安全性是通过对策略和相关契约的管理（而非服务实现）来提供的。

　　在SSLC的任何阶段，拥有流程的实时可见性都很重要。SSLC中的安全和管理阶段集中根据当前实际使用情况管理一些服务，这些服务将满足业务需求。这可能包括对性能和错误事件的SLA管理。管理此信息的能力是遵循企业或组织内已建立的管理控制点的一个重要方面。例如，考虑从假想组织购买的每一本书，您需要确保该订单对某个时间帧，并且，一些成人性质的书只应售已经过某种形式的年龄验证的人。在这种情况下，可能要实现一种服务策略，来确认已通过年龄验证，这也可通过当前客户规范的内省实现。（必须注意：在一种高利用环境中，单个服务实现可能也应该提供多个服务策略和契约，以确定其用途。）继续考虑购买一本成人书籍的例子，实际上两个策略在此有效：第一，如果该书是成人性质，需进行年龄验证；第二，一条要求在特定时间帧内发送订单的SLA。对这些SLA的任何违背都可能被报告为某种形式的异常或违规。一个成熟的SOA组织可能具有明确定义的管理流程，明确地标识控制点和异常例程，所有这些控制点和异常例程都会记录在企业存储库中，比如AquaLogic Enterprise Repository。

　　建立好SLA和业务策略后，组织可利用企业仪表板式的功能，为那些要求企业运作状态可见性的用户提供即时和集中反馈。通过这种可见性，安全和管理阶段应提供运行时灵活性，以增强为客户交付的服务质量（如果当时情形要求这样的话）。一个这样的例子就是，如果一个终端不可用，或将请求发送到一个低成本通道，比如IVR（Integrated Voice Recognition），而不是高成本的CSR（Customer Sales Representatives）（大多数标准请求发到此处），在这种情况下系统“dial-down”服务的能力。

　　评估

　　正如政府的财政和货币政策那样，在行动付诸实践时，规划和准备随时可能发生更改。这个SSLC的最终阶段涉及一些详细的分析，分析服务是如何根据使用情况在运行时被使用的。做出这类分析和评估的目的在于使组织更好地根据实际生产影响来管理服务使用行为。

　　本系列第1部分中介绍了作为服务建模方法的一部分建立的服务分类指导方针，评估阶段主要是以此方针为依据，获得生产服务并评估其使用情况。经验表明，最初为实现某种特定功能或使用级别而开发的服务，往往在实际上得到了比原始预期更充分的使用。这样的运行时更改，是组织中所期望的SOA的有机发展，但必须对其加以有效管理，以避免它对SLA和SOA的有效性产生不良影响。在评估流程中，服务工程组应确定：服务是否按预期得到利用，是否需要重新分类以维持或改善服务的期望水平。这种重新分类更改了管理一项服务从而使其能向前推进的方式，并需要在支持或投资结构上做出更改。如果该服务是水平服务，是一个最初为业务线使用而设计，而现已开始在整个企业范围内使用的服务，那么这一点尤其正确。这样的服务可重新分类为企业服务，并相应地加以管理。

　　评估阶段的另一个重要方面是，利用服务基础架构，收集度量标准来论证ROI和SOA计划的成功。业务和IT收益都可通过SOA度量标准的收集得以确定。确定ROI和SOA的成本收益是一个广泛的话题，超出了本文的讨论范围（在另外一篇我打算写的文章中将会介绍）。为简明起见，SSLC相关的一条度量标准是服务的重用水平。特别地，评估SOA程序未来成功情况时，度量服务的重用频率与创建频率对比情况的度量标准非常重要。要使度量标准真正发挥效力，必须从第一天起开始捕捉相关数据，并使之能与过去的度量信息进行比较，如先前IT计划中的上市时间、重用以及中断-修复循环的减少。

　　最后，SSLC的评估阶段应该用来促使下一轮候选服务与需求目录协同。使用度量标准能够直接表明需求目录中标识的依赖项是否精确地表示了实际情况。另外，服务使用和复合指出了另外的一些关系，这些关系保证了开发特定、可管理、可度量的服务。通过评估这些关系，这些服务可能会显然比单纯地通过SSLC的设计时阶段来实现容易得多。

　　SOA面临的新挑战

　　许多报告和文章都指出了SOA给组织带来的益处。然而，任何新技术都会同时带来新挑战。特别地，SOA SSLC和相关管理流程必须为应对这些挑战做好准备。下一节介绍了一系列挑战，一些是好的，另一些是不好的，但所有这些挑战对于使服务工程团队获得更好的理解来说都很重要。

　　变更

　　前一节讲述了SSLC的运行时阶段，以及它们与组织SOA计划的关联方式。有一个常规因素与SSLC一样重要，需要引起特别注意：变更——业务演化中无法避免也必不可少的组成部分。准确理解SSLC是一种很好的方式，可为变更做好准备，还可为实现SOA计划提供一致的方法论。管理SOA和SSLC中的变更带来了全新的变更管理挑战。特别地，将服务引入组织带来了许多新抽象，需要仔细加以考虑。像服务契约和策略等概念，要求用另一种方式来思考功能是如何开发的。这将需要付出时间和实践来把这一点做好，直到共享服务团队可在整个组织范围内促进某种形式的一致性采用。

　　SOA还引入了这样一种可能性，在某个特定的时间，组织在生产中可能拥有多个版本的服务实现。这种想法不适于很多组织，也带来了管理和支持挑战：应该在多长时间内为用户的应用程序的先前版本提供支持、更改版本却不造成有害的逆向效应的能力，以及通知用户即将进行更改的能力。我遇到的很多组织都只是通过管理“强制”用户迁移到最新的服务版本，从而解决这些问题。尽管这确实是一个解决方案，但是一个更成熟的组织可以为用户提供一个机会窗口，使其能够在需要时才转到最新的版本，通过一个服务注册库提供对以前版本的支持，并利用服务契约的灵活性提供无缝的变更控制、请求转换等等。您需要记住，SOA是用来提高组织敏捷性的。要求应用程序团队升级到服务的各发布点可能会被认为对此类敏捷性有害。

　　打包应用程序

　　SOA计划在组织中取得成功的另一项新挑战可能来自令人出乎意料的地方；就是现有的打包应用程序。目前，大多数供应商为其产品中默认启用的功能提供web服务接口。取决于组织中这些打包应用程序的大小，它们可能引入数以百计的服务，这些服务可能并不符合您所建立的服务指导方针。未被结构化的服务的涌入可能会对SOA计划的成功造成严重破坏。这些服务可能不符合SLA需求，可能需要通过与企业组相对的业务线进行管理，并且可能导致依从性方面的问题。如果所公开的服务发布自核心企业系统，比如CRM、Data Warehouses和ERP，那么这一点尤其正确。强烈建议组织建立管理模型的一个方面，来明确地处理应公开并相应地管理哪些服务。此类方法之一可能是：通过SSLC的发布和供应阶段提供额外的服务策略或契约，来控制打包应用程序。与安全和管理阶段的一些准备工作相结合，此方法可能减轻您组织中难以管理的服务的增殖。

　　服务契约

　　将服务契约视为实现服务的一部分时，大多数时候，除契约帮助确定服务使用的事实以外，您实际上并未对其给予充分的考虑。事实确实如此，而人们往往未能意识到服务契约是一份正式的、有约束力的协议，可能会制约未来的灵活性。由定义可知，一份契约是两方或多方采用一种特定行为方式的约束性协议。不论您喜欢与否，通过建立服务控制，生产者和消费者都将受到其特定规则的管理。

　　回到我们的需求目录，目录中确定出我们希望开发服务，按一种输入普通订单规范来接受。这种规范模式构成了您所公开的、有约束力的契约的一部分。所有用户都必须为服务提供这种规范，将其作为一个输入参数。必须谨慎，确保模式未允许过高的灵活性，如果灵活性过高，就会导致调用一项服务的方法的变换。特别灵活的契约将造成这样的后果：在尝试调试或维护服务时，服务将变得脆弱，并越来越难以处理。

　　在积极的方面，服务契约为确保您的服务能得到迅速和有效利用提供了一种很好的方法。通过设计不涉及业务逻辑和运行时决策的服务实现，服务更可能被用来作为复合服务的部分。通过认识到服务可拥有多个契约，且这些契约决定了如何在运行时使用这些服务，这类收益可得到进一步实现。此概念与面向对象（OO）程序设计中的多态性（polymorphism）相似。服务设计中的最佳实践允许需求在契约级别独立演进，从而保持服务实现的简单和整洁。策略和契约自身可能拥有多对多关系，并且多个服务可能实现同一契约，弄清楚这一点后，服务拥有多个契约的理念可得到进一步的扩展。此时就可利用服务存储库按需调整的能力，从而管理系统的运行时操作。真正的松耦合需要服务基础架构中存在多对多关系。在我看来，这是一种强大的概念，只是在SOA计划中仍处于其幼年时期。

　　遗憾的是，通过利用运行时契约和策略所获得的全部收益包含一些技术限制。特别地，WSDL目前无法对所有组织需要的功能和非功能性需求提供全面支持。此外，WS-Policy规范仍然所欠缺：它只为交换策略信息提供了一个可互操作的容器，但并未提供支持来指定策略行为。我相信，随着组织中SOA采用和技术的继续成熟，这些限制不久之后就会得到改变。

　　元数据

　　根据我的经验，从长远角度来看，组织SOA计划的成功取决于它如何管理和利用元数据。尽管许多组织将通过上市时间的缩短、服务重用等方面受益于SOA计划，但我相信，将可证实组织中元数据的使用就是短期成功和长期改造间的差异。元数据描述了服务以及那些服务的用户如何与之交互，从而提供了灵活性，以便集中关注通过复合连续满足业务需求，从而创建共享服务。

　　对元数据的理解可帮助组织避免将管理和流程硬编码到工具与实现之中，并允许了资源的动态发现。组织必须能够利用SOA基础架构来获取很多信息，而不仅仅是服务细节。必须建立一个元数据存储库来支持所有SOA工件，并允许描述环境中的流程和操作上下文。有效管理元数据的能力将与在整个管理流程中建立恰当、可度量的控制点直接相关。

　　结束语

　　为了在组织中利用SOA计划的全部益处，采纳以下观念非常关键：运行时中的服务是一项企业资产，可被编目和跟踪。这不仅有助于构建您的共享服务目录和缩短上市时间，而且还可连续地作为SOA支出的合理证据。如果您无法通过SOA平台跟踪和度量收益以及成本节约情况，那么将来的成本收益决策就可能仅限于主观信息。

　　通过共享服务的精确运行时管理，组织将改善其SOA计划的效力。与传统软件开发不同，SOA主要关注构建可重用的原子服务上，这些服务通过契约和策略促进灵活性。通过成功的设计和一致的建模方法论，面向服务的运行时方面应更加关注组织中已有的服务基础架构。

　　除了可靠的设计实践和运行时实践外，组织还应认识到SOA也带来了新的挑战，必须通过一致的管理模型和包容的思想加以有效管理。通过包容环境的一些确定因素（如变更），您的SOA计划应提供有机的增长——这些增长只与组织保持竞争优势并被视为行业领袖的期望相匹配。此后，所有的变更都与创新相关，而创新则是具有与众不同的想法。若管理得当，SOA可成为此类变更的关键组件。

　　最后，作为一种架构范例，SOA的目标在于促进重用，允许企业更快地将新产品推向市场。作为一种方法论，SOA要求对组织如何快速地适应变更有深入理解。SSLC的运行时方面与构建组织的灵活性直接相关。本文尝试了提出以下见解：企业要如何通过仔细分析当前需求和面向服务的设计实践来达成此目标。