Workspaces as a Subscriber AND a Publisher

We've now looked at how to set up a workspace to be a Subscriber (reacting to incoming messages) and how to set up a workspace as a Publisher (sending outgoing messages). A workspace can do each task individually, but when it is set as both a Subscriber and a Publisher, the overall setup looks like this:

In this scenario the same workspace that receives an incoming notification also sends an outgoing notification. It is set up as a Subscriber with a Subscription component in order to receive incoming notifications, and set up as a Publisher by registering it with the notification parameters on a different service.

For example, details of a lightning strike are received via a LightningStrike topic. A Publication watching for this topic starts a workspace that processes the incoming information; for example it determines which state/province/county the strike occurred in. The workspace then creates a new message and dispatches it to subscribers via a WeatherAlert topic.

The important thing to realize is that the scenario must involve at least two different topics.

A major problem occurs if you set up such a scenario but attempt to use the same one topic for incoming and outgoing. That’s because the workspace would be set up as a subscriber to each message that it is publishing! It would republish each of its outgoing messages, causing an infinite loop of messages!


Daily Interop Reporter, Chad Pugh-Litzer says …
Using the same topic for incoming and outgoing notifications is like setting up your email to forward all incoming messages to yourself, or automatically re-tweeting your own tweets. You end up with a loop that continues until you crash the system!

To avoid confusion it’s a good idea to clarify which topics are for in and out communication through their names; for example, use LightningStrike_In and LightningStrike_Out to differentiate.

results matching ""

    No results matching ""