DR-HMB模式的消息总线是智能控件化虚拟仪器系统的连接件，智能虚拟控件向消息总线登记感兴趣的消息，形成控件-消息响应路由表；消息总线根据发出的消息类型和控件-消息响应路由表的信息定位对此消息的响应者，并把该消息传递给相应的响应和返回处理结果；必要时，消息总线还对特定的消息进行过滤和阻塞。与图8-11中的HMB消息总线稍有不同的是，这里形成了控件-消息路由表，其结构如图8-16所示。
图8-16 控件-消息路由表结构
由图8-16，控件-消息路由表为总线上的每一个控件建立一条表项，表项中的第一部分表示控件在总线上的位置，而不是HMB模式中控件的名称；表项中的第二部分表示控件登记在总线上的消息号，以及该消息对应的有关信息，实际上表明消息在控件中的位置。例如，对于图8-16中2-2消息，由第一部分得到该消息所对应的控件，由第二部分得到该消息的响应在控件中的位置。控件-消息路由表是连续的，从而保证消息在总线中的传递无需遍历，即可由消息号直接定位响应控件。
1.消息登记
在基于消息的系统中，控件需要向消息总线登记当前响应的消息集合，消息响应者只对消息类型感兴趣，通常并不关心是谁发出的消息。在DR-HMB模式的系统中，对挂接在同一消息总线上的智能虚拟控件而言，消息是一种共享的资源，控件-消息响应登记表记录了该总线上所有智能虚拟控件和消息的响应关系。类似于程序设计中的“间接地址调用”，避免了将智能虚拟控件之间的连接“硬编码”到智能虚拟控件的实现中，使得智能虚拟控件之间保持了灵活的连接关系，便于智能控件化虚拟仪器系统的演化。
智能虚拟控件接口中的接收消息集合意味着智能虚拟控件具有响应这些消息类型的潜力，默认情况下，智能虚拟控件对其接口中定义的所有接收消息都可以进行响应。但在某些情况下，例如，当一个智能虚拟控件在部分功能上存在缺陷时，就难以对其接口中定义的某些消息进行正确的响应，这时应阻塞掉那些不希望接收到的消息。这就是需要显示进行消息登记的原因，以便消息响应者更灵活地发挥自身的潜力。
2.消息分派和传递
消息总线负责消息在智能虚拟控件之间的传递，根据控件—消息响应路由表把消息分派到对此消息感兴趣的智能虚拟控件，并负责处理结果的返回。在消息广播的情况下，可以有多个智能虚拟控件同时响应一个消息，也可以没有智能虚拟控件对该消息进行响应。在后一种情况下，该消息就丢失了，消息总线可以对系统的这种异常情况发出警告，或通知消息的发送控件进行相应的处理。
实际上，控件-消息响应路由表定义了消息的发送控件和接收控件之间的一个二元关系，以此作为消息分派的依据。(www.xing528.com)
消息总线是一个逻辑上的整体，在物理上可以跨越多个机器，因此挂接在总线上的智能虚拟控件也就可以分布在不同的机器上，并发运行。由于智能控件化虚拟仪器系统中的智能虚拟控件不是直接交互，而是通过消息总线进行通信，因此实现了智能虚拟控件位置的透明性。根据当前各个机器的负载情况和效率方面的考虑，智能虚拟控件可以在不同的物理位置上透明地迁移，而不影响智能控件化虚拟仪器系统中的其他智能虚拟控件。
在软件体系结构设计层面上，假设消息总线是建立在稳定可靠的底层通信机制之上的，消息的传递和结果的返回是可靠的。
3.消息过滤
消息总线对消息过滤提供了转换和阻塞两种方式。消息过滤的原因主要在于不同来源的智能虚拟控件事先并不知道各自的接口，因此可能同一消息在不同智能虚拟控件中使用了不同的名字，或不同的消息使用了相同的名字，造成智能虚拟控件集成时的冲突和不匹配。
消息转换是针对智能虚拟控件实例而言的，即该智能虚拟控件实例发出和接收的消息类型都经过消息总线的过滤，这里采取简单换名的方法，其前提是保证每种类型的消息名字在其所处的局部总线范围内是唯一的。例如，假设复合智能虚拟控件A，由智能虚拟控件C的两个实例C1和C2，以及智能虚拟控件S的一个实例S1构成的，智能虚拟控件C发出的消息msgC和智能虚拟控件S接收的消息msgS是相同的消息，但由于某种原因，它们的命名并不一致（除此之外，消息的参数和返回值完全一样），可以采取简单换名的方法，例如把智能虚拟控件C发出的消息msgC换为msgS，这样无需对智能虚拟控件进行修改，就解决了这两类智能虚拟控件的集成问题。由简单的换名机制解决不了的智能虚拟控件集成的不匹配问题，例如参数类型和个数不一致等，则采取更为复杂的包装器（wrapper）技术对智能虚拟控件进行封装。
表8-7给出了消息总线的形式化描述。
表8-7消息总线的形式化描述
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
