Shuttle ESB(四)——宣布订阅模式实例介绍(1)
前,我的重点是关注的三篇文章Shuttle ESB入境和宏观的概念范例。
Shuttle ESB模式:请求/对应模式与Pub/Sub模式。
关于这两种模式的区分,请看以下文章的介绍:Shuttle ESB(三)——架构模型介绍(2)
在Shuttle ESB的第一篇文章中,关于入门实例的介绍,是基于Command命令的请求响应模式。这样的模式发送的消息比較简单,是同步的。发送消息端与接收消息端的行为耦合性比較大。请求发送后,其它进程都会处于等待状态,等待服务端返回响应信息后,client才会进行其它行为。
PS:Shuttle ESB的Command模式与Pub/Sub模式全然类似于Ejb中的P2P与Pub/Sub。
然而。Pub/Sub模式将消息的公布端与订阅端进行了充分的解耦。
Pub端发送消息后。不用等待消息的返回。它能够选择继续发送或者停止发送。
接收端假设想接收消息。仅仅需订阅该事件消息就可以。
我们在项目中真正使用Shuttle ESB的时候,大多数情况下。我们会使用Pub/Sub模式。以下。我们就对这样的模式进行解说。
注意:即便是基于命令的请求/对应模式,也可用公布订阅的方式实现。
眼下,Shuttle ESB仅仅支持三种队列:微软的消息队列MSMQ、SqlServer基于表的队列和Rabbit MSMQ。Shuttle ESb的Pub/Sub模式。须要MSMQ和SqlServer基于表队列两种消息队列进行实现。
关于基于SqlServer表队列。我们大家可能会有疑义:使用SqlServer数据库。不就限定了Shuttle ESB的适用范围了吗?
大家不必有此操心。Shuttle ESB核心组件是不基于不论什么第三方组件的。
将来它肯定会支持MySql和Oracle或者别的数据库的。眼下仅仅是由于Eben没有使用过Oracle,对Oracle还不是非常熟悉,所以没有做基于Oracle的队列实现。当然他跟我提过多次,希望我为开源社区做点贡献,在GitHub上给他贡献点儿代码。
但是这个实现也不是一天两天的事儿。我如今实在没时间研究。这段儿时间又比較紧迫,我得考虑生计问题啊!
得先活下来,在考虑做贡献的事儿吧!
过了年再说吧。
言归正传。我们继续来介绍基于Pub/Sub模式的Demo实现。功能非常easy:
从消息公布端Pub公布一个消息事件OrderCompletedEvent,多个client(如SubA和SubB)订阅该事件OrderCompletedEvent。那么当Pub公布消息后。SubA和SubB就行收到该消息OrderCompletedEvent。
SubA和SubB接收到消息后。依据须要进行一定的处理。然后他们都会公布一个WorkDoneEvent事件消息。这次服务端订阅WorkDoneEvent消息。当SubA和SubB公布WorkDoneEvent消息后,Pub端就行接收到该消息WorkDoneEvent。
PS:消息的公布端与订阅端为什么使用两个不同的消息呢?由于假设使用同一个消息的话。上面的实现,将会形成死循环。原因就是启动的Shuttle ESB实例后。该实例会监听一个或多个给定的消息队列,假设公布端和订阅端监听听一个队列,就形成死循环了。
以下介绍一些开发实例的准备工作
1、安装微软消的息队列:MSMQ
详细安装请參见:Shuttle ESB(一):入门实例
2、创建数据库并初始化数据库表队列
在SqlServer中创建数据库:shuttle(可自己定义数据库名称)。然后执行“{root}\Shuttle.ESB\source\Shuttle.ESB.SqlServer\Scripts\SubscriptionManagerCreate.sql”脚本(在源代码中。本样例中提供该脚本)。创建以及初始化SqlServer表队列。
3、安装NuGet插件
它就是一款管理第三方dll的插件。关于NuGet的安装、使用。网上有一大堆,这里我就不具体介绍了。
大家自己百度就可以。
具体的例子,继续推出下篇文章。