订阅发布模式

场景概述：

 　　有时须要将多个应用程序集成到一个框架中，这些应用程序常见的基础通讯方式包含总线模式、代理模式、

或者点对点模式。一些应用程序发送多种类型的消息，其余应用程序可能更关注这些消息类型的组合。

　　例如，在一个金融系统存在多个应用程序管理同一客户信息的状况，存在一个客户关系管理程序(CRM)掌握客户信息。

一种典型的状况：客户信息存在于其余系统中，且这些系统执行各自客户信息管理函数来处理客户信息。

当某个面向客户的应用程序生成更新客户信息的消息，例如客户地址的修改时，CRM和其余管理客户信息的程序

都将到该消息，然而，这个消息类型对于那些无论理客户信息的其余程序是没有意义的。

问题：

　　如何才能让一个程序在集成环境中只发送消息到那些对该消息感兴趣的应用程序中，而不须要知道消息接收方

的基本信息？

 

 约束：

　　为确保集成的软件可以只接收到各软件感兴趣的消息，这些软件须要知足下列约束条件：

　　1. 集成框架中的应用程序关注不一样的消息类型。例如，管理客户信息的应用程序关注客户信息的更新，贸易程序关注买卖事务，用于双向提交事务消息的应用关注消息的提交。

　　2. 集成框架中的某个应用可能发送若干个消息类型。例如，应用程序可能发送用户和操做的状态信息。

一样，集成框架中的某个应用一般关注的是其余应用程序发布的消息子集。例如，投资经理只关注那些影响其

所管理的股票的金融信息事务。

　　3. 应用程序添加不一样信息到消息的状况是多种多样的，这种状况下，固定长度的二进制消息一般是不灵活

的，相比而言，使用封装元素来扩展SOAP(简单对象访问协议)消息更为简单。

　　4. 大多数集成框架集成全部的应用，这些应用一般假定在该集成环境中存在同其余应用通讯的消息，甚至

对于一个灵活的消息格式，插入或处理应用未知的消息元素均可能遇到困难。

 

解决方案：

　　经过建立主题或动态检测消息内容来扩展通讯基础框架。通讯框架能确保应用程序可以收到订阅的消息，

并可以建立一种机制来发送消息到全部关注该消息的接收端（订阅方）。

　　这里列举了三类建立订阅/发布机制方式：

　　1. List-Based Publish/Subscribe（基于列表的订阅发布模式）

　　2. Broadcast-Based Publish/Subscribe （基于广播的订阅发布模式）

　　3. Content-Based Publish/Subscribe （基于内容的订阅发布模式）

　　这三类模式都可以发送消息到全部关注该消息的订阅方。

 

List-Based Publish/Subscribe (基于列表的订阅发布模式）

 　　基于列表的订阅发布模式须要管理由订阅方组成的链表，这些订阅方都关注于某一主题。当事件发生时，

订阅方链表上的全部关注该主题的订阅者都将被通知到，这很像常见的观察者模式。当你使用观察者模式时，

需先肯定两个类：主题和观察者。假定采用push模式来更新，对于主题（subject）类须要添加三个方法：Attach(), Detach()和Notify()，对于观察者添加Update()方法。

　　使用观察者模式时，全部观察者以及其所关注的主题将被注册（使用Attach()方法）。当该主题内容发生

改变时，每一个关注该主题的观察者都将被通知到。

　　当你建立对象实例而且具体化全部观察者和主题时，使用观察者模式构建订阅发布比较合适， 观察者和主题

的关系要一直保持。经过构建关系数据库，在多对多的情境下，构建主题与观察者的依赖关系。使用时，经过

检索该关系数据库表，便可获取关注某一主题的全部订阅者。

　　维护主题和订阅者链表，而后在事件来临时，通知每个订阅者是基于链表订阅发布实现的基础。

 

Broadcast-Based Publish/Subscribe(基于广播的订阅发布模式)

 　　当使用基于广播的订阅发布模式时，事件发布方将建立消息并广播到局域网中，每一个监听节点都会检查

消息主题，若是主题为该节点所关注的就会接收并处理该消息。若是该主题不是监听节点关注的，就会忽略该

消息。

　　一般主题能够分层而且可能包含多个域，每一个域根据周期来分隔，若是须要监听节点能够采用通配符来订阅

某一特殊主题。

　　基于广播的订阅发布可以有效的将生产者和消费者解耦，在某些状况，还能够作到区分特殊主题订阅者。

为了区分主题订阅者，协调程序发出消息，订阅该消息的节点将被要求回复，这些响应回复会指明全部该主题

的订阅者。

　　这种订阅发布体如今全部的消息都会发布到全部的监听节点，每一个节点负责过滤不感兴趣的消息。

 

Content-Based Publish/Subscribe（基于文本内容的订阅发布模式）

 　　基于广播和列表的订阅发布基本上都根据主题来分类，都使用预约义主题的方式实现多对多通讯。

基于主题和基于内容通讯的不一样点以下：

　　在基于主题的系统，进程交换信息经过一个预订的主题集合，这些主题在多对多的情景下用来区分各

逻辑通道。基于内容的系统更为灵活，由于订阅方与特殊消息内容有关，信息组合的方式被视为动态的

逻辑通道，这极大的扩展了潜在的逻辑通道数量，也改变了订阅发布系统实现的方式。

 

使用订阅发布

　　图一显示四个应用程序集成的一种方案。发送方使用基于主题的方式来发布消息给主题A和主题B。其中

三个接收方订阅这些主题；其中一个订阅了主题A，一个订阅了主题B，一个订阅了主题A和B。箭头描述消息发送

路径。

　　实现订阅发布过程，一般影响消息结构，应用集成和通讯基础框架。　　

　　首先， 必须区分主题或应用程序感兴趣的内容。这将转化为将消息类型分为不一样的子集。例如在贸易领域

消息类型，一些贸易应用须要追踪买入事务，一些追踪卖出事务，其余应用追踪买卖事务。经过建立买入和卖出

主题来分离消息，并将贸易消息划分到不一样子集。

　　下一步，必须给消息中添加信息，这些消息指明主题或识别特殊内容信息。有时能够经过保存主题相关的

信息到消息结构的某个未使用的域内。还有一种方式，能够为主题添加一个新的域，例如在SOAP头中添加一个

新的元素。若是既不能使用已存在的域又不能添加，只能找到某种方式将主题嵌入到消息中，或者使用基于

内容的订阅发布方式。

　　接下来必须扩展通讯基础框架以便消息可以传递给每一个订阅者。使用的方法依赖于集成解决方案的拓扑

结构，例如三类广泛的拓扑结构。对于总线结构，能够采用在总线接口上实现订阅机制；对于代理结构，能够

经过为代理者建立订阅者链表来实现；对于点对点结构，能够在发布方建立订阅链表来实现。

　　最后，须要修改应用集成框架，发布方必须将与主题相关的信息添加到每一个发布的消息中。例如，若是主题

做为头元素编入，发布方必须将主题相关信息插入到合适的位置，一样地，订阅方必须明确感兴趣的主题。

　　订阅方能够是固定或动态的，当订阅方是固定的，集成框架设置应用订阅的主题，应用程序没法控制订阅。

一般，订阅过程由每一个应用程序在被添加到集成环境时肯定。图二显示一个针对主题A的固定订阅方式。

 

　　与之相比，动态订阅能让每一个应用程序经过一组控制消息来控制其自身订阅过程。应用程序经过发送消息

到通讯基础框架，使其将应用程序从订阅链表中移除，来实现移除订阅内容。大多数提供订阅发布功能的通讯

框架都提供该功能，然而，不是非得要动态订阅才能实现这种功能。

　　

 

 　上图描述了动态订阅的功能，首先是初始订阅主题A，而后应用发送消息了从订阅链表中移除订阅，接着应用

发送两个消息来订阅主题B和主题C。

相关决定：

　　在决定使用订阅发布模式后，须要肯定下述要素：

　　1. 初始订阅。 必须肯定订阅方首次添加到集成环境中如何经过通讯框架与订阅内容通讯。

　　2. 通配符订阅。必须肯定是否让订阅发布模式支持通配符订阅。通配符订阅确保订阅者经过一个订阅过程来

订阅多个主题。

　　3. 静态或动态订阅。必须肯定集成解决方案是动态订阅仍是静态订阅。

　　4. 主题发现。 必须肯定订阅者在解决方案中支持动态订阅的状况下可以发现能够主题。

职责与协做：

　　下表为订阅发布个组件的职责和功能。