级别： 初级 Kunal Mittal (kunal@kunalmittal.com), 主管，Domestic TV IT, Sony Pictures Entertainment
2007 年 5 月 15 日 在本文中，将为面向服务的体系结构（Service-Oriented Architecture，SOA）项目的服务建模用例和业务需求。另外，您还将了解如何以最佳方式捕获和记录这些需求。
概述
在本系列的第一篇文章中，您已经了解了如何确定面向服务的体系结构 (SOA) 项目的技术需求。其中首先讨论了在分析业务需求之前分析技术需求的原因。尽管这个问题并没有“正确”答案，但就我个人的经验而言，大部分（如果不是全部的话）SOA 项目都是由信息技术（Information Technology，IT）部门牵头进行的，通常会首先讨论技术方面的内容。前一篇文章讨论了不同类型技术需求的细节以及在捕获这些需求时需要注意的各种问题。
在本文中，将了解有关 SOA 项目的业务方面的更多信息。您将了解需要作为初始 SOA 服务推出工作的一部分加以捕获的业务需求的关键方面。另外，您还将了解可用于捕获这些需求的基础需求技术的信息（虽然了解“是什么”比知道“怎么做”更为重要）。
本文将讨论需求标识流程和如何在 SOA 项目中构建第一批服务。本系列的第 3 部分（最后一部分）将基于这些服务收集、记录和管理需求，以便推出企业 SOA 。
入门
本文假定您拥有一个定义良好的 SOA 计划。您已经为 SOA 标识了一组基本技术需求，现在需要考虑“应该构建哪些 SOA 服务”。组织内不同的 IT 团队可能会有不同的观点：有些人可能会希望构建技术服务，如内容管理服务、安全（身份验证/授权）相关的服务或其他服务。不过，SOA 项目的关键是第一组业务服务。我不讨论从何处入手——我假定您从业务服务入手。首先分析一下用于标识这些业务服务的方法。
 |
一点建议
任何 SOA 项目都很难推行。在大多数情况下，初始项目并不具有短期投资回报（Return On Investment，ROI）。需要确保具有非常实际的 SOA 发展计划，以便能说服控制资金来源的人——业务负责人。尽早与业务负责人建立合作关系，在业务方面找一个执行资助人（不是 CIO 或 CTO）。这对您项目的成功至关重要。它不仅将帮助您获得项目资金，而且还将确保业务部门参与 SOA 项目并会花时间了解项目对业务的意义。
|
|
服务标识
让我们了解一些基本思路，确定如何标识将要作为 SOA 的一部分构建的第一个服务或第一批服务。需要从对业务影响的角度将这些服务隔离开来，而且必须准确地确定其范围。反过来说，这些服务应该足够重要，能说明长期 SOA 发展计划的价值和远景。
自顶向下服务标识
在自顶向下方法中，将首先从高级业务用例或组织中存在的业务流程流开始。还可以从业务策略或 IT 策略计划说明（其中包括业务策略）着手。这只是一个入口点，以便开始将流程划分为功能区域或子系统。将为整个系统进行此工作，并随后开始确定任何难点、高度可重用用例或可初步作为候选 SOA 服务的功能。请注意不要选择最复杂或有争议的服务。
自顶向下方法是由业务进行驱动的：存在可作为参考信息来确定 SOA 服务的业务文档。图 1 显示了可以在自顶向下方法中使用的简单步骤。
图 1. 自顶向下方法
自底向上服务标识
在自底向上方法中，将从现有系统或应用程序开始着手。将尝试发掘存在的任何有关这些系统的文档，并随后以此为依据构建功能区域、子系统映射和高级业务用例。这可能更为困难，但在大多数组织中都是不可避免的，因为自顶向下方法中使用的高级文档要么不存在，要么已过时。自底向上方法更多是由 IT 驱动的；业务缺乏关于其策略、功能和核心能力的文档。
|
自顶向下或自底向上？
可以在网上找到各种优先选择其中一种方法的文章。实际上，大部分组织都混合使用这两种方法。务必了解的是，自顶向下方法更关注业务——如果完全不使用此方法，则可能在 SOA 项目进行过程中发现困难重重。这主要是因为只有在关注业务的情况下（而不是仅关注 IT），SOA 才能成功。
|
|
图 2 显示了用于进行服务标识的自底向上示例方法。它与自顶向下方法的差别并不大——但起点差异很大。
图 2. 自底向上方法
请参见参考资料中列出的文章，其中对服务标识的概念进行了更为深入的分析。
收集单个服务的需求
此部分将对一个服务进行深入的分析。将讨论需求的类型，以及为 SOA 中的服务收集需求所需遵循的流程。
需求类型
现在已经准备好，可以捕获第一个 SOA 服务的需求了。从广义而言，需要捕获以下方面的需求。请记住，本文关注的是业务需求——前一篇文章讨论的是服务的技术需求：
-
可访问性。服务的用户如何查找和访问此服务？这个需求既是技术需求，也是业务需求。不过目前暂时仅考虑需要查找并调用所构建的服务的业务流程。
-
功能。此服务将提供何种核心业务流程或功能？所解决的业务问题是什么？这方面可能要进行大量的讨论。必须确定 SOA 中服务的恰当粒度。（请参见本文最后的参考资料部分，其中给出了对此进行更为详细讨论的文章。）
-
交互。调用此服务的服务或应用程序如何与其进行交互？服务如何处理各种错误情况？
-
信息。向此服务发送什么数据，以及从此服务接收什么数据？
-
流程。此服务的操作和事件的关系如何？
需求流程
现在已经了解了需要作为服务需求的一部分加以捕获的信息类型，接下来让我们讨论一下相应的流程。在非 SOA 环境中，需要服务或应用程序的用户从业务的角度说明其希望服务执行什么工作。在 SOA 中，并不总是知道服务的所有使用者（或潜在使用者）。在这种情况下，需要服务提供者（为其创建此服务的业务涉众）描述其希望服务完成什么工作。应该与一些已知的服务使用者验证这个描述——但无法也不应该尝试与所有潜在使用者接触。这样做并不可行。
|
满足业务团队的需求
企业希望能够按时在预算内完成应用程序的开发。管理层希望能事半功倍。他们希望能比以前更快地得到所需的结果。但他们并不关心 IT 如何进行相应的工作。以上这些都是事实。由于这些原因，很多 IT 负责人都坚持与业务部门就 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 计划了。您将更多地了解到如何为这个更大而且复杂得多的工作收集、管理、记录需求，并恰当地就这些需求进行沟通。
参考资料
关于作者 | | | Kunal Mittal 是专攻 Java 技术、J2EE 和 Web 服务技术的顾问。他是有关这些主题的许多书籍的合著者和撰稿人。他是 Sony Pictures Entertainment 公司 Domestic TV IT 小组的主管，负责该部门应用程序的技术架构和管理。有关更多信息，请访问他的 网站。 |
对本文的评价
| 
