Messaging sample

Overview

This simple messaging scenario consists of the following applications:

zero.messaging.app1.demo

This application, app1, uses the Connection API and the messaging protocol to send a message to a messaging queue hosted by a broker application, broker1.

zero.messaging.broker1.demo

This long running application, broker1, contains the messaging broker. It also contains a messaging kicker that is monitoring the queue and which notifies the messaging receiver in app2 when a message arrives.

zero.messaging.app2.demo

This application, app2, contains a messaging receiver that passes the message to the application code in a message event handler.

The following diagram outlines the applications in this scenario.

Creating the sample applications

After installing and configuring the command line tools you can create the three demonstration applications using the following commands:

zero create zero.messaging.broker1.demo from zero:zero.messaging.broker1.demo
zero create zero.messaging.app1.demo from zero:zero.messaging.app1.demo
zero create zero.messaging.app2.demo from zero:zero.messaging.app2.demo

If you choose to examine the applications files, note the following:

• The broker application, broker1, contains no application code. A messaging broker is configured by the inclusion of the zero.messaging.broker dependency and the broker configuration in zero.config.
• The zero.config files of both messaging client applications, app1 and app2, contain broker connection configurations referring to the port on which broker1 provides the messaging service.
• The sending application, app1, contains a destination configuration for queue1 and a script, public/sendMessage.groovy, that uses the Connection API to send a simple message.
• The receiving application, app2, contains a simple handler for the message event, app/scripts/onMessageHandler.groovy.

Running the sample scenario

Start each of the applications in the normal manner, using zero start.

The messaging client applications, app1 and app2, behave as normal applications. They begin listening on their configured HTTP ports but their full runtimes are not started until an HTTP request arrives. However, the long running broker application starts immediately to provide the messaging service. The error-0.0.log file for broker1 shows the progress of the initialization of the messaging broker.

When all three applications have been started, use a Web browser to launch the user interface of the sending application, app1, at http://localhost:8081/. Click the button to invoke the sendMessage.groovy script to send a message to the queue. The response displayed by the browser is similar to the one shown in the following example:

Sending message, "Message from zero.messaging.app1.demo at 13:47:36 BST", to queue1.
Message sent successfully. See zero.messaging.app2.demo log for receipt.

After a few seconds, the messaging kicker discovers there is a message on queue1 and sends a notification to the messaging receiver in app2, using HTTP. If it is not already active, the full runtime for app2 starts and the messaging receiver fires a message event for the new message. The handler registered for this event, onMessageHandler.groovy, writes to standard output when the message is received. The result can be seen in the trace-0.0.log file for app2 and is similar to the following example:

Message received on queue1, "Message from zero.messaging.app1.demo at 13:47:36 BST". 

The onMessageHandler.groovy script also records some information in the global context, which can be viewed using the user interface of the receiving application, app2, at http://localhost:8082/. Click the button to view the latest messages recorded by the onMessageHandler.groovy script.

When you have finished experimenting with the sample applications, they can each be stopped in the normal manner, using zero stop.