加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > 安全 > 正文

Mule ESB-3.Build a webservice proxy

发布时间:2020-12-16 23:07:02 所属栏目:安全 来源:网络整理
导读:这些年人们一直在谈论 SOA ,有过面向服务开发经验的人对企业服务总线 ESB 一定不会陌生。但大家对 ESB 的理解却并不相同,可能是千奇百怪的,我找了很多资料,也没有找到一个能被大家普遍接受的定义。正式因为对 ESB 的理解不同,大家对 ESB 的使用也不同。

这些年人们一直在谈论SOA,有过面向服务开发经验的人对企业服务总线ESB一定不会陌生。但大家对ESB的理解却并不相同,可能是千奇百怪的,我找了很多资料,也没有找到一个能被大家普遍接受的定义。正式因为对ESB的理解不同,大家对ESB的使用也不同。我觉得应该清楚地认识ESBSOA中扮演的角色,才能让ESB真正在干分内的事情。

?

最近在实施一个采用ESB的项目,纯靠几个人研究,大家以前都没有这方面的经验,算是摸着石头过河吧,走了很多弯路,供大家参考。

?

?

1、一劳永逸现实吗?

?

一开始,我们的设想是:能否设计一个一劳永逸的ESB中间平台,将来不论哪种服务都可以方便地接入到ESB上,当服务足够多的时候,我们就可以提供一个万能平台。

?

这个想法很让人兴奋,我们在做的项目也确实在往这个目标上靠,但现在看来,这个想法有些天真了。首先,当不同的客户端采用不同的方式访问同一个服务的时候,这个时候,服务里的仲裁逻辑是非常具体的,我们要考虑的不仅是协议的差异,还要考虑消息格式的差异。另一方面,具体的业务往往是复杂的,并不存在对每个系统完全通用的服务,就像不可能存在两个完全一样的人。如果让ESB去关心业务层面的事情,我觉得本身就是对ESB的片面认识,复杂的业务应该在具体的业务系统中实现,ESB解决的事技术层面的工作。

?

?

如果我们定义一套标准的数据接口,使用统一的协议,所有ESB服务的消费者和生产者都遵循该标准,那么是不是就可以呢?

这样的做法肯定是为了简化ESB的开发工作,但如果要求所有的外围应用的协议标准和数据标准都统一了,那我们要ESB干什么?

?

丢失了ESB本身最强大的连通性方面的功能,正式因为需要联通的应用之间的差异性,才逐渐发展出了ESB这样的组件

?

?

2、在一个系统中所有的业务操作都采用ESB,采用消息机制,即系统的下层为上层提供服务。

?

之所以会想到这种方式,是为了最大限度的提高系统的灵活性和可扩展,可维护性,即我们可以通过服务编排和添加服务来满足系统的需求变更。

?

现在看来想法太过幼稚,第一,原本很简单的业务,我们需要编辑很多代码,配置很多XML才能完成,最后导致系统很臃肿。第二,通过ESB,数据要经过处理,经过网络……得到处理返回,如果实时性不高,数据量较小,可以承受,反之,将是灾难。第三,在一个系统内部实施ESB,是ESB产生的初衷吗?这是ESB的职责所在吗?显然ESB不是存在在一个系统中的组件。

?

?

3、用ESB实现业务流程

?

我们看到ESB支持服务组合(ServiceComposition)模式,进而认为可用该模式来实现业务流程。因此,ESB产品就演变成了BPM产品。

?

事实上,二者有着本质的区别。其一:ESB是一个偏向技术层整合的组件,比如将“用户信息修改”服务与“日志”服务组装起来,得到的结果还是“用户信息修改”服务,只是在仲裁流中间插入了一个新的附加功能,即“日志”服务。BPM中的服务编排的含义很侧重于业务流转的概念。比如“项目立项审批流程”,该流程的实现可能需要来自几个相关系统中的服务的参与,它们可能是“立项申请”,接着是“一级职能经历审批”,然后是“部门经理审批”,“财务审批”等。这些服务流转起来形成的是一个完整的业务流程。其二:ESB上的服务组合是无状态的,ESB运行时会为每个请求建立一个实例来执行其仲裁逻辑,请求与请求之间没有时序关系,是互不相干的、各自独立的。相反,BPM上的服务编排这不一样,未完成的业务流程实例一直会存活在BPM运行时中,存活期可能为一天、一周、甚至1个月或更长;请求与请求之间可能存在着一定的关联性,比如对与一个项目(相同的项目ID)的立项审批流程,一级职能经理、部门经理和财务对流程发出的请求都是针对同一运行时实例的。

?

应该认清认清技术上的服务组合与服务编排之间的差异。

?

?

4、用ESB做数据传输总线

?

我们仅仅使用ESB去从一个系统把数据直接搬到另一个系统。也就意味着只使用了ESB提供的连通性功能,而没有使用其他功能,如消息解析,转换,路由等。

?

ESB作为企业级的服务联通、管理平台,需要穿透ESB的服务应该是企业内重用可能最大、价值最大的那些服务,应用程序对这类服务的访问应该非常频繁,因此同一时刻需要ESB支撑的业务可能非常繁重。所以,ESB产品的设计初衷是实现一个无状态、高吞吐的服务总线,为企业内重要的业务服务提供透明、标准、开放的接入能力。如果仅仅是作为一个数据传输通道,去传输大量数据,并不划算。

?

?

以上只是我的片面思考,也参考了一些大牛的意见,希望大家在实施ESB的时候,能真正理解ESB到底能干什么,放在什么位置上最合适。

?

参考文献

http://soft.zdnet.com.cn/software_zone/esb-soa-middleware.shtml

http://www.cnblogs.com/skyme/archive/2012/08/06/2623414.html

http://www.infoq.com/cn/articles/esb-enterprises-case

http://www.infoq.com/cn/articles/mgy-esb-implementation-suggestion

等等

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读