Introduction to JMS and Message-Driven POJOs

10,843 views

Published on

Published in: Technology
0 Comments
19 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
10,843
On SlideShare
0
From Embeds
0
Number of Embeds
51
Actions
Shares
0
Downloads
0
Comments
0
Likes
19
Embeds 0
No embeds

No notes for slide


  • So before we get into the details of JMS, let’s take a bird’s eye view of the landscape. What is messaging all about, and why would we want to use it? Any ideas?
  • So here’s the most basic look at a messaging architecture. You have a component that sends messages, which are sent to some type of message channel. This message channel is charged with routing the messages to other components that receive and process messages. So you have multiple components, maybe even multiple systems. They are decoupled - the sender does not know the details of the receiver, nor does the receiver know the details of the sender. What are some use cases for an architecture like this?

    Asynchronous processing, remoting, SOA, interoperability, integration....how about increasing user productivity? Tell the story about the guy who sends off a request and the goes to get his coffee, gets distracted, finally comes back vs. the guy who can send off a request, knows he’ll get a notification when it’s done, and continues working.
  • So we’ll start off with point-to-point (or p2p) models. This first examples is what we’ll call Fire and Forget. You send to a queue and move on with your day. A receiver picks up the message from the queue, processes it, and moves on with its day. With p2p you have on and only one receiver per message. You may have multiple receivers load balanced, but only one component can receive each message. The second model is what we’ll call request/reply or “Pseudosynchronous.” Here the sender blocks and waits for a response from the receiver. Finally we have the publish and subscribe or pub/sub model. Here you publish or “broadcast” to not a queue, but a topic. Multiple subscribers can “listen” to this topic, and all will get a copy of each message.
  • So we’ll start off with point-to-point (or p2p) models. This first examples is what we’ll call Fire and Forget. You send to a queue and move on with your day. A receiver picks up the message from the queue, processes it, and moves on with its day. With p2p you have on and only one receiver per message. You may have multiple receivers load balanced, but only one component can receive each message. The second model is what we’ll call request/reply or “Pseudosynchronous.” Here the sender blocks and waits for a response from the receiver. Finally we have the publish and subscribe or pub/sub model. Here you publish or “broadcast” to not a queue, but a topic. Multiple subscribers can “listen” to this topic, and all will get a copy of each message.
  • So we’ll start off with point-to-point (or p2p) models. This first examples is what we’ll call Fire and Forget. You send to a queue and move on with your day. A receiver picks up the message from the queue, processes it, and moves on with its day. With p2p you have on and only one receiver per message. You may have multiple receivers load balanced, but only one component can receive each message. The second model is what we’ll call request/reply or “Pseudosynchronous.” Here the sender blocks and waits for a response from the receiver. Finally we have the publish and subscribe or pub/sub model. Here you publish or “broadcast” to not a queue, but a topic. Multiple subscribers can “listen” to this topic, and all will get a copy of each message.
  • So basically you have two parts, the header and the payload. JMS distinguishes within the header between what it calls the “Header” which includes all of the standard JMS properties, and the “Properties” which includes application and/or provider-specific extension properties, as well as JMS extensions (otherwise known as JMSX properties), which may or may not be supported by all JMS providers. Finally you have the payload or “Message Body,” which distinguished what type of JMS message we’re talking about and the possible payloads it may carry.
  • So just as we have many different colors of mailboxes here, there are many different types or “colors” of JMS messages out there.

  • This is super cool, huh? Well, what’s wrong with this? One of the goals of messaging is decoupling of the sender and receiver. Well, in this case both Sender and Receiver must be aware of TradeData. So we end up with a tightly coupled architecture, we have versioning issues (i.e. if TradeData changes, we have to update multiple systems), and it forces heterogeneity of systems (i.e. I can’t have a non-Java consumer). UC - same machine, interservice communication.

  • This can be useful for transfer of data between two applications in their native format which may not be compatible with other Message types. It’s also useful where JMS is used purely as a transport between two systems and the message payload is opaque to the JMS client. There is no type information encoded into the message - for example, it is possible for the sender to encode a long and the sender to read a short, resulting in semantically incorrect interpretation - it is purely up to the receiver to properly interpret the message.
  • The alternative is the StreamMessage. This type maintains a boundary between the different data types stored, storing the data type information along with the value of the primitive. StreamMessages strictly prohibit reading incorrect types from the data stream.
  • In fact, here are the type conversions that are supported by the StreamMessage. As you can see, just like in regular Java code, you can read to a bigger type but not to a smaller type (with the exception of String, which can be read to any of the supported types).
  • So a couple of weekends ago I attended the NFJS symposium in St. Louis. While watching the presentations there, I gained a renewed appreciation for what properly placed images can do to enhance a talk. In fact, the use of Creative Commons licensed images came up several times. For this talk, all of the images are actually Creative Commons licensed, meaning in this case that all I have to do to use them legally is run the credits at the end of the talk. So, while searching for images for this slide, I actually entered “API” as my search criteria, thinking that nothing would come up. Imagine my surprise when I got this really cool photo of a sign. So, with that let’s examine the API...
  • So staring with JMS 1.1, the spec consolidated the various interfaces such that all interfaces descend from common generic types, shown here.
  • As you can see, there’s a one-to-one relationship between all of the interfaces here and the generic ones, with Message carrying over.

  • So this is probably how many of us feel when it comes to configuration. Thankfully, configuring JMS can be relatively simple depending on your provider.
  • For this talk we’ll be working with OpenJMS, which is great for development and testing, but is not production ready. In fact, it has been in beta for years!

    Go to TextMate and look at the openjms.xml file!



























  • Introduction to JMS and Message-Driven POJOs

    1. 1. Introduction to JMS and Message-Driven POJOs Matt Stine Memphis JUG March 19, 2009
    2. 2. Agenda Introduction to Messaging JMS Message Types The JMS API JMS Configuration Sending and Receiving Mesages Request/Reply Messaging Using Spring’s JMS Support Message-Driven POJOs with Spring
    3. 3. Introduction to Messaging Why use messaging?
    4. 4. Why use messaging? Message Message Message Sender Receiver Channel Component Component
    5. 5. Messaging Models
    6. 6. Messaging Models Point to Point Sender Queue Receiver
    7. 7. Messaging Models Point to Point Sender Sender Sender Queue Queue Receiver Receiver Receiver
    8. 8. Messaging Models Point to Point Publish and Subscribe Sender Sender Sender Subscriber Subscriber Queue Queue Topic Receiver Receiver Receiver Publisher
    9. 9. JMS Message Structure Header JMSDestination } JMSMessageID JMSTimestamp JMSCorrelationId Message JMSPriority Header Properties App-specific Properties JMS-extended (JMSX) Properties Provider-specific Properties } Message Body Text-based Payload Message Object-based Payload Map-based Payload Payload Bytes-based Payload Stream-based Payload
    10. 10. JMS Message Types
    11. 11. TextMessage Used for sending simple String text or XML Sender TextMessage message = session.createTextMessage(); StringBuffer text = new StringBuffer(); text.append("<priceRequest>"); text.append(" <symbol>AAPL</symbol>"); text.append("</priceRequest>"); message.setText(messageText.toString()); sender.send(message); Receiver TextMessage msg = (TextMessage)message; String xml = msg.getText();
    12. 12. ObjectMessage Used for sending a serialized Java object Sender ObjectMessage message = session.createObjectMessage(); TradeData trade = new TradeData(1, "BUY", "AAPL", 100); message.setObject(trade); sender.send(message); Receiver ObjectMessage msg = (ObjectMessage)message; TradeData trade = (TradeData)msg.getObject();
    13. 13. MapMessage Used for sending type-safe name-value pairs Sender MapMessage message = session.createMapMessage(); message.setString("side", "BUY"); message.setString("symbol", "AAPL"); message.setLong("shares", 100); sender.send(message); Receiver MapMessage msg = (MapMessage)message; String side = msg.getString("side"); String symbol = msg.getString("symbol"); long shares = msg.getLong("shares");
    14. 14. BytesMessage Used for sending a formatted series of primitive native-format bytes Sender BytesMessage message = session.createBytesMessage(); message.writeUTF("BUY"); message.writeUTF("AAPL"); message.writeInt(100); sender.send(message); Receiver BytesMessage msg = (BytesMessage)message; String side = msg.readUTF(); String symbol = msg.readUTF(); int shares = msg.readInt();
    15. 15. StreamMessage Used for sending a formatted series of bytes as Java primitive types Sender StreamMessage message = session.createStreamMessage(); message.writeString("BUY"); message.writeString("AAPL"); message.writeInt(100); sender.send(message); Receiver StreamMessage msg = (StreamMessage)message; String side = msg.readString(); String symbol = msg.readString(); long shares = msg.readLong();
    16. 16. StreamMessage Conversion Rules
    17. 17. The JMS API
    18. 18. Generic Interfaces Message Connection Message Connection Session Factory Producer Message Destination Consumer JMS Provider (JNDI)
    19. 19. Queue-based Interfaces Message Queue Queue Queue Queue Connection Connection Session Sender Factory Queue Queue Receiver JMS Provider (JNDI)
    20. 20. Topic-based Interfaces Message Topic Topic Topic Topic Connection Connection Session Publisher Factory Topic Topic Subscriber JMS Provider (JNDI)
    21. 21. JMS Configuration
    22. 22. Configuring a JMS Provider Open Source Project (http://openjms.sourceforge.net) Comes preconfigured with Derby, but can be used with any JDBC 2.0 compliant database Includes an embedded JNDI Provider (Spice) Configured using the openjms.xml configuration file
    23. 23. Sending and Receiving Messages Live Coding
    24. 24. Sending and Receiving Messages Connect to the JMS provider (OpenJMS) and obtain a connection to the message server Send a JMS TextMessage with XML containing a stock trade order Create an asynchronous message listener to receive the XML stock trade order
    25. 25. Request/Reply Messaging Live Coding
    26. 26. Request/Reply Messaging Modify the sender to block and wait for a return message Modify the asynchronous message listener to send a confirmation number for the trade
    27. 27. Using Spring’s JMS Support
    28. 28. Spring JMS Support
    29. 29. Spring JMS Support Simplifies use of JMS API
    30. 30. Spring JMS Support Simplifies use of JMS API Infrastructure in XML configuration
    31. 31. Spring JMS Support Simplifies use of JMS API Infrastructure in XML configuration JmsTemplate in code
    32. 32. Spring JMS Support Simplifies use of JMS API Infrastructure in XML configuration JmsTemplate in code Message production
    33. 33. Spring JMS Support Simplifies use of JMS API Infrastructure in XML configuration JmsTemplate in code Message production Synchronous nessage reception
    34. 34. Spring JMS Support Simplifies use of JMS API Infrastructure in XML configuration JmsTemplate in code Message production Synchronous nessage reception Let’s Code!!!
    35. 35. Message-Driven POJOs with Spring
    36. 36. Message-Driven POJOs with Spring
    37. 37. Message-Driven POJOs with Spring Enables asynchronous communication
    38. 38. Message-Driven POJOs with Spring Enables asynchronous communication Little or no coupling to JMS
    39. 39. Message-Driven POJOs with Spring Enables asynchronous communication Little or no coupling to JMS Three options:
    40. 40. Message-Driven POJOs with Spring Enables asynchronous communication Little or no coupling to JMS Three options: Implement javax.jms.MessageListener
    41. 41. Message-Driven POJOs with Spring Enables asynchronous communication Little or no coupling to JMS Three options: Implement javax.jms.MessageListener Implement Spring’s SessionAwareMessageListener
    42. 42. Message-Driven POJOs with Spring Enables asynchronous communication Little or no coupling to JMS Three options: Implement javax.jms.MessageListener Implement Spring’s SessionAwareMessageListener Configure via Spring’s MessageListenerAdapter
    43. 43. Message-Driven POJOs with Spring Enables asynchronous communication Little or no coupling to JMS Three options: Implement javax.jms.MessageListener Implement Spring’s SessionAwareMessageListener Configure via Spring’s MessageListenerAdapter Add to Spring-provided MessageListenerContainer
    44. 44. MDP Live Coding
    45. 45. MDP Live Coding Configure MessageListenerContainer
    46. 46. MDP Live Coding Configure MessageListenerContainer Implement MDP that receives a JMS message object using default handler method
    47. 47. MDP Live Coding Configure MessageListenerContainer Implement MDP that receives a JMS message object using default handler method Let’s Code!!!
    48. 48. MDP Live Coding Configure MessageListenerContainer Implement MDP that receives a JMS message object using default handler method Implement MDP with automatic message conversion Let’s Code!!!
    49. 49. MDP Live Coding Configure MessageListenerContainer Implement MDP that receives a JMS message object using default handler method Implement MDP with automatic message conversion Implement MDP with automatic message conversion and Let’s Code!!! custom handler method
    50. 50. Credits http://www.everystockphoto.com/photo.php?imageId=2743792 http://www.everystockphoto.com/photo.php?imageId=1218094 http://www.everystockphoto.com/photo.php?imageId=4463765 http://www.everystockphoto.com/photo.php?imageId=2106868 http://www.everystockphoto.com/photo.php?imageId=1310486 http://www.everystockphoto.com/photo.php?imageId=708018 http://www.everystockphoto.com/photo.php?imageId=3012910 Richards, Mark. Introduction to JMS Messaging. NFJS Gateway Software Symposium 2009 Richards, Mark. “Message Driven POJOs: Messaging Made Easy.” No Fluff Just Stuff, the Magazine. Jan-Mar 2009. http://www.allapplabs.com/interview_questions/jms_interview_questions.htm#q11

    ×