前面，我已经集中用了三篇文章来讲Shuttle ESB的入门实例与宏观概念。Shuttle ESB一共有两种发送消息的模式：请求/相应模式与Pub/Sub模式。
关于这两种模式的区分，请看下面文章的介绍：Shuttle ESB（三）――架构模型介绍（2）
在Shuttle ESB的第一篇文章中，关于入门实例的介绍，是基于Command命令的请求响应模式。这种模式发送的消息比较简单，是同步的。发送消息端与接收消息端的行为耦合性比较大。请求发送后，其他进程都会处于等待状态，等待服务端返回响应信息后，客户端才会进行其他行为。
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实现。功能很简单：
从消息发布端Pub发布一个消息事件OrderCompletedEvent，多个客户端（如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.ESBsourceShuttle.ESB.SqlServerScriptsSubscriptionManagerCreate.sql”脚本（在源码中，本例子中提供该脚本），创建以及初始化SqlServer表队列。
3、安装NuGet插件
它就是一款管理第三方dll的插件。关于NuGet的安装、使用，网上有一大堆，这里我就不详细介绍了。大家自己百度即可。
详细实例，下篇文章继续介绍。