Publish/Subscribe Scenario with Permanent Backup 

Use

In this scenario, the reliability of the process flow that is described in the simple publish/subscribe scenario is increased by using a permanent subscription on the part of the purchasing departments. The subscription mode that is used in the simple publish/subscribe scenario may lead to loss of messages if an interested receiver is temporarily not available for receiving subscribed messages. As observed in the simple publish/subscribe scenario, messages that are sent during downtime are not received. This is not a problem if the receiver intentionally suspends the subscription. In this example, however, it has to be guaranteed that both departments receive all material requirement notifications. The method provided by the JMS API – permanent subscription – lends itself to this purpose. This method ensures that messages are retained for an interested receiver until they are accessed, or until the receiver explicitly ends the subscription. To what extent and in which timeframe this can be guaranteed depends on the JMS provider setting. Receivers must remember to deactivate subscriptions that are not required so as not to overload the JMS provider unnecessarily.

For this scenario, a message sender is required for the warehouse management, and message receivers are required for the purchasing departments.

The message sender can be copied from the simple publish/subscribe scenario for this scenario without any changes.

The purchasing departments receive messages asynchronously in an endless loop and return a relevant message for each message received. The receiver that was introduced in the simple publish/subscribe scenario can be used for this purpose.

To use a permanent subscription, each receiver requires a unique ID. This ID is transferred to the receiver program as a parameter.

The receiver object is generated as part of the known procedure by using the classes NamingContext, TopicConnectionFactory, Topic, TopicConnection, and TopicSession. The session is generated without a transaction and with an automatic confirmation of the messages when they are received (AUTO_ACKNOWLEDGE). The method that is used (createDurableSubscriber) contains the subscription ID as an additional parameter.

topicSession = topicConnection.createTopicSession(false,Session.AUTO_ACKNOWLEDGE); topicSubscriber = topicSession.createDurableSubscriber(topic,subscriptionId);

Before the calls are started, the message receiver described above is generated and registered as a last step.

topicListener = new RequirementListener(); topicSubscriber.setMessageListener(topicListener); topicConnection.start();

Before the connection is started, a separate thread is started for interaction with the user.

Thread stop = new Thread(new Commandline(this)); stop.start(); System.out.println("Now receiving, enter q and" +                    "<Return> to end the program");   topicConnection.start();

Permanent subscriptions are managed by the JMS provider and require the corresponding resources. It is therefore important to end subscriptions that are no longer required. For this reason, the receiver program provides two ways of ending a subscription.

One way is to simply suspend the subscription. This means that the JMS provider continues to retain messages for this receiver.

The other way is to stop the subscription completely; messages are no longer saved for this receiver.

Thread stop = new Thread(new Commandline(this)); stop.start(); System.out.println("Now receiving, enter q and" +                    "<Return> to end the program");   topicConnection.start();   if (key == 'c') {    System.out.println(subscriptionId+" closing subscription");    topicSubscriber.close(); } else if (key == 'q') {    System.out.println(subscriptionId+" unsubscribing from topic");    topicSubscriber.close();    topicSession.unsubscribe(subscriptionId); }

Procedure

...

       1.      Generate and register the topic

Using the Visual Administrator tool of the J2EE Engine, generate one topic named WarehouseRequirements.

       2.      Start the receivers

Make sure that the J2EE Engine is running. In the directory of the compiled example packages, open two windows for the command line, and start one receiver for each purchasing department with the following commands:

java -cp .;<Path to J2EE Client Library>;<Path to JMS API Library> scenario4.PurchasingSubscriber operational   java -cp .;<Path to J2EE Client Library>;<Path to JMS API Library> scenario4.PurchasingSubscriber strategic

       3.      Start the sender

In the directory of the compiled example packages, open a window for the command line, and start the sender for the warehouse management with the following command:

java -cp .;<Path to J2EE Client Library>;<Path to JMS API Library> scenario3.WarehousePublisher P-100 2 06.03.2003

Result

The sender then sends a message to the topic with the parameters that were specified when the program was started. Both receivers see the following message:

Reading message with content: MaterialID: P-100 MaterialAmount: 2 MaterialRequirementDate: 06.03.2003

Now stop a receiver in Cmode to suspend the subscription, and send an additional message. This message is displayed as expected by the current receiver. Now restart the second receiver. The subscription is continued, and the receiver can now display the sent message that was retained by the JMS provider. It is important to use the same subscription ID to enable the JMS provider to make the correct assignment.

Now stop a receiver in Qmode to end the subscription, and send an additional message. Now restart the second receiver. A new subscription starts. That is why no messages are displayed.

 

See also:

 

Source Code of JMS Scenarios