看见这篇文章的人士可以对比下自己周围的项目情况，是不是有人言必及SOA;是不是就连内部系统也要往SOA上靠;没有实际的需求，假想未来两三年的应用场景，然后硬加上SOA;攀比，跟风，大家都SOA了，我们也快SOA吧;听了厂商忽悠就也非要把系统带个SOA，仿佛不这样就不好意思出去见人一样。
有天在网上看见这么个消息：”现在有项目，找人合作，地点最好在深圳。要求：windows系统下，在驱动程序(C++编写而成)中，调用web service更新驱动程序，时间2周。“这个应用场景具体的特点我不清楚，但我实在是想破头也不明白为什么驱动程序的更新都要用web service，难得就因为这年头流行这个概念吗?
那么问题来了，如何避免滥用?首先要肯定SOA确实有它的优势，否则它也不会流行起来。肯定了这点，然后我们再来看，哪些是SOA适合的场景，只有在适合的地方才能发挥出它最大的潜力。
在强调松散耦合、多应用交互、快速变更业务流程、分散数据集中显示等等的场景中，SOA是一种很好的架构风格。松散耦合，这个不用说了，通过 XML定义服务接口，有了这个中间层，服务之间的耦合性可以降低很多。
多应用交互，不同的应用通过暴露服务来实现应用之间的交互，甚至这些服务可以组织成新的有价值的应用。把已有应用的服务重新组织排列成新应用有几点好处，一是快速，因为单个服务都是现成的;二是灵活，服务之间松散耦合，可以灵活改变组织方式;三是省钱，现成的拿来就用了，实在没有再开发任务量也不会太大。
分散数据集中显示，XML不作为应用接口，而作为数据呈现接口，可以统一处理对比分散但存在相关性的数据，而且取得数据的方式与提供数据的应用间的耦合性被降低了。
但是如果是一个应用的内部作为分层，SOA就不适合了。首先这种内部分层几乎不可能暴露给外部，因为它们的粒度大部分都不足以提供一个有意义的功能。其次，SOA需要某种形式的 XML文档来作为service的表现形式，而一旦采用XML就注定了它的性能是个硬伤，而作为内部系统来说，这种硬伤是不可能绕过去的。还有就是这种为了SOA而分层必然会加大层与层之间的工作量，结果却是没有带来任何收益，费力不讨好。
贴近底层系统的应用，使用SOA也是不合适的。这种情况下不同应用分层之间存在耦合的情况比较少，即使存在耦合其耦合性也比较强，而且一般都有更高效的接口或通道来作为耦合机制。
对于为什么SOA如此被滥用，我想最主要还是由国内的IT环境所致。国内的IT行业发展时间比较短，大部分应该都属于新建应用。在这种情况下，其实SOA 多数应该做为前瞻性的准备工作来做，更多的是方便以后工作开展，各种应用能够很快、很容易的就暴露有价值的服务出来，并且快速组合为新的应用，实现新的业务目标。
然而为了赚到银子，大部分厂商都拼命往自己的东西上加卖点，往往忽视了实际情况到底需不需要;很多客户也不知道自己到底需要的是什么，只好很盲目地挑哪个名词多，哪个叫的响，选哪个厂商。
相比来说，欧美的IT行业发展了几十年，客户相对理性，花多少钱就要得到多大的收益，这也是他们在谈论SOA时很强调ROI的一个原因所在。
就甲方来说，与其跟风，不如静心规划好应用，让IT投资真正体现出价值，同时给以后扩展留下余地。就乙方来讲，流行概念当然也要跟进，做好技术储备，但绝不能拿客户的钱做试验，需要方案的时候能很快拿出。用户最好是两手抓，专心手头工作，跟紧技术趋势。对待新技术我们的口号是：不盲目，不掉队，不排斥。
