Introduction to the Java Messaging Service
People are sending messages to each other via e-mail and applications can send messages to each other using Message-Oriented-Middleware (MOM). One of the major advantages of MOM is that it provides asynchronous communication between the applications. It's somewhat similar to e-mail operations - you don't have to be online when someone sends you a message - you can read it later.

JMS is the standard API to work with MOM. JMS does not transport messages. JMS-to-MOM is the same as JDBC-to-a-database management system. Java applications could use the same JMS classes with any MOM vendor.

Two Modes of Message Delivery
A program could either send a message to the queue or publish a message to the topic. The first scenario is called Point-to-Point (P2P) messaging. In this mode a message is deleted from the queue as soon as it is successfully received. The second scenario is called Publish/Subscribe (Pub/Sub) messaging. With Pub/Sub many recipients can get the same message as long as they stay subscribed to it.

Here we'll use the Pub/Sub mode for publishing the stock quotes. Do we need to persist our messages so the subscribers who are not online at the moment can eventually get them? Apparently not, since it does not make sense to store the price of MSFT as of 11:53:59a.m. and show it an hour later when the subscriber decides to go online. So our subscribers (and topics) will be non-durable. Do we need to guarantee the successful delivery of each and every quote, given their frequency? Again, the answer is, most likely, no. So our publishing will not be transacted.

JMS Classes and Terms
Below are the names and a short description of the relevant JMS classes:

• TopicPublisher: An object that publishes messages to topics
• TopicSubscriber: An object that receives messages
• Topic: An object used to store messages in the Pub/Sub mode
• TopicPublisher: An object that publishes messages to a topic
• Message: An wrapper object that contains some data; it can be put in a queue or published to a topic

In a typical scenario, properties - name/value pairs - can be used as a "mark" to filter messages by business purpose. Accordingly, body is best suited to deliver the content. JMS offers the following message types:

• TextMessage: This could be any Java String (any text, CVS, XML, etc.)
• ObjectMessage: This could be any serializable Java object
• BytesMessage: An array of bytes
• StreamMessage: A stream of Java primitives for sequential reading
• MapMessage: Any key/value pair, for example, id=123
• Message: A message that contains the header and maybe properties, but no body

How to Publish a Message
Programs publish messages to topics. For a given topic, multiple subscribers can get messages published in a "one-to-many" mode (as opposed to "one-to-someone" mode for a queue).

The snippet of code in Listing 7 illustrates the steps that will be included in our TickerFeed Java program: look up the topic factory, create the topic connection, session, and publisher and, finally, publish a serialized object:

How to Subscribe for a Topic
In our scenario, the Java TickerFeed program will do the publishing and the Flex application, via the mx:Consumer tag, will act as the subscriber. The code in the section, therefore, is purely educational. And yet, you may find it useful, particularly to unit-test your publisher without leaving the confines of the Java side of the wire.

Subscribers can be durable and non-durable. A durable topic subscriber gets all of the messages sent to a destination, including those sent while the consumer is inactive. A non-durable message consumer gets messages from its chosen destination only if the messages are available while the consumer is active. This mode is similar to the way the chat rooms operate - you must be online to get the messages. Please be aware that you cannot possibly create a durable subscriber on the non-durable transport. In the case of Flex, you'd have to declare your messaging destination (more on that later in this chapter) as durable.

The code snippet in Listing 8 creates a non-durable subscriber.

Now that we've touched on the subject of JMS, let's look at the integration of JMS and native Flex messaging.

Integrating Flex and Java Messaging Services
Flex provides a Messaging Service of its own, which enables messaging between many clients via a Flex server component. Unlike JMS, Flex Messaging Services are not simply an API, but a full implementation as well. Flex Messaging Services in and of itself are completely sufficient to establish messaging between clients in your enterprise application. Flex Messaging integrates with external messaging via an adapter architecture. In particular, Flex provides a specific adapter class for JMS. This adapter acts as a middleman between the two messaging components, translating message flows from the Java destinations to Flex ones and vice versa.

An important point here is that Flex and Java have separate message destinations. The mapping between the Flex destinations and external messaging destinations has to be configured in the XML configuration file (under the default configuration scenario - WEB-INF/flex/messaging-config.xml). Figure 2 shows an integration between Flex and Java Messaging using a JMS adapter.

Flex clients can connect to servers using different transport protocols: the Real-Time Messaging Protocol (RTMP) and the Action Message Format (AMF) that runs over HTTP (you'd need polling in the latter case). When you configure a destination in the messaging-config.xml, you can specify more than one channel and Flex will try to access the destination using the protocols in the order specified. We'd like to emphasize that Flex clients just need to know the names of the FDS destinations. They are decoupled from MOM servers and JMS names. All features of the Flex messaging are described in the Flex manual called the Flex Developer's Guide. Now we'll get back to our stock portfolio application, but this time we'll make it JMS-enabled.