在本文中，将为面向服务的体系结构（Service-Oriented Architecture，SOA）项目的服务建模用例和业务需求。另外，您还将了解如何以最佳方式捕获和记录这些需求……

　　在本文中，将了解有关 SOA 项目的业务方面的更多信息。您将了解需要作为初始 SOA 服务推出工作的一部分加以捕获的业务需求的关键方面。另外，您还将了解可用于捕获这些需求的基础需求技术的信息(虽然了解“是什么”比知道“怎么做”更为重要)。

　　本文将讨论需求标识流程和如何在 SOA 项目中构建第一批服务。

　　入门

　　本文假定您拥有一个定义良好的 SOA 计划。您已经为 SOA 标识了一组基本技术需求，现在需要考虑“应该构建哪些 SOA 服务”。组织内不同的 IT 团队可能会有不同的观点：有些人可能会希望构建技术服务，如内容管理服务、安全(身份验证/授权)相关的服务或其他服务。不过，SOA 项目的关键是第一组业务服务。我不讨论从何处入手——我假定您从业务服务入手。首先分析一下用于标识这些业务服务的方法。

　　服务标识

　　让我们了解一些基本思路，确定如何标识将要作为 SOA 的一部分构建的第一个服务或第一批服务。需要从对业务影响的角度将这些服务隔离开来，而且必须准确地确定其范围。反过来说，这些服务应该足够重要，能说明长期 SOA 发展计划的价值和远景。

　　自顶向下服务标识

　　在自顶向下方法中，将首先从高级业务用例或组织中存在的业务流程流开始。还可以从业务策略或 IT 策略计划说明(其中包括业务策略)着手。这只是一个入口点，以便开始将流程划分为功能区域或子系统。将为整个系统进行此工作，并随后开始确定任何难点、高度可重用用例或可初步作为候选 SOA 服务的功能。请注意不要选择最复杂或有争议的服务。

　　自顶向下方法是由业务进行驱动的：存在可作为参考信息来确定 SOA 服务的业务文档。图 1 显示了可以在自顶向下方法中使用的简单步骤。

图 1. 自顶向下方法

　　在本文中，将为面向服务的体系结构（Service-Oriented Architecture，SOA）项目的服务建模用例和业务需求。另外，您还将了解如何以最佳方式捕获和记录这些需求……

　　自底向上服务标识

　　在自底向上方法中，将从现有系统或应用程序开始着手。将尝试发掘存在的任何有关这些系统的文档，并随后以此为依据构建功能区域、子系统映射和高级业务用例。这可能更为困难，但在大多数组织中都是不可避免的，因为自顶向下方法中使用的高级文档要么不存在，要么已过时。自底向上方法更多是由 IT 驱动的;业务缺乏关于其策略、功能和核心能力的文档。

　　图 2 显示了用于进行服务标识的自底向上示例方法。它与自顶向下方法的差别并不大——但起点差异很大。

图 2. 自底向上方法

　　收集单个服务的需求

　　此部分将对一个服务进行深入的分析。将讨论需求的类型，以及为 SOA 中的服务收集需求所需遵循的流程。

　　需求类型

　　现在已经准备好，可以捕获第一个 SOA 服务的需求了。从广义而言，需要捕获以下方面的需求。请记住，本文关注的是业务需求——前一篇文章讨论的是服务的技术需求：

• 　　可访问性。服务的用户如何查找和访问此服务?这个需求既是技术需求，也是业务需求。不过目前暂时仅考虑需要查找并调用所构建的服务的业务流程。
• 　　功能。此服务将提供何种核心业务流程或功能?所解决的业务问题是什么?这方面可能要进行大量的讨论。必须确定 SOA 中服务的恰当粒度。
• 　　交互。调用此服务的服务或应用程序如何与其进行交互?服务如何处理各种错误情况?
• 　　信息。向此服务发送什么数据，以及从此服务接收什么数据?
• 　　流程。此服务的操作和事件的关系如何?

　　需求流程

　　现在已经了解了需要作为服务需求的一部分加以捕获的信息类型，接下来让我们讨论一下相应的流程。在非 SOA 环境中，需要服务或应用程序的用户从业务的角度说明其希望服务执行什么工作。在 SOA 中，并不总是知道服务的所有使用者(或潜在使用者)。在这种情况下，需要服务提供者(为其创建此服务的业务涉众)描述其希望服务完成什么工作。应该与一些已知的服务使用者验证这个描述——但无法也不应该尝试与所有潜在使用者接触。这样做并不可行。

……