大家都想往SOA上靠，这让我想起股市的一句话：当大家都疯狂的时候，离崩溃就不远了。

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

    看见这篇文章的人士可以对比下自己周围的项目情况，是不是有人言必及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投资真正体现出价值，同时给以后扩展留下余地。就乙方来讲，流行概念当然也要跟进，做好技术储备，但绝不能拿客户的钱做试验，需要方案的时候能很快拿出。用户最好是两手抓，专心手头工作，跟紧技术趋势。对待新技术我们的口号是：不盲目，不掉队，不排斥。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。