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

　　摘要

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

　　传统的应用程序开发

　　识别一些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实践可以发挥作用的重要机制。早期选择没有依赖性的孤立服务可能会限制服务工程团队在成型阶段获取更多的学习机会。

　　服务设计和建模

　　服务设计和建模阶段的目标是，基于需求目录中确定的业务流程建立一种定义侯选服务的一致方法。真到开始做的时候，服务工程团队通常用白板描绘业务流程、分解步骤以及讨论当前和未来的需求。为此，一致的设计方法学应该使用业务和IT均可理解的常用语言来建立。

　　服务设计方法学为服务工程团队提供了一系列用于分解业务流程的步骤或活动，基于面向服务的设计原则确定服务中开发哪些方面是合理的。对于这种设计方法学，许多企业最初有一些争执，尤其是服务粒度。过细的粒度可能产生不可重用的服务增殖；过粗的粒度，又很难着手。在团队对建模流程满意之前，它应该将其活动集中在定义良好的业务流程中，这些业务流程可能并没有较大企业需求（如高生产量、长期事务）。

　　尽管从技术上来说不是建模阶段的一部分（但可能是建模方法学的一部分），但我的经验表明：在定义服务分类原则方面投入时间对企业来说是很重要的。这些指导方针应该定义服务的哪些方面决定了服务是业务线（LOB）或应用程序级服务，还是具有特殊需求的企业服务。这些指导方针可能包括生产量、服务质量（QoS）、正常运行时间、服务关键程度以及多少客户将使用该服务。另外，开始定义与建立和管理服务相关的企业治理控制时，这些指导方针至关重要。开发指导方针可能本身是贯穿始终的工作，但开头很简单，只定义当前需求所要求的部分就可以。而且，服务分类可能有助于将相似功能分组并确认这些功能的业务所有者。记住，后续出现新的需求时可以重新调整指导方针。

　　图3：服务分类及其与SOA治理的关系；此分类可能有助于定义SOA资产的企业治理控制。

　　根据服务目录示例，企业可能已经建立了企业服务和业务线服务类别。以下进行详细描述。

　　企业服务

　　企业服务具有水平影响，可能包括：

　　无论在是周边或核心部门，安全性都需要符合行业规范。

　　活动审计。记住审计可能是某一特定功能的一个方面，如外汇交易，而不是进行交易的流程。

　　一般异常处理。

　　服务要求24x7可靠性，并且必须据此进行治理。

　　服务要求大容量和（或）低延迟吞吐量。

　　根据使用环境，服务可能要求更高级别的客户服务或响应时间。例如，客户个人信息表明他们是贵宾客户，则服务契约会要求不同的SLA。

　　若服务要求跨业务线进行交互，则可能具有必须满足的企业基础架构需求。

　　服务与企业数据进行交互。这方面可能意味着企业拥有通用模型，而具体用户数据存储的实现则由业务线控制。经验和实践表明，大量的用户数据存储存在于企业中。SOA目标的一部分就是为了长期巩固这些方面，但在定义未来计划时，不应脱离现实，而是要充分利用现有资源。

　　业务线服务

　　这些服务具有垂直影响，可能包括：

　　特定业务功能，如采购单（PO）或新的租赁处理。

　　具有特定UI和外观的表示服务，或者通常用于提供某一特定业务功能的可视化表示的向导。

　　支持业务线的CRUD（创建、读取、更新、删除）活动的信息和访问服务。

　　应用服务，如基于特定业务线数据的销售跟踪或预测。

　　此分类并不完整，但应该可以提供企业如何开始分类工作的概念。

　　通过检查以上类别，可将以前定义的需求目录中的某些侯选服务放至治理组中，并识别出以前并不明显的许多典型结构：

　　企业服务 业务线服务

　　登录企业内部网（内部网基础架构主要由IT或特殊的LOB管理）

　　更新个人信息（个人信息范例） 更新个人信息（服务）

　　登录电子商务网站

　　销售人员个人信息范例 创建销售人员个人信息

　　清单项范例 购买电影

　　清单项范例 购买书籍

　　查看我的订单状态

　　支付范例 提供支付信息

　　清单项范例 出售书籍

　　查看企业新闻

　　清单范例 检查电影清单

　　清单范例 检查书籍清单

　　检查所有清单

　　整合清单系统（通常按实际服务进行长期计划）

　　服务生命周期主要是为了解决业务需求问题，而不是过度陷于具体的分类练习。SSLC评估阶段是为了支持基于实际应用和环境的再评估。我想到电影《梦幻之地》中凯文·科斯特纳听到的声音重复说：“你盖好了，他们就会来”。这与在企业中公开服务没有什么区别。在某一时间点上以某一使用级别定义的内容实际上可能会以完全不同的方式使用，也就是通常在最初设计时并未考虑到的方式。指导方针在重分类阶段应该有所帮助。

　　在流程的这一阶段，我主要谈论侯选服务与服务实现的概念。Erl（2004）建议侯选服务是潜在的服务，这些服务可能在最后的设计中实现，也可能不实现。设计流程是为了确定设计和开发的未来阶段的输入。理解企业中哪些服务已存在以及哪些需要开发对服务工程团队来说特别重要。支持服务发现的工具（如兼容UDDI的注册库）是促进服务重用和了解现有可用资源的重要组件。

　　最后，在建模阶段，随着逐渐理解了团队正在定义侯选服务，服务工程团队应通过独立于技术架构和物理环境约束的已确定方法学继续进行设计。服务设计和建模阶段的目的就是定义期望的未来状态。SSLC的构建和组合阶段将使侯选服务遵守组织约束以定义最后的服务实现。

　　构建和组合

　　为更加快速经济地开发新的功能，服务生命周期的构建和组合重点集中在开发新服务以及利用企业中现有资源所要求的任务上。这一方法可以缩短上市时间，从而实现SOA的一项关键财务收益。

　　在本阶段，服务建模和设计阶段确定的侯选服务被具体化成服务操作，并将基础架构和环境实体映射到它们。正如在建模阶段提到的，确定SOA计划的目标是很重要的。由于当前环境的限制，实现这些目标可能比较困难，但是可能会促进某些良性讨论以及某种成本利润分析，从而确定如何实现期望的未来状态。但是，现在的企业需要继续发展，所以您的侯选服务在企业环境中必须具有现实意义。

　　理解了哪些服务操作和实现比较现实之后，就可以着眼于重用的可能性以及在上一阶段确定的组合。要充分利用SOA，组合的概念对业务敏捷性来说非常重要。开发环境和服务基础架构工具必须推动设计时发现服务，并可组合这些服务，完成整个业务流程。

　　没有这些工具，SOA计划的成功可能会受到阻碍。随着初始服务对业务线团队和其他工程团队可用，组合的机会可能得以实现。在这种情况下，在分类的同时已确定了初始依赖性。这些依赖性应描述为构建组合服务的直接可能性，并应提供重用的切实收益。本文中只稍微提到了组合，但这些活动的重要性与SSLC的构建和组合阶段直接相关。

　　考虑需求目录示例：一个称为整合清单系统的计划已在长期目标中确定。在第一次浏览时，该任务可能被描述为物理上废弃旧清单系统，并将存储库整合到一个主数据源中。尽管可能真的会是这样（如果成本利润分析表明废弃旧系统更加经济有效的话），活动也可能表述为一种没这么具体的形式。服务工程团队可能产生一系列逻辑数据服务，对客户隐藏物理端点。构建普适数据访问层的这一方法将通过组合直接利用在中期需求目录中开发的现有检查清单X服务。整合清单系统计划可能要求根据清单文档的典型表示来决定哪些端点需要修改。这种分散式CRUD逻辑应在“服务基础架构工具”中提供，这样的一个示例是BEA AquaLogic Data Services Platform。

　　通常，服务起源于业务线级别而不是通过企业计划，因为一般情况下这是驱动项目建立和需求的地方。结果，“你盖好了，他们就来了”方案可能导致设计时发现的服务不是良好的重用侯选服务。它们可能不提供足够的性能或一致模式。尽管它们在企业中可用，但仍为应用程序级服务。最后，企业必须开始创建管理流程以控制服务的企业可见性。在通常情况下，服务注册提供确保服务质量的管理机制和流程。这些问题必须在服务生命周期的发布和准备阶段予以解决。

　　最后，要进行快速的开发，经验表明，工具标准化可使企业充分利用现有知识并在整个SOA计划中重用。这不是说每个人都必须使用相同的IDE或某个特定工具，而是说使用的任何工具必须以类似的模式工作，必须支持标准；若开发人员需要使用不同的工具支持其他项目，则必须降低学习的难度。另外，这些工具必须能够轻松地度量服务的重用性和控制上市时间。通过服务生命周期获得度量可以为企业提供价值巨大的信息，帮助SOA计划获得成功。

　　BEA域模型

　　正如许多方法学所述，需要建立一种底层模式来统一所有其他活动。在BEA和SOA环境中，就是BEA的域模型（需要注册）。Dev2Dev中有许多文章描述理解SOA各个方面的重要性（详见David Groves撰写的Successfully Planning for SOA）。共享服务生命周期使用该模型并按此方式提供切实的控制点。在本文定义的设计时阶段中，域模型的影响通过定义项目和应用程序的需求以及架构方法的需求目录来表述。

　　该方法通常开始于远景，最初通过基础服务或构造块实现。尽管治理在设计阶段没有在SSLC的运行时那么关键，但是治理已开始在流程中产生了一定的影响，特别是在决定初始服务实现时。

　　本系列文章的第二部分将揭示评估部署服务成本和收益的重要性，并继续关注在运行时如何对服务进行治理。另外，SSLC的设计时和运行时阶段都要求紧密结合业务策略和流程。这就要求确定和设计可能成为侯选服务的业务流程，并将它们组合成可重用服务，以实现业务的灵活性。

　　结束语

　　通过进一步理解与共享服务生命周期相关的设计时需求，正在寻求使用SOA促进重用和增加业务灵活性的企业可能认识到及早建立基础架构（如方法学、分类指导方针以及开发工具）是实现早期及后续成功的重要因素。通过突破传统应用程序开发范型以及关注作为发展蓝图的业务流程，服务工程团队可以及时有效地紧密结合业务需求。