了解 SOA 中的服务生命周期：设计时

作者：Quinton Wall
10/04/2006

摘要

面向服务的体系结构 (SOA) 描述了一种体系结构方法，它依赖于将业务流程和较低级别的活动分解为基于标准的服务。这些服务可以是细粒度、粗粒度、以表示为中心、以数据为中心或许多其他变换方式。有效管理服务的生命周期是 SOA 计划中获取成功的基石。这些内容将在两篇文章中分别针对生命周期设计时和运行时进行讨论。第一篇文章涵盖服务生命周期中的设计时阶段。

传统的应用程序开发

识别一些 SOA 引入企业的范例转换是了解服务生命周期管理需求的重要因素。许多设计人员和分析人员（Groves 2005、Dwyer 2006）已经指出 SOA 要求业务和 IT 更紧密地相结合。这本身通常就是企业运营中的巨大转变。另一个是从应用程序的开发和部署转换到离散服务。

关于 IT 项目，应用程序可以定义为解决某一或某类用户需求的任务集合。例如，外汇应用程序可能包含支持搜索交易、定义交易方式以及将订单提交至交易记事簿的任务和功能。这些功能是针对松散定义为外汇交易者的某一类用户设计的。传统上，应用程序是按照企业中的项目或计划进行开发的。项目经理和分析师定义需求和所需功能、确定工作成果级别以及所需资源和某些控制因素（如成本、范围和时间）。这正是传统应用程序开发生命周期令人担忧的地方。

通常在定义这些应用程序的功能时 考虑 需求。通过在整个构建过程中迭代需求定义，敏捷编程方法试图消除这一担忧。此方法在一定程度上减少了人们的担忧，但是规则及处理行为可能仍然嵌入在应用程序中。服务生命周期讨论将不会直接解决这一问题，但是 SOA 中的服务组合提供了一种对逻辑进行分离的方法。另外，由于传统应用程序中的紧密耦合，在任务的可交付、运行时管理中组合众多功能的需求通常是相当困难的。与安全性、服务质量等相关的许多决策在设计时而不是运行时完成，因此极大地降低了应用程序的灵活性，而灵活性正是满足不断变化的业务需求所需要的。

对传统应用程序开发项目的更大担忧是过长的开发和准备时间。应用程序在投入生产之前花费 6 到 12 个月的情况并不少见。我曾经参与过许多项目，它们在进入生产之前花费了数年时间。希望更快地投入市场是导致 SOA 出现的一个关键因素。传统应用程序开发流程通常导致试图将尽可能多的功能融入到一个项目中，这是不现实的！从这个角度讨论服务生命周期是很重要的。扩大范围会产生两种后果：降低发布质量和导致项目延迟。这两种情况对业务或 IT 部门都是不理想的。了解服务生命周期管理可以直接解决这一问题。

作为将应用程序分解为跨公司共享的服务的一种方法，SOA 的普及度和受关注程度日益提高，利用 SOA 原理来尝试解决许多传统应用程序开发周期的负面问题一点儿也不令人惊讶。到目前为止，采用 SOA 来消除这些担心已表现出了可观的成效，但是也引入了大量关于生命周期管理、服务管理和企业感知的新需求。本文试图发现有关所谓的共享服务生命周期 (SSLC) 的一些问题和最佳实践。

共享服务生命周期

许多公司和分析师使用 业务服务生命周期 来描述与 SOA 服务关联的生命周期。我更喜欢使用术语 共享服务生命周期（即 SSLC）。在定义中使用术语 业务 表示我只讨论代表业务流程的服务（通常称为组合服务），而不是基础服务，如提供信息和访问物理数据源及安全服务。使用 共享 代替 业务，您可以更好地认识到服务生命周期管理直接受其与企业中其他服务（某些组合业务服务）的关系所影响。

图 1 描述了典型的迭代 SSLC，包括设计时和运行时两个方面。本文集中讲述设计时方面，后续文章将讨论 SSLC 的运行时阶段。

图 1：共享服务生命周期的设计和运行时阶段