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:

The Soccer Results sample demonstrates the following features of WebSphere Message Brokers publish/subscribe applications:

The SoccerResults sample performs the following actions:

  1. When the SoccerResults application starts, it registers the following subscriptions with the broker:
  2. When an instance of the SoccerGame application starts, it simulates a soccer match between two teams.
  3. 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:
  4. The messages that contain the event information are passed through the SoccerPublish message flow to the SOCCER_SUBSCRIPTION subscription queue.
  5. 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.
  6. 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.
  7. 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:

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.

A screen capture of the SoccerPublish message flow.

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