理解SOA中的服务生命周期：设计时(1)

传统的应用程序开发

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

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

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

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

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

共享服务生命周期

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

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

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

SSLC中的设计时注意事项

现在我们来看看共享服务周期的设计时方面。提到设计时，我主要关注服务投入生产和使用之前的生命周期。本文不涉及设计时建模的许多需求，如开发服务建模方法学，但如有兴趣，我将在未来的文章中阐述这一主题。

确定业务流程

SOA的一个核心原则是业务和IT保持一致以及建立竞技场(playing field)。通过识别企业通过服务定位提供价值的业务流程，服务工程团队(通常是业务、分析师和IT人员的组合)可能在讨论的出发点方面达成一致。

许多企业发觉很难理解从何处开始SOA以及哪些是最合适的业务流程。一种好的方法是首先在白板上定义需求目录。将白板划分为3条泳道，分别代表短期需求(3到6个月——通常本质上更有战术性)，中期需求(6到18个月)和长期需求(超过18个月——通常为战略需求，可能随业务需求的变化而变化)。划分泳道之后，开始为每个区域添加需求。尽量避免按应用系统(如，电子商务网站)思考;看得越远，越有可能达到您要求的高度(例如，我需要完善自己的清单系统)。在生命周期的这一阶段，主要着眼于可能成为业务组成部分的业务流程，如电子商务站点。

完成初步分析之后，服务工程团队可能开始寻找依赖性，试图决定优先级、揭示重用可能性或确定需求之间的依赖性。观察下面的需求目录示例，可以看到对于该企业来说，最初集中在用户注册流程上是再合理不过了，因为许多其他流程依赖于该流程，而且它可以在整个电子商务功能和企业内部网中重用。

图2：需求目录示例，它向服务工程团队提供了实现公司未来状态的路线图

根据公司在服务设计和开发方面的成熟度，选择首先开发哪种服务可能很自然地导致构建没有很多依赖性的服务，同时积累经验。尽管这些想法是对的，但是在企业成熟度中，熟悉增强重用的服务建模技术是很重要的，如强大的契约和策略定义。服务工程团队必须意识到重用概念以前曾在业务中提到过多次，但没有多大成效。由于相对于传统应用程序生命周期来说，服务开发周期较短，服务工程团队有能力从短期目录创建一系列可以跨计划快速利用的基础服务，从而实现早期的成功。

无论如何，对初始服务（特别是依赖服务）的选择应与服务工程团队的能力相一致。这是很重要的。新的团队需要时间才能在SSLC的设计阶段具有更多经验。在服务目录中确定的依赖服务可能由于具有较高的重用水平，看似是一个好的侯选服务，但是不适合于尚未成熟的团队。若一个服务已涉及到跨业务线、提供企业级功能或遵守严格的服务质量规章的依赖性，则它可能不是一个理想的初始侯选服务。

另一方面，对于一个具有已定义流程和已知端点的服务，如果这些端点是受控的、成熟的并且范围很小，在必要的情况下，服务本身的离散程度足以构建或重构，那么在很短的时间内，这种服务是初始开发的主要侯选服务。这样的初始服务应该可以很快地验证假设、方法学和流程。正确的设计需要经验和实践。反复进行试验并纠正错误，尤其在SOA计划的成型阶段，这种方法是判断在您的企业内哪些SOA实践可以发挥作用的重要机制。早期选择没有依赖性的孤立服务可能会限制服务工程团队在成型阶段获取更多的学习机会。