最近一年多满耳朵都是SOA的宣传，几个QQ群里也都在一直忽悠概念，大家都想往SOA上靠。这让我想起股市的一句话，当大家都疯狂的时候，离崩溃就不远了。就我所能接触到的范围内的情况，种种迹象显示SOA已经开始泛滥了。

　　看见这篇文章的人士可以对比下自己周围的项目情况，是不是有人言必及SOA；是不是就连内部系统也要往SOA上靠；没有实际的需求，假想未来两三年的应用场景，然后硬加上SOA；攀比，跟风，大家都SOA了，我们也快SOA吧；听了厂商忽悠就也非要把系统带个SOA，仿佛不这样就不好意思出去见人一样。

　　有天在网上看见这么个消息：“现在有项目，找人合作，地点最好在深圳。要求：windows系统下，在驱动程序（C++编写而成）中，调用webservice更新驱动程序，时间2周。”这个应用场景具体的特点我不清楚，但我实在是想破头也不明白为什么驱动程序的更新都要用webservice，难得就因为这年头流行这个概念吗？

　　那么问题来了，如何避免滥用？首先要肯定SOA确实有它的优势，否则它也不会流行起来。肯定了这点，然后我们再来看，哪些是SOA适合的场景，只有在适合的地方才能发挥出它最大的潜力。

　　在强调松散耦合、多应用交互、快速变更业务流程、分散数据集中显示等等的场景中，SOA是一种很好的架构风格。松散耦合，这个不用说了，通过XML定义服务接口，有了这个中间层，服务之间的耦合性可以降低很多。

　　多应用交互，不同的应用通过暴露服务来实现应用之间的交互，甚至这些服务可以组织成新的有价值的应用。把已有应用的服务重新组织排列成新应用有几点好处，一是快速，因为单个服务都是现成的；二是灵活，服务之间松散耦合，可以灵活改变组织方式；三是省钱，现成的拿来就用了，实在没有再开发任务量也不会太大。

　　分散数据集中显示，XML不作为应用接口，而作为数据呈现接口，可以统一处理对比分散但存在相关性的数据，而且取得数据的方式与提供数据的应用间的耦合性被降低了。

　　但是如果是一个应用的内部作为分层，SOA就不适合了。首先这种内部分层几乎不可能暴露给外部，因为它们的粒度大部分都不足以提供一个有意义的功能。其次，SOA需要某种形式的XML文档来作为service的表现形式，而一旦采用XML就注定了它的性能是个硬伤，而作为内部系统来说，这种硬伤是不可能绕过去的。还有就是这种为了SOA而分层必然会加大层与层之间的工作量，结果却是没有带来任何收益，费力不讨好。

　　贴近底层系统的应用，使用SOA也是不合适的。这种情况下不同应用分层之间存在耦合的情况比较少，即使存在耦合其耦合性也比较强，而且一般都有更高效的接口或通道来作为耦合机制。

　　对于为什么SOA如此被滥用，我想最主要还是由国内的IT环境所致。国内的IT行业发展时间比较短，大部分应该都属于新建应用。在这种情况下，其实SOA多数应该做为前瞻性的准备工作来做，更多的是方便以后工作开展，各种应用能够很快、很容易的就暴露有价值的服务出来，并且快速组合为新的应用，实现新的业务目标。

　　然而为了赚到银子，大部分厂商都拼命往自己的东西上加卖点，往往忽视了实际情况到底需不需要；很多客户也不知道自己到底需要的是什么，只好很盲目地挑哪个名词多,哪个叫的响，选哪个厂商。

　　相比来说，欧美的IT行业发展了几十年，客户相对理性，花多少钱就要得到多大的收益，这也是他们在谈论SOA时很强调ROI的一个原因所在。

　　就甲方来说，与其跟风，不如静心规划好应用，让IT投资真正体现出价值，同时给以后扩展留下余地。就乙方来讲，流行概念当然也要跟进，做好技术储备，但绝不能拿客户的钱做试验，需要方案的时候能很快拿出。用户最好是两手抓，专心手头工作，跟紧技术趋势。对待新技术我们的口号是：不盲目，不掉队，不排斥。