The sample application (see Sample programs) simulates a results gathering service that reports the latest score in a sports event such as a soccer match. It receives information from one or more instances of a soccer match simulator that scores goals at random for the two teams. This is illustrated in Figure 8.
The match simulator does not keep track of the score. It merely indicates when a match starts or finishes, and when a goal is scored. These events are published to three different topics on the SAMPLE.BROKER.RESULTS.STREAM stream. (The sample program sets up its own stream to avoid any possible conflict with customer applications on the default stream).
The publications on these topics are not retained, because they contain event information and not state information.
The results service subscribes to the topic Sport/Soccer/Event/* to receive publications from any matches that are in progress. It keeps track of the current score in each match, and whenever there is a change it publishes the score as a retained publication on the topic Sport/Soccer/State/LatestScore/Team1 Team2, where Team1 and Team2 are the names of the teams in the match.
A subscriber wanting to receive all the latest scores could register a wildcard subscription to topic Sport/Soccer/State/LatestScore/* . If it was interested in one particular team only, it could register a different wildcard subscription to topic Sport/Soccer/State/LatestScore/*MyTeam* .
Note that the results service must be started before the match simulators, otherwise it might miss some events and so cannot ascertain the current state in each match. This is usually the case with event publications, in which subscriptions are static and need to be in place before publications arrive.
If the results service stops while matches are still in progress, the results service can find out the state of play when it restarts. This is done by subscribing to its own retained publications using the Sport/Soccer/State/LatestScore/* topic, with the 'Publish on Request Only' option. A Request Update command is then issued to receive any retained publications that contain latest scores. (This is done using a different CorrelId as explained in Publisher and subscriber identity.)
These publications enable the results service to reconstruct its state as it was when it stopped. It can then process all events that occurred while it was stopped by processing the subscription queue for the Sport/Soccer/Events/* topic. Because the subscription is still registered (no Deregister Subscriber message has been sent) it includes any event publications that arrived while the results service was inactive.
This sample program illustrates the following aspects of a Publish/Subscribe application:
Further details of the messages sent between the publisher, subscriber and broker, and the results service sample program, are given in Writing applications.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
amq6246 |