了解 SOA 中的服务生命周期：设计时
页面： 1, 2, 3

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

• 无论是在周边还是核心部门，安全性都需要符合行业规范。
• 活动审计。记住审计可能是某一特定功能的一个方面，如外汇交易，而不是进行交易的流程。
• 一般异常处理。
• 服务要求全天候可靠性，并且必须据此进行治理。
• 服务要求大容量和/或低延迟吞吐量。
• 根据使用环境，服务可能要求更高级别的客户服务或响应时间。例如，如果客户个人信息表明他们是贵宾客户，则服务合同会要求不同的 SLA。
• 若服务要求跨业务线进行交互，则可能具有必须满足的企业基础架构需求。
• 服务与企业数据进行交互。这方面可能意味着企业拥有规范模型，而具体用户数据存储的实现则归由业务线控制。经验和实践表明，大量的用户数据存储存在于企业中。SOA 目标的一部分就是为了长期巩固这些方面，但在定义未来计划时，不应 脱离现实，而是要充分利用现有资源。

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

• 特定业务功能，如采购订单 (PO) 或新的租赁处理。
• 具有特定 UI 和外观的表示服务，或者通常用于提供某一特定业务功能的可视化表示的向导。
• 支持业务线的 CRUD（创建、读取、更新、删除）活动的信息和访问服务。
• 应用服务，如基于特定业务线数据的销售跟踪或预测。

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

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

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

在流程的这一阶段，我主要谈论侯选服务与服务实现的概念。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 撰写的“成功规划 SOA”）。共享服务生命周期利用该模型并按此方式提供切实的控制点。在本文定义的设计时阶段中，域模型的影响通过定义项目和应用程序的需求以及体系结构方法的需求目录来表述。

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

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

总结

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

本文的第二部分将关注共享服务生命周期的运行时。

参考资料

• SOA Compass:Business Value, Planning and Enterprise Roadmap，Bieberstein 等著（2005 年）；可从 Amazon.com 或其他零售商处购买
• Business Benefits of Implementing SOA，Tom Dwyer 著（The Yankee Group，2005 年）
• Service-Oriented Architecture:Concepts, Technology & Design，Thomas Erl 著（2004 年）；可从 Amazon.com 或其他零售商处购买
• W3C（2004 年） Web Service Management:Service Life Cycle

Quinton Wall 是 BEA 集成部门的高级产品营销经理，他负责明确产品（WebLogic Integration 和 AquaLogic Integration）的战略远景和方向。