服务设计和建模
服务设计和建模阶段的目标是，基于需求目录中确定的业务流程建立一种定义侯选服务的一致方法。真到开始做的时候，服务工程团队通常用白板描绘业务流程、分解步骤以及讨论当前和未来的需求。为此，一致的设计方法学应该使用业务和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促进重用和增加业务灵活性的企业可能认识到及早建立基础架构（如方法学、分类指导方针以及开发工具）是实现早期及后续成功的重要因素。通过突破传统应用程序开发范型以及关注作为发展蓝图的业务流程，服务工程团队可以及时有效地紧密结合业务需求。
