当企业有一些面向服务的体系结构（Service-Oriented Architecture，SOA）服务时，需求收集流程就可能非常有挑战了。当某个业务单位需要与另一个组相同的服务时，如何进行处理呢？通过本文可了解如何最好地捕获和记录来自多个不同组的需求。

本系列的第一篇文章讨论了面向服务的体系结构 (SOA) 项目的技术需求。其中对之所以在业务需求前分析技术需求的原因进行了详细的说明。其中还讨论了不同类型技术需求的细节以及在捕获这些需求时需要注意的各种问题。

在本系列的第 2 部分中，您已了解了用于第一批 SOA 服务的需求流程，包括需要收集的不同需求类型，以便启动 SOA 项目和构建第一批 SOA 服务。

现在我们将了解如何从第一组 SOA 服务过渡到成熟的 SOA 平台，包括在推出企业 SOA 平台前必须处理的需求。此处的重点是业务，本文并不对企业服务总线之类的技术产品进行深入探讨。

企业 SOA

本系列的前一篇文章讨论了第一组 SOA 服务的业务需求。在这个阶段，最多选择三到五个服务。现在我们将讨论企业 SOA 的业务需求。

企业 SOA（此术语在本文所述的上下文中使用）指代具有数十或数百服务的组织。这包括内部服务（供企业内的客户使用）、合作伙伴服务（供企业客户使用）和客户服务（供 B2B 客户以及最终客户或使用者使用）。您的 SOA 项目已从试点开始向广泛部署过渡。您开始将公司视为一个成熟的 SOA 组织——或者正在逐渐成熟的 SOA 组织。

在此阶段，您可能已经回答了是否应该实施 SOA 的问题。资金投入不是问题——已经证明了 SOA 的价值。当然，您可能将仍然面临单个服务或一组服务的资金投入问题，但将不会有人对 SOA 的整体价值提出质疑了。

企业 SOA 的技术需求

尽管本文的大部分都关注的是业务问题，但我们仍然需要首先讨论一些基本技术问题。

初始 SOA 的需求

正如前一篇文章中讨论的，首批 SOA 服务的需求关注五个主要方面。

• 可访问性。如果有数百个服务，则需要定义一个可靠的方法，以便客户找到正确的服务并知道如何有效地使用这些服务。我通常不建议在初始 SOA 期间采用注册中心或统一描述、发现和集成（Universal Description, Discovery, and Integration，UDDI）。确定开始使用注册中心的合适门槛是 50 个服务。并没有所谓“神奇”的数字，也没有用于选择哪个数字的基本原则，这需要您自己做出决定。
• 功能。由于构建的服务较多，因此务必对每个服务的功能进行分析。确保功能重合尽可能少。例如，正在构建的新服务是否可通过对现有服务进行组合得到？此服务是否真的是新服务，或者仅是某个现有服务的不同变体？
• 交互。此时您可能并不知道自己对哪些东西不了解。您无法预测别人会如何（使用何种技术）、何时、何地或为什么使用某个特定的服务。必须对您的服务交互进行仔细考虑，且必须最大限度地遵循各项标准。
• 信息。无论服务数量如何，这个领域都不会发生改变。只要记住，在服务增多的情况下，必须对通过其中的信息量加以管理。对公共词汇的使用就变得非常重要了，您需要开始考虑能够定义和采用的现有 XML 标准或新标准。
• 流程。您组织中的 50、100 或 200 个服务如何一起工作？这些流程如何更改，这些更改如何影响每个流程？

这些方面仍然适用于您将作为企业 SOA 的一部分推出的每个服务。不过，您需要在每种情况下考虑的事情的定义扩大了。本文指出了您需要捕获的其他信息——这并不能替代您在前一部分捕获的每个类别的信息。

企业 SOA 的其他需求

需要为真正的企业 SOA 收集哪些其他信息？请记住，企业 SOA 的概念着眼于“变化”。使用 SOA 的基本业务需求是支持业务敏捷性——也称为变化。开始收集这些需求时需明白一点，即没有人真正知道正确答案是什么。您需要为每个需求类别中的变化做出计划。成功的企业 SOA 始终处于不断变化的状态——它在不断发展，持续支持随时可能出现的改变。

此类需求的高级类别包括：

• 编排。现在已经从有少量与其他应用程序交互的状态过渡到了拥有与自己或其他企业构建的服务进行交互的服务的状态。这些服务之间的编排或建模至关重要。作为需求的一部分，您需要对这些交互进行一些假设，并针对其进行一定的计划。务必记录每个服务的异步交互、服务版本控制和退役计划等等。
• 安全。毫无疑问存在安全顾虑。确保您从 SOA 服务的角度认真地对待安全性问题。哪些人能够访问哪些服务？哪些人能够访问每个服务中的哪些数据？在服务间传递服务时，如何保护数据的安全？
• 尽量保持简单（keep it simple, stupid，KISS）。对于任何希望使用该服务的人而言，实际使用该服务的过程是否足够简单？此需求既是业务需求，也是技术需求，必须认真加以分析。尽可能少地对服务的任何潜在使用者的业务和技术成熟度进行假设。服务应该方便调用，能正常工作，具有良好的错误报告能力，且通常能够与其他服务进行集成。成熟度较低的企业应该能够使用您的服务，而且不需要在技术方面进行大量资金投入，也不需要对其业务流程进行较大的更改。
• 全面“考虑”。需考虑可用性、可伸缩性、可靠性等等。这些如何从业务角度影响您的 SOA？确保业务和技术团队保持同步。
• 全球化。是否需要针对国际用户对您的服务进行本地化？这会对性能、可用性、容量等造成何种影响？

一般来说，捕获这些基本类别中的需求是一个很不错的起点。当然，每一步都包含很多细节，需要投入大量的精力进行计划和协调，还需要很好地对项目进行管理。不过，这些有关需要捕获的信息类型的指导方针可帮助您定义自己的需求流程。

您的企业 SOA 的技术需求

当从技术角度看待企业 SOA 时，需要仔细考虑总体的体系结构。对服务平台的可用性、可伸缩性、性能、可靠性等等的要求要比在非 SOA 环境中更为重要。如果基础设施无法满足这些需求（您没有办法确切预测这些需求或针对这些需求制定相应的计划），则会极大地增大丢失业务的风险。因此一定要谨慎：要事先进行计划，并保持沟通渠道的畅通。应主动了解相关业务趋势以及如何使用您的 SOA 中的服务、正在构建哪些新服务、服务使用者趋势等等。遵循流程，积极进行容量规划、管理和监视，并主动进行故障排除工作。

从软件体系结构的角度而言，需要确保随时关注不断变化的 SOA 技术、标准和框架。您服务的使用者可能会使用各种可用技术，因此需要持续地关注技术趋势，并尽可能多地针对新兴技术对服务进行测试。针对互操作性制定相应计划——或者从技术选择的角度预测互操作性挑战。

需求流程回顾

无论使用正式的工具（如 IBM® Rational® RequisitePro®、CaliberRM 或 iRise Application Simulator），还是使用非正式工具（如 Microsoft® Office Word 或 Visio），所有典型的需求流程都适用于 SOA 项目。制定两个流程来为您的企业 SOA 收集需求：一个用于收集各个服务的需求（如本系列第二篇文章中所述），另一个用于收集关于服务如何适应现有 SOA 的需求（如本文中所述）。

创建自己的用例模板或需求文档或任何用于捕获需求的工具，但要确保具有映射到这两个流程的两个不同部分。可以继续使用前一篇文章中所示的用例模板，或对其进行扩展，以捕获企业 SOA 服务的其他相关部分。

总结

通过此包含三个部分的系列文章，您从技术需求开始，了解了 SOA 项目的整个生命周期的需求流程。第二篇文章讨论了首批 SOA 服务的初始需求。而本文作为本系列的最后一篇，对企业 SOA 的总体需求进行了说明，结束了这个话题的讨论。

请记住，技术是 SOA 活动中较为容易的一部分。为了确保 SOA 的成功，请将重点放在这三篇文章中所讨论的各个关键领域。请仔细记录您的需求，并促进业务与 IT 及 IT 与 IT 间就这些需求进行有效的沟通，并随时保持警觉。SOA 处于变化之中，因此您的需求将不断发生改变。不要放松警惕！

参考资料

• 参与论坛讨论。
• 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
• 阅读本系列的第 1 部分和第 2 部分。
• 阅读 IBM developerWorks 文章“组建理想的 SOA 团队”。
• 阅读关于 SOA 成熟度和方法的信息。
• Ali Arsanjani 的文章“基于服务的建模和架构”说明了如何标识和建模 SOA 服务。
• 了解关于 Sonic Software 的 SOA 成熟度模型的信息。
• 阅读 developerWorks 文章“Capturing business requirements using use cases”。
• 阅读 SEI 网站上关于能力成熟度模型 (Capability Maturity Model) 的更多信息。
• 阅读 IBM 网站上关于 Rational RequisitePro 的更多信息。
• 了解 Rational Software Architect 能如何帮助您方便地创建 SOA 应用程序。

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号