主题
企业架构
了解 SOA 中的服务生命周期:设计时
页面: 1, 2, 3
现在我们来看看共享服务生命周期的设计时方面。提到设计时,我主要关注服务投入生产和使用之前的生命周期。本文不涉及设计时建模的许多需求,如开发服务建模方法,但如有兴趣,我将在未来的文章中阐述这一主题。
SOA 的一个核心原则是业务和 IT 保持一致以及建立 竞技场 (playing field)。通过识别企业通过服务定位提供价值的业务流程,服务工程团队(通常是业务、分析师和 IT 人员的组合)可以在讨论的出发点方面达成一致。
许多企业发觉很难理解从何处开始 SOA 以及哪些是最合适的业务流程。一种好的方法是首先在白板上定义需求目录。将白板区域划分为三条 泳道,分别代表短期需求(3 到 6 个月 — 通常本质上更有战术性)、中期需求( 6 到 18 个月)和长期需求(超过 18 个月 — 通常为战略需求,可能随业务需求的变化而变化)。划分泳道之后,开始为每个区域添加需求。尽量避免按应用(例如,电子商务站点)思考;看得越远,越有可能达到您要求的高度(例如,我需要完善自己的清单系统)。在生命周期的这一阶段,主要着眼于可能成为业务组成部分的业务流程,如电子商务站点。
完成初步分析之后,服务工程团队可以开始寻找依赖性,试图决定优先级、揭示重用可能性或确定需求之间的依赖性。观察下面的需求目录示例,可以看到对于该企业来说,最初集中在用户注册流程上是再合理不过了,因为许多其他流程依赖于该流程,而且它可以在整个电子商务功能和企业内联网中重用。
图 2:需求目录示例,它向服务工程团队提供了实现公司未来状态的路线图
根据公司在服务设计和开发方面的成熟度,选择首先开发哪种服务可能很自然地导致构建没有很多依赖性的服务,同时积累经验。尽管这些想法是对的,但是在企业成熟度中,熟悉增强重用的服务建模技术是很重要的,如强大的合同和策略定义。服务工程团队必须意识到重用概念以前曾在业务中提到过多次,但没有多大成效。由于相对于传统应用程序生命周期来说,服务开发周期较短,服务工程团队有能力从短期目录创建一系列可以跨计划快速利用的基础服务,从而实现早期的成功。
然而,对初始服务(特别是依赖服务)的选择应与服务工程团队的能力相一致,这是很重要的。新的团队需要时间才能在 SSLC 的设计阶段具有更多经验。在服务目录中确定的依赖服务可能由于具有较高的重用水平,看似是一个好的侯选服务,但是不适合不太成熟的团队。如果一个服务已涉及到跨业务线、提供企业级功能或遵守严格的服务质量规章的依赖性,则它可能不是一个理想的初始侯选服务。
另一方面,对于具有已定义流程和已知终端的服务,如果这些终端是受控的、成熟的并且范围很小,在必要的情况下,服务本身的离散程度足以构建或重构,那么在很短的时间内,这种服务是初始开发的主要侯选服务。这样的初始服务应该能够很快地验证假设、方法和流程。正确的设计需要经验和实践。反复进行试验并纠正错误,尤其在 SOA 计划的成型阶段,这种方法是判断在您的企业内哪些 SOA 实践可以发挥作用的重要机制。早期选择没有依赖性的 独立 服务可能会限制服务工程团队在成型阶段获取重要经验的机会。
服务设计和建模阶段的目标是,基于需求目录中确定的业务流程建立一种定义侯选服务的一致方法。真正开始执行的时候,服务工程团队通常用白板描绘业务流程、分解步骤以及讨论当前和未来的需求。为此,应使用业务和 IT 均可理解的常用语言来建立一致的设计方法。
服务设计方法为服务工程团队提供了一系列可用于分解业务流程的步骤或活动,基于面向服务的设计原则确定服务中开发哪些方面是有意义的。对于这种设计方法,许多企业最初有一些争执,尤其是服务粒度。过细的粒度可能产生不可重用的服务增殖;过粗的粒度又很难着手。在团队对建模流程满意之前,它应该将其活动集中在定义良好的业务流程中,这些业务流程可能并没有较大 企业 需求(如高生产量、长期运行的事务)。
尽管从技术上来说不是建模阶段的一部分(但可能是建模方法的一部分),但我的经验表明:在定义服务分类原则方面投入时间对企业来说是很重要的。这些指导方针应该定义服务的哪些方面决定了服务是业务线 (LOB) 或应用程序级服务,还是具有特殊需求的企业服务。这些指导方针可能包括生产量、服务质量 (QoS)、正常运行时间、服务重要性以及多少客户将使用该服务。另外,开始定义与建立和管理服务相关的企业治理控制时,这些指导方针至关重要。开发指导方针可能本身是贯穿始终的工作,但开头很简单,只定义当前需求所要求的部分即可。而且,服务分类可能有助于对相似功能分组并确认这些功能的业务所有者。记住,后续出现新的需求时可以重新调整指导方针。
图 3:服务分类及其与 SOA 治理的关系;此分类可能有助于定义 SOA 资产的企业治理控制。
根据服务目录示例,企业可能已经建立了企业服务和业务线服务类别。以下进行详细描述。