Enterprise Flex and Java RIA with Clear Toolkit Framework

Clear Toolkit Magazine

Subscribe to Clear Toolkit Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Clear Toolkit Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Clear Toolkit Authors: Yakov Fain, Victor Rasputnis, Anatole Tartakovsky, Shashank Tiwari

Related Topics: Apache Web Server Journal, XML Magazine, Java Developer Magazine, Clear Toolkit Magazine

Apache Web Server: Article

A Complete Application with RPC Communications...

... between Flex and Java

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
Types of Messages
Every message created by the JMS provider contains a header, a body (aka payload), and properties. The header contains standard message identification such as message ID, destination, etc. Properties and body are optional.

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
When you're configuring Flex messaging destinations specific to JMS, keep in mind that at the time of writting, Flex only supported TextMessage and ObjectMessage types.

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.

More Stories By Victor Rasputnis

Dr. Victor Rasputnis is a Managing Principal of Farata Systems. He's responsible for providing architectural design, implementation management and mentoring to companies migrating to XML Internet technologies. He holds a PhD in computer science from the Moscow Institute of Robotics. You can reach him at [email protected]

More Stories By Yakov Fain

Yakov Fain is a Java Champion and a co-founder of the IT consultancy Farata Systems and the product company SuranceBay. He wrote a thousand blogs (http://yakovfain.com) and several books about software development. Yakov authored and co-authored such books as "Angular 2 Development with TypeScript", "Java 24-Hour Trainer", and "Enterprise Web Development". His Twitter tag is @yfain

More Stories By Anatole Tartakovsky

Anatole Tartakovsky is a Managing Principal of Farata Systems. He's responsible for creation of frameworks and reusable components. Anatole authored number of books and articles on AJAX, XML, Internet and client-server technologies. He holds an MS in mathematics. You can reach him at [email protected]

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.