级别： 初级 Kunal Mittal (kunal@kunalmittal.com), Domestic TV IT 主管, Sony Pictures Entertainment
2007 年 3 月 26 日 无论您的面向服务的体系结构（SOA）项目看起来功能是多么强大，如果它不能满足业务需求，注定是要失败的。本文将探究为您的首个 SOA 项目获取所有技术需求的艺术和科学原理。
与传统的信息技术（IT）项目相比较，当提到需求收集和需求处理的时候，面向服务的体系结构（SOA）项目面临着更严峻的挑战。来自领先公司的文章和研究材料讨论了缺乏正确的需求是如何导致 IT 项目失败的。作为一名 IT 项目经理、构架师或者开发人员，您可能具有直接对这些问题进行处理的第一手材料。由于不完整的，错误的或者经常变更的需求，有相当数量的项目超出了他们的预算，而且并没有在规定时间内完成。到了最后，技术已经并不重要：如果一个项目具有最高效体系构架，比如它使用了 SOA ，利用了所有标准技术的，架构是非常健壮的，并且它性能远超过所有人的期望 ，但这个项目并不满足最初的业务需求，那么这个项目也是在浪费时间和资金。
获取需求需要一套独特的技术，这些技术是艺术与科学的结合。比如，您不能逃避人为的因素 —— 人们有时候会改变他们想要什么东西的想法。假设您想要获取百分之百的需求或者期望需求不会变更是不实际的。一个优秀的业务分析师会与系统的用户一起工作，并向他们建议正确需求的价值。分析师已经证明了用户参与到这个过程是极其重要的，并且应当让用户对任何的变更或者疏忽担负责任。这就好比“如果您输入的是垃圾，那么输出的也一定是垃圾”—— 如果您由一个不良需求开始，那么最终的产品肯定是毫无用处的。
本文是由三个部分组成的系列文章的第一部分，这个系列专门讨论 SOA 实现的需求过程。本文集中讨论了 SOA 项目技术方面的内容，以及您怎样对这种项目的技术需求进行定义。这个系列的第2部分将讨论，服务作为您的 SOA 不可缺少的一部分，我们如何对它进行需求定义并为它创建用例。第3部分研究了如何为 SOA 的持续管理获取需求。贯穿这个系列，我们将利用 IBM® Rational® RequisitePro® 作为需求工具来获取这些需求。
您应该从哪里入手?
我将不会对 SOA 的基础或者 SOA 实现路标的不同方法进行深入探讨。您可能正在阅读这篇文章，因为您的组织已经有了一个明确的 SOA 路标（或者正处于被的定义的过程中）。或许您已经确定了一个路标上的起始点，并有一个投资项目来构建最初的三到五个服务。
在这个阶段您需要确定两种类型的需求：您服务的需求以及支持这些服务的技术需求。这篇文章集中讨论了后者：技术需求。我将在第2篇文章中谈到业务需求。但是等等 —— 您可能会问，业务需求不是应该首先出现吗？
我更希望先谈谈业务需求，但是绝大多数 SOA 计划由 IT 团队领导的，而不是被与 IT 团队协作的业务团队领导的。IT 团队往往能够在业务团队之前获取新的技术。他们开始提出一些关于治理、支持、成本模型等等的问题。在技术的方向上，他们开始谈论统一描述、发现和集成规范（UDDI）存储的问题，技术框架构建服务的问题，企业服务总线（EBBs）问题等等。我很少见到 IT 团队谈论关于选择业务服务以及进行概念验证（POC）的问题。他们挑选一个服务，然后主要精力集中在技术上。他们讨论这个POC要用什么技术、用什么样的扩展标记语言（XML）标准、使用什么平台、用什么 ESB 等等问题。从此处开始并不是不正确，我曾见到过一个 SOA 的项目，后来进展缓慢或者延期一直到下一个财务年度末，因为 IT 团队对于 SOA 所展示的某些方面不能达成一致。因此我们也这里开始，然后转移到服务的业务需求上来。
对我来说，从这里开始的另外一个原因是这个由三个部分组成的系列逻辑流程。这篇文章概括了所有的技术讨论，接下来的两篇文章将集中讨论业务，首先讨论最初的服务，然后讨论那些服务的维护和扩展。
SOA 路标需求的技术可交付产品
您怎样为您的 SOA 项目获取技术需求？假设您已经确定了您准备最初展示的三到五个服务作为您 SOA 项目的一部分。
 |
警告
有三件事情我要告诫大家： UDDI、ESB和框架的标准开发工具。您可能认为这超出了本文的范围，但我有我的原因。UDDI 是一个非常大的概念。然而，在您首次 SOA 展示中，您可能只有很少的服务和一个相关的定义明确的消费者基础。在这个场景中，使用 UDDI 有点小题大做了。
ESB 也是一样。我们假设您需要构建几个服务并运行它们。只要您使用了动态的绑定（也就是说您对端点不使用硬编码），您就为这些服务的可操作方法提供可见性，这时使用 ESB 同样小题大做了。
最后，您也许要求标准话您企业的开发框架和工具。如果是这样就太好了。如果不是，也不要以 SOA 作为借口来这样做。您可能会疏远一些构架师和开发人员。只要您的服务能够使他们对服务级别的要求达到一致，潜在的技术是没有问题的。 这对您最初的服务和 SOA 展示来说就是真理 －－ 尽管对这种标准化也可能存在其它正当的理由，比如， 离岸外包、减少开发和维护成本、新资源的学习曲线等等。您应该使这些与 SOA 保持独立。
|
|
首先您必须能够支持少数几个服务。为了做到这一点，您需要定义：
- 运行方面的服务级协议（SLA）
- 支持方面的 SLA
- 服务的执行需求
- 部署需求
一旦这些初始的服务存在于产品环境中，您就可以对您的 SOA 的其它技术需求进行形式化了。这些包括以下几点：
- 长期 SOA 的整体运行战略
- 管理服务发现，供应以及交付
- 面向服务开发的最佳实践和模式
- 运行方面的 SLA
- 支持方面的 SLA
这时就应该开始为建立您 SOA 的真实企业规模考虑 ESB、Web 服务管理平台以及其它的技术问题了。
获取技术需求
获取技术需求从不是一件很容易的事情。比如，如果您问别人他们需要系统的应答速度有多快，他们会回答，“尽可能快。”从技术上说，这个需求不会有什么帮助。在一个 SOA 例子中，获取技术需求变得更加困难。您要能够为您的服务确定运行级别：应答时间、启动时间，当前用户的平均数量等等。此外，您还必须定义服务级别：与修复严重程度为2或者3的服务缺陷相比，修复严重程度为1的服务缺陷需要多长时间，构建一个新的特性或增强需要花费多长时间，以及更多的问题。从这些服务的消费者获取这些需求毫无疑问更多的是艺术问题而不仅仅是科学方法的问题。科学在于为问题定义正确的答案。艺术是让您的消费者以一种具体的方式来回答那些问题而不是得到一些含糊的答案。
|
获取需求的工具
当然您需要一个需求存储库。Rational RequisitePro 是一个非常好的选择，这是因为您可以利用 Rational Software Architect 和 Rational 套件中的工具在整个设计和实现阶段将需求与设计紧紧联系起来。(查看参考资源部分，可以获取更多关于 Rational RequisitePro 的信息。)
|
|
一个技术构架师或者一个技术分析师必须与您最初服务的消费者进行沟通，并开始获取这个信息。您的 SOA 项目的成功很大程度上取决于您的团队准确、真实地获取这些需求的能力。比如，您的需求是您的系统支持每秒一百万次的点击和两秒以内的响应时间。满足这个运行级别的时间和所需资金的总数可能会破坏您的项目的成功，对于一个 SOA 项目领导者，您需要从小规模着手并逐渐成长。另一方面，如果这个服务的确需要极其高的运行级别，您需要为您最初的 SOA 选择一个或者一套不同的服务。
其它的需求
SLA 和运行级别协议（OLA）是两套最困难的 SOA 技术需求，因为任何人都希望这个服务能够尽可能的快速响应，达到24/7，来支持无穷大数量的用户等等。为这些服务开发定义良好的参数是十分困难的，在构建这样的服务的时间和成本上达到平衡更是难上加难。一旦您拥有了业务需求（在第2部分讨论）、SLA 以及 OLA，您就可以开始您的实现和部署需求。正如前面所提到的那样，在这个阶段您不必因为技术、框架、工、，产品或者甚至是许多的标准而延迟进展。简易地开始，利用 SOAP 和 Web 服务描述语言（WSDL）作为基础标准。采用 .NET®或者 Java™技术 —— 无论您的企业是否已经选择它们作为一个标准或者在这方面有更多的经验。选择刚刚好的最小数量的开发工具。从开发的角度来看，如果您选择了.NET 您就应该利用 IIS。然而，如果您选择了 Java 技术，就可以使用一个简单的应用服务器，比如 Tomcat 或者 Geronimo。在这个阶段您甚至不需要 Jboss，更不用说 WebLogic 或者 IBM WebSphere®。然而，如果您的企业对于特殊的开发容器有标准限制（WebSphere、WebLogic或者其它），采取各种办法来与它保持一致。
构架师必须有前瞻的思维，以小规模开始，但是头脑中必须一直保持着一个宏伟的蓝图。在开始时使用任何简单的工具或者您当时所拥有的构架。当这些服务成熟以后，您就可以对您的 SOA 定义全面的技术需求。您将会有更多的经验知识来更好地决定您的最终构架、基础结构需求、工具和产品需求，以及您想要采取的各种标准得级别。您所选择的服务应该能够在更大程度上帮助您做出抉择。
总结
在这篇文章中您很少关注对最初 SOA 项目的技术需求的学习，而更多关注的是从哪入手进行需求获取过程。SOA 提供了很大的远景。然而，为了达到这种远景，您应该从小规模开始。从一开始就尝试在整个范围接受 SOA 将延迟您的项目，并将使成本增加以至于您的 CIO 在证实它对业务的价值时出现麻烦。您甚至需要在下一个预算财年中冒些风险来开展您最初的 SOA 项目.
SOA 项目和获取 SOA 得技术需求与能力成熟度模型（CMM）非常相似。一旦开始，就应在级别1的 CMM 中审视自己。不要试着去解决级别为4或者5的问题。集中精力于短期的 SOA 展示上，并在脑子里保持宏伟的计划。
下一篇文章将对您最初的 SOA 服务的业务需求进行讨论。它阐述了如何获取这些需求以及利用 Rational RequisitePro 作为工具来完成这项工作。然而，使用任何工具都要有这种思想和概念，您可以利用 Microsoft® Office Word 或者任何形式的需求存储库来获取相同的信息。
参考资料 学习
获得产品和技术
讨论
关于作者 | 
| | Kunal Mittal 是一位擅长 Java 技术、J2EE 和 Web 服务技术的顾问。他已与人合作出版了多本有关这些主题的书籍。Kunal 目前在 Sony Pictures Entertainment 中担任 Domestic TV IT 部门的主管，他负责该部门开发的应用程序的技术架构及管理。有关更多信息，请访问他的网站www.kunalmittal.com，您也可通过kunal@kunalmittal.com与他联系。 |
对本文的评价
| 
