1

Java Message Service

Манин П. 5087

2

Enterprise messaging• 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 Ambrosia and 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.

6

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

interfaces and classes needed by messaging clients when communicating with messaging systems.

• Using JMS, a messaging application's messaging clients are portable across MOM products.

Two types of messaging models provided by JMS:

1. publish-and-subscribe (Pub/Sub),

2. point-topoint queuing (P2P).

8

JMS Messaging Models

9

Publish-and-Subscribe

• One producer can send a message to many consumers through a virtual channel called 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 without them having to request

• The producer sending the message is not dependent on the consumers receiving the message.

• Durable subscriptions that allow consumers to disconnect and later reconnect and collect messages that were published while they were disconnected

10

Pub/Sub Types

Topic Topic

Subscriber has selectorBroadcast

11

Point-to-Point

• JMS clients can send and receive messages by virtual channels known as queues.

• Pull- or polling-based model, where messages are 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 each message.

• The JMS specification does not dictate the rules for distributing messages among multiple receivers

• Offers a queue browser that allows a client to view the contents of a queue prior to consuming its messages

12

P2P P2P

PullPush

P2P Types

Active

13

Guaranteed Messaging1. Message autonomy• Messages are self-contained autonomous entities.• A message may be sent and resent many times across multiple

processes throughout its lifetime. • Each JMS client along the way will consume the message,

examine it, execute business logic, modify it, or create new messages in order to accomplish the task at hand.

• When a JMS client sends a message, it has done its job. The messaging 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 is established between the client runtime portion of the JMS provider and the server.

• Servers acknowledge the receipt of messages from JMS producers and JMS consumers acknowledge the receipt of messages from servers.

• The acknowledgment protocol allows the JMS provider to monitor the progress of a message so that it knows whether the message 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 the message server that ensures the message will be delivered as far as the server.

• The server has a contract with the consumer that ensures the message will be delivered to it.

• The two operations are separate, which is a key benefit of asynchronous messaging.

• It is the role of the 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

OpportunitiesIn 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 ApplicationBefore 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 ApplicationExample 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