What you will learn

  1. Publish/subscribe basics
  2. Request/response basics
  3. How to code an MQ client application
  4. How to debug your application
  5. Transactional messages
  6. Message persistence
  7. Security

What you will need

  1. Everything you need is in the mq-dev-badge-sample repo in GitHub
  2. If you’re working with your own MQ configuration, you might need:

The challenge

Congratulations! You’ve just started a new job as a developer for a conference ticket reseller.

Your team lead has tasked you with creating a new messaging application that integrates with an MQ conference booking system and automates the ticket allocation process. This will ensure your new organisation keeps pace with customer demand.

I know the basics, but where do I start with this one?

Don’t worry, we have it covered.

OK, so what do I get?

We’ve already built the event booking system, including a queue manager, and made it available as a Docker image. You just need to grab the image and run it.

Good news so far, but what do I need to do?

You will be coding the reseller application. We will provide a Java template in GitHub with comments and code stubs. You just need to fill in the gaps, code the JMS and message processing parts of the scenario. Your code will:

  • Connect to a queue manager
  • Subscribe to the newTickets topic
  • Send a request message to purchase a batch of tickets, setting a reply-to destination and message expiry of 15 minutes (we don’t want to commit to a purchase indefinitely)
  • Get a response message from the confirmation queue specified as the reply-to destination
  • Print out the result

What if I get stuck?

We’ve included a cheat sheet and packaged a model answer for reference.

Nope, really busy, don’t have time to write all the code right now!

No problem, you can tackle the problem in three different ways:

  • just take a peak using the pre-canned ModelAnswer application,
  • have a go a fixing a simple defect, or
  • simply take it all on.

Explore the options in section 5 when you get coding.

Architecture overview

When tickets become available for sale, the third party system generates a reseller message to notify its subscribers (that’s you!).

Ticket resellers then request a batch of tickets for the conference event. Once tickets are allocated, the reseller is free to distribute to their customers.

How the application should work:

Messages are published on the newTickets topic every 30 seconds by the event booking system.
The message payload contains an EventId and the number of available tickets.
The Reseller application uses the received payload to construct a request message.
Finally, the booking system consumes from the purchase queue and responds to each message on the JMSReplyTo destination (confirmation queue) with a payload set, as follows:



Rejected - Sold out

Why messaging?

The conference event system and reseller applications are loosely coupled. Asynchronous messaging allows us to integrate these components and build in a buffer, or shock absorber. Should either component lose connectivity, fail or experience fluctuations in throughput, the messaging layer will deal with any instability. Our application code is simplified as the messaging layer takes care of the difficult stuff like security, recovery and persistence of message exchange between the components.
The messaging API provides a framework so that our reseller application logic is driven when a message is delivered rather than continually polling the server to check for work. This removes unnecessary load from the network and conference event application. IBM MQ allows the solution to scale as demand increases.

OK, lets get started. First step, lets get the booking system online.

Docker container – Event booking system

We provide this bit. You can get it from this GitHub repository.

Click to expand steps for standing up the Event booking system

Make a new directory, for example, in your home folder, issue:

mkdir mq-badge-dev

Change to new directory:

cd mq-badge-dev

Clone the repository:

git clone https://github.com/ibm-messaging/mq-dev-badge-sample.git

From the badge-app directory where the Dockerfile is, build the Docker image;

docker build . -t mqbadge:latest

Docker will pull the prerequisites and build the image. When it is done, check which images you have:

docker images

You’ll see:

REPOSITORY                         TAG                 IMAGE ID            CREATED             SIZE
mqbadge                            latest              3449c16be95c        27 hours ago        846MB

Run the container from the image:

docker run -e LICENSE=accept -e MQ_QMGR_NAME=QM1 -e LOG_FORMAT=json -p 1414:1414 -p 9443:9443 mqbadge:latest

After 30 seconds, You’ll see:

Tue Sep 13 19:32:17 UTC 2018 main Hursley Comes to You,Apr 26 7:30 PM,Royal Albert Hall,5272
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=1, title=Hursley Comes to You, time=Apr 26 7:30 PM, location=Royal Albert Hall, capacity=5272]
Tue Sep 13 19:32:17 UTC 2018 main European Summit,Mar  6  7:30 PM,Royal Albert Hall,5272
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=2, title=European Summit, time=Mar  6  7:30 PM, location=Royal Albert Hall, capacity=5272]
Tue Sep 13 19:32:17 UTC 2018 main IBM Think,Dec 13 7:00 PM,Hammersmith Apollo,5039
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=3, title=IBM Think, time=Dec 13 7:00 PM, location=Hammersmith Apollo, capacity=5039]
Tue Sep 13 19:32:17 UTC 2018 main IBM Interconnect,Sep  7 7:30 PM,The O2,20000
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=4, title=IBM Interconnect, time=Sep  7 7:30 PM, location=The O2, capacity=20000]
Tue Sep 13 19:32:17 UTC 2018 main Beta Workshop,Aug 22,KOKO,1410
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=5, title=Beta Workshop, time=Aug 22, location=KOKO, capacity=1410]
Tue Sep 13 19:32:17 UTC 2018 main WebSphere User Group,Aug 24,The O2,20000
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=6, title=WebSphere User Group, time=Aug 24, location=The O2, capacity=20000]
Tue Sep 13 19:32:17 UTC 2018 main IBM Impact,Sep  7 7:00 PM,O2 Academy Brixton,4921
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=7, title=IBM Impact, time=Sep  7 7:00 PM, location=O2 Academy Brixton, capacity=4921]
Tue Sep 13 19:32:17 UTC 2018 main Share,Aug 27,Trent Country Park,10000
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=8, title=Share, time=Aug 27, location=Trent Country Park, capacity=10000]
Tue Sep 13 19:32:17 UTC 2018 main MQTC, 7 Feb 6:30 PM,The O2,20000
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=9, title=MQTC, time= 7 Feb 6:30 PM, location=The O2, capacity=20000]
Tue Sep 13 19:32:17 UTC 2018 main T&M, 11 Mar 6:30 PM, The O2,20000
Tue Sep 13 19:32:17 UTC 2018 main Event [eventID=10, title=T&M, time= 11 Mar 6:30 PM, location= The O2, capacity=20000]
Tue Sep 13 19:32:18 UTC 2018 ProcessTicketRequest Starting to listen to responses
Tue Sep 13 19:32:18 UTC 2018 main Starting to sleep

The event booking system is now running inside the container. Note: the container was started without the --detach option so that the logs is displayed to screen while the container is running.

The container process includes:

Queues were created administratively by running MQSC commands when the Docker container started.
Queue objects can also be created with the MQ Console, using the MQ REST interface or programatically.

You are now ready to start developing your solution.

MQ client application – Ticket reseller app

This is where you come in, you’re bringing this to the party.

To help you focus on your MVP, this diagram shows the elements of the application you have to create in red.

To summarise, when you’ve completed section 5, you’ll have coded your application so that it:

  1. Connects to a queue manager
  2. Subscribes to topic
    • Receives a publication
    • Processes a publication
    • On receiving a publication, a request message is sent to the purchase queue to purchase zero or more tickets
    • Request message has properties;
      • says how many tickets to ask for
      • for a given EventID
      • sets a reply-to destination for the confirmation (response)
      • sets message expiry to 15 minutes – what does this mean?
  3. Puts the request message to a purchase (request) queue
    • (The Ticket purchase coordinator app does a get from this queue)
    • (Processes the message and allocates a number of tickets, if any are available)
    • (Puts a message to the confirmation (response) queue)
    • (Response message has properties;
      • says how many tickets have been allocated – if any
      • for a given EventID)
  4. Does a get from the response queue
  5. Prints how many event tickets have been purchased

What should happen?
Your application will receive a message on the newTickets topic every 30 seconds.
The Reseller (your) application will provide the prompt to ask the user how many of the available tickets they want to purchase.
The conference event booking system will process your request message and provide a response.
The Reseller application will print the outcome to stdout.


Publish/subscribe is one of the messaging styles that IBM MQ implements. The other is point-to-point. In point-to-point, messages are exchanged between two single applications. In publish/subscribe, one or many publishers can publish to one or many subscribers to a topic.

Topics are objects and they have properties.

The key property of a topic is a topic string.

Messages are published to a topic string by a publisher. Each publication is to a single topic string.

Subscribers register an interest in, or subscribe to, a topic string.

When a publisher publishes a message to a topic string, one or more subscribers for that topic string receives the the publication message.

A JMS application can use the JMS destination object which maps to a topic in the same way as it would use the destination to map to a queue, in a point to point scenario. For the publication to reach the subscriber successfully, both the publisher and the subscriber must match same topic string. The subscriber will get publications only from the time they subscribe to a topic.

If a publication is sent before the subscription by a specific application is created, that application will not get it.


Request response or request reply is an integration or messaging pattern where the application that sends a message to another application, requires a reply of some sort from the receiving application. This is often based on the point to point messaging style and can be synchronous (the sending application waits for the response before it times out) and asynchronous (also called request/callback, where the sending application disconnects but sets up a callback to handle a reply).

The sending application usually sets a reply-to-destination and a correlation-id so that a response can get back to the right sender application.

For the event booking system the reply-to destination has been defined administratively on the queue manager. However, the requester could dynamically create a temporary destination from its JMS session to complete the exchange.

Code your application

For convenience, you might want to use a Java IDE such as Eclipse. Alternatively you can develop your code in your favourite editor such as Atom. If you haven’t already, see our JMS Tutorial for instructions on compiling Java applications.

    We’ve got a challenge to suit everyone. Here’s some options:
  1. Want to see it working? – go to the ModelAnswer directory – compile and run.
  2. Want to debug and code a quick fix? – get going in the ModelAnswerWithDefectToFix directory.
  3. Ready to code? – start in the TicketReseller directory.

The sample code is broken down into multiple classes and to complete the challenge you will make code updates to:

      TicketSubscriber.java and

Most of the information you need to get coding is in GitHub repository readme file and the comments in the stubs of the classes you need to complete. Again, refer back to the JMS tutorial.

Need to debug?

Something went wrong? Take look at the cheat sheet.

What about security?

Find out how you can configure your queue manager and client application to use TLS to encrypt messages as they flow between the server and the client, over the internet.

What do I need to know about message persistence?

It is important to consider message persistence when designing an application. IBM MQ supports persistent and non-persistent messaging. In our event booking scenario, we use persistent messaging as the default setting on the pre-defined MQ queues.
Critically, in the event of a system outage, non-persistent messages may be lost following recovery. While in most cases non-persistent messaging might provide for faster exchange of messages, it’s not the right solution for all applications.
For example, persistence might be of importance for a high value message, but less so for a scenario where information messages are transmitted continually. In the latter cases, the system design might tolerate some level of message loss.

Read more about message persistence in the blog post How to set message persistence with JMS applications?

And do I need to worry about transactionality of messages?

Often production applications are more sophisticated than our sample, with each interaction involving multiple resources, such as messages or database updates, being coordinated as a single atomic operation. Resources that are managed in this way are said to occur within a unit of work, or a transaction.

For example, a simple banking transaction might require one account to be debited by $100 and another credited by the same amount.

A transactional coordinator is used to ensure that either both operations complete successfully, or none of them complete at all.

As application complexity increases, enterprise scale frameworks such as those provided by Open Liberty, an IBM Open Source Project, IBM WebSphere Application Server or Spring are utilised to coordinate transactions across multiple applications or back end systems.

Ready for the quiz?

You checked out our GitHub repository with three ways to engage with our sample. You’ve learnt loads and even checked out the MQ cheat sheet? It’s packed full of ninja moves every MQ dev should know. You might also want to learn about some best practices for developing apps with MQ, though if you’ve got here you’re probably ready for the badge!

Need some help getting through the exercise or found a bug along the way? Raise an issue in our GitHub repo.

If you’re all done and ready for the test, click the button below to go back to the course page and click through to the quiz.

Well done, the challenge took some effort to master.
You deserve a nice cup of builder’s tea (strong, milky, two sugars). See you at an MQ conference very soon.