20世纪90年代,在客户机/服务器模型刚刚推广之初,很多文章都悲观地认为,客户机/服务器模型不能达到事先所承诺的地步,它只是一种理论而已,不能在现实实践中运行得很好。
但几年后,客户机/服务器模型成了一种标准,几乎所有的应用开发都是照着这个标准进行的。它不再是虚无飘渺的理论了,并且在一定程度上,它不再是一个大家讨论的热门话题了。
现在,新技术成了大家谈论的热门话题,包括XML、Web服务和SOA。当然,正如市场分析机构Gartner的一位分析师在几年前的一次讲话中指出,SOA最早出现于在20世纪90年代中期,作为客户机/服务器模型的延伸。
2006年,Gartner公司副总裁兼资深分析师 Massimo Pezzini在一次谈话中说:“客户一直在做的工作其实属于SOA的范畴,虽然他们并不这样称呼它。”他们往往使用20世纪90年代的术语称呼自己的工程,也就是所谓的客户机/服务器模型。Pezzini说,这是一个秘密,几乎很少有SOA倡导者愿意承认这样一个事实:SOA只是经典的客户机/服务器模型的一种升级。
在最近的一篇文章有关SOA普及问题的文章中,Ron Schmelzer LLC高级分析师Ron Schmelzer也赞同Gartner的观点:客户机/服务器模型在1996年转变为SOA。
因此,似乎没有达到预期期望的客户机/服务器模型已经演变为SOA,而SOA也没有达到预期期望。但很多企业部署了客户机/服务器模型,即使部署得不是很完善。而现在的情况与过去也很相似,很多公司都部署了SOA,尽管不是很完善。
其实,人类一直努力在做的事情一般并非都十全十美,但是几乎总是可以做得更好。除了四成左右的学生,我们大多数人受到的教育并不完善。美国的州际公路系统距离“完美”二字太遥远了,但我们一直使用它长达数十年之久。Schmelzer认为,城市规划(City Planning)也许是SOA的最好比喻,因为二者都是在逐渐进步,但城市规划并没有产生完美的城市。不过,从另外一个角度看,城市规划者在许多情况下确实有助于设计更适合居住和工作的城市。
实际实施SOA的首席技术官、架构师和开发者都认为SOA正在取得进展,尽管缺乏完美。
Cars.com首席信息官Manny Montejano本周在一片文章中解释他是如何实现难以捉摸的SOA目标,并促使商业行政人员和管理人员部署SOA。但同时,他还指出他所部署的SOA是完成了SOA最终目标的30%。尽管在实施过程中遇到了bushao困难和障碍,但Montejano从来没有把这看作失败,而是作为学习的经验。
“我不是说我们每次所做的一切从一开始都是完美的,这也正是我们得到教训的来源。” Montejano说。 “我们已经学到了很多教训,特别是商业计划而不是IT或技术计划。”
大部分实施SOA的人都用发展二字描述SOA,或使用Schmelzer的城市规划的比喻:SOA是一个持续不断的项目,始终是在变化和发展的,但从来没有彻底完成过。
运输公司Con-Way 的首席企业架构师Shibashis Mukherjee早在1996年就已经开始在做类似SOA的项目,后来,该项目就变成了SOA。
Mukherjee在这一项目上工作了长达10年之久,他亲眼见之了SOA从有到无这个过程。他回忆说:“我们已开始使用的是基于组件的开发方法。在当时,SOA并不是什么了不起的东西。但我们意识到如果我们有可重用组件来创建各种应用的话,将有助于我们更快地进行软件开发。随着我们的开发过程逐渐成熟和SOA开始发挥作用,我们学会了如何组合服务。”
或许如果把SOA看作一个过程,我们就不会对它的不完善缺少耐心了。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
SAP收购CallidusCloud 与Salesforce竞争
一直被称为后台办公巨头的SAP现在似乎也想在前台办公大展拳脚。 最新的迹象是SAP收购CallidusClou […]
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。