无论您的面向服务的体系结构（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项目的一部分。

　　首先您必须能够支持少数几个服务。为了做到这一点，您需要定义：

　　·运行方面的服务级协议（SLA）
　　·支持方面的SLA
　　·服务的执行需求
　　·部署需求

　　一旦这些初始的服务存在于产品环境中，您就可以对您的SOA的其它技术需求进行形式化了。这些包括以下几点：

　　·长期SOA的整体运行战略
　　·管理服务发现，供应以及交付
　　·面向服务开发的最佳实践和模式
　　·运行方面的SLA
　　·支持方面的SLA

　　这时就应该开始为建立您SOA的真实企业规模考虑ESB、Web服务管理平台以及其它的技术问题了。

　　获取技术需求

　　获取技术需求从不是一件很容易的事情。比如，如果您问别人他们需要系统的应答速度有多快，他们会回答，“尽可能快。”从技术上说，这个需求不会有什么帮助。在一个SOA例子中，获取技术需求变得更加困难。您要能够为您的服务确定运行级别：应答时间、启动时间，当前用户的平均数量等等。此外，您还必须定义服务级别：与修复严重程度为2或者3的服务缺陷相比，修复严重程度为1的服务缺陷需要多长时间，构建一个新的特性或增强需要花费多长时间，以及更多的问题。从这些服务的消费者获取这些需求毫无疑问更多的是艺术问题而不仅仅是科学方法的问题。科学在于为问题定义正确的答案。艺术是让您的消费者以一种具体的方式来回答那些问题而不是得到一些含糊的答案。

　　一个技术构架师或者一个技术分析师必须与您最初服务的消费者进行沟通，并开始获取这个信息。您的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与他联系。