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的安装、使用,网上有一大堆,这里我就不具体介绍了。大家自己百度就可以。

具体实例,下篇文章继续介绍。

上一篇:VGA原理


下一篇:AngularJs angular.Module模块接口配置