Configuring Flex Messaging Destination
Let's start by configuring the topic on the Flex side. We will modify the file messaging-config.xml in /WEB-INF/flex, and create the destination for the "ticker-topic-jms" as in Listing 9. Please note the difference between the destination ID "ticker-topic-jms," which will be used by the Flex client, and the jndi-name "ticker," which the Flex JMS adapter will use for look up in the JNDI tree. The middleman subscriber created by the Flex JMS adapter won't be durable; it's okay to lose the quote if you aren't online.

Note the channel tags. The RTMP channel is listed first, and the AMF polling is the second option. This means the following: try the push first, but if it doesn't work (because of firewalls), start polling.

Configuring ActiveMQ JMS
There are different ways to start ActiveMQ. For purposes of this chapter it's convenient to start ActiveMQ with the same process that's running the Tomcat when the Web application starts. Accordingly, we use a Web application context listener and start the ActiveMQ broker from the contextInitialized() method:

public void contextInitialized(ServletContextEvent arg0) {
     try{
       broker.addConnector("tcp://localhost:61616?trace=true");
       broker.start();
     }catch(Exception e){
       e.printStackTrace();
       throw new RuntimeException(e);
     }
   }

Naturally, we have to guarantee the availability of the ActiveMQ classes on the Web application class path. To that end we dropped activemq-4.0-M4.jar into the common/lib folder off the Tomcat root. Listing 10 is the application listener.

To register the listener with the Web application we modify the web.xml file and add the following XML snippet (according to the DTD it should go right after the filter mappings. If your app does not have a filter, the placement is right after the application context parameters):

<listener>
     <listener-class>com.theriabook.jms.ActiveMQBrokerListener</listener-class>
</listener>

Writing the TickerFeed Java Program
In our data feeding program the quotes will be published to a JMS topic, but we are still going to reuse the class Porfolio.java, which we used to pull quotes via the RemoteObject. When it comes to sending the message, we will be putting the return of the Portofolio getQuotes() method into the serializable QuotesHolder:

      Portfolio port = new Portfolio();
      . . . .
      StockQuoteDTO[] quotes = port.getQuotes();
      QuotesHolder holder = new QuotesHolder();

The listing for the QuotesHolder class is below:

package com.theriabook.jms;
import java.io.Serializable;
import com.theriabook.jms.dto.StockQuoteDTO;

public class QuotesHolder implements Serializable{
     private static final long serialVersionUID = -8823588238987890758L;
     public StockQuoteDTO[] quotes;
}

To avoid hard-coding the JNDI properties in the TickerFeed program, we will make sure that the file jndi.properties as shown in Listing 11 belongs to the application classpath.

Now we're ready to complete our TickerFeed.java program. It continuously publishes the QuotesHolder objects to the JMS topic called "ticker." On your console you should see output similar to this one:

Publishing quotes...
Publishing quotes...

The complete code for TickerFeed.java is in Listing 12. 

Modifying the Flex Client to Consume Messages
The final part is to make changes to the Flex client. We will use the last version of PortfolioView from the remoting series and make the following modifications.

First, we will replace the <mx:RemoteObject> tag with the following <mx:Consumer> tag:

<mx:Consumer id="consumer" destination="ticker-topic-jms" message="applyQuotes(event.message.body.quotes)" />

This is an example of decoupling the application components. If you need to change the MOM provider, or you decide to use message queues instead of topics, no code modification is needed. Just change the destination parameter and you're set.

The second change is to actually start consuming messages. The modified startQuotes will look as follows:

private function startQuotes():void{
     consumer.subscribe();
}

The third and last change is in the processFault method, due to the differences in mx.messaging.events.ChannelFaultEvent instead of mx.rpc.events.FaultEvent:

   private function processFault(evt:ChannelFaultEvent):void{
       errorText = "Server Error";
       errorTip = evt.faultDetail;
       startQuotes();
     }

In all other respects the JMS code specific to the PortfolioView is the same as in its remoting counterpart (see Listing 13).

Summary
In this excerpt we went through different ways of establishing RPC communications between Flex and Java. In particular, we've been using RemoteObject, HTTPService, and Flex JMS adapters to establish communications.