Responder Communication Framework

Responder PubSub allows Data Services and Responder Explorer to communicate geodatabase changes to one another. The PubSub functionality uses MSMQ multicast and Pragmatic General Multicast (PGM) to provide reliable multicasting using message queues. Responder PubSub provides subscription functionality that allows a client to “listen” for messages broadcast from the server.

Unlike MSMQ .NET remoting channel, MSMQ Multicast provides one-to-many communication between components. This allows Responder PubSub to efficiently communicate with all listeners in the system.

Responder uses PubSub to publish database changes from the server (e.g., Data Services) to the client (e.g., Responder Explorer). For example, when a user edits an incident, Data Services publishes the details of the change so that all Responder Explorer client applications can integrate the change into their local copy of the data and refresh the display without requiring a query back to the database.

Every process in the system (e.g., every instance of Data Services or Responder Explorer) has its own *.event queue. An instance of Data Services may publish a message on a particular multicast group address. This message is received by every "listener" or event queue on that same group address, including all Responder Explorer and other Data Services event queues. Messages are broadcast on a group multicast address rather than a particular machine IP address. Important information about group multicast addresses is documented on the Tech Paper - Responder Communication Framework page.

You may use the PubSub Viewer tool to view the messages moving through Responder PubSub. More information about the PubSub Viewer tool is available in the online help files.

How PubSub Works

Responder PubSub uses MSMQ Multicast to broadcast messages. Every message begins with a topic string that describes the message contents. The topic string looks something like this:  msmq.oms.databaseA.incident

• System Name (msmq): This value indicates whether you’re using Responder PubSub (msmq) or Telvent PubSub (e.g., es).
• OMS (oms): Outage Management System.
• Configuration Name (databaseA): This refers to the <configuration name> value in the configuration files. It is critical that the <configuration> settings are configured properly for every database used by Responder. Below is an example from Miner.Responder.DataServices.exe.config.

<configuration name="databaseA">

• Table (incident): This is the table to which the change notification applies.

Responder components may subscribe to a particular topic string. For example, an instance of Responder Explorer that subscribes to "es.oms.databaseA" would receive the message contents for the topic string shown above. This instance of Responder Explorer would NOT receive a message with a topic string of "es.oms.databaseB".

If you have multiple databases, you won’t want all changes going to all databases. For example, changes for DatabaseA should not go to DatabaseB. To ensure database changes are communicated properly, Responder includes the database name in the topic string of the message.