This document was written during the Georgetown Hackfest. In the meantime, a message broker solution has been implemented in the CTK Plugin Framework. A in-process implementation is available and an out-of-process implementation is available for experimentation.

  1. Use cases
  2. Event Management Each component/application generates many different types of events. A centralized event manager (Hub and Spoke) can be used to aggregate/dispatch events
  3. Synchronization: Window/Leveling events in one window should be synchronized across all viewer windows

  4. Temporal calibration: Different components have different update frequency, a centralized manager can be used to filter UpdateEvents, so the whole system is updating at the same frequency

  5. System Integration Different system/application have different data format or are running on different physical devices. A event bus can be used for system integration

  6. Solution

  7. UseMessage Broker for event management AMQP model Source: http://upload.wikimedia.org/wikipedia/en/9/9d/The-amqp-model-for-wikipedia.svg

  8. Use Message Bus and Publisher/Subscriber design pattern for system integration {| |Message Bus Source: http://i.msdn.microsoft.com/dynimg/IC97398.gif |Message Bus Source: http://i.msdn.microsoft.com/dynimg/IC17158.gif |}

  9. Implementation
  10. Message layer: OpenIGTLink #* OpenIGTLink defines many common data format and message structure #* It has plain vanilla socket support, might switch to ZeroMQ for transportation
  11. Transportation layer abstraction: ZeroMQ #* ZeroMQ is a small and fast implementation of the Advanced Message Queuing Protocol under the LGPL license #* It supports both synchronous and asynchronous messaging mode #* It supportsTCP, multicast/PGM, inter-process, and inter-thread transportation #* CMake version of library can be found here http://github.com/PatrickCheng/zeromq2 #* API can be found here http://api.zeromq.org/zmq.html