不同的人对于SOA的认识各不相同。有人认为它是概念，有人认为它是架构，有人则认为它是服务。本文将说说SOA在整个应用软件开发生命周期中的作用。

在SOA的概念提出以前，应用软件开发过程就已存在很多难题。最早的CORBA、COM等就是希望能借助工具解决这些问题，很可惜它们没有成功。但SOA就是成功的吗？事实上，换一个角度看，SOA并没有解决应用开发中需求、交付和管理这三个阶段的问题，甚至有可能让它们变得更加糟糕。

需求阶段

应用开发皆始于需求。这是某个业务用来明确它到底需要IT系统帮助满足哪些要求的阶段。在这一阶段，最大的难题是横亘在业务人员和技术人员之间的沟通鸿沟。说鸿沟可能是夸大了，也许这只是一道小小的缝隙，也足以让需求阴差阳错。

业务人员无法让技术人员完全和准确地理解他们所需要的功能。技术人员同样无法将业务需求转换为规范的需求文档，而只有根据文档开发人员才能明确如何展开产品开发。进一步地，再将这些需求规范转换为实际产品时，业务人员同样无法充分理解它们，以至没法决定是否可以开始由技术人员构建原型了。

SOA的应用并不能解决这两方面的问题。它没有为技术人员和业务人员提供一个通用的“语汇表”，让他们能够彼此理解对方所需要的和表述的。所以，在SOA驱动开发项目的需求阶段，对于需求和规范文档的错误理解依然存在。

对于业务人员，他们更适合讨论用户希望创建怎样的服务，而无法理解数据库、应用服务器、接口这些实现服务的具体技术。随着SOA的应用，技术人员开始考虑采用何种标准技术来保证服务的规范，是Java、.Net、BPEL、SOAP还是XML？这些对于用户依然没有意义。SOA的应用让开发人员不再担心在基于组件开发时代就已规范的细粒度组件问题。但是，业务人员依然对诸如EJB、BPEL和XSLT等SOA组件的粒度大惑不解。所以，SOA并没有弥补需求阶段的这一沟通问题。

交付阶段

再来看看产品交付阶段。在这一阶段，开发者已经实现了全部或部分功能，并准备将其形成真正的产品。这一阶段面临的最大问题是交付时间，而追根溯源问题还是来自整个生命周期的早期——需求阶段。

由于对需求的误读，开发人员可能错误地或者部分地实现了所需功能。没办法，业务人员正好让技术人员一遍一遍地进行修改，直到用户满意为止。采用了Web服务和SOA，是否就能让这一过程变得更加容易呢？事实上，可能性不大。

当开发人员采用细粒度组件构建系统时，他们可以很容易地返回初始设计，并修改细粒度组件，甚至是大段代码，而无需太过担心这些变化会影响到正在开发的其他项目，这些项目将更多地依赖于粗粒度服务。采用SOA后，系统可能是多个Web服务的聚合，如果某一应用服务发生改变，就必须考虑是否会影响整个系统中其他并行服务的实现。在最坏的情况下，为了满足新的业务需求，可能需要更换所有的现有服务。

更糟糕的是，对需求的重新认识，可能会发现在服务库里根本没有可以替代的可选服务，开发人员不得不从头开始创建一个或更多的新服务。这些新服务同样必须满足IT部门在封装、标准、可重用性等方面的整体要求。无疑这将严重影响交付进度。

IT部门承诺产品的交付时间大都基于一个进度估算，很多情况他们仅仅考虑了通过已有服务聚合产生新产品所需时间。当突然需要构建新服务时，交付时间就不得不随之延长。对于业务人员和用户，他们不关心产品是否采用了更为高效地开发方式，他们所想要的只是根据预期按时交付产品这样一个结果。

因此，SOA同样没有解决如何令用户满意地交付应用和系统这个大难题。

管理阶段

最后来看看应用生命周期的管理阶段。在SOA出现之前，管理应用软件开发项目实在不是一项容易的工作。采用SOA以后，根据SOA应用开发所采用的粒度大小，整个开发项目需要分解成若干小的部分，以便开发团队能够采用分布式地方式对它们进行开发。对于管理者，这同样不是一件容易的事情。应用SOA本身对此并无帮助。而项目经理则开始需要应付诸如选择工具、标准、可重用性和文档等涉及开发的标准问题。

SOA应用给管理者们带来了一个必须时时关注的服务库，此外，他们还需要关注诸如SOA治理等问题，这包括了谁能“拥有”某些特定服务，服务的版本控制，共享服务的安全影响，以及这些共享服务的变化给其他应用带来的影响等。

SOA没有解决管理应用开发项目的所面对的问题。事实上，它反而加重了管理人员的负担。他们不得不时刻留心某一变化对本身和其他与交付业务相关应用服务的影响。一旦应用程序交付，大部分的系统管理和服务管理技术都能帮助IT部门跟踪瓶颈、错误或缺陷。相较于SOA部署，这些技术对于更多传统应用基础设施更为适用。

一个糟糕的SOA应用不如不用？

说了这么多，希望读者不要误解我的意思。正确地实施SOA确实可以产生巨大的效益，它的可重用、更容实现复合应用（或称之为聚合）的能力，甚至对于业务和技术人员沟通语言的改善，都有相当的可取之处。但是，同样也要看到，如果你不能首先控制应用开发最根本的挑战，那么SOA将是比基于组件的传统开发方式更大的挑战。所以，一个糟糕的SOA应用不如不用。