前，我的重点是关注的三篇文章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的安装、使用。网上有一大堆，这里我就不具体介绍了。
大家自己百度就可以。
具体的例子，继续推出下篇文章。