Java Message Service

1. Java Message Service Манин П. 5087

2. Enterprisemessaging • Key concept: 1. Messages are delivered asynchronously 2. Sender is not required to wait for the message to be received by the recipient • Not a new concept (IBM MQSeries,Microsoft MSMQ, TIBCO Rendevous, • Open Horizon Ambrosiaand Modulus InterAgentProgress SonicMQ, • Softwired iBus and FioranoMQ)

3. Remote Method Invocation

4. Synchronous and asynchronous messaging Synchronous • Synchronous remote queues are queues that can only be accessed when connected to a network that has a communications path to the owning queue manager (or next hop). • If the network is not established then the operations such as put, get, and browse cause an exception to be raised. • It is the application's responsibility to handle any errors or retries when sending or receiving messages as, Message queue is no longer responsible for once-only assured delivery.

5. Asynchronous • Asynchronous remote queues are queues that move messages to remote queues but cannot remotely retrieve messages. • When message are put to the remote queue, the messages are temporarily stored locally. • When there is network connectivity, transmission has been triggered and rules allow, an attempt is made to move the messages to the target queue.

7. Java Message Service • The Java Message Service (JMS) is an API for enterprise messaging created by Sun Microsystems. • JMS is not a messaging system itself; it's an abstraction of the interfacesand classes needed by messaging clients when communicating with messaging systems. • Using JMS, a messagingapplication's messaging clients are portable across MOM products. Two types of messaging models provided by JMS: 1. publish-and-subscribe (Pub/Sub), 2. point-topointqueuing (P2P).

8. JMS Messaging Models

9. Publish-and-Subscribe • One producer can send a message to many consumers through a virtual channelcalled a topic • Consumers, which receive messages, can choose to subscribe to a topic. • Any messages addressed to a topic are delivered to all the topic's consumers. • messages are automatically broadcast to consumers withoutthem having to request • The producer sending the message is not dependent on theconsumers receiving the message. • Durable subscriptions that allow consumers to disconnect and later reconnect and collectmessages that were published while they were disconnected

10. Pub/Sub Types Broadcast Subscriber has selector Topic Topic

11. Point-to-Point • JMS clients can send and receive messages by virtual channels known as queues. • Pull- or polling-based model, where messagesare requested from the queue instead of being pushed to the client automatically. • A given queue may have multiple receivers, but only one receiver may consume eachmessage. • The JMS specification does not dictate the rules for distributing messagesamong multiple receivers • Offers a queue browser thatallows a client to view the contents of a queue prior to consuming its messages

12. P2P Types Push Pull Active P2P P2P

13. Guaranteed Messaging 1. Message autonomy • Messages are self-contained autonomous entities. • A message may be sent andresent many times across multiple processes throughout its lifetime. • Each JMS client alongthe way will consume the message, examine it, execute business logic, modify it, or createnew messages in order to accomplish the task at hand. • When a JMS client sends a message, it has done its job. Themessaging server guarantees that any other interested parties will receive the messages.

14. 2. Message Acknowledgments and Failure Conditions • JMS specifies a number of acknowledgment modes. These acknowledgments are a keypart of guaranteed messaging. • A message acknowledgment is part of the protocol that isestablished between the client runtime portion of the JMS provider and the server. • Serversacknowledge the receipt of messages from JMS producers and JMS consumersacknowledge the receipt of messages from servers. • The acknowledgment protocol allowsthe JMS provider to monitor the progress of a message so that it knows whether themessage was successfully produced and consumed.

15. Message Persistence 1 As per the "Message Delivery Mode" section of the JMS Specification, messages can be specified as persistent or non-persistent: • A persistent message is guaranteed to be delivered . The message cannot be lost due to a JMS provider failure, but it must not be delivered twice. It is not considered sent until it has been safely written to a file or database. • Non-persistent messages are not stored. They are guaranteed to be delivered at-most-once, unless there is a JMS provider failure, in which case messages may be lost, and must not be delivered twice.

16. Message Persistence 2

17. Message Persistence 3

18. Transacted Messages • The producer has a contract with themessage server that ensures the message will be delivered as far as the server. • The serverhas a contract with the consumer that ensures the message will be delivered to it. • The twooperations are separate, which is a key benefit of asynchronous messaging. • It is the role ofthe JMS provider to ensure that messages get to where they are supposed to go.

19. Transacted consumer Transacted producer

20. Redelivery

21. WebLogic JMS Features • WebLogic JMS provides numerous WebLogic JMS Extension APIs that go above and beyond the standard JMS APIs specified by the JMS Specification. Major Components • WebLogic JMS servers • Client applications • JNDI (Java Naming and Directory Interface), which provides a server lookup facility • Persistent storage (disk-based file or JDBC-accessible database) for storing persistent message data

22. WebLogic JMS Classes • To create a JMS applications, use the javax.jms API. • The API allows you to create the class objects necessary to connect to the JMS, and send and receive messages. • JMS class interfaces are created as subclasses to provide queue- and topic-specific versions of the common parent classes. • The following table lists the JMS classes described in more detail in subsequent sections.

23. Developing a WebLogic JMS Application • WebLogic JMS Application Development Flow—Required Steps

24. Opportunities In addition to the application development steps defined in the previous figure, you can also optionally perform any of the following steps during your design development: • Manage connection and session processing • Create destinations dynamically • Create durable subscriptions • Manage message processing by setting and browsing message header and property fields, filtering messages, and/or processing messages concurrently • Use multicasting • Use JMS within transactions (described in Using Transactions with WebLogic JMS)

25. Setting Up a JMS Application Before you can send and receive messages, you must set up a JMS application. The following figure illustrates the steps required to set up a JMS application.

26. Example: Setting Up a Pub/Sub App. Define the required variables, including the JNDI context, JMS connection factory, and topic static variables. public final static String JNDI_FACTORY= "weblogic.jndi.WLInitialContextFactory"; public final static String JMS_FACTORY= "weblogic.examples.jms.TopicConnectionFactory"; public final static String TOPIC="weblogic.examples.jms.exampleTopic"; protected TopicConnectionFactory tconFactory; protected TopicConnection tcon; protected TopicSession tsession; protected TopicPublisher tpublisher; protected Topic topic; protected TextMessage msg;

27. Set up the JNDI initial context, as follows: InitialContext ic = getInitialContext(args[0]); . . . private static InitialContext getInitialContext( String url ) throws NamingException { Properities env = new Properities(); env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY); env.put(Context.PROVIDER_URL, url); return new InitialContext(env); {

28. Step 1 Look up a connection factory using JNDI. tconFactory = (TopicConnectionFactory) ctx.lookup(JMS_FACTORY); Step 2 Create a connection using the connection factory. tcon = tconFactory.createTopicConnection(); Step 3 Create a session using the connection. The following defines the session as non-transacted and specifies that messages will be acknowledged automatically. For more information about setting session transaction and acknowledge modes, see Session Object. tsession = tcon.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);

29. Step 4 Look up the destination (topic) using JNDI. topic = (Topic) ctx.lookup(topicName); Step 5 Create a reference to a message producer (topic publisher) using the session and destination (topic). tpublisher = tsession.createPublisher(topic); Step 6 Create the message object. msg = tsession.createTextMessage(); Step 7 Start the connection. tcon.start(); }

30. Sending Messages Within a Pub/Sub Application Example shows the code required to create a TextMessage, set the text of the message, and send the message to a topic. msg = tsession.createTextMessage(); . . public void send( String message ) throws JMSException { msg.setText(message); tpublisher.publish(msg); } tsubscriber = tsession.createSubscriber(topic); Message msg = tsubscriber.receive(); msg.acknowledge(); The first line creates the topic subscriber on the topic. The second line executes a receive() method. The receive() method blocks and waits for a message. Receiving Messages Synchronously Within a Pub/Sub Application