对基于JMS消息发布订阅的进一步封装(1.24)

栏目: Java · 发布时间: 6年前

内容简介:对基于JMS消息发布订阅的进一步封装(1.24)

最近研究Weblogic基于Topic主题的消息订阅模式,整体感觉还是没有达到一个理想的效果。我们拿MDM将会计科目信息分发给A,B,C三个业务系统这个场景来举例。首先MDM先调用ESB封装后的WS服务来讲消息分发到ESB总线,然后ESB总线将消息送到Weblogic JMS,JMS根据消息订阅情况分发消息到A,B,C三系统。


其一:对于MDM如果要完整的监控整个消息分发流程不方便,即使在当前的Weblogic JMS管控台也不方便,不能很明显的就看到一个消息分发给哪些系统成功了?分发给哪些系统失败了。同时Weblogic JMS提供的监控界面数据是实时在刷新的,对于这些数据并没有落地存储到数据库里面。

其二:最好的逻辑是消息订阅方有了一个明确的订阅过程,即订阅方在订阅消息的时候提供目标端的IP,JMS接收消息接口,然后JMS再查询订阅情况实时进行数据分发。而当前的逻辑则不是如此,仍然是需要暴露JMS服务器的IP,端口和Provider等信息,由订阅方去实时监听。

也正是如上这些原因,我一直在思考是否可以对消息发布订阅模式进行一个完整的两端WS封装,即不论是消息发送方还是消息订阅方,都提供WS服务接口,而对于消息发布订阅的过程由内部的定制的消息订阅组件来完成消息的分发,重试或持久化等动作。

基于这个思路,我们来看:

在基础数据配置那个地方,只需要提供一个服务订阅功能,即你需要订阅哪个服务接口,如会计科目分发信息服务接口。那么你作为订阅端也是根据会计科目分发信息服务接口规范去实现一个完整的服务提供端即可。然后将实现好的服务提供端地址告诉ESB总线进行订阅信息的配置。

比如,在ESB平台我们可以对会计科目信息分发服务配置了三个订阅方

1. CRM系统,订阅地址:http://10.0.0.1/esb/importCoaInfoSrv.wsdl

2. SRM系统,订阅地址:http://10.0.0.2/esb/importCoaInfoSrv.wsdl

3. MES系统,订阅地址:http://10.0.0.2/esb/importCoaInfoSrv.wsdl

这样MDM再分发会计科目信息的时候,我们就知道需要去分发到CRM,SRM,MES三个系统。这个分发能力不再由MDM系统去多次调用服务实现,而是通过ESB平台提供的服务订阅功能来实现。这种模式最大的好处就是最终暴露的服务全部都是WS服务,不再存在其他模式,对于JMS能力隐藏在内部。但是缺点就是,需要自己去实现类似JMS消息发布订阅,消息持久化等能力。


1. ESB提供一个会计科目信息分发WS服务,MDM有新数据的时候调用该服务分发数据,形成Instance_ID。

2. ESB将拿到的数据写入到JMS消息队列。

3. 定制化的程序从消息队列里面取数据,并持久化到数据库,然后根据订阅情况循环调用目标端WS服务接口

4. 将调用的结果信息写入到日志表中,对于不成功或出现异常则写入False。

5. 定制化程序定时的发起对异常日志进行重试,可设置最大重试次数。

在这里我们通过将接收到的消息持久化到数据库来进行持久化处理,以方便后续对目标端分发失败的系统再次发起重试,这个重试操作在ESB端即可完成,而不再需要MDM重新进行主数据的分发操作。


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

创新

创新

理查德·福斯特 / 王宇锋 / 中信出版社 / 2008-10 / 32.00元

《创新:进攻者的优势》内容简介:为什么一流企业突然间将它们的市场拱手让与新的竞争者?要避免这样的命运,需要无情地抛弃那些过去使它们成功的技能和产品,那么究竟哪些企业能够做到这一点呢?企业如果总是墨守成规、因循守旧,那么长期下去,必然无法以市场的速度及规模进行革新或创造价值。这样的企业会像得州仪器、施乐等市场领先者一样,被一些资源较少、技术较差、市场支配力较弱的竞争对手超越,而这些所谓进攻者的优势,......一起来看看 《创新》 这本书的介绍吧!

在线进制转换器
在线进制转换器

各进制数互转换器

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具