About the Soccer Results sample
The SoccerResults sample uses the publish/subscribe type of messaging to transport data. For more information, read about publish/subscribe messaging in the WebSphere Message Brokers documentation.
The Soccer Results sample demonstrates a results gathering service that reports the scores of a soccer match while the match is being played. The sample consists of one or more publisher applications, which simulate and publish the match results, and one subscriber application, which subscribes to the results of all the matches being played. As goals are scored in the simulated matches, information about the time the goal was scored and which team scored is published.
The Soccer Results sample includes two small applications to run from the command line:
- SoccerResults, the subscriber, which subscribes to the results of all the soccer matches being played. You run only one instance of SoccerResults at a time.
- SoccerGame, the publisher, which simulates soccer matches and publishes event information as goals are scored. You can run one or more instances of SoccerGame at the same time.
The Soccer Results sample demonstrates the following features of WebSphere Message Brokers publish/subscribe applications:
- Event information, which is not retained when the subscriber, SoccerResults, has received it
- State information, which is retained by the broker
- Wildcard matching of topic strings, for example, Sport/Soccer/Event/#
- Multiple publishers on the same topic, that is, more than one instance of the SoccerGame publication application running, and publishing, at the same time
- The need to subscribe to a topic before it is published, otherwise the subscriber misses publications and cannot determine the current state of play
- A subscriber continuing to be sent publications when the subscriber is unavailable
- The use of retained publications to recover state after a subscriber failure. The SoccerGame application maintains the current state of all the matches being played; it publishes, to the broker, a retained publication message containing the latest goal score for each match every time the score changes. This means that if you restart the SoccerResults application after a failure, it subscribes to all the retained publications to restore the previous match state.
The SoccerResults sample performs the following actions:
- When the SoccerResults application starts, it registers the following subscriptions with the broker:
- A subscription to the retained topic Sport/Soccer/State/LatestScore/#. The SoccerResults application states that it only wants to receive publications on this topic when it explicitly requests them.
- A subscription to any publications on the topic, Sport/Soccer/Event/#. Because the publications on this topic contain event information, the SoccerResults application must start before the SoccerGames application. If the SoccerResults application is not started first, it could miss publications and, therefore, be unable to determine the current state, that is, the current score in a match.
- When an instance of the SoccerGame application starts, it simulates a soccer match between two teams.
- When the match starts, ends, or a goal is scored, the SoccerGame application publishes (and displays) event information to the SOCCER_PUBLICATION queue on the following topics:
- Sport/Soccer/Event/MatchStarted topic when a soccer match starts
- Sport/Soccer/Event/ScoreUpdate topic each time that a goal is scored
- Sport/Soccer/Event/MatchEnded topic when the match ends
- The messages that contain the event information are passed through the SoccerPublish message flow to the SOCCER_SUBSCRIPTION subscription queue.
- SoccerResults receives the publications from the SOCCER_SUBSCRIPTION queue because, in step 1, SoccerResults subscribed to any publications on the topic Sport/Soccer/Event/#. None of these publications are retained because when a new publication is received, previous publications are no longer of interest to the subscriber.
- When SoccerResults receives each publication, it publishes the score, state information, to the broker on the topic: Sport/Soccer/State/LatestScore/Team1 Team2 where Team1 and Team2 are the names of the teams in the match. This state information is saved, as a retained publication, by the broker.
- If the SoccerResults results server fails during a match, when it restarts it issues a Request Update command to request retained publications on the Sport/Soccer/State/LatestScore/#, which it published before it failed. This means that the results server can reconstruct the state of play as it was when the server stopped. It can then process all the event publications for the Sport/Soccer/Event/# topic on the SOCCER_SUBSCRIPTION queue, which were published by SoccerGame and processed by the message flow while the results server was stopped. Even though the SoccerResults results server failed, it is still subscribed to the topic because it did not issue the Deregister Subscriber command to ask to be deregistered.
The following sections describe the sample's resources in more detail:
The publication messages
The Soccer Results sample uses self-defining XML messages that have a standard message template containing:
- A WebSphere MQ header, which the message flow uses to identify the message format and to determine which parser to use to parse the message
- An MQRFH2 header, in which publish/subscribe commands are contained
- A string that specifies the playing teams and their scores
The SoccerGame application uses the information in this message template to publish a message that contains event information to the SOCCER_PUBLICATION queue. For example, when a match starts, the SoccerGame application publishes a message that contains the following data in the MQRFH2 header:
<psc>
<Command>Publish</Command>
<Topic>Sport/Soccer/Event/MatchStarted</Topic>
</psc>
When the SoccerResults application publishes the latest score in the match between Team1 and Team2, the message it publishes contains the following data in its MQRFH2 header:
<psc>
<Command>Publish</Command>
<PubOpt>Retain</PubOpt><Topic>Sport/Soccer/State/LatestScore/Team1 Team2</Topic>
</psc>
The message flow
The following figure shows the SoccerPublish message flow, which processes the publication messages in the Soccer Results sample.

The following table lists the types of nodes that are used in the SoccerPublish message flow.
Node type |
Node name |
MQInput |
SOCCER_PUBLICATION |
Publication |
Publish Results |
For more information, read about the nodes in the SoccerPublish message flow and message flows in the WebSphere Message Brokers documentation.
The SoccerPublish message flow is very simple because it contains only two nodes. The MQInput node is configured to identify the SOCCER_PUBLICATION publications queue as its input queue. When the SoccerGame publisher application publishes event information, as a self-defining XML message, to the SOCCER_PUBLICATION queue, the MQInput node gets the message and passes it to the Publish Results Publication node.
The Publication node publishes the message to the SoccerResults subscriber application, which has subscribed to the topic on which the event information was published.
The WebSphere MQ queues
The Soccer Results sample message flow interacts with two WebSphere MQ queues. The queues are defined on the WBRK61_DEFAULT_QUEUE_MANAGER queue manager, which hosts the broker on which the message flow runs.
The following table shows the queues that are used by the SoccerPublish message flow and how they interact.
Message flow |
Queue |
How the message flow uses the queue |
SoccerPublish |
SOCCER_PUBLICATION |
Gets event publications that have been published to the queue by one or more instances of the SoccerGame publisher application. |
SOCCER_SUBSCRIPTION |
Puts publications on the queue for the SoccerResults subscriber application to take and publish to the broker. |
Back to sample home