我一直在抵制任何个人职业投资,因为我的特定工作领域并不需要它,因此无法学习任何关于这个缩写词的事情.我很好奇是否值得我的时间,或者它是否会最终消亡的另一种计算时尚.
这两者都是.
从实际工程的角度来看,面向服务的体系结构具有优缺点.它松散耦合,这很好,因为拥有"小块,松散连接"是适用于Unix的可靠设计策略,并且在软件工程师中有许多支持者.
然而,像任何其他软件一样,它需要非常仔细的设计:你可能有一个糟糕的SOA,就像你可以有一个坏的东西,并且由于该领域更新,最好的做法还没有充实.它通常表现出比其他架构方法更差的性能.在这一点上,大多数大型玩家(如谷歌)似乎认为它最适合不同系统之间的互操作(它们的API实际上是SOA的定义),但不适用于单个系统的内部架构(它们使用自己的协议缓冲区)为了那个原因).
对于那些对工程没有任何了解的经理来说,SOA 是一种时尚.他们喜欢它,因为a)它听起来又新又热,而b)它里面有"服务"这个词,这让它们感觉很有用.问一半他们"服务台"和"面向服务的架构"之间的区别是什么,他们很难告诉你.
对于工具供应商而言,这是一种非常好的方式,可以让您购买大量的东西(例如,ESB),顾问可以计算大量的计费时间,而Gartner可以提供更多的Magic Quadrants.
我认为这不是一个"时尚"; 这是自网络到来以来一直存在的一个想法的演变:分布式组件.CORBA和DCOM都是专有的分布式组件体系结构.SOA使用HTTP作为其通用线路协议,可以通过防火墙中的端口80.所有其他标准(如XML,WSDL等)都试图使客户端可以发现并自动理解这些标准.重要的是理解这一切背后的想法,而不是太过于热衷于炒作.
它似乎适用于亚马逊,雅虎等等.对于像我们这样的凡人来说也可能有一些东西.
我看到一些担忧:
延迟来自分布式组件.如果一切都是服务,通过企业服务总线进行通信以实现更好的解耦,那么它又如何快速?我们可能有创造一个美丽,脱钩,企业的猪的危险.
设计很难.没有人能就什么是服务达成一致.你的企业应该有多少人?十?数百?成千上万的?他们一定要细粒度吗?
如果您的雇主传统上通过项目模型资助工作,那么长寿服务如何适应这种模式?
从某种意义上讲,这将是一种时尚,会有一些人会说"从现在开始,一切都需要成为SOA".然后过了一段时间,来自SOA的好东西将会保留,而更有争议或更少有用的东西将会消失.
关于SOA最重要的事情是,它不是真正的技术,它是将IT基础架构组织为可以组合的一堆可重用服务的一种方式,而不是需要额外努力集成的大量应用程序的当前规范.必要时.
当然,做这项工作需要技术,但如果你没有(重新)以这种方式组织你的IT,"学习"或购买该技术毫无意义.
我认为SOA的基本思想是合理的,并且留在这里(虽然它可能在每个上下文中都没有用).另一方面,SOA-as-a-technology是一种会流行的流行语.
我个人认为这是一种时尚.目前云计算很大,就像大型机一样,但桌面出现并接管了.现在我们要回到大铁...