SOA需要ESB吗?

  服务的监控及提供相对比较简单。最让人困惑的SOA决策是服务如何联系、服务之间应采用哪种仲裁机制。
  在理想情况下, SOA中的每个服务都应符合标准的Web服务规范,健壮可靠,而且可以供需要服务的应用或者XML负载的一系列众多授权的应用或者服务直接使用。但实际上,企业需要应对使用从MQ到AS2等各种专有协议的遗留系统。而许多人认为,只有WS-Reliable Messaging等Web服务协议完全成形,并得到广泛实施,Web服务的传送才会获得企业所需的可靠性。
  于是,ESB蜂拥而入——ESB是如今与SOA关系最紧密的一类产品。ESB是一种消息传送总线及服务平台,有了它,连接旧系统、管理及编制服务就会比较简单。与企业应用集成(EAI)产品一样,ESB也负责转换及发送消息。ESB厂商对自己的产品是否基于标准非常重视,目前大多数使用Java消息服务(JMS)或者某种专有的消息传送协议,目的是为了提供必要的可靠性。
  支持者喜欢ESB是因为ESB让他们可以配置服务、管理服务之间的联系。经历了好几年没有ESB的日子后,工资单处理服务市场的巨擘ADP公司最近采用了分布式ESB,因为“很难维护大批一对一的消息传送适配器”,该公司雇主服务部门的CIO Bob Bongiorno说。这家公司的服务数量从9个增加到了30个以上,但在此过程中,“管理难度绝不是仅仅增加了三倍”。Intuit公司集成架构解决方案部门的首席架构师Martin Moseley说,ESB适用于需要编制的长时间运行流程,譬如订单处理。在这种流程中,各步骤必须按某种次序来进行,而且整个过程都要进行验证。譬如,在计算运费或者批准使用信用卡之前,订单流程可能需要验证顾客的地址(原因是验证信用卡往往需要地址); 只有完成了所有步骤,才可以发送货物清单。Intuit的订单处理系统就使用这样一种仲裁服务方法。
  但也有人认为ESB只是改头 换面的EAI而已,他们认为ESB有悖于SOA的开放性。伯顿集团的分析师Anne Thomas Manes认可使用ESB配置服务,甚至把细粒度服务编制成可广泛访问的粗粒度服务,但抨击了总线作为传送所有服务的网关这一概念,尤其当ESB消息的来回传送带来额外开销时,她更是觉得不能接受。

我的意见是:

根据你的项目中对soa识别,soa服务,soa接口掌握的需求程度,以及soa预算所需要的情况来决定。而且在中国,务必要考虑旧系统的整合,你要站在信息中心主任的角度去思考:我应该把这个项目定义为一个EAI项目呢?还是一个soa项目?毕竟许多国内的项目是为了soa而soa的,选择厂商的同时也就决定了你的配置,因为soa项目目前作为一个集成类项目来搞的可能性很大,经济搭台,技术唱戏。如果客户已经选了esb,那你作为架构师就要随学蠕动,充分的去搞定使用esb的问题带来的性能问题。所以需要esb与否还是要casebycase来看。架构师需要做的,还是抽象再抽象,熟练的可以进行webservice的封装调用,客户买了esb就用esb做,没有esb就自己来搞,毕竟,项目的成功验收才是王道。反过来成功验收的项目,用户一定自己有一堆理由为什么用或者没有用esb。这样的马后炮的事情就让用户自己去虚荣吧!

你可能感兴趣的:(SOA)