Progress
External Program
Interfaces


Typical JMS Messaging Scenarios In a 4GL Application

The following sections describe various JMS messaging scenarios in a 4GL application. These scenarios include connecting to a SonicMQ broker, publishing and subscribing, sending messages to a queue, receiving messages from a queue, and deleting objects.

Connecting To a SonicMQ Broker For a Pub/Sub Session

Publish and Subscribe (Pub/Sub) is a domain of JMS messaging in which an application (or publisher) sends (or publishes) messages to topics. A topic is like a node in a content hierarchy. If an application is interested in one or more topics, the application can subscribe to them and whenever messages are published to those topics, the application receives them. The same application can be a publisher and a subscriber, and a single publisher can send a message to multiple subscribers.

The following general steps outline how a 4GL application connects to a SonicMQ broker for a Pub/Sub session:

  1. The application runs jms/pubsubsession.p persistently.
  2. The application sets connection parameters for SonicMQ.
  3. The application calls beginSession to connect to the SonicMQ Adapter and the SonicMQ broker and start the JMS session.
  4. The application uses the handle of pubsubsession.p to create and publish messages to topics and to subscribe to and receive messages from topics.
  5. The application calls the deleteSession() internal procedure in pubsubsession.p to close the session and the underlying connection.
Publishing a Message To a Topic

The following general steps outline how a 4GL application publishes a message to a topic:

  1. The application obtains a handle to pubsubsession.p.
  2. The application creates a message by calling one of the create...Message procedures in the Session object.
  3. The application populates the header fields, properties, and body of the message.
  4. The application calls the publish() internal procedure in pubsubsession.p with the message handle and the name of a topic as input parameters.
  5. If the application is not going to use the message after publishing, it deletes the message.
Subscribing To a Topic and Receiving Messages

The following general steps outline how a 4GL application subscribes to a topic and receives messages:

  1. The application obtains a handle to pubsubsession.p.
  2. The application creates a Message Consumer object by calling the createMessageConsumer internal procedure.
  3. The application passes to the message consumer the name of an internal procedure and a handle to the procedure that contains that internal procedure. The internal procedure is the procedure that handles messages.
  4. The application calls the subscribe() internal procedure in pubsubsession.p with the name of a topic and the message consumer handle as input parameters.
  5. The application executes a WAIT–FOR statement (or a waitForMessages call) and processes incoming messages and other 4GL events.
  6. The application deletes the messages after the application finishes using them.
Connecting To a SonicMQ Broker For a PTP Messaging Session

Point-to-Point (PTP) is a domain of JMS messaging in which an application, known as a sender, sends a message to a destination, called a queue. Another application, known as a receiver, receives that message from the queue. The same application can be a sender and a receiver, but a single message goes to only one receiver.

The following general steps outline how a 4GL application connects to a SonicMQ broker for a PTP session:

  1. The application runs jms/ptpsession.p persistently and calls beginSession to start the JMS session.
  2. The application uses the handle of ptpsession.p to create and send messages to a queue and to receive messages from a queue.
  3. The application calls the deleteSession() internal procedure in ptpsession.p to close the session and the underlying connection.
Sending Messages To a Queue

The following general steps outline how a 4GL application sends a message to a queue:

  1. The application obtains a handle to ptpsession.p.
  2. The application creates a message by calling one of the create...Message procedures of the Session object.
  3. The application populates the header fields, properties, and body of the message.
  4. The application calls the sendToQueue internal procedure in ptpsession.p with the message handle and the name of a queue as input parameters.
  5. The application can use the message more than once and then delete it.
Receiving Messages From a Queue

The following general steps outline how a 4GL application receives a message from a queue:

  1. The application obtains a handle to ptpsession.p.
  2. The application creates a Message Consumer object by calling the createMessageConsumer internal procedure.
  3. The application calls the ReceiveFromQueue internal procedure in ptpsession.p with the name of a queue and the message consumer handle as input parameters.
  4. The application executes a WAIT–FOR statement (or a waitForMessages call) and processes incoming messages and other 4GL events.
  5. The application deletes the messages after it finishes using them.
Sending a Message and Receiving a Reply

The following general steps outline how a 4GL application sends a message and receives a reply:

  1. The application obtains a handle to a session procedure (pubsubsession.p or ptpsession.p).
  2. The application creates a message by running one of the create...Message internal procedures.
  3. The application creates a Message Consumer object for handling replies by calling the createMessageConsumer internal procedure.
  4. The application calls the requestReply() internal procedure in the Session object with the message handle, the name of a destination (a topic name in the pubsubsession.p case and a queue name in the ptpsession.p case), and the message consumer handle as input parameters.
  5. The application executes a WAIT–FOR statement (or a waitForMessages call), which waits for the replies to arrive while processing other 4GL events.
  6. The Message Consumer object handles the replies.
  7. The application deletes reply messages after it finishes using them.
Deleting Objects

A 4GL application must explicitly delete 4GL objects after using them:

These calls delete the SonicMQ Adapter and server side resources as well as the 4GL persistent procedure of that instance.


Copyright © 2004 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095