Hello, dear friends. In this video, we will continue examining JMS with API components. Let's begin. In the previous video, we learned there are seven components in the API. Now we will examine them one by one. Let's start with the connection factory. Connection factories are administered objects that allow an application to connect to a provider by creating a connection object programmatically. A javax.jms.ConnectionFactory is an interface that encapsulates the configuration parameters that have been defined by an administrator. To use an administered object such as a connection factory, the client needs to perform a JNDI lookup or use an injection. Now, you can continue with Eclipse if you wish. However, for the JMS topic, I'd like to use code snippets to demonstrate the use of key components. At the end of the JMS topic, we will create an example project that includes all of these components. So, let's take a look at this code snippet.

This code snippet illustrates the usage of the connection factory. For example, this code fragment obtains the JNDI initial context object and uses it to lookup a connection factory by its JNDI name. First, we have to define a context from the initial context. After that, we can define the connection factory from the context using the lookup method of the context. The connection factory is an interface that has many methods. This code shows us the connection factories methods as you can see in the connection factory, we have two create connection methods that return connection objects and four create context methods that return JMSContext. You can create a connection or a JMSContext, either with a default user identity or by specifying a username and password. I think that's enough for the connection factory. Let's continue with the destination. A destination is an administered object that contains provider-specific configuration information such as the destination address.

But this configuration is hidden from the JMS client by using the standard javax.jms.Destination interface. Like the connection factory, a JNDI is needed to return such objects. This is how destination is used. As I previously stated, we will use all of these components in the JMS Project. Let's go to components with the connection. The javax.jms.ConnectionObject which you create using the create connection method of the connection factory encapsulates a connection to the JMSProvider. Connections are thread-safe and designed to be shareable as opening a new connection exhausts the resource. However, a session provides a single threaded context for sending and receiving messages using a connection to create one or more sessions. Once you have a connection factory, you can use it to create a connection like this. First, you have to define the connection from the factory before a receiver can consume messages. It must call the start() method. If you need to stop receiving messages temporarily without closing the connection, you can call the stop() method. When the application completes, you need to close any connections created.

Closing a connection also closes its sessions and its producers or consumers. With a connection close method, you can close the connection. I think your understanding of connection is now better. Let's continue with session. You create a session from the connection using the createSession() method. A session provides a transactional context in which a set of messages to be sent or received are grouped in an atomic unit of work, meaning that if you send several messages during the same session, JMS will ensure that either all of them are sent or none are. This behavior is set at the creation of the session. The first parameter of the method specifies whether or not the session is transactional. In the code, the parameter is set to true, meaning that the request for sending messages won't be realized until either the session's commit method is called or the session is closed. If the parameter was set to false, the session would not be transactional and messages would be sent as soon as the send method was invoked.

The second parameter means that the session automatically acknowledges messages when they have been successfully received. A session is single threaded and is used to create messages, producers, and consumers. Let's move on to the messages. Messages are the core component of JMS. To communicate, clients exchange messages. One producer will send a message to a destination and a consumer will receive it. Messages are objects that encapsulate information and are divided into three parts: header, properties, and body. The header contains standard information for identifying and routing the message. Properties are name value pairs that the application can send or read. Properties also allow destinations to filter messages based on property values. The body contains the actual message and can take several formats like text, bytes, objects, etc. Let's examine these parts one by one. First, header. The header has predefined name value pairs that are common to all messages that both clients and providers use to identify and route messages.

They can be seen as message metadata as they give information about the message. Each field has associated getter and setter methods defined in the javax.jms.Message interface. Some header fields are intended to be set by the client, but many are set automatically by the send() or publish() method. This table describes each JMSMessage header field. As you can see, there are many header fields for JMS. Let's examine them. JMSDestination indicates the destination to which the message is being sent. The delivery mode for a JMSMessage is specified by the sender who instructs the server concerning persistent storage for the message. The JMSDeliveryMode message header field defines the delivery mode for the message. JMS supports two modes of message delivery. Persistent mode instructs the provider to ensure the message is not lost in transit due to a failure. Non-persistent mode is the lowest overhead delivery mode because it does not require the message to be logged to persistent storage. JMSMessageID provides a value that uniquely identifies each message sent by a provider. JMSTimestamp contains the time a message was handed off to a provider to be sent.

A client can use the JMSCorrelationID field to link one message with another, such as linking a response message with its request message. JMSReplyTo contains the destination where a reply to the message should be sent. JMSRedelivered is a Boolean value. This Boolean value is set by the provider to indicate whether a message has been redelivered. JMSType serves as a message type identifier. Let's look at JMSExpiration. When a message is sent, its expiration time is calculated and set based on the time to live value specified on the send method. the last one is JMSPriority. JMS defines a 10-level priority value with zero as the lowest priority and nine as the highest. I think that's enough for the header. Let's continue with properties. In addition to the header fields, the javax.jms.Message interface supports property values, which are just like headers but explicitly created by the application instead of being standard across messages. This provides a mechanism for adding optional header fields to a message that a client will choose to receive or not via selectors.

Property values can be Boolean, byte, short, int, long, float, double, and string. For example, for float, you have to use the setFloat() or getFloat() methods like this. Now, the last part of the message is the body. The body of a message is optional and contains the data to send or receive. Depending on the interface that you use, it can contain different formats of data like StreamMessage, MapMessage, TextMessage, ObjectMessage, and BytesMessage. StreamMessage is a message whose body contains a stream of Java primitive values. It is filled and read sequentially. MapMessage is a message whose body contains a set of name value pairs, where names are strings and values are Java primitive types. TextMessage is a message whose body contains a string like XML. ObjectMessage contains a serializable object or a collection of serializable objects . BytesMessage contains a stream of bytes.

It is possible to create your own message format if you extend the javax.jms.Message interface. When a message is received, its body is read only depending on the message type. You have different methods to access its content. A TextMessage will have a getText() and setText() method and an ObjectMessage will have a getObject() and setObject() method. Since JMS 2.0, the new method T, getBody() returns the message body as an object of the specified type. That's enough. In the next video, we will start to send and receive. See you in the next video.