一个糟糕的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部门在封装、标准、可重用性等方面的整体要求。无疑这将严重影响交付进度。

原文转自：http://www.ltesting.net