前面，我已经集中用了三篇文章来讲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.ESBsourceShuttle.ESB.SqlServerScriptsSubscriptionManagerCreate.sql”脚本（在源代码中。本样例中提供该脚本），创建以及初始化SqlServer表队列。
3、安装NuGet插件
它就是一款管理第三方dll的插件。
关于NuGet的安装、使用，网上有一大堆，这里我就不具体介绍了。大家自己百度就可以。
具体实例，下篇文章继续介绍。