大家都想往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投资真正体现出价值,同时给以后扩展留下余地。就乙方来讲,流行概念当然也要跟进,做好技术储备,但绝不能拿客户的钱做试验,需要方案的时候能很快拿出。用户最好是两手抓,专心手头工作,跟紧技术趋势。对待新技术我们的口号是:不盲目,不掉队,不排斥。

0

收藏

yuyunhai

14篇文章,2W+人气,0粉丝

Ctrl+Enter 发布

发布

取消

0

分享
yuyunhai