Developing applications using the JMS APIs is a straightforward process. The APIs facilitate the creation of objects that mitigate the interface between client applications and the message broker. Once connected to a broker, clients can create, send, and receive messages.
A JMS broker provides connectivity, message storage, and message delivery functions to its clients. It also provides quality of service features, such as reliability, persistence, security, and availability. A simple broker application typically consist of these basic interfaces and classes:
Connection factory[1]
Clients use a connection factory to create connections to a broker instance. You can optimize some messaging characteristics by enabling, disabling, or otherwise modifying the values of certain connection factory properties.
Connection
Connections are the technique clients use to specify a transport protocol and credentials for sustained interaction with a broker.
Session
Defined by a client on a connection established with a broker, a session defines whether its messages will be transacted and the acknowledgement mode when they are not. Clients can create multiple sessions on a single connection.
Destinations
Defined by a client in a session, a destination is either a queue or a topic. The broker maintains destinations.
Producer
Producers are client applications that create and send messages to a broker. They use the broker's
MessageProducerinterface to send messages to a destination. The default destination for a producer is set when the producer is created.The
MessageProducerinterface provides methods not only for sending messages, but also for setting various message headers (see Message headers and properties), which enable you to control many message aspects, such as persistence, delivery priority, life span, and so on.Consumer
Consumers are client applications that process messages retrieved from a broker. They use the broker's
MessageConsumerinterface to receive messages from a destination.The
MessageConsumerinterface can consume messages synchronously or asynchronously. Receiving messages asynchronously frees the consumer from having to repeatedly poll the destination for messages.Messages
Messages are the backbone of a messaging system. They are objects that contain not only the data payload, but also the required header and optional properties needed to transfer them from one client application to another. (See, JMS Message Basics.)
Figure 4 shows the typical sequence of events involved in sending or receiving messages in a simple broker client application.
This procedure shows how to implement the sequence of events shown in Figure 4:
Get a connection factory by looking one up by name in the JNDI.
ConnectionFactory=(ConnectionFactory)ctx.lookup("ConnectionFactoryName");Create a connection.
connection=connectionFactory.createConnection();Start the connection.
connection.start();Create the session.
session=connection.createSession(false, Session.AUTO_ACKNOWLEDGE);Create the destination (in this case a queue called foo.).
destination=session.createQueue("FOO.QUEUE");Do Step 6.a to create a producer, or do Step 6.b to create a consumer.
Create a text message.
message=session.createTextMessage("This is a foo test.");Do Step 8.a to have the producer send a message, or do Step 8.b to have the consumer receive 1000 iterations of the producer's message and print out an enumerated listing.
Close all JMS resources.
[1] Connection factories and destinations are preconfigured JMS objects, known as administered objects. They contain provider-specific configuration data for clients' use. Clients typically access administered objects through the Java Naming and Directory Interface (JNDI).
 |  |  |
 |
