避免在企业服务总线中迷失

日期: 2008-06-11 作者:Jason Bloomberg翻译:杨君 来源:TechTarget中国 英文

你跟随ZapThink 足够长的时间,知道通过购买企业服务总线(ESB)而开始一个面向服务架构是一个错误的开端。在一个架构工程建立之初购买任何技术尤其是ESB就预计失败。你和任何可以倾听的人都在谈论这件事。但是不管是出于什么原因,你的机构不会关注你,现在他们又在ESB下降了一束。

也许你的老板正和销售商的供应代表打高尔夫球。也许可能的某些领导正在听错误的分析公司的报告。但是,不管是何种情况,你都坚持这项决定,并预计将要和SOA一起执行。   幸运的是,在一个SOA工程过早的购买一个ESB确实增加了你失败的几率。

毕竟,这不是你一人造成的,这是现今全世界IT工厂里最流行的SOA混乱。并且不是所有的这……

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

你跟随ZapThink 足够长的时间,知道通过购买企业服务总线(ESB)而开始一个面向服务架构是一个错误的开端。在一个架构工程建立之初购买任何技术尤其是ESB就预计失败。你和任何可以倾听的人都在谈论这件事。但是不管是出于什么原因,你的机构不会关注你,现在他们又在ESB下降了一束。也许你的老板正和销售商的供应代表打高尔夫球。也许可能的某些领导正在听错误的分析公司的报告。但是,不管是何种情况,你都坚持这项决定,并预计将要和SOA一起执行。

  幸运的是,在一个SOA工程过早的购买一个ESB确实增加了你失败的几率。毕竟,这不是你一人造成的,这是现今全世界IT工厂里最流行的SOA混乱。并且不是所有的这些工程都以失败告终。当今许多ESBs都是成熟的产品,是高效SOA实施的重要组成部分。意识到在一个SOA措施中过早购买一个ESB的风险并且能够具有前瞻性的处理这些问题就能够把坏的局面扭转过来,令你的SOA举措步入正轨。
 
  理解风险

  从根本上来说,最先购买ESB的问题是,你可能落入了ESB为你安排的陷阱中,根据许多ESB都是以之为借口的中间件。毕竟,如果中间件解决了你所有的问题,你就不会一开始就考虑SOA了---将服务能力加入中间件不会改变这个基本事实。

  事实上,最先使用ESB方法引入的陷阱主要有三种类型:
 
  ·拿工程过度以集合为中心的方面为例---大多数ESB都很会连接事物---换句话说,大多数ESB都很会使用集成中间件方案。问题是SOA不是和连接事物有关。而是和业务能够杠杆作用服务建立松耦合从而满足变化的过程需要有关。我们想从“连接事物”中解脱出来以便分布计算,或者采用一种“编制服务”方法范例,在该范例中,集成成为合成物的副产品。

  ·“你的中间件设备的中间件”问题——如果可能获取一个简单的中间件并且在你的IT基础设施中将其单独放置,是一码事。但是对于大多数大型(和许多中型)机构来说,依靠一个中间件来解决所有的集成问题是一个不切实际的幻想。现实生活中,机构更趋向于为不同的目的而拥有几个不同的中间件。将一个或者更多的ESB引进混合装置,现在你必须将该装置和一个或者更多的

  ·“于事无补”谬误——“于事无补”谬误应用的领域实际上比IT行业的范围要广。人们宁愿把钱花在已经耗费了很多金钱的方法上也不愿换一种更便宜并且更有效的方法。如果你几年来一直从供应商那里购买中间件,现在他们告诉你,你需要一个ESB。你很有可能采纳他们的建议尽管这其它的方法的耗费更低,风险更小,只是简单的因为你已经在这些供应商身上花了太多的钱。

  SOA最佳实践首先使用ESB

  既然你已经将总线引离了陷阱,让我们看一看,是否能让其朝着正确的方向发展。最需记得的是你的架构应该驱动技术而不是技术驱动技术。记住ESB和其它成熟的方案一样有许多特征——许多特征并不适合我们。要想成功的使用像ESB这样的产品,需要我们弄清楚什么是不能用的特征,而不是我们真正使用这些特征的能力。

  尤其是,我们要将过程驱动的方法而不是以集成为中心的方法引入你的基础设备。记住建立实施过程的服务复合主要是在许多执行环境中组成能力。此外,这些复合是变化而不可测的。——管理复合的业务过程专家可能在你设置了这些服务很长一段时间后,彻底改变他们。控制性而不是事先规定的集成,成为管理不可测性的关键。

  事实上,由于这个原因,你不能将自己的服务实施或者任何一个过程管理环境依赖任何执行环境。ESB可以为你的服务接口提供一个有效管理执行环境,但是你虽然希望但是没有必要让自己全部的服务都依赖任意一个运行环境。换句话说,你“在总线”必须平衡运行服务的优点,事实上,SOA 准许你在总线内外杠杆作用自己的非均匀性。
 
  很重要的一点是,比起轻便性来说,SOA更能杠杆作用互操作性。在一个虚拟的基于机器的“写一次,在任何地方运行” 的环境中,无论是Java还是以共同语言运行时间( CLR )为基础的微软,分布式计算依赖于可携性的程式码。但是杠杆作用服务接口的互操作性,这样你就不必移动底层的服务实施。在ESB上运行所以服务可能会阻碍而不是支持SOA实施。

  所以如果你不把ESB看成是集成中间件或者一个普遍的服务执行环境,那么你的ESB能起到什么作用呢?答案是中介服务。。变革和基于内容的路由以及稳固的安全和管理是服务中介应该提供的必不可少的能力。所以,如果你真的需要它们的话,你仅需要使用ESB传统的消息中间件的能力,只需在合适时杠杆作用你ESB提供的服务运行时间,但是作为SOA基础结构中的一部分,将你的ESB配置为一个中介以便从中获取最大价值。
 
  不单是使用作为中介的ESB让您可以设计业务服务抽取,它也解决了“您服务中间件中的中间件”问题,因为中介机构可以干预不相干的集成技术如同他们可以干预服务供应商和消费者一样。如果您觉得您需要使用你的ESB消息排列技术,例如,只是因为它的存在,不过,您不会得到这个好处

  ZapThink措施

  是的,为了建立一个有效的SOA基础设施,除了变革和服务中介的基于内容的路由功能以外,你还需要安全性,统治性、质量和管理,但是请记住ESB不是SOA 基础结构的全部也不是最终目标——市场上许多ESB包括大多数上述的能力,但是很少能提供一个机构所要求的如何事物。事实上,XML设备可能是执行安全性和政策更好的方法。一个含有整个生命周期SOA质量方案的注册表/储存库可能会成为你设计时间和运行时间的管理工具。而一个稳固的SOA管理方案也可能是你基础设施的关键部分。事实上,许多机构都会杠杆作用这些产品和现有的中间件以便不需要购买一个ESB就可以建立他们的SOA基础设施。
 
  其中的底线就是,永远记住业务驱动架构,架构驱动技术。不要让技术驱动架构!SOA对抽取现有的技术非常熟悉,这包括旧环境以外最近买的产品。但是知道如何杠杆作用哪些,放弃哪些你现有的能力——可以决定你的SOA是成功还是失败。

相关推荐

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • 揭秘New Relic APM技术细节

    New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响

  • 仅凭SOA和云无法解决业务数据管理风险问题

    SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。

  • 总线技术究竟该不该用?

    曾几何时企业服务总线(ESB)被视为企业IT的核心。今天,不仅ESB受到了比被废弃还要糟糕的攻击,若干开发趋势似乎对更简单的消息总线也发起了质疑。