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

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

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

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

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

组合应用程序和服务分层

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

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

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

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

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

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

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

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

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

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

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