背景介绍

背景一

项目中使用到消息中间件。之前是采用另一位同事的思路实现：主要通过OPC通道，检测前端的消息。一旦发现有新消息，马上发送到各个终端，终端再根据自己的业务需要进行各自的显示以及处理。不过这样实现，系统对接时，出现了很多问题。如项目中很多WPF事件无法触发。几经探索，还是困难重重。所以，就改为今天的思路了。

背景二

技术调研后，经理还是决定使用同事推荐的Shuttle ESB做为消息中间件。也就是放弃了之前OPC的尝试，采用ESB作为消息路由。即前端监测点检测到数据。然后以消息的形式，经过消息中间件发送到各个终端。

Shuttle ESB

Shuttle ESB是一个免费的.NET开源项目。它为面向消息的事件驱动架构系统的开发提供一个新思路。Shuttle项目兴起时间不长，成形的产品也只有南非有一个案例。

Shuttle主要包含以下内容

1、基于C#开发(.NET FrameWork3.5）；

2、核心功能不依赖任何第三方的东西；

3、既支持命令消息，又支持事件消息；

4、具有集成的消息分发功能；

5、能够自动重试，增强了容错能力。

几个要点

Shuttle服务总线依赖两个东西：1、消息；2、队列。

队列基础设施可以是任何实现。目前，Shuttle提供现成支持有两种队列：微软的消息队列MSMQ和Sql Server基于表的队列 Table-based queues。Shuttle已经提供好了接口，这两种实现是Shuttle最初版本中实现的。如果你想支持其他队列，只需要参照现有实现，在写一个实现类就可以了。

命令消息和事件消息

Shuttle中的消息有分为命令消息和事件消息。命令消息（command）会发送到单独的终结点，这就要求命令消息要发送一个需求明确的请求。为了发送消息，你需要知道那个终结点实现的某个行为。所以命令消息是高度耦合的。

刚好相反，事件消息（event）可能没有或者有多个订阅者。事件发布后，每个订阅者都会收到一个消息。

PS：命令消息与事件消息，完全类似于与JavaEE中的Ejb规范中的JMS。命令消息类似于与P2P模式的，而事件消息类似于Pub/Sub模式。

各种ESB产品，包括Shuttle ESB，都是SOA的软件架构模型，为相互作用的软件应用程序之间的交互进行设计和实现。Shuttle ESB作为一种分布式计算的软件架构模型，有人称之为 客户端服务器架构的变体。主要用途就是在异构、复杂的情况下进行企业集成。

我们项目用到的Shuttle

1、前方监测点检测到数据，以命令消息形式发送到服务终端；

2、使用发布订阅模式，各个显示终端订阅消息事件，服务终端接受到命令消息后，向各个订阅的终端发送消息；

3、终端进行相应处理及显示。

参考

维基百科：http://en.wikipedia.org/wiki/Event-driven_architecture

http://en.wikipedia.org/wiki/Extensibility

以及

http://www.infoq.com/articles/Shuttle-Service-Bus