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

　　概述

　　在本系列的第一篇文章中，您已经了解了如何确定面向服务的体系结构（SOA）项目的技术需求。其中首先讨论了在分析业务需求之前分析技术需求的原因。尽管这个问题并没有“正确”答案，但就我个人的经验而言，大部分（如果不是全部的话）SOA项目都是由信息技术（Information Technology，IT）部门牵头进行的，通常会首先讨论技术方面的内容。前一篇文章讨论了不同类型技术需求的细节以及在捕获这些需求时需要注意的各种问题。

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

　　本文将讨论需求标识流程和如何在SOA项目中构建第一批服务。本系列的第3部分（最后一部分）将基于这些服务收集、记录和管理需求，以便推出企业SOA 。

　　入门

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

　　服务标识

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

　　自顶向下服务标识

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

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

                          

　　图1. 自顶向下方法
 
　　自底向上服务标识

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

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

                     

　　图2. 自底向上方法
 
　　请参见参考资料中列出的文章，其中对服务标识的概念进行了更为深入的分析。

　　收集单个服务的需求

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

　　需求类型

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

　　·可访问性。服务的用户如何查找和访问此服务？这个需求既是技术需求，也是业务需求。不过目前暂时仅考虑需要查找并调用所构建的服务的业务流程。

　　·功能。此服务将提供何种核心业务流程或功能？所解决的业务问题是什么？这方面可能要进行大量的讨论。必须确定SOA中服务的恰当粒度。（请参见本文最后的参考资料部分，其中给出了对此进行更为详细讨论的文章。）

　　·交互。调用此服务的服务或应用程序如何与其进行交互？服务如何处理各种错误情况？

　　·信息。向此服务发送什么数据，以及从此服务接收什么数据？

　　·流程。此服务的操作和事件的关系如何？

　　需求流程

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

　　从流程的角度而言，您需要让服务提供者描述服务功能和非功能需求。首先将使用任何需求方法或工具捕获前一部分中描述的所有信息类型：IBM Rational Unified Process和IBM Rational RequisitePro或自发需求会议中使用的简单文字处理文档。在此阶段，我并不建议使用太过正式的流程。基本想法是，快速提供能说明SOA价值的一些服务。不过，仍然应该采用某种方式对这些需求进行记录。

　　记录单个服务的需求

　　如何有效地记录需求呢？此文档流程可帮助您验证业务需求，以便最终加以确定；它还可帮助与将负责实现服务的技术团队就需求进行沟通。

　　您可能以前使用过用例。这是一项可用于捕获SOA需求的优秀技术。图3显示了可以用于记录这些需求的用例模板示例。Rational RequisitePro和其他Rational工具提供了可供使用的很多其他模板。关键不是您使用哪个模板。只要捕获了前面描述的需求类型，就没有问题了。

                  

　　图3. 用例模板
 
　　总结

　　阅读了本文之后，您应该已经了解了如何标识作为SOA项目的一部分的初始服务集。另外，您还了解了如何使用现有需求流程和技术为这些服务收集需求并记录需求。文章“Creating ideal SOA teams”（请参见参考资料）说明了如何更为有效地设计团队结构以及业务分析人员在SOA项目中的角色。

　　下一篇文章将假定您在进行企业SOA规划——试点项目很成功，已经准备好，并获得了所需的资金，可以启动覆盖范围大的SOA计划了。您将更多地了解到如何为这个更大而且复杂得多的工作收集、管理、记录需求，并恰当地就这些需求进行沟通。