引言
“使用多重 SOA 来消除企业系统之间的差异”探索了如何从一个或多个 SOA 中重用 Web 服务——以数据为中心和业务逻辑——并将它们合并到组合应用程序中。“SOA 中的紧密耦合 Web Services”研究了紧密耦合和松散耦合 Web 服务的优点和缺点，以及紧密耦合所带来的规模上的最终变化。
这些文章讨论了 SOA 开发的不同方面。本文介绍应该如何调整系统 REF 以适应构成 SOA 应用程序的各个 Web 服务，以此作为使用多个 SOA 来缩小系统差距的方式。了解业务和系统需求工程如何改进由 SLA Web 服务组成的 SOA 应用程序的性能和系统安全性，这些 Web 服务大部分是松散耦合的，只有一小部分是紧密耦合的。
回页首
传统需求工程
作为软件开发流程中的第一步，传统需求工程确定新产品或系统所必须满足的功能性和非功能性需求或条件。
功能性需求指定系统或产品必须具有的行为或功能。
非功能性需求指定用于确定系统如何运行或工作的质量标准。
定义需求工程并没有解释软件开发流程的为什么问题；它只是告诉您需要做什么，以及应该如何在需求工程的引出、分析、验证和文档说明方面继续下去。
转换到系统需求工程框架
要解释流程，可以转换到系统 REF。此框架从作为需求的输入的系统上下文和目标开始，并使用需求的约束和风险完成其运行。该框架响应系统上下文、目标、约束和风险方面的重大更改而重复执行流程。
不要在该框架中忽略的是参与到设计一个或多个目标的涉众（stakeholder）。涉众的参与允许分析人员权衡不同涉众对制定需求（以响应 SOA 约束和风险方面的变化）的不同目标意见。
系统上下文考虑有关构建 SLA Web 服务的需求引出、协商和文档说明所必需的需求源。系统上下文的更改可能使目标更改变得必要。一些系统上下文更改示例包括：
用于实现更快响应的高速带宽升级。
企业收购和合并导致的企业网络扩充。
实施 SOA 以缩小企业系统差距。
紧密耦合的 SLA Web 服务组件。
利用未使用资源的网格计算。
必须对所有更改进行版本管理、验证、文档说明和监视。
回页首
使软目标可操作
目标并非始终是确定和可测量的；有些目标还是软目标。分析人员需要将软目标转换为可实现的需求。在该框架中，在对需求进行实现、验证和版本管理之后，或在对系统上下文施加新的约束之后，您可以在将软目标转换为可实现的需求之前整合新的更改。传统需求工程不允许您在实现需求之后整合新的更改。
例如，您指定了某个 Web 服务必须使服务可用的硬目标；该服务充当自动 SLA Web 服务。同时，目标发起者或代理之间的协议集中于三个软目标变量（举例而言），系统分析人员可以将这些变量转换为可实现的需求。其中包括正常运行时间可用性、异常和可用性变量。您以后可以进行更改。
第一个软目标：正常运行时间可用性
第一个软目标指定必须保证达到 99%（举例而言）或更多的正常运行时间可用性。目标发起者或分析人员决定要在可用时间低于保证时间时施加什么惩罚，以及要在可用时间在给定时间段内实现了目标时给予什么激励。
第二个软目标：异常
第二个软目标指定异常，例如计划的故障、拒绝服务、计划的维护、网络中断和服务提供商控制内的网络问题。在确定提供商做出的哪些服务停用惩罚不公平和不合理之后，目标发起者或分析人员将关注这些异常。当第一个软目标的条件显著更改时，分析人员可以添加新的异常或从第二个目标中去掉现有的异常。
对于某些异常，目标发起者可以指定客户公司获取合理的补偿。太多的异常会导致客户选择竞争者的 SLA Web 服务，只要那些服务提供更少的异常、更多的正常业务运行时间和更好的服务保证。该软目标应该为客户提供机会以选择服务提供商允许的异常。
第三个软目标：可用性变量
第三个软目标指定服务可用性变量。表 1 显示了可用性变量的列表以及每个变量的说明。
表 1. 服务可用性变量
可用性变量 说明
有状态性 服务器必须在后续状态中正确地响应。
访问 未经授权的用户成功访问了某个只有管理员才被授权使用的控件。
响应时间 Web 服务可用并可靠和快速地响应，否则没有耐心的用户会转而投向竞争者的服务。超过最大响应中断阈值数量将对响应时间产生负面影响。
版本管理 新的构建不会破坏现有 Web 服务的功能。如果功能被破坏，则使用版本管理过程来恢复功能。
超时 Web 服务需要在超时时采取的步骤。它可以转到另一个具有相同或不同任务或功能集的 Web 服务。或者，可以向用户发送警报，表明该 SLA Web 服务已超时。
当第一或第二软目标更改时，可用性变量的类型将更改。
回页首
可操作化示例
下面查看一个示例，看看如何操作某个有关访问可用性变量的软目标。为了将该软目标转换为可实现的需求，您需要构建一个质量模型，然后填充该模型。
例如在构建该模型时，分析人员应该允许涉众判断服务的可用性有多迅即。涉众能够确定使某个服务对组织可用所需要的时间，以及在服务不中断的时候下载文档的时间。
然后分析人员使用涉众所需要的系统行为的相关数据来填充质量模型。拥有正确访问授权的涉众可能要求该服务在 99% 的时间内可用，并且每个文档页的下载时间不超过四秒。类似地，要使某个文档可访问，涉众可能要求他们访问该文档所花的时间不超过 20 秒。
如果涉众发现服务可用性惩罚不公平和不合理，例如计划的维护、拒绝服务和不在提供商控制之内的网络中断，则涉众和目标分析人员必须就要在质量模型中包括有关异常的什么数据达成一致。此外，质量模型数据应该包括有关状态性、访问、响应时间、版本管理、超时和其他 SLA Web 服务可用性变量的数据。
回页首
约束、风险和更改
为了在第一回合中完成该框架，您需要执行几个额外的步骤。首先，您需要验证需求以确保它们按最初预期的那样正确工作，并假设系统上下文的约束还没有变化。作为验证过程的一部分，如果打算通过 Internet 提供由紧密耦合和松散耦合的 SLA Web 服务组成的 SOA 应用程序，您需要评估服务可用性风险。如果结果表明风险概率很高，您可能希望更改目标和需求，以将风险缓解到更加可接受的级别。
然而，如果监视表明在完成验证过程和缓解风险之后出现了新的环境约束，那些约束可能造成负面影响或限制需求。这意味着您需要重新评估施加在系统上下文上的新约束是什么，哪些当前约束不再适用，以及目标和需求的哪些部分可以重用。
然后将目标作为新的输入来添加、删除或转换为可实现的需求，并在框架中重复执行验证和风险缓解过程。只需确保在框架的每个阶段中对所有更改流程做文档说明，以允许分析人员和其他角色根据需要执行影响分析。
回页首
结束语
您需要一个由开发人员、系统管理员和需求开发人员组成的项目团队，以协作升级到 SOA 中的系统 REF。提前计划到 REF 的转换，并将软目标转换为可实现的需求。使用约束、风险缓解和变更管理来解决完成该框架所涉及的问题，从而使得更容易转换到该框架。
您的团队可以使用 IBM® Rational® RequisitePro® 来管理需求、改进可跟踪性、加强协作、降低项目风险和提高质量。可以将此软件与 IBM Rational Portfolio Manager 集成在一起，以提供业务案例管理和活动的定期管理和战略检查。还可以使用 IBM Rational Method Composer 来改进已确定更改时的流程，以及使用 IBM Rational ClearQuest® 来通过缩短测试时间提高工作效率。
参考资料
学习
您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
阅读 Judith M. Myerson 撰写的其他 developerWorks 文章，以了解有关如何在企业级 SOA 中使用 Web 服务的信息。
阅读 Judith 的系列 在 Web 服务上下文中使用 SLA ，以了解有关 SLA 的详细信息。
在“集成 IBM Rational RequisitePro 与 IBM Rational Portfolio Manager”中了解有关需求工程的更多信息。
请参阅 Judith M. Myerson 撰写的图书 The Complete Book of Middleware ，其中主要讨论关于系统设计的基本原则和优先考虑事项，重点是由于电子商务和分布式集成系统的兴起而带来的新需求。
通过阅读 Enterprise Systems Integration, Second Edition ，了解业务概况和技术相关知识，以确保成功完成系统集成。
使用 RFID in the Supply Chain 引领您的组织走向未来，其中解释了业务流程、操作和实现问题、风险、漏洞，以及安全性和隐私。
IBM 红皮书®：在 Tivoli Manager for Domino V2.1:Fulfilling Service Level Agreements Using Tivoli Technology 中深入了解开发 SLA 的具体细节。
IBM developerWorks SOA and Web services 专区提供了大量的文章，以及关于如何开发 Web 服务应用程序的初级、中级和高级教程。
使用 IBM SOA 沙箱进行试验！通过 IBM SOA 进行实际的亲手实践来提高您的 SOA 技能。
IBM SOA 网站提供 SOA 的概述，并介绍 IBM 是如何帮助您实现 SOA 的。
了解关于 developerWorks 技术事件和网络广播的最新消息。
访问 Safari 书店，浏览有关这些技术主题以及其他方面的书籍。
查看快速的 Web 服务按需演示。
获得产品和技术
使用 IBM 试用软件开发您的下一个项目，可下载或索取 DVD 光盘。
