Revising Parameters in the Build File

Basics

The Ant build.xml file was revised to add the FUSE Message Broker version and installation location. Now you will change and add parameters in the target section for each sample run. Each parameter's name-value pair is presented as two sequential arguments. For example:

<target name="chat1">
          <java classname="Chat" ...>
          ...
          <arg value="-u"/>
          <arg value="Chatter1"/>
          </java>
          </target>

That listing shows that the -u parameter, the user name, is assigned the value "Chatter1"

	Note
The `password` parameter requires implementation of security. For these samples, that would require all the user names and their respective passwords be defined in the security store. That goes beyond the scope of exploring JMS, and will be discussed in the configuration guide. There, you will learn about the simple authentication plugin (so you can specify credentials directly in the configuration file), and how to access and set up the Java Authentication and Authorization Service (JAAS) authentication plugin for a more powerful and customizable solution.

The password parameter requires implementation of security. For these samples, that would require all the user names and their respective passwords be defined in the security store. That goes beyond the scope of exploring JMS, and will be discussed in the configuration guide. There, you will learn about the simple authentication plugin (so you can specify credentials directly in the configuration file), and how to access and set up the Java Authentication and Authorization Service (JAAS) authentication plugin for a more powerful and customizable solution.

Changing destination names

The queue and topic names used in the sample are arbitrary and can be created dynamically. Some TopicPubSub application applications let you specify the publish topic and the subscribe topic as parameters. For wildcard, the HierarchicalChat exposes the topic to which the application publishes as the -t parameter, and the topic to which it subscribes as the -s parameter. You could change these topics to demonstrate a FUSE Message Broker feature by extending the publish topic to a fourth level, and changing the wildcard on the subscriber topic from * to >. That expands the wildcard from all topics at the current hierarchical level to all topics at that level or deeper.

<target name="wildcard">
          <java classname="HierarchicalChat" fork="true">
          ...
          <arg value="-u"/>
          <arg value="HierarchicalChatter"/>
          </java>
          </target>

Other topic and queues could be changed in the build file so you can observe how they interact with other sample applications. For the MessageMonitor application, change its depth of topic hierarchies in its properties file, MessageMonitor.properties, to subscriptionTopics jms.samples.>

Changing the queue round trips

The QueueRoundTrip application is set in the build file to iterate 10,000 times through sending a message to a queue, receiving it off the queue, and taking that as the cue to send another message. You can change that number to a larger or smaller value to see start and stop operations are impactful. Try 1000 (one thousand), save the build file, and run ant roundtrip. Try 100000 (one hundred thousand), save the build file, and run ant roundtrip. For example:

<target name="chat1">
          <java classname="QueueRoundTrip" ...>
          ...
          <arg value="-n"/>
          <arg value="1000"/>
          </java>
          </target>

Distributing the client and the broker

At this point in exploring JMS, the broker used by the samples is always on the computer where the sample applications run. While you might use a local or an embedded broker, JMS messaging is designed so that the sample applications can run on a computer that has the appropriate libraries, yet can connect to a broker on a different system to produce and consume messages. The standalone broker system would typically by in a location where it can be monitored and provided resources that ensure optimal availability to any applications that use it.

The sample applications provide a -b parameter to specify the protocol, host, and port of the preferred broker. As the default broker configuration specifies the TCP protocol on localhost, listening on port 61616, you can use another installation of the Java, FUSE Message Broker, Ant, and the Exploring JMS files (as described in the previous chapter) on another computer to experience distributed connection. On one host set up and start the broker. On the other host (the remote host), do the same.

Stop the broker on the remote host, then modify the build.xml file on the remote host to specify add the connection parameter and specify the host name where the broker is running. For example:

<target name="chat1">
          <java classname="Chat" ...>
          ...
          <arg value="-u"/>
          <arg value="Fred"/>
          <arg value="-b"/>
          <arg value="tcp://remoteHostName:61616"/>
          </java>
          </target>

Save the build file and then run chat1 in a sample window on each of the computers. When you enter messages in either Chatter_1 window, the subscribers both get the message from the same broker.