正如面向服务架构（SOA）自身一样，SOA生命周期是一个受到广泛关注的话题；而专家对生命周期的定义各持己见，他们认为需要强调的领域也不尽相同。本文主要阐述了SOA生命周期的基本概念，及其与传统的应用程序开发生命周期有什么不同、对SOA架构师需要执行的任务有什么影响。文章汇总了专注SOA的分析师的观点，提供该话题的专业意见。

　　OnStrategies公司首席分析师Tony Baer简短地总结了SOA生命周期需要承担的任务，他说：“我们要想方设法把事情搞定。首先，你要明确要求，收集需求条件，设计解决方案，然后对方案进行开发、测试、部署以及管理。在生命周期终止时，你需要修改方案或者更换方案。”

　　他补充道，SOA生命周期与传统应用程序生命周期的不同之处在于，管理SOA生命周期需要维持松耦合服务的秩序。

　　Burton Group公司研发主管Anne Thomas Manes表示同意：“实际上，SOA生命周期相当复杂。你可以想想服务生命周期，包括最初的身份认证阶段，及在最初的位置提供服务的承诺。”

　　Manes提出的SOA生命周期第一步有别于其他人提供的第一步。一开始，她会事先进行规划，得出创建服务及根据服务编写应用程序所需的费用预算。

　　“当你观察SOA项目的起始位置时，”她说，“你需要明确成为一项服务所需的条件。许多组织并没有仔细审查究竟应该在哪建立服务。目前，很多工作人员都没有事先进行规划。他们通常会说：‘我们获得了这项很棒的新技术。我们要将一切都设为服务。’他们并没有真正经历决策过程——明确哪些应该成为服务以及应该在哪付出努力。决定哪些成为一项服务是生命周期中非常重要的一个方面。

　　Macehiter Ward-Dutton公司研发主管Neil Ward-Dutton从了解SOA应用程序的情景开始，全面地阐述了SOA生命周期。

　　“在我们看来，SOA生命周期可以从企业架构和商业架构等情景理解开始，通过服务分析和建模向各方面拓展。建模不仅仅和功能性事件相关，还与安全、性能、审计等非功能性的事件相关。然后就有了开发、测试、供给、监测和改变管理。即使你的想法局限于从应用程序开发的角度来看SOA，这也提供了前所未有的考虑方式。例如，你需要考虑采用一致性方法来建立商业服务，这样的话非功能性事件也可以与基础架构服务的运行时间保持一致。”

　　ZapThink LLC公司的主分析师Jason Bloomberg认为可以在服务中找到SOA生命周期和传统应用程序生命周期的主要区别。

　　“SOA生命周期的主要挑战在于，实际中有两套彼此交叉的生命周期在运行。”

　　Bloomberg说，“一方面，你依然拥有传统的软件生命周期，此时服务是运行软件的接口。你必须采用以代码形式编写的软件。那就是传统的软件生命周期。但是，现在你还拥有服务生命周期，在元数据级中发生作用。在你更新服务、创建服务及重新配置服务的时候，服务生命周期又发生在不同的级别上，因为除非在软件中，否则它就不涉及新的编码过程，但我们的目标是要在元数据级中完成这些变化。”

　　因而，面向服务需要一种新的生命周期，能将注意力集中于元数据和注册表/存储库的内容。

　　“SOA架构设计部分的关键在于建立和维持服务抽象。” Bloomberg说，“一方面，服务是软件的接口，你必须运行相关软件。另一方面，服务是商业能力的抽象表征，企业将这种能力融合在进程中。所以你还需要支持软件的抽象概念，支持其成为企业元数据，使企业变得更加灵活，这是SOA的主要目标之一。”

　　SOA基本生命周期

　　Current Analysis LLC公司应用程序基础架构主分析师Bradley F. Shimmin提出，利用服务建立应用程序的基本SOA生命周期需要八个主要步骤。有些方面与其他分析师提出的步骤不一致，但没有本质区别，因此我们从这里开始讲。

　　利用服务建立SOA的八个步骤

　　1.收集数据：包括收集企业需求和使用案例
　　2.设计：包括明确服务需求、设置服务策略、建立一致性任务、建立并测试模型以及构造数据集成
　　3.发展：包括开发服务、根据服务编写应用程序
　　4.质量保证/测试/认可
　　5.部署
　　6.监测/管理
　　7.变化
　　8.退休

　　谈到这个纲要时，Shimmin说：“我把它看成是梯子上的梯级，通向生活中确实存在的某些东西。你必须从某个地方开始，然后又在某个地方结束。生命周期始于企业分析师从企业中收集信息，这些信息主要是关于应用程序和服务的需求条件。”

　　Shimmin说，信息因公司而定，但是企业分析师通常需要创建一份需求文件，里面有各种使用案例。就像用户需要检查银行财务状况一样，使用案例可以很简单。企业分析师会提供生命周期需要承担的详情。这与最终的应用程序没有关系，只是涉及需求条件和具体使用案例之间的关系。

　　Shimmin说，在收集阶段，企业分析师会给IT人员和系统架构师带来各种需求条件和使用案例。他们一起工作，明确如何将需求条件转化为最终的软件。从这个角度讲，传统应用程序生命周期和SOA生命周期之间存在很大区别。

　　“你在讨论传统的软件开发生命周期时，你拥有软件的开发生命周期，只是在最后几天扩建应用程序，通常一个应用程序拥有一个项目。” Shimmin这么解释，“采用了SOA，你讨论的就是两种截然不同的应用程序类型。你建立的第一种类型是一种服务，这种服务是一个完全独立的单元，没有‘银行帐户的返回值’等具体参数。因此，针对服务具有一种生命周期，另外一种生命周期将那种服务和其它服务合成到最终的应用程序中。”

　　Shimmin强调，这么阐述SOA生命周期的前提是这些服务都会建立。而不是假设服务已经存在且能重复利用，这一点将在后面说明。

　　生命周期基本步骤既可应用在服务中，也能应用于根据这些服务编写的应用程序，但是通常情况下这两种生命周期过程截然不同，包括在SOA架构保护伞下的任务也各不相同。最初，在开发需求条件的数据收集阶段，哪些将成为服务、而哪些将成为合成的应用程序，两者间的区别并不重要。

　　但是在设计之前，架构师就要开始明确哪些使用案例要成为服务，如检查银行财务状况；而哪些商业进程又要包含在SOA应用程序中。

　　服务设计

　　在设计阶段，企业分析师需要和IT人员、系统架构师一起坐下来，根据已确认的服务挑选出需求条件在服务策略方面需要承担什么任务，需要布置怎样的服务策略，一致性方面需要遵守什么条件，如服务等级协议(SLA)和公共密钥基础结构(PKI)。

　　“一些PKI和SLA可以在收集阶段提前完成。” Shimmin说，“但是从我所见到的来讲，大多数都是根据软件即将形成的样子才变得更加明确，然后才完成PKI和SLA。”

　　前两步会产生一些人工的痕迹，如使用案例、设计阶段的模型、以及PKI和SLA。然后开发人员就要根据提供的流程图设计服务。

　　开发和质量保证/测试阶段与传统的软件开发生命周期非常相似。

　　“开发阶段建立服务。” Shimmin解释道，“在第4阶段加入质量保证，可以确保已经形成的架构满足SLA。在这一步中，你也可以在企业测试认可度，从而保证企业用户的需求得到满足。”

　　Shimmin指出，经过了质量保证和认可阶段，项目进入开发阶段，有时候也成为“发布”阶段，这是因为在这一步中服务将发布到存储库和注册表中。人工痕迹也都进入存储库中。

　　“这时，你就进入了下一步，我称之为嵌套软件生命周期。”他说，“因为在这一步你所做的是集成应用程序，所以你可能把已经创建的不同服务综合在一起，然后集成到最终的程序中。可能形成BPEL或Java WAR [Web ARchive]文件，在服务器中运行。要编写这样的应用程序，你得先经历之前的步骤。你需要设计、合成，而不是开发，这就是不同之处。然后你还得经历质量保证/测试/认可等阶段，最后就能部署应用程序了。”

　　步骤6采用了监测、管理及SOA运行时间控制工具。为保证开发软件与策略一致，之前的步骤还采用了设计时间控制工具。监测和管理能保证满足SLA和PKI，并符合一致性需求。如果遇到什么问题，可能还需要回到服务设计阶段，修改某项服务使其符合一致性需求。

　　Forrester Research公司副总裁Randy Heffner认为SOA控制和SOA生命周期彼此交叉。

　　“生命周期就是传送你的服务，你需要在生命周期中有很好的控制权。”Heffner说，“控制是对你所做东西的覆盖。”

　　Shimmin解释，这样生命周期可能得跳回到之前的步骤。例如，在变化阶段，生命周期可能得回到收集或者设计阶段，重新开始改变服务。

　　“如果你需要在服务中添加选项，” Shimmin说，“跳过所有的步骤回到第一步——收集，从头开始。若有问题，就跳到步骤3，也就是开发阶段。如果逻辑上有问题，就跳到步骤2设计阶段。”

　　项目回到步骤1、2还是步骤3，都需要再次经过质量保证和部署阶段。这样，SOA生命周期就会无止境地循环。

　　退休是Shimmin生命周期概要的最后阶段。采用传统的应用程序管理方法，就可能简单地使程序离线；但是在SOA环境中就没这么容易了，因为最初的开发人员和架构师并不了解这项服务在企业中的使用方式。因此在取消一项服务之前，必须检查其与其它服务的依存性。如果一项服务由新的版本取代，必须进行检查并确保依靠就版本工作的SOA应用程序仍然有效。

　　SOA服务组合管理

　　Forrester公司的Heffner比较关注SOA服务，其中重复利用也是一个因素，他认为SOA服务生命周期的最高级别由三个关键部分：

　　1.服务消费
　　2.服务创建
　　3.服务组合管理

　　“人们都认为服务消费和服务创建是两个子生命周期。” Heffner说：“你可能在开始使用时满怀希望，但是你还得创建服务。而且应该在服务组合管理的情景下完成，我们尝试着管理长期的组合，以确保我们拥有正确的服务，而服务也能得到合时、合地、合理的应用。我们在创建这些东西的时候，就把它作为内部组合的一部分。”

　　似乎应该在服务消费前创建服务，但Heffner比较关注在SOA已经准备好的地方重复利用服务。在那种情况下，SOA应用程序开发的错误消费可能重复利用现有的服务。然而，他也承认应用程序需要的服务还未完成时，由这种情况来决定。这时你就应该开始第二步，创建服务。

　　“首先关注消费，这样你采用SOA就有正确的想法了，因为那是错误的方法。”
Heffner说，“这使你第一次有重复利用的想法。”

　　按层次来讲，Heffner认为服务组合管理应该体现在服务消费和服务创建中。

　　“如果你正在实施的服务组合管理正好与其它两项有关，你就需要改变用以实现重复利用的模型，而且要用业内还不怎么讨论的方式来实现这种变化。”Heffner说，“专业人员在讨论重复利用时主要关注‘发现’，但是如果你能仔细考虑，这就是类似于哥伦布式的大事件。”

　　这种发现的方法相当于一种说法：“我们要开始一个新的项目，让我来发现一个新的服务世界吧。” Heffner说，这将是开发SOA的专用方法。

　　他说：“如果你仅仅拥有服务消费和服务创建，那就是你即将拥有的。”

　　采用服务组合管理，你能获得由企业进程域组织的企业主要服务结构组。

　　“然后在你开始设计一个新的项目时，你就不会说我们看看能找到什么。”Heffner进一步解释，“你会说这个项目属于这个领域。我们拥有组合管理。这种组合如何体现在项目中？从而在项目中设计重复利用。我们已拥有一套组合，我们正在实施这些主要的商业单元。我们拥有了解、理解这个领域的人员。我们可以采用正确的方法合法地利用服务。因此就不再是发现式的模型。脱离组合，这个项目中我们还要消费什么？”

　　只有当组合中没有需要的服务时，生命周期才开始创建服务。

　　SOA服务消费者生命周期

　　在Manes看来，使SOA生命周期异常复杂的其中一项原因在于，生命周期需要同时处理服务创建和服务消费这两方面内容。生命周期在消费方面有别于创建，但仍属于SOA架构师的工作。

　　服务创建生命周期的基本消费在于，建立的服务至少拥有一名消费者，但是其他消费者可能会把现有的服务融入到新的应用程序中。

　　Manes认为SOA服务生命周期在消费方面需要三步：

　　1.检索存储库中的元数据
　　2.为新应用程序提供服务
　　3.测试性能并规划容量

　　消费者要做的第一步就是检索存储库中的元数据。

　　她说：“根据契约规定，元数据可以在将要采用该项服务的应用程序之间正确进行连接。”

　　但是服务消费在部署之前，需要得到正确供给。消费者需要在策略管理体系中注册，此时才允许享受这项服务。使用服务还需要身份验证机制。

　　第三步是测试性能和规划容量，确保服务能支持应用程序的需求条件。这可能包括协调服务的SLA。

　　Manes说，服务提供商需要了解参与服务、准备服务的负担。

　　缩短SOA生命周期

　　上述内容大都和SOA生命周期的复杂性相关，Interarbor Solutions LLC公司首席分析师Dana Gardner认为，在时间框架方面应尽可能缩短，以维持SOA的动态质量。他说，这是SOA生命周期和传统应用程序生命周期的主要区别。

　　“你的服务是动态的，所以你想要根据需求相对频繁地更新或者替代专项服务。” Gardner这么解释，“更抽象地讲，你要改变那些服务支持的商业进程，因为你想相对较快地进行调整和修正，以保证效率。你想给更多的人——那些与商业进程有关的人——一个说法，告诉他们如何适时修改、优化进程。”

　　为什么SOA架构师的工作与众不同

　　分析师说，SOA生命周期改变了SOA架构师的作用，使他们有别于传统的企业架构师。

　　“几乎可以说是思想上的差异。”Gardner说，“SOA架构师应该不断寻求更高的生产力。他的作用应该是一个城镇的规划者，而不是高楼的建设者。他需要考虑所有影响企业能力的动态因素，而一个企业的能力往往包括完成各项工作、进军新市场、生产新产品等。因此，从SOA角度讲架构师总是在寻求生产力的持续提高。”

　　实际上，可以认为架构师是实施SOA的关键人物。

　　“SOA生命周期以很有趣的方式影响了架构师。” Ward-Dutton说，“首先，很多架构师在以前仅仅是‘办公室角落的设计师’，实际上，这样的人也很少。他们如果想要摆平SOA，就得拓宽视野，担起责任，协调服务设计人员和开发人员的要求与期待，协调基础结构管理人员和系统管理人员的需求。其次，服务提供商和消费者在SOA上很容易出现空白，架构师需要填补这种空白。这些挑战非常严峻，因为它们并非关于技术技巧，或者不仅仅是关于技术技巧。迎接这些挑战要求架构师成为真正的外交官，具备协商能力和影响力。”