SOA:新衣裳还是美丽的谎言?

来源:互联网 发布:java常用的包 编辑:程序博客网 时间:2024/04/30 05:17

标题   SOA:新衣裳还是美丽的谎言?     选择自 liuruhong 的 Blog 
关键字   SOA:新衣裳还是美丽的谎言?
出处   
 
 原文是在《程序员》杂志社第十期发表,详细信息请参看杂志,本文允许非商业站点转载,如果商业网站转载,请和《程序员》杂志社联系,本文仅代表作者个人的观点

 

         用这样的题目有点哗众取宠的意味,不过相对于SOA(Service-Oriented Architecture)这个所谓“下一代软件架构”,任何的修饰都显得暗淡无光。早在1996年,Gartner Group就已经提出了SOA的预言,不过那个时候仅仅是一个“预言”,当时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。


         2002年12月,Gartner又提出了SOA是“现代应用开发领域最重要的课题”,并且预言到2008年, 75%的新的企业应用将使用SOA 的元素,从2003年的20%产生急剧的增长;到2006年,在全球销售出的所有商业应用产品中,面向服务的将超过 80%;到2005年,试图建立实时企业能力的企业中,80%将会严重的低估网络的需求,他们将不得不做出最后的增加、升级或者修改,从而能够开展实时企业应用和能力。2008年,SOA将成为占有绝对优势的软件工程实践方法,主流企业现在就应该在理解和应用SOA开发技能方面进行投资,更好地支持商业流程。


         于是此刻,这个“老调重弹”的概念一夜之前成为各大厂商的新宠,商业利益追逐也好,跟风也罢,他们不约而同地选择了在2004年将SOA作为他们概念炒作的重点,籍希望能够刺激当前依旧疲软的IT采购市场,那么究竟什么是SOA,是一个怎样的软件方法论能够让厂商趋之若鹜,究竟是什么理由让他们在推进概念的同时自立山头?

 

        纵观软件发展史,我们经历了面向过程->面向对象->面向组件->面向集成的几个时代:

 面向过程:高度耦合、高效率,通常是针对一个具体的应用实现,因此无法适应快速业务变化,不适合做大型面向客户应用的开发。
 面向对象:OOP提供了封装、继承、多态和重载等等一系列的特性使应用软件的架构可以被重用,开发人员可以不用关心其具体实现,而是专注于对象能够提供怎样的功能,因此提高了软件重用性,从而使得整个IT的基础架构能够适应需求的快速变化。语言的单一性和源代码级的共享决定了在跨应用系统重用的过程中必定会有各种各样的困难。
 面向组件:二进制级别的组件共享进一步加速了面向应用实现的步伐,继承了OO的显著的优点,使得IT基础架构能够更加快速适应业务变化,但是平台单一性依然阻碍了其复用程度。
 面向集成:这是一个完全面向业务的时代,所有的应用都是以业务应用为主题去组织的,但是集成高昂的成本让许多企业望而却步。
         SOA正是在这样的大背景之下应运而生的,在OOP相对成熟之后,软件学术界出现了诸多的方法学用来解释开发过程遇到的种种问题,比如AOP(面向方面编程)、MDA模型驱动架构),契约式设计及其极限编程(XP)等等,于是有人提出了“后OO时代已经到来”的论调,SOA正是这个新时代最重要的软件方法论。简单地说,SOA是“抽象、松散耦合和粗粒度”的软件架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。

 

        那么我们再来看看各大厂商是怎样宣传和鼓吹他们对于SOA的支持?
        IBM: 宣称是第一个为构建、部署基于SOA的IT系统提供一系列全面的工具、培训和服务线路的大型厂商,它涵盖了SOA生命周期的所有方面,整个概念覆盖了他们提供的五大产品线Websphere、Workplace、Tivoli、DB2及其Rational。


       BEA:宣称其旗舰产品WebLogic Platform 8.1是业界内最佳的SOA实现平台,从WebLogic Server到WebLogic Portal再到WebLogic Integration,BEA的全线产品都是采用SOA的理念去设计的,而Workshop 8.1则是第一个完整的ISE(Integrated Services Environment,面向服务集成环境),它覆盖了从设计、开发、测试再到部署的各个环节,并且宣称通过其能够快速为企业建立基于服务的应用。


       Oracle: 宣称其JDeveloper 10g是一种基于Java与Web服务环境的开发工具,具有网络激活功能,并能够支持SOA(面向服务的体系结构),并且提出在SOA工具方面,领先于IBM和Sun这样的公司,通过其数据库产品Oracle 10g和OAS(Oracle Application Server)的支持,同时加上APF(Application Platform Foundation)的支持,因此在SOA的支持方面,Oracle将领先于其他厂商。


      Microsoft: 虽然SOA的概念不是源自这家厂商,不过在后期推广中却占据了非常重要的位置,Biztalk Server 2004的推出,也终于让这个软件巨人理直气壮的开始关于SOA的宣传,相对于其他厂商而言,更加“明智”的选择了从开发人员入手,引导开发人员进入SOA,从MBF(Microsoft Business Framework)来看,就是提供给开发人员的参考架构。

 

         从目前的市场对峙来看,企业应用开发可以分解为三大阵营:


          以IBM、BEA、Oracle、Sun为首的Java应用牢牢占据企业高端应用,除了具备跨平台的特点之外,更加重要的是他们在Java标准之上形成了非常成熟的产品线,从开发工具到应用服务器再到企业应用实现,自始至终都有一套完善的解决方案,在这个世界里面他们成为领导者,他们着眼于中高端市场。


        以微软为首的基于Windows平台的应用解决方案提供商,他们完全依赖于Windows体系架构所提供的功能,主要的开发工具早期为Visual Stuido 6.0和Borland的Delphi,现在逐渐迁移到.NET为主,在中低端市场,他们以开发效率和易用性见长,并且有逐步走向高端应用的趋势。


         以Perl、PHP、Python等等开源为主的应用则着眼于中低端市场,他们则以价格方面的优势见长,并且有比较扎实的社区支持,关键的问题在于没有强势厂商的支持,因此更加适合做一些相对独立的应用解决方案。


         从某种意义上来说,SOA是“自顶向下”而产生的,正是因为企业应用复杂度的增强造成了目前很多应用无法完全是用不断发展的业务需求,于是“整合(Integration)”就成为企业望而生畏却不得不面对的问题,SOA在应对这样的问题时则显得理直气壮,“面向服务、无需整合、标准化、松散耦合”等等一系列与生俱来的优势让睿智的厂商意识到这个新概念是刺激IT采购的最好入点,于是群拥而上造就了今日SOA的荣光无限。

 

         一切不是如此完美,如果完美了就没有我今天的文字,也没有了那么多的牢骚,相信很多人都在问SOA是否等同于Web Services,从最初的定义到厂商的宣传都在传达一个主题:SOA!=Web Services,Web Services只是SOA的一种技术实现方式,并不足以构成SOA的全部,通过JMS、JDBC、.NET Remoting、IIOP乃至CORBA和TCP/IP都可以成为SOA的技术实现架构,而且也有厂商在私有协议上实现了SOA的模型,比如IBM WebSphere产品线,比如WebLogic Workshop,比如微软的.NET 2.0类库等等。

 

         作为SOA的Java世界的SOA推动者他们认为SOA不等同于Web Services,因为他们可以理直气壮地宣称SOA的实现过程中可以使用IIOP、JMS、CORBA等等协议,在Java平台上,这些协议能够工作的比Web Services来的有效率,在Java世界里面实现大统一的软件架构似乎已经近在咫尺,那么我们也有理由选择SOA。


        虽然到目前为止微软还不足以成为这个概念的绝对领导者,但是有一点可以肯定,忽略微软的团圆是不够完美甚至是悲哀的,虽然可以不在乎,但是忽略如此之多的微软开发人员去论述新一代的软件架构似乎还是底气不足。微软选择了圆滑的方式去推进SOA,虽然他的产品他的软件架构不是最出色的,但是有一点无可置疑,在易用性方面让其他厂商望尘莫及。微软也知道SOA不是Web Services,但是同样的也知道只有Web Services才能够真正帮助其去实现SOA的梦想,于是就有意的淡化其中的区别,最终的结局就是大部分的微软开发人员以为SOA就是Web Services,而VS.NET目前是开发Web Services的最佳工具,虽然一切不是那么令人满意,不是让微软满意,更加让Java世界不满意,但是有一点我们不要忘记了:微软开发人员占据着开发人员的半壁江山。

 

         从个人的角度而言,我赞同SOA是新一代的软件架构,是“后OO时代”最耀眼的软件方法论,但是理论归理论,是不是能够解决当前企业应用存在的种种问题?一切需要我们拭目以待。无意去否定或者攻击厂商的做法,毕竟通过概念来刺激IT采购是他们的最终目的,我们对于我们开发人员或者企业而言呢,SOA是不是灵丹妙药呢?
 
         还是需要回到SOA!=Web Services的话题上来,虽然彰显无聊的本质,但是在没有探讨出SOA等于什么或者完整包含什么之前,我们无法不去继续这个百无聊赖的主题,既然SOA强调能够跨越异构平台整合业务,那么必然需要特定的技术手段去实现,就目前三大阵营的发展来看,Web Services似乎是唯一可以跨越异种开发平台的标准,而就如SOA提倡因为标准化所以卷土重来,那么标准的起点在于何处?我们谁都明白只有Web Services能够让这个论调自圆其说。

 

         那么今天的Web Services又如何呢?在跨越企业应用方面,的确逐渐成为主流的协议,但是在企业内部,在对于响应速度要求比较高的领域,我们都知道目前的Web Services依然难当大任,毕竟SOAP的序列化和反序列化在很多实际应用中会成为可怕的性能瓶颈。因此Web Services目前的应用中还是以集成为主,在实时应用中,还无法成为自己的舞台。

 

         SOA到底是一个怎样的东西,它和Web Services是一个怎样的关系,是软件学的新衣裳还是厂商美丽的谎言,我们将拭目以待。


 

 

作者Blog:http://blog.csdn.net/liuruhong/
相关文章
《MSDN开发精选》第三期卷首:八月繁花开 
SOA:新衣裳还是美丽的谎言? 
回归C/S?解释Bindows 
JavaScript的Prototype(原型)方式实现 
用户手册(GB8567——88) 
 
对该文的评论 
 liuruhong ( 2004-09-23) 
hi,betaman

我赞同SOA是应该立足于标准而言的技术架构,或者如同你所说的软件交互形态的愿景,如果说一个技术或者说一个架构有魅力,那么我更加愿意相信魅力是来自于标准,即如J2EE,在Java世界已经形成自己的标准,虽然各自的厂商的实现不同,但是并不阻碍其沟通。

SOA!=Web Services,这点在众多厂商是认同的,但是如果需要跨越开发和运行平台进行异构的业务整合,到目前为止Web Services应该是一个最适合的技术架构,是实现SOA这个更上层的架构的一种手段。

可是目前的Web Services固然标准,但是在相当多的应用中并不是如此合适的,在B2Bi当然,Web Services已经可以被大家接受,但是在应用响应要求比较高的A2A呢? 
 betaman ( 2004-09-23) 
对于SOA,因为前端时间集中精力研究过一段时间,有如下一些心得与大家分享:

1)目前市场上总将SOA和Web Service、OO等放到一起来评价,我觉得有些不妥:Web Service是一套技术实现体系(XML、WSDL、SOAP、UDDI),而OO是一种设计思想,SOA虽然直译过来是“面向服务的架构”,但这个架构实际上更强调的是一种软件交互形态上的愿景,为了实现这一愿景,可以采用各种技术手段(J2EE、CORBA、Web Service...)和各种设计方式(OO、MDA、AOP...);

2)从SOA的定义来看,实际上我们现在做的很多东西就是SOA的,但为什么业界还要强调SOA呢?这是因为SOA背后还存在着一个与当前我们所做的完全不同的东西——标准。这个标准将是非常强势的,是要求我们像遵守J2EE标准那样来实施的,从抽象的角度来讲,是对软件更高层次应用的归纳和总结(.Net和J2EE标准实际上仅是约束了Web应用服务器这一基础层面上的东西),单就这方面的意义而言,是我们无法回避的,就像我们现在无法抛开J2EE和.Net来构造基于其他平台的应用一样。如果说E-Business的提出造就了J2EE平台,那么IBM新的E-ON(Service on Demand)就是为了造就一个比J2EE标准大得多的SOA体系,这个体系将包括诸如安全、流程、组织机构等更高层次的一系列相关标准;

3)这里需要澄清的是:Web Service作为一种特定的、以B2B应用为主的技术实现体系,的确不适用于要求处理周期短、吞吐量高的业务系统,但SOA却并不能被简单的理解为“慢”,这是因为SOA并没有限定具体的技术实现手段,RMI、进程内的调用等等,都可以作为SOA的技术实现载体,前提是只要相应的技术载体实现的是SOA的相关标准就可以了。

4)最后,从历史的角度来看,和其他行业相比,软件业还处于比较低的发展层次,我们可以看看建筑业:在建筑业的初级阶段,大量的建材商提供各种口径不一的水管,在这种情况下,出现了专门为各种口径不一的水管供应转换管的建材商(恰如现在的EAI厂商),但随着建筑行业的发展,不论是买方还是卖方,都意识到:如果水管基于同样的标准,岂不是会省去很多的麻烦,于是相关的标准就出来了(比如GB系列的国家标准),在这种情况下,供应转换管的建材商也就消亡了,大家都从这种标准化的过程中尝到了甜头。回顾这个过程,我们发现,生产水管的具体方式没变(技术载体几乎没有任何的创新),只是都基于标准而已。我们现在的软件业也正在经历几乎同样的过程,SMTP、JNDI、J2EE都是这一过程不断进化的产物,那么到了现在这一阶段,由软件业本身的厂商提出了标准化的口号,我更希望这是一种混沌竞争后的理性回归,那些大厂商赚钱的同时,我们也会分享到由于标准化所带来的市场扩大和利润的增加,如果不信的话,可以想想,今天的BEA、IBM的确是在利用J2EE平台大赚特赚,但如果没有这个平台,我们现在肯定会赚的更辛苦,正是因为J2EE标准化打消了客户在不同技术标准之间进行选择的踌躇,才换来了今天J2EE遍天下的局面和我们的良好收益,希望SOA也能继续这一辉煌!

SOA的实质就是标准。
 
 

 

原创粉丝点击